Copyright Notice: This article is Copyright AI Factory Ltd and the authors. Ideas and code belonging to AI Factory may only be used with the direct written permission of AI Factory Ltd.
This article follows the author's passage from early primitive means of creating program code through to modern editing tools. The transition had a profound impact on the author's productivity and design methodology.
Having been a programmer since the dawn of time, starting my first major coding project using punch cards (a chess program that took a game from the World Champion Belle), I have seen a substantial range of different programming environments. This time span has seen radical advancements from the most primitive to exotic development tools.
In among these, one particular "revolution" in advancement has had a substantial impact on my own productivity and this article catalogues that.
Early Signs
Back in the early eighties I was involved in the development and use of a development language/tool called Engol. This was used for teaching at Westfield London University for programming, allowing the programmer to start writing their program in English and then gradually migrate this to program code. On many levels this was a natural idea as it allowed the user to completely express their program in English but then start generating code in any order. Any English phrase could be later expended to a code segment by adding a definition. It looked something like this:
The English-only version could be expanded. Adding expansions such as this:
Using an on-line tool, that I developed to support this, the user could browse their source and view any item as either the original English or the English as a comment and the code expanded, allowing a gradual expansion of the code so that the code could be viewed on any level of detail. The user might therefore see:
This was an unfamiliar but not unnatural way of developing a program. It allowed the user the freedom to expand the code in any order while allowing them to easily review the structure of their program in easily comprehensible terms.
As I moved on to other things Engol was left behind at the university and the microcomputer revolution was just starting. After a few years working with assembler and the Z80 the IBM PC started to really take off and then the next step prevailed.
PC Outline
John Friend published a shareware program for creating folded documents for the PC and very quickly I saw that this might have a potential role as a programming tool. His program cost $220 dollars to register (a lot for an editor but software in those days was expensive). It was designed to create structured text documents, not unlike Microsoft Word now, but actually with more power than Word. This created complex binary PCO files that were of no use for a compiler to process, but the editor could export to a text-only PRN file. That offered an opportunity to do something, but editing PCO, exporting to PRN then having some external conversion to C was not convenient. I put on my hacking hat and disassembled PCO.EXE (PC Outline) and converted it to export to C files and created macros for C save so that it was possible to work in PC Outline on a PCO source file and then export to C source for compilation.
That was a lot of work to get to this point but this is what it gave:
Code could be expanded at any level, tied to indentation. The language, based on Kernighan layout conventions, fitted this very well. Now it was possible to expand regular code on any level. The editing facilities of PC Outline made this easy. You could with single keystrokes do expand/contract all folds on the current level, close/open all sub-folds, retreat one level and open/close, search for text and expand only the folds needed to expose the searched-for text.
This was a massive step in advance of the usual: Search text, cursor/page up down that you usually had with flat editors and offered a really useful and new way to manage coding. The screenshot below shows what this looked like.
To the modern developer this may not look that good! The screen offers only a 22-line window on your code, which would bust the patience of anyone used to seeing 140 lines displayed on their 2560x1600 monitor, but remember, this was 1987 and PC screens were 80x25 in size, so life was much more limited.
Merging Engol and Folding
The above was a minor revolution to my own coding but not enough. The ideal step would be to still have the Engol-like capacity to mix English and code, and to be able to view the source in any mixture of code and English that the programmer wished. To get closer to this took a very small step, creating a macro that created an Engol substitute fold that was simply:
with an invisible indent on the following line. The user was left at the end of the 3 stops and could type in their English. Now the code element above could be represented as follows:
The triple dot "…" is equivalent to the use in English to mean "this is to be expanded", in this case to an indented block sitting below it. Now the block of code can be viewed on any level, with English comments also being broken up into structured blocks, such as below:
Note in the above that we have nested terms expressed in English and also that the loop has been partially closed so that the body cannot be seen. The structure of the program can be seen mixing English and code structures, mixed to allow the logical structure of the program to be seen on any level and in any configuration.
Impact on Coding
Although working alone, I was not entirely in isolation: a colleague of mine, Mick Reiss, also saw the advantages of this and we each took our own path to use such a facility. In his case he created his own folding editor that embedded structural information in hidden comments. This allowed him to have a single source file, but meant that any other editor that accessed the sources would be exposed to these mysterious comments that encoded folding instructions.
As for my own coding, I also went on to create a patch of PCO.EXE to handle ASM files, so that this could be applied to other work.
Impact on productivity
This minor "revolution" in handling a source file actually had a huge impact on my programming. For assembler work it was the difference between accepting and rejecting a project where I took on a huge undocumented multi-tasking 8086 assembler source for chess and improved its strength. On the C front I am sure that without this I would not have had the success I achieved in Shogi (Japanese chess), where I managed to successfully take my program Shotest to the world championship in Tokyo.
The key to this advantage was to be able to keep an easy grasp on the structure of the program. Without this a major project such as Shotest would have been a much harder undertaking. Developing the structure would have required some parallel planning and design, instead of which I was able to directly code in an engol-like series of comments. This allowed blocks of pseudo code to be coded and worked on before actually migrating to program code. Structures could be created that might even never be eventually used. The editor then becomes not just a coding but also a design tool. To convey the impact of this I think you have to realise that coders basically adapt to whatever the tools they have. If you only have a simple editor your methodology adapts to just that. In this case folding delivers a substantially more capable space that the programmer can re-structure to exploit the new advantage. Your whole approach to design can completely morph. In my estimation this doubled my productivity of small projects and made more complex projects possible that might not have been viable with just a basic editor.
Fast forward past 1987
It is pretty clear that as the capabilities of PCs have somewhat progressed, through the start of Windows 3.0 to where we are now, and that I could not possibly be still using PC Outline. I have moved on, but doff my hat to John Friend whose product radically impacted my software career.
After searching around, rejecting quite a few options that provided "folding", but in a somewhat restrictive format that were simply too limited to be useful, I finally found SlickEdit, which supported a flexible configurable folding capability with a capable macro language. I took this and worked to create all the keyboard macros to provide the folding manipulation operations I needed. The start point was to provide PC Outline emulation just to maintain continuity, but I was able to expand on this. Many macros I needed for PC Outline were unnecessary, such as automatic program blocks that no longer need to be tied to keystrokes. SlickEdit supported automatic expansion of if, do, while and for control structures so that as soon as you start typing, SlickEdit will automatically fill in the appropriate structure.
Given the freedom of a programmable macro language you can go on to imagine and create exactly want you want. In particular a key for "jump to and open next fold at this level" and "drop back one level and close child". Once you get into the loop of creating and using such operations your operational style changes and from that new perspective you can go on to evolve new operations that allow take you to progress to a further more productive state.
The screen below shows a sample screen segment from SlickEdit showing the interface I see now. Of course with all that flexibility at hand you can create a front end that works best for you. For me the usual harsh solid white background offered as default also offers eyestrain, so I go for light blue and take advantage of that by having comments in white and code in black, making the differentiation between English and program code as obvious as it can be.
Conclusion
Of course, at best, what is described above is an editing and design tool. Beyond that follows the domain of development tools and practice needed for development. That is detailed elsewhere in other articles in this periodical.
However if, by some freak of circumstance, I was dropped into a world where I needed to revert to non-folding coding and design I think I would hang up my programming boots and find some alternative career.
Of course existing standard tools must have evolved to adopt something of this paradigm, which they have. Word offers a simple folding system and visual studio does too. However these are as yet still too primitive to really make any profound impact on development style. In consequence I edit in SlickEdit and debug in my own console and only load visual studio when I need to embark in breakpoint decoding, which is relatively rare for me.
The "downside" of this system is that it encourages you to create substructures as folds, rather than break up blocks into many functions. Very often breaking up into functions is desirable for optimisation, but in the world of the modern compiler, with the supporting help of scope blocks, this is now largely an imaginary advantage. Another benefit of functions is re-cycleable code, which encourages the very helpful practice of modularity, which is still very valuable. Of course with a fold you can drop the function body to be into the fold at an early stage and then migrate it to a function later.
However folding avoids the unnatural practice of creating a set of parameterised functions called one after the other, simply to allow the programmer to be able to view the code structure in some top level fashion. This is a kludge simply to compensate for the absence of folds. If you are trained to do this then this is basically primarily an artefact of the limitation of flat editing.
Finally one downside of folding is that it encourages you to create code that is hard work to work on without folding editors, so any joint sharing might be harder work for any programmer using a flat editor.
In balance, I doff my hat again to John Friend and am grateful that his editor allowed me to evolve to adopt this paradigm.
Jeff Rollason - February 2014
