James M. Clark, retired after 43 years at ITT.
I began designing parts of computers, then communications hardware, and eventually entire computers and systems such as the MDU (Message Data Unit) of the GPS satellites.
From hardware design, I learned programming first as an engineering tool, then as an engineering component.
I first learned Fortran -- the hard way -- like learning to swim by jumping into the pool.
I also did some assembler code when needed, which wasn't hard since I designed computers.
Then I learned C -- now there was structure, and dynamic memory allocation.
Then I learned Pascal (Borland, that is) -- now I could write programs that ran correctly the first time.
Now there were other levels between local and global.
I could show programs to non-programming engineers, and they could understand them (I told them it was 'design language').
I found the Interface and Implementation sections of Units easier to handle than Header files.
And no more makefiles -- just click the Make button (it even saves your source files).
Programming and programs were faster.
Now I use Virtual Pascal (http://www.vpascal.com/news.php
In spite of all the programming I have done, I never, in all my 43 years of engineering, worked officially as a programmer. I've been a system engineer and inventor. I primarily used programming as an engineering tool. I learned it on my own, from books and experience. I mainly wrote programs for myself, to test design ideas, whether designing hardware or software algorithms. My bosses were generally more interested in the results than my methods, so I was free to develop my own style. And I could use Pascal when the programming department used only C and assembler. After converting my Pascal to C for them several times, I started writing a Pascal-to-C converter.
The Borland Pascal compiler was so fast that I got in the habit of compiling every few minutes so that I could catch errors one at a time before they compounded, knowing that compound errors would make debugging harder. This led to the habit of starting with a skeletal program (sometimes while the design concept was still fuzzy) and adding features. Years later, I explained my programming style to an expert at an Object-Oriented Design seminar, and he said "Oh, you do ExtremeProgramming
." It was the first time that I heard the term. I also learned that I had developed habits called TestDrivenDevelopment
After finding that I was re-using my own code, sometimes years later, I started commenting the code more, and looking for code with re-use potential. I developed a personal library of re-usable units which often enabled me to complete projects faster than anyone expected.
I have written:
- assemblers with compiler-like properties;
- interpreters and simulators; some simulators were also interpreters;
- a visual dialog editor (for TurboVision)
- a Pascal-to-C translator (partial -- procedural code, not declarations)
- design generators that convert a hardware specification into VHDL (a hardware design language) or Pascal. Some of these also generate test vectors (a set of tests that can detect all, or nearly all errors).
- a multi-processing system. I ran simulations that used the spare time of about 60 computers on the company network, and ran for several days, typically.
My e-mail: mailto:JamesMClark5@comcast.net