Structuring my Thinking

Originally published on: Mon, 30 Nov 2009 16:50:50 +0000

In my post Learning Z-80 Assembly Language on the TRS-80, I describe my acquisition of the assembly language programming skills that could have led to a career as a game-developer. I emphasized the phrase "could have", because I had mentioned in that post that I really knew nothing about good software design practices.

Like many of my generation, I started out coding in 8-bit BASIC dialects and later began to code in assembly language. What I often did when writing assembly was picture the program in BASIC. That's the sort of mental modeling I was doing at the time because it was the only programming environment I had known. My early coding style for writing assembly programs was just to start and interactively try to shape the program as I went along, without a clear high-level mental picture of what I wanted to accomplish.

At this time, the trade press was starting to warm up to the Pascal programming language as a means by which good programming habits could be taught. Many add-on packages for BASIC supplemented the interpreters with some Pascal-like constructs ( named procedures and functions, structured loops, block-structured if/else/endif, ...etc. ) One such extended BASIC was a language called COMAL from Denmark. A free version was available at the time for the Commodore 64 home computer, so I tinkered with it a bit. ( You can try out COMAL on modern OS's via the OpenCOMAL project: http://www.josvisser.nl/opencomal/ ).

COMAL was a powerful BASIC with extended flow-control and instant feedback on errors as you entered lines of text. I really didn't understand the value of these named FUNC's and PROC's that it would encourage the developer to use, although I had seen similar constructs in the language Simons' BASIC ... another extended BASIC available in cartridge form for the C-64.

I had purchased a couple of Commodore 64 Pascal compilers at the time. They were very cumbersome to use due to the limited amount of memory plaguing 8-bit computers of that time, and also due to the slow disk speeds of the serial protocol used to talk to the 1541 disk-drives. Often, you had to unload the editor while the compiler pored over your program. When a mistake was found, you had to re-load the editor ... which took a lot of time. Development with most of these compilers was a very slow process.

I wasn't making very much headway learning Pascal on my own, so I took a Pascal course as an elective in college. I learned much more quickly in a formal curriculum. It's not that the assignments were all that enlightening; I just needed a bit of a nudge in the right direction. I worked a little with the small Pascal compilers I had, but they were very frustrating to use.

Just after I had completed my introductory Pascal class, Commodore released the Commdore 128 home computer. I bought one as soon as the department stores started to carry them. The C-128 had a C-64 emulation mode and a CP/M mode. I had an interest in CP/M as I had a desire to work with a "real" operating system, but the Z-80 cartridge I'd bought for my C-64 and the CP/M software for the cartridge were just too slow.

CP/M on the C-128 was much better. I bought a composite Apple monitor and cobbled together a video cable that allowed me to use the 80-column text mode on the C-128. I began to frequent a local BBS with a CP/M software repository. Some local people were writing CP/M utilities in Turbo Pascal. I really enjoyed downloading the source code and looking through each program. Tech magazines of this time period were providing coverage of Turbo Pascal.

I ended up getting Turbo Pascal 3.0 for CP/M-80 for my C-128. I was amazed at how quickly TP would compie my code. It was an incredible experience after putting up with all of those slow compilers for such a long time. I spent a lot of time toying with TP and bought a book on the MS-DOS version of TP from Compute! publications.

I was beginning to model programs mentally using a more structured, top-down approach. I would start by envisioning some high-level functions / procedures and would flesh each one of those out as I thought about them in detail.

A friend of mine who was attending a reputable university advised me to buy the venerable book The C Programming Language by Kernighan and Ritchie. So, I did. I loved reading that book. Learning Pascal helped ease me into similar concepts in C. Unfortunately, I didn't have a C compiler to toy with. I went to a computer store in a neighboring city and bought the C-64 version of Abacus' ( Data Becker's ) Super-C compiler. It was really cumbersome to use like the Pascal compilers I had tried to use earlier. I had realized that I was just going to need to go with a computer that had better compilers available.

By this time, I was out of school and was working writing mainframe code. I sold all of my 8-bit Commodore gear and bought an Amiga 500. I tried to learn C using this new computer as that seemed to be the most popular development language available for it. I didn't have a hard-disk drive, so the compiler required some diskette shuffling. I would compile with one floppy to a ramdisk, then I'd link with a separate floppy. I still had a long way to go, but this process wasn't really that bad. Even with the floppy swaps, I was able to edit, compile, and test pretty quickly.

I used to read the code listings in Dr. Dobbs Journal ( I loved Allen Holub's C Chest column ) and in Byte magazine each month and would try to understand what the author was trying to accomplish, line by line. I checked out a copy of the Waite Group's Advanced C Primer Plus text, which helped de-mystify pointers and C's pointer notation.

My next planned purchase was an MS-DOS machine as the prices for the rising clone market were dropping. I bought a book on 8086 assembly language in MS-DOS to be certain that I understood the OS at a very low level.

"Chance favors the prepared mind." - Louis Pasteur

An opportunity arose to be a founding member of an MS-DOS C development team at work. Although I had no MS-DOS machine at home, the rigor that I had put forth studying C and low-level MS-DOS had paid off. Although, my team and I all started out as novice C programmers, our prowess grew in leaps and bounds as we went on to build some very respectable, long-lived software.

I continued on the C path, first using C++ and later Java as well as a myriad of diverse languages along the way. Often, these languages cater to specific programming idioms and/or philosophies. By learning a little about each of these languages I've learned more about programming in general.

While I have only used Pascal a few times professionally ( most recently Object Pascal in Delphi), I consider it to be the language that kick-started my software design skills.

Unless otherwise noted, all code and text entries are Copyright Š2009 by James K. Lawless

Save to del.icio.us
Save to StumbleUpon
Digg it
Save to Reddit
Share on Facebook
Share on Twitter
More bookmarks