Random Thoughts – Randocity!

Careful what you say

Posted in botch, Employment, tips by commorancy on May 26, 2019

angryguy2This story is about a co-worker at a previous job. I won’t name any real names or the company or describe him in detail, but I will explain the situation, which is most important for this article. Let’s explore.

Flowery Explicit Language

I’ve worked at various Internet companies and occasionally I run into co-workers who choose to use flowery explicit language while at work. In most cases, that language is a form of expression, usually reserved for exasperating circumstances. You know, when something goes wrong and you might yell, “shit”.

Well, a particular co-worker, let’s call him ‘J’, used this language casually and at all times. I thought it a bit odd, because I’d never met someone who did it so often and so casually in a professional workplace, particularly as loudly as he did it.

Before I go any further, I’ll explain that J wasn’t a native English speaker. He also wasn’t American. I had personally attributed his tactlessness, loudness and language to his personal nature (read: upbringing). With that said, I’ve met many people of J’s nationality and many of this nationality worked at this particular company. By and large, most of the people I’ve met of his nationality were cool and collected. They didn’t use such language at all (or very, very rarely). However, J had a mouth on him like you might expect on, well let’s just say on someone “low class”. It was particularly surprising to hear this language from someone in his situation (no green card, needing sponsorship, here on a work visa) and position. His language was always a bit like “Throwing caution to the wind”, in other words, risky. I always felt that he should have been a bit more cautious considering his personal work circumstance and that the workplace staff didn’t often use this kind of language. It was an odd mix for J, but apparently he was set in his ways.

I even politely commented that he should reserve these colorful expressions to more appropriate times rather than using them all of the time. I even told him he should be careful when using these expressions around the office as it’s likely to get him into trouble… and so begins this story.

Reading Your Environment

I’ll take a brief detour before continuing on with my story. When you hire onto a workplace, you should always go into observation mode for at least a couple of weeks. This observation period allows you to “read” your environment and understand what is considered acceptable and what isn’t. You don’t come in with mouth ablazin’ shooting off all manner of colorful expressions. Instead, you learn to read the staff, the behaviors and the acceptability of that kind of expression.

Some businesses have managers who are very verbally expressive with expletives. Some businesses do not. Reading the environment is the only way to determine if such behavior is considered ‘normal’ at that place of business. In general, it’s not typically considered professional or acceptable language and you should always choose not to use colorful expressions at all. However, if you find your manager uses them at times, then it’s not off to use them yourself if you’re so inclined. Your manager probably won’t even care if he/she also uses expletives.

Unfortunately, certain employees don’t understand this concept of “reading your environment” when they begin new employment. J was one of these folks and remained completely oblivious. Let’s continue with this story…

Executive Bailout

Our company had had a particularly successful last 18 months. However, all good things must come to an end, and so it did. First, the CEO announces his departure. Then, a number of other executives also announce their departures. An interim CEO is named and he takes over as CEO immediately after the other CEO announces.

My team was led by an executive VP who, at the time, had been simply going through the motions for the last 12-18 months. At first, this executive was highly motivated, on-board, and extremely engaged with everything and everyone. By the last 18 months, he had more or less checked-out. He no longer kept up with the day-to-day operations, he didn’t really much care how the department operated (other than not wanting to see it melt down, of course) and he no longer took an interest in the team. He was simply disengaged and “going through the motions”. I saw it and so did everyone else. So, it wasn’t a surprise what happened next.

Mandatory Meeting

We were called, as a department, to a large open presenting space in the lobby of our company’s building. At the time, we had no idea as to the reason for this impromptu “all hands” meeting, but I had my suspicions as to what was coming as we had had many of these in the last few weeks. I didn’t make any snap judgements as we had also had some of these meetings that simply ended up new product announcements, rah-rah sessions or other random weird (and unnecessary) company “all hands” announcements.

As I showed up a bit early, I was able to get a seat. Unfortunately, not so with everyone who showed up later. In fact, by the time the presentation started, it was standing room only and many were standing around the entire perimeter of the room, including in front of the two main double doors. For an impromptu meeting, it was really the only large-ish space the company had and it was well overfilled.

Anyway, the room fell silent and the executive who was disengaged took the stage and began explaining that he would be departing. No surprise there. After a few rah-rah type statements from him to try and keep the team motivated, the interim CEO took the stage, announced this now-departing executive’s replacement and began well wishing and additional rah-rah messages.

After it is all over (about 15 minutes later), we exit the room and head back to our desks to continue with our day on that news. The meeting had convened early, around 9AM… so we had a full day of work ahead on that “exciting” news. On the way back to our desks, I spoke with J in the elevator. We had a quick conversation about this executive’s departure and he was, as usual, using his standard flowery expressions in the elevator. Since we all knew one another, nothing here was a surprise. I even had a few more conversations with J before the end of the day about meeting up tomorrow and at this week’s wine event. At this point, nothing seemed out of the ordinary (other than this latest executive’s departure news).

Surprising News

On the following day, I noticed that J was no where to be found. He wasn’t at his desk. I needed to talk to him about a project we had both been working on. Because my direct boss was also his boss, I asked my boss where he was. I was told he was no longer with the company. That was a surprise much more than the disengaged executive’s departure.

I was a little bit in shock. My boss offered no additional explanation other than he was no longer with the company. It was an abrupt change that I didn’t see coming… at least, not at that moment. Usually when staff are let go, there’s a process… typically involving a probationary period. I didn’t think that J was currently on any kind of probation or performance plan. Even though he did rub a lot of people the wrong way, it didn’t really much seem to affect his job. At least, the people in my department were tolerant of his behavior, and had grown accustomed to it. It was definitely a surprise at his departure.

In fact, my boss actually seemed surprised at the news when he told me. His voice and words implied to me that he had nothing to do with J’s departure. In other words, my boss’s tone and words told me he hadn’t fired J. Instead, something else had happened. This is where things get interesting…

The Full Story

We had a regularly scheduled after-hours wine event once every couple weeks where we could unwind, meet people from other departments, drink a little wine, snack and, of course, chat. This wine event was already scheduled a day or two after this disengaged executive departure announcement. This executive even attended briefly. In addition to consuming choice wines, obviously, we’d chat about whatever was on our minds (i.e., company gossip). As the wine took effect, so did the venting. Sometimes the conversation was about the office. Sometimes it was about world events. Today, we chatted about all of the departures, including J’s.

At this wine event, even though my boss had been extremely tight lipped, the beans were spilled as to exactly what happened with J by an attendee (not my boss). Here’s how the story went…

Let’s go back in time to the presentation…. As I was comfortably sitting in my seat awaiting the presentation to begin (probably working on my laptop), J was standing by the entry doors. He was apparently holding onto one of the door handles. The presentation starts and the disengaged executive begins his departure announcement.

At this point, someone opens the main entry doors where J is standing and holds the door open. Because there was some commotion outside in the echo-filled lobby preventing him from hearing the presentation, J, who gets irritated and triggered way too easily, chimes in and says, “Close the f*cking door, dumb*ss!” (or something very similar) rather loudly and without looking. He might have even said something more demeaning to the person, but this is what I had heard that he said.

Needless to say, the person holding the door open was none other than the brand spankin’ new interim CEO himself. At the time, the then CEO ignores the comment, enters the room, walks to the front and begins his speech. He finishes up and exits through the side door as if nothing happened.

Here’s where things get interesting. Immediately following the announcement, the CEO (and this is according to those at the wine event) walked over the HR to first identify J and then he requests J’s termination. J was gone the following day.

My boss told me none of this. Whether he knew the details, I have no idea. He wasn’t the one who told the story. This was from another person at this wine event who apparently had close ties to the HR person.

After speaking with J later, I had come to find J had no idea what went on or why he was fired. According to J, one day he was there, the next day he was gone. He doesn’t get it. Either he’s thick and can’t recall what he says or he’s feigning ignorance at what he did. I’ve spoken with J several times, even meeting at a restaurant for dinner, and he still doesn’t seem to get it. In fact, I’ve disclosed none of the details to him for fear he’d go do something stupid. He’s not only abrupt with his language, but he’s also a bit of a hothead with a temper. It’s also not really my place to tell him as I didn’t actually witness the event. I was sitting in my seat not watching the rest of the room. I’m getting this information from a third party. However, it does make perfect sense based on J’s personality.

The moral of this story is, if you’re at work, always use professional language at all times and …

Careful What You Say

If you’re thinking of using flowery explicit language (or you do already) at work, here’s an example where it can easily backfire. Everyone gets frustrated when things don’t go as planned. That’s to be expected.. and even a flowery phrase or two directed at the situation might even be expected, if not warranted. However, you should never direct flowery explicit expressions at anyone at your workplace, especially if you can’t see the person. You never know just whom you might have insulted.

↩︎

CanDo: An Amiga Programming Language

Posted in computers, history by commorancy on March 27, 2018

At one point in time, I owned a Commodore Amiga. This was back when I was in college. I first owned an Amiga 500, then later an Amiga 3000. I loved spending my time learning new things about the Amiga and I was particularly interested in programming it. While in college, I came across a programming language by the name of CanDo. Let’s explore.

HyperCard

Around the time that CanDo came to exist on the Amiga, Apple had already introduced HyperCard on the Mac. It was a ‘card’ based programming language. What that means is that each screen (i.e., card) had a set of objects such has fields for entering data, placement of visual images or animations, buttons and whatever other things you could jam onto that card. Behind each element on the card, you could attach written programming functions() and conditionals (if-then-else, do…while, etc). For example, if you had an animation on the screen, you could add a play button. If you click the play button, a function would be called to run the animation just above the button. You could even add buttons like pause, slow motion, fast forward and so on.

CanDo was an interpreted object oriented language written by a small software company named Inovatronics out of Dallas. I want to say it was released around 1989. Don’t let the fact that it was an interpreted language fool you. CanDo was fast for an interpreted language (by comparison, I’d say it was proportionally faster than the first version of Java), even on the then 68000 CPU series. The CanDo creators took the HyperCard idea, expanded it and created their own version on the Amiga. While it supported very similar ideas to HyperCard, it certainly wasn’t identical. In fact, it was a whole lot more powerful than HyperCard ever dreamed of being. HyperCard was a small infant next to this product. My programmer friend and I would yet come to find exactly how powerful the CanDo language could be.

CanDo

Amiga owners only saw what INOVATronics wanted them to see in this product. A simplistic and easy to use user interface consisting of a ‘deck’ (i.e, deck of cards) concept where you could add buttons or fields or images or sounds or animation to one of the cards in that deck. They were trying to keep this product as easy to use as possible. It was, for all intents and purposes, a drag-and-drop programming language, but closely resembled HyperCard in functionality, not language syntax. For the most part, you didn’t need to write a stitch of code to make most things work. It was all just there. You pull a button over and a bunch of pre-programmed functions could be placed onto the button and attached to other objects already on the screen. As a language, it was about as simple as you could make it. I commend the INOVATronics guys on the user-friendly aspect of this system. This was, hands down, one of the easiest visual programming languages to learn on the Amiga. They nailed that part of this software on the head.

However, if you wanted to write complex code, you most certainly could do this as well. The underlying language was completely full featured and easy to write. The syntax checker was amazing and would help you fix just about any problem in your code. The language had a full set of typical conditional constructs including for loops, if…then…else, do…while, while…until and even do…while…until (very unusual to see this one). It was a fully stocked mostly free form programming language, not unlike C, but easier. If you’re interested in reading the manual for CanDo, it is now located at this end of this section below.

As an object oriented language, internal functions were literally attached to objects (usually screen elements). For example, a button. The button would then have a string of code or functions that drove its internal functionality. You could even dip into that element’s functions to get data out (from the outside). Like most OO languages, the object itself is opaque. You can’t see its functions names or use them directly, only that object that owns that code can. However, you could ask the object to use one of its function and return data back to you. Of course, you had to know that function existed. In fact, this would be the first time I would be introduced to the concept of object oriented programming in this way. There was no such thing as free floating code in this language. All code had to exist as an attachment to some kind of object. For example, it was directly attached to the deck itself, to one of the cards in the deck, to an element on one of the cards or to an action associated with that object (mouse, joystick button or movement, etc).

CanDo also supported RPC calls. This was incredibly important for communication between two separately running CanDo deck windows. If you had one deck window with player controls and another window that had a video you wanted to play, you could send a message from one window to another to perform an action in that window, like play, pause, etc. There were many reasons to need many windows open each communicating with each other.

The INOVATronics guys really took programming the Amiga to a whole new level… way beyond anything in HyperCard. It was so powerful, in fact, there was virtually nothing stock on the Amiga it couldn’t control. Unfortunately, it did have one downside. It didn’t have the ability to import system shared libraries on AmigaDOS. If you installed a new database engine on your Amiga with its own shared function library, there was no way to access those functions in CanDo by linking it in. This was probably CanDo’s single biggest flaw. It was not OS extensible. However, for what CanDo was designed to do and the amount of control that was built into it by default, it was an amazing product.

I’d also like to mention that TCP/IP was just coming into existence with modems on the Amiga. I don’t recall how much CanDo supported network sockets or network programming. It did support com port communication, but I can’t recall if it supported TCP/IP programming. I have no doubt that had INOVATronics stayed in business and CanDo progressed beyond its few short years in existence, TCP/IP support would have been added.

CanDo also supported Amiga Rexx (ARexx) to add additional functionality to CanDO which would offer additional features that CanDo didn’t support directly. Though, ARexx worked, it wasn’t as convenient as having a feature supported directly by CanDo.

Here are the CanDo manuals if you’re interested in checking out more about it:

Here’s a snippet from the CanDo main manual:

CanDo is a revolutionary, Amiga specific, interactive software authoring system. Its unique purpose is to let you create real Amiga software without any programming experience. CanDo is extremely friendly to you and your Amiga. Its elegant design lets you take advantage of the Amiga’s sophisticated operating system without any technical knowledge. CanDo makes it easy to use the things that other programs generate – pictures, sounds, animations, and text files. In a minimal amount of time, you can make programs that are specially suited to your needs. Equipped with CanDo, a paint program, a sound digitizer, and a little bit of imagination, you can produce standalone applications that rival commercial quality software. These applications may be given to friends or sold for profit without the need for licenses or fees.

As you can see from this snippet, INOVATronics thought of it as an ‘Authoring System’ not as a language. CanDo itself might have been, but the underlying language was most definitely a programming language.

CanDo Player

The way CanDo worked its creation process was that you would create your CanDo deck and program it in the deck creator. Once your deck was completed, you only needed the CanDo player to run your deck. The player ran with much less memory than the entire CanDo editor system. The player was also freely redistributable. However, you could run your decks from the CanDo editor if you preferred. The CanDo Player could also be appended to the deck to become a pseudo-executable that allowed you to distribute your executable software to other people. Also, anything you created in CanDo was fully redistributable without any strings to CanDo. You couldn’t distribute CanDo, but you could distribute anything you created in it.

The save files for decks were simple byte compiled packages. Instead of having to store humanly readable words and phrases, each language keyword had a corresponding byte code. This made storing decks much smaller than keeping all of the human readable code there. It also made it a lot more tricky to read this code if you opened the deck up in a text editor. It wasn’t totally secure, but it was better than having your code out there for all to see when you distributed a deck. You would actually have to own CanDo to decompile the code back into a humanly readable format… which was entirely possible.

The CanDo language was way too young to support more advanced code security features, like password encryption before executing the deck, even though PGP was a thing at that time. INOVATronics had more to worry about than securing your created deck’s code from prying eyes, though they did improve this as they upgraded versions. I also think the INOVATronics team was just a little naïve about how easily it would be to crack open CanDo, let alone user decks.

TurboEditor — The product that never was

A programmer friend who was working towards his CompSci masters owned an Amiga, and also owned CanDo. In fact, he introduced me to it. He had been poking around with CanDo and found that it supported three very interesting functions. It had the ability to  decompile its own code into humanly readable format to allow modification, syntactically check the changes and recompile it, all while still running. Yes, you read that right. It supported on-the-fly code modification. Remember this, it’s important.

Enter TurboEditor. Because of this one simple little thing (not so little actually) that my friend found, we were able to decompile the entire CanDo program and figure out how it worked. Remember that important thing? Yes, that’s right, CanDo is actually written in itself and it could actually modify pieces that are currently executing. Let me clarify this just a little. One card could modify another card, then pull that card into focus. The actual card wasn’t currently executing, but the deck was. In fact, we came to find that CanDo was merely a facade. We also found that there was a very powerful object oriented, fully reentrant, self-modifying, programming language under that facade of a UI. In fact, this is how CanDo’s UI worked. Internally, it could take an element, decompile it, modify it and then recompile it right away and make it go live, immediately adding the updated functionality to a button or slider.

While CanDo could modify itself, it never did this. Instead, it utilized a parent-child relationship. It always created a child sandbox for user-created decks. This sandbox area is where the user built new CanDo Decks. Using this sandbox approach, this is how CanDo built and displayed a preview of your deck’s window. The sandbox would then be saved to a deck file and then executed as necessary. In fact, it would be one of these sandbox areas that we would use to build TurboEditor, in TurboEditor.

Anyway, together, we took this find one step further and created an alternative CanDo editor that we called TurboEditor, so named because you could get into it and edit your buttons and functions much, much faster than CanDo’s somewhat sluggish and clunky UI. In fact, we took a demo of our product to INOVATronics’s Dallas office and pitched the idea of this new editor to them. Let’s just say, that team was lukewarm and not very receptive to the idea initially. While they were somewhat impressed with our tenacity in unraveling CanDo to the core, they were also a bit dismayed and a little perturbed by it. Though, they warmed to the idea a little. Still, we pressed on hoping we could talk them into the idea of releasing TurboEditor as an alternative script editor… as an adjunct to CanDo.

Underlying Language

After meeting with and having several discussions with the INOVATronics team, we found that the underlying language actually has a different name. The underlying language name was AV1. Even then, everyone called it by ‘CanDo’ over that name. Suffice it to say that I was deeply disappointed that INOVATronics never released the underlying fully opaque, object oriented, reentrant, self-modifying on-the-fly AV1 language or its spec. If they had, it would have easily become the go-to deep programming language of choice for the Amiga. Most people at the time had been using C if they wanted to dive deep. However, INOVATronics had a product poised to take over for Amiga’s C in nearly every way (except for the shared library thing which could have been resolved).

I asked the product manager while at the INOVATronics headquarters about releasing the underlying language and he specifically said they had no plans to release it in that way. I always felt that was shortsighted. In hindsight for them, it probably was. If they had released it, it could have easily become CanDo Pro and they could sold it for twice or more the price. They just didn’t want to get into that business for some reason.

I also spoke with several other folks while I was at INOVATronics. One of them was the programmer who actually built much of CanDo (or, I should say, the underlying language). He told me that the key pieces of CanDo he built in assembly (the compiler portions) and the rest was built with just enough C to bootstrap the language into existence. The C was also needed to link in the necessary Amiga shared library functions to control audio, animation, graphics and so on. This new language was very clever and very useful for at least building CanDo itself.

It has been confirmed by Jim O’Flaherty, Jr. (formerly Technical Support for INOVATronics) via a comment that the underlying language name was, in fact, AV1. This AV portion meaning audio visual. This new, at the time, underlying object oriented Amiga programming language was an entirely newly built language and was designed specifically to control the Amiga computer.

Demise of INOVAtronics

After we got what seemed like a promising response from the INOVATronics team, we left their offices. We weren’t sure it would work out, but we kept hoping we would be able to bring TurboEditor to the market through INOVATronics.

Unfortunately, our hopes dwindled. As weeks turned into months waiting for the go ahead for TurboEditor, we decided it wasn’t going to happen. We did call them periodically to get updates, but nothing came of that. We eventually gave up, but not because we didn’t want to release TurboEditor, but because INOVATronics was apparently having troubles staying afloat. Apparently, their CanDo flagship product at the time wasn’t able to keep the lights on for the company. In fact, they were probably floundering when we visited them. I will also say their offices were a little bit of a dive. They weren’t in the best area of Dallas and in an older office building. The office was clean enough, but the office space just seemed a little bit well worn.

Within a year of meeting the INOVATronics guys, the entire company folded. No more CanDo. It was also a huge missed opportunity for me in more ways than one. I could have gone down to INOVATronics, at the time, and bought the rights to the software on a fire sale and resurrected it as TurboEditor (or the underlying language). Hindsight is 20/20.

We probably could have gone ahead and released TurboEditor after the demise of INOVATronics, but we had no way to support the CanDo product without having their code. We would have had to buy the rights to the software code for that.

So, there you have it. My quick history of CanDo on the Amiga.

If you were one of the programmers who happened to work on the CanDo project at INOVATronics, please leave a comment below with any information you may have. I’d like to expand this article with any information you’re willing to provide about the history of CanDo, this fascinating and lesser known Amiga programming language.

 

%d bloggers like this: