Keep it simple. Keep it fast. Code it so you can read it.
Having been programming since the 1980’s, I often wonder what has happened to programming. When learning something new from a technology book I would often gauge the books quality on how simply the topic was explained and how quickly I could grasp the subject. Complexity may seem impressive, but how often do we question whether there may be a simpler way ?
A lesson from woodworking
One of the interesting things about woodworking over the centuries is that many seemingly complex tasks can be done using very simple techniques. To the novice though, they may wonder “how did they do that ?”. But to the expert, it may actually be quite simple. You simply just have to know how to do it. Often the more simple techniques are the most powerful, since they tend to be easier, faster and safer. It is just knowing how to use them to handle a more complex task which is the real trick.
Programming is similiar. Sadly though, I have seen programming become more complex rather than become easier. High level programming languages are suppose to make coding easier, not more complex. Back in the old days many a novice learned how to program using BASIC. Actually BASIC was harder than it needed to be, since on Computers like the Commodore 64 many tasks needed to be done by “peeking and poking” bytes into memory addresses to make the hardware do something. Still, despite those challenges, many a young person learned how to write real computer code to make the computer do some amazing things. Despite the mistaken views of many new programmers today, BASIC back then (and today) wasn’t simply a childish interpreted language. For example, programmers back then were using real compilers. I used the Abacus BASIC compiler which provided significant performance increases. There were many programming language choices back then (see: Programming Languages uses on C64 ). It was not uncommon for BASIC programmers to learn machine language or assembler language. I chose to learn machine language rather than assembler, so I could write my own compiler. I used the Abacus BASIC compiler to write my own compiler which generated machine language directly. Rather than try to create a very high level language, I chose to create something which was very low level with few commands, which was similiar to BASIC in syntax, but was closer to the machine. I used my compiler instead of using an assembler. It would generate machine code with nearly as good performance as something written in assembler. I used it to write a family friendly video game which I sold to the Compute Gazette magazine.
Despite the need to learn machine language, I still apreciated the importance of keeping it simple. The language syntax of my compiler was kept very simple, borrowing from BASIC while being much easier to code than assembler. One thing I learned was the importance of keeping code simple and clean. 6502 (CPU in Commodore 64) machine language is actually quite simple compared to many modern CPU architectures. One would think that learning pure machine language (not simply assembler) would be difficult. The book I used to learn it was:
“Machine Language for Beginners”
by Richard Mansfield (dated 1987)
How this author was able to write a book about something like machine language for the 6502 CPU and yet make it so simple that it was easy to learn is amazing. Like the old time woodworkers of old, sometimes it is a matter of knowing how to keep things simple, even when the task seems complex. This is something todays programmers could benefit from, making programming simple and clear, even if the task seems complex.
BASIC – why ?
In a world where everything seems to be about C++ and programming languages with a syntax similiar to C++, like Javascript, some may wonder why does anyone even care about BASIC anymore ?
The principle of “keep it simple” comes to mind. The easier it is to teach a language the faster one can learn to program. Even professionals still like BASIC. For example, one of the more difficult tasks today is pure WIN32 programming. Back in the early 1990’s, WIN32 programming was how all Windows software was written. One usually would use something like C (later C++) to write a WIN32 program. It went out of fashion because it was too difficult to do for many (that is my take on it anyway). Things like MFC and OWL came along to supposedly make it easier, but in time dot.net became the standard and WIN32 programming lost its luster.
While WIN32 programming is quite difficult to learm especially if you want to do something very complex, I had a very interesting experience few programmers get. I came to WIN32 programming about 15 years ago and for me it wasn’t easy to learn, especially the more complex stuff. But despite WIN32 programming being naturally difficult, I personally feel I had one advantage which many programmers back in the 1990’s didn’t have. I started learning WIN32 programming, not using a C compiler but a BASIC language compiler. I was using the PowerBasic 5.0 compiler (todays version is 10). There is something interesting about the history of BASIC between the transition between DOS to Windows. BASIC was a popular programming language back in the DOS days. A lot of commercial software likely was written using BASIC. Microsofts QuickBasic 4 and later PDS 7.1 became the standard for BASIC language compilers. Borlands TurboBasic also was a very powerful programming language. BASIC had proven it could be both an easy to learn language, as well as a language which could offer many of the modern contructs a programming language required. Like my earlier years, I even learned how to code in assembler so I could write high performance modules which I compiled into my PDS 7.1 applications (BASIC).
BASIC though would have a problem. The transition from DOS to Windows would prove very challenging at first. Microsoft was fortunate to come across the original developer of Visual Basic, Alan Cooper . Visual Basic it appears didn’t start out as a compiler for BASIC for Windows. It was something totally different and it was all about scripting and drag and drop. I still have a copy of Visual Basic 2.0 and to be frank about it, the visual designer back then was very rudimentary by todays standard. But for back then it was amazing. Real drag and drop. Microsoft tweaked Alan Coopers software into what became Visual Basic. But it differed greatly from how software was developed back then using the WIN32 API and C. I doubt Microsoft fully expected what would happen with Visual Basic and how popular it would become. From what I gather, it wasn’t planned, it just happened. This explains a lot about Visual Basic and its core weakness, performance. Visual Basic was not a real compiler, but a Pcode compiler with a runtime engine. It was not until version 4.0 that Microsoft finally appreciated the need to turn it into a real compiler and even there, from what I have read, they had to use a C backend for the real compiler part. It is no wonder that Visual Basic was both loved and hated by programmers. For many it shined as easy to use and it used BASIC as the core language. For others, it wasn’t a real compiler and it took many iterations before it would have the performance of a real compiler. So BASIC programmers gravitated to Visual Basic and so called “real” programmers stuck with C and in time C had to find its way, with C++ and later all the dot.net stuff with C#.
BASIC though as a language nearly died during this time. Why ? In the DOS days, BASIC was a high performance compiler on par with C. “Real” programmers wrote a lot of commercial software with BASIC. In the Windows world, one had to consider how to talk to the operating system and Windows was written in C, so naturally “real” Windows development was done in C. Visual Basic changed much of this, but it was inherently weak because it is was PCode compiler and while it had ease of use, it lacked the power of the WIN32 and a native code compiler. In time Visual Basic programmers benefited from books on how to use the WIN32 in Visual Basic and later a real compiler backend, but much of this was a “hack” to add what should of been there from the start.
What is really interesting is to consider the other BASIC’s that came along trying to make the jump to Windows. I tried many of them myself and I was rarely satisfied. They jumped on the VBX bandwagon and the concept of components and object oriented programming, but none of them could come close to Visual Basic. Visual Basic actually was a significant departure from the WIN32 API itself, so learning how to integrate WIN32 techniques with object oriented techniques would prove challenging for many. It was like two different worlds trying to merge together. Many a DOS BASIC programmer found Visual Basic confusing, despite its easy drag and drop environment. Likely the reason has to do with code flow. No matter how software is written, understanding code flow is critical. Object Oriented programming actually gets in the way at times and can make understanding code flow confusing. There were a number of DOS Basic programmers who could not make the transition from DOS to Windows, even with Visual Basic.
There were attempts with other BASIC languages for Windows like CA Realizer (see also: Ad about CA Realizer) by Computer Associates and GFA Basic . I bought both of them, but found them too confusing. The transition from DOS to Windows caused confusion for DOS Basic programmers, not because they were poor programmers, but because many concepts were very different and more complex. Visual Basic, despite it not being a real compiler was the most successful but it was more because of the ease of drag and drop, rather than it being a superior programming language. As a long time BASIC programmer I got caught up with change and I gravitated to Visual Basic, but while I liked the easy drag and drop environment, I missed the power of a real compiler with high performance. Despite the misnomer that BASIC programmers didn’t know how to code, but simply were beginners, many BASIC programmers were very advanced and were often looking for ways to improve software and get better performance and to create more complex user interfaces.
Learning the WIN32
So back to my story. About 15 years ago, I had stopped using Visual Basic. There were too many limitations, not because of BASIC, but because of how Visual Basic was designed from the start. I didn’t mind a runtime library (DLL) for Visual Basic, but its dependency upon OCX controls for so many core features of the language was disappointing. Things like the common controls and the common dialogs requiring OCX controls which added complexity to distributing ones application. I had to find something that was more familiar to me. I found the PowerBasic compiler, which was a big change for me. I got started with it with version 5.0 and at that time PowerBasic too was floundering, trying to make the transition from DOS to Windows. The compiler was like a good old fashioned C compiler, but had no MFC to make coding easier and no drag and drop front end like Visual Basic. So what was it good for ?
PowerBasic advertised their compiler as an addon to Visual Basic for writing real DLL’s which could be accessed by any language. It had all the features of a real compiler and was on par for performance with any C compiler of the time. But they marketed the compiler as an addon for Visual Basic to do all the non-GUI stuff Visual Basic was poor at. But I wanted to build real applications with it and while one could do that, they would have to learn how to code using the WIN32 API just like old time C programmers did. I had a choice and so I started to learn how to work with the WIN32 API. I had to learn about window messages, window classes (not same thing as object classes), DC’s, message loops and so on. Simply put, learning the WIN32 API is difficult and I now understand why in the past C programmers got away from it and why things like MFC were developed. But something else happened which I did not expect.
BASIC shined for WIN32 programming
One of the big problems I had when I started learning WIN32 programming was there was absolutely no books on WIN32 programming for PowerBasic. Most API books for Visual Basic, were not for writing an application using the WIN32 API, but simply how to integrate a few key APIs into a Visual Basic program. So most Visual Basic books, if not all, were useless for a Basic programmer who wanted to learn how to code completely using the WIN32 API. Actually even today, there are still few (if any) well known books about programming the WIN32 API using BASIC. They are all primarily about C. I also had the problem of many Windows programming books dealing with MFC or ATL, so I had to search for old books, many out of print, which were about programming Windows using simply C.
Now I am not a C programmer. I don’t even like C, even though I have had a few C compilers over the years but they never caught my attention. Surprisingly though, there were a few Windows books which were so well written, even though about C, that I could learn many of the things I needed to know. I started on my path to learn the Windows WIN32 API. It took time, but with the right books, written simply, I began to grasp it. The interesting thing for me though, was that I found that the BASIC versions of what I wrote compared to a C version were much easier to code and much easier to read. Windows was written in C, so it took me time to grasp many of its concepts, functions, structures and so forth. Personally, I feel that the Windows API is actually very well written and has many advantages. The problem is that it was written in C, so it carries the terse syntax and complexity of C which made it harder to learn than it needed to be. Seeing WIN32 code, but in BASIC made me more easily make sense of what was going on. If only Windows has been written in BASIC, rather than C, maybe WIN32 programming would still be in fashion today.
Actually, a well written BASIC compiler can have many advantages. One thing I appreciated about PowerBasic was its strong string command set. PowerBasic, unlike C and many indie BASICs on the web which borrow heavily from C, uses the Windows OLE APIs for the variable length string data type. OLE strings don’t require a zero character for an end of string. They can contain 100% binary data (from byte 0 to 255) of any length. Working with the Windows API does not require C, but there are BASIC language compilers today which can do much of what C does. Languages like PureBasic and FreeBasic are examples.
WIN32 code written in BASIC, I found to be easier to read than C. Also WIN32 coding, while not easy, lends itself to a programmer seeing the need to write modular code much like old time BASIC programmers did. Building quality libraries, especially for user interface code was quite common for old time BASIC programmers. The old saying “don’t reinvent the wheel” is fitting. If code was complex, why not build a reusable routine so the next time you simply call your library. Unlike todays programmers who get bogged down with object oriented programming, old time BASIC programmers became very adept at building reusable libraries using simple functions and procedures. Modular design makes sense, but it need not be overly complex for it to work.
The “Internet of Things”
The coming “Internet of Things” means there is a need for smaller, faster software. Tiny devices won’t run at optimial speeds if the software is overly bloated. BASIC programmers have a history of writing small and fast software, despite the stories todays programmers have been told. Yes, we have been using compilers, working directly with machine language and working with simple API’s for a very long time. If there was one thing this old time programmer would like to see in the software world, it would be a resurgence in BASIC. If a company wants to build the next generation of “Internet of Things” devices, why not develop operating systems which lend themselves to being simple? Why not write API’s which are simple in design from the ground up? Why not build the next generation of not C, but BASIC compilers, capable of being used by the average person ? Why not build BASIC compilers capable of being used to write those next generation compilers ?
BASIC code leans towards simplicity. BASIC tends to be more readable. BASIC and the “Internet of Things” would go like a hand in a glove, a perfect fit.