How We Built Excosoft part 1: The Dawn of the EXCO Editor

An Electronic Engineer Turned Programmer

In 1975, Stansaab, a company outside of Stockholm, got a big order from the Soviet Union: 3 air traffic control systems for Moscow, Kiev, and Mineralnye Vody. USSR wanted to be prepared for the increased air traffic expected in 1980, the year of the Olympic games in Moscow.

One year later I graduated from KTH as an electronic engineer and was looking for a job. Stansaab needed engineers for testing hardware, and I sent in an application. After several months, I was called for an interview:

“The testers are already in place but we are also looking for programmers— would you be interested in that?”

“I think so” I replied, having only completed a single course in the Fortran programming language.

I joined the “Radar Tracking Group,” and was assigned to developing one module: TAS, the plot association module. You can find it somewhere in the middle of this overall design picture I sketched at the time, in order to understand my place in the universe:

The Frustration

The programming language I needed to learn was the Assembly Language. An Assembly Language is a programming language on a very low level, where each line of code corresponds to a machine code instruction. In this case, the machine was a Stansaab computer. Here is a code example:

For almost every line of code, we added a Line Comment to make it more understandable. Here and there we’d also add a Block Comment, to indicate the functionality implemented by the following bunch of lines. Finally, we had a Subroutine Comment describing the overall purpose of the routine.

I remember the frustration of not being able to describe the purpose of a Group of Blocks— we only had the three levels of abstraction: routine, block, and line.

This limitation was very irritating. But on the other hand, it also served as a challenging problem to occupy my spare time with: Could there possibly be another way to write source code —a hierarchical way instead of the flat way?

Thinking Differently

In 1979 I stumbled across an article in the magazine Communications of the ACM. It was titled “Beyond Programming Languages,” and was written by Professor Terry Winograd at Stanford University.

He wrote things like, “The programmer needs to be able to reorganize the information dynamically, looking from one view and then another, going from great generality down to specific detail, and maneuvering around in the space of descriptions to view the interconnections.” As well as, “… reduce complexity by allowing imprecision when precision is not required.”

It was like heaven to my ears. Someone else was thinking along the same lines as me, someone else was talking about abstractions— and he was a professor!

Summer Evening Innovations

1979 was also the year we delivered the air traffic control systems to the USSR, The following year I became involved in a project delivering the same type of system to the Sturup airport outside of Malmö. By this time, Stansaab had been split and merged with other companies, and it was now part of Ericsson Radio Systems.

During the summer evenings at Sturup in 1980, I began programming a new type of editor. The programming language was Pascal, and the programming environment was from Digital Equipment, (the EDT editor on a VT100 terminal, connected to a VAX VMS mini-computer).

By the end of the summer, the first version was ready. In the editor, lines of text could be compressed into titles in as many levels as desired. Upon opening the file, the highest level of the hierarchy would be presented. The titles could then be expanded to reveal more details, or compressed to hide them. In short, you could walk up and down in the structure to view different levels of precision, just as Terry Winograd had envisioned.

Furthermore, links could be used to connect lines of text with other parts within the hierarchy. Upon expansion, a link presented it’s contents on the spot, as if it was an ordinary expansion. By following links, a reader could view interconnections between different parts in the hierarchy without losing context.

This is how it looked on the screen:

The screens in those days were alpha-numeric, with no graphical features at all. I used reversed video to show where an expansion started and ended, (indicated by minus signs). A column to the right contained a character to indicate what could be done with the line. The character “<“ indicated a compression, (ex: something expandable). The character “e” as in “entry,” indicated a target place for a link.

The first file I structured was the editor source code itself. I remember that elated feeling I felt in my stomach when the program was finally “documented”— Now I’m really starting to understand my own program! I could sit for ages just expanding and compressing structures. I knew it could be an important tool for programmers.

I used the terms Expand – Compress, since I thought a compression was the opposite of an expansion. In the early 1980s other tools addressing the same challenge were launched. They were called outliners, and they all used the terms Expand – Collapse. (I still think Compress is a better term!)

I named the editor EXCO, short for ExpandCompress. Seven years later, when I founded Excosoft, it became a part of the company name.