Programming Languages
People often have strong opinions about programming languages and so do I. Well, perhaps a bit less strong than others. Yesterday I took a moment to reflect about the things I liked and disliked through my journey with different languages. I started to write things down, and I decided to share my notes. This likely has little value for anyone, do not expect any deep insights here.
BASIC (late 1970s)
I first touched what we call a “computer” these days in the late 70s. I think it was a Wang 2200, an incredible device with a CPU built out of hundreds of TTL chips. The programming language of the Wang was BASIC. Learning to code simple algorithms in BASIC (i.e., the classic moon lander) was relatively easy. The Wang computer was owned by the school, and I got the permission to stay longer in the afternoon to work with the system. I had two really enthusiastic school teachers. One of them exposed me to an algorithm that was called RSA and brand new and I implemented it for the numbers the box could handle, small numbers, fairly small numbers….
Pascal (early 1980s)
The other teacher said we should learn Pascal. When the Wang computer decided to stop working, we got to work with computers of a neighbouring school, and I started to learn different flavors of Pascal. Pascal was far more interesting for me than BASIC. BASIC was only used occasionally for typing in source code of games that were sometimes published on paper in those days. When our school got some Apple II clones, I started to learn switching floppy discs fast while handling the UCSD Pascal system and its overlays.
Algol 68 (mid 1980s)
I started to study computer science (“Informatik” as it is called in Germany) at the university in the mid 1980s. At the university, I had to learn Algol 68. Since Pascal is largely a simplified version of Algol 68, this was not too difficult for me, but students lacking experience with a structured programming language or programming in general had to study hard. The Algol 68 implementation was running on an IBM mainframe. The terminals did operate in a local editing mode and they only contacted the mainframe when you were finished with an edit and you needed the compiler again. Fun time when the light indicating the health of the mainframe turned red and all you could do was to send messages between the terminals. Privately, I still wrote code in Pascal because this is where I felt at home and Algol was out of reach for private 8-bit computers. After two years at the university, I took a teaching assistant position, helping other students to learn Pascal, in particular students enrolled in non-computing programs. Due to this job, I ended up in a department where people were hanging out writing code in C, APL, LISP, Prolog and Occam, pretty much everything you could imagine.
Smalltalk (late 1980s)
I guess I just had to add to the mix and I ended up using Smalltalk-80 for my final project. What an experience, the Smalltalk-80 environment was so much ahead of the time in terms of usability. The compiler suggested corrections for typos, fixing the source on the fly and continuing compilation afterwards. The graphical user interface was awesome in terms of look and feel compared to what everybody else had at that time. I was using a Sun workstation (one of the pizza boxes) to run Smalltalk-80. The Suns (initially we only had two) were always used by multiple people concurrently since they were the best computers around at that time. And yes, when I walked into the room and took control of the console and started Smalltalk-80, others got a bit unhappy; the Smalltalk-80 system did pretty much occupy the whole system.
C [C++] C (1990s)
My thesis project took place during the symbolic AI wave, a time where expert systems were expected to change the world. After finishing my thesis project in Smalltalk-80, I took a sharp turn since I was disappointed by a fast growing research community suddenly calling even the simplest decision tree or control algorithm an expert system. I became a systems person and I got interested in the Internet that was rolling out fast at research institutions. Instead of high-level object-oriented abstractions, I went down to bits and bytes and I started to love C because of the raw speed you could get with it and the full access to the operating system it provided. C quickly became my primary programming languages, I have not written Pascal code for decades.
When C++ came along, I was of course interested. But for someone with a Smalltalk-80 background, the experience was quite horrible. If you are used to dynamically typed object-oriented programming languages, a statically typed language looks like a culture shock. It took long for C++ compiler technology to stabilize and for code to become portable between C++ compilers. After several attempts to use C++, I gave up on it and whenever I turned back later, I felt things did just get worse. One of my friends really got deep into C++ and he later wrote books about C++ and the STL; he is meanwhile well recognized as a C++ expert and active in C++ standardization.
Tcl (early 1990s)
Tcl came along in the 90s and for me this was fantastic. Instead of rolling my own little command line front ends, it was now possible and to simply add new commands to the Tcl interpreter and then write higher-level stuff for demonstrations etc. as scripts on top of my commands written in C. Fast prototyping, good speed, easy to move between Tcl and C. I read the entire Tcl source code and I loved John Ousterhout’s coding style.
Python (late 1990s)
Python came along in the 1990s but somehow I did not take too much notice of it initially, in hindsight this was perhaps a mistake. Python was designed from the ground up to be an interpreted programming language, Tcl was designed to be an embeddable command interpreter. Many people confused the differences between these two things in the 90s (and I am also guilty of writing Tcl scripts that better would have been written in a programming language). But it was noticeable that many Tcl developers switched the Python, a language with some nice concepts.
Java (2000s)
I had to learn Java in quite some detail since I got an offer to teach it. The Java experience was better than my C++ experience, but not as good as my Smalltalk-80 experience. Java was pretty usable to get things done. However, for someone with a systems programming background, the startup behavior of Java programs even today is making me feel bad. Sure, for many programs this does not matter at all and once all the just-in-time compilation has finished, programs run reasonably fast. But living in a sandbox, where people reinvent everything, probably simply because it is too painful to reuse existing native libraries, always felt bad. To do real work, I continued to use C.
Haskell (mid 2010s)
While I played with lots of programming languages, I never got deep into functional programming. This changed when I took over a course that introduced student among many other things to functional programming. The previous instructor used a collection of different functional programming languages but students wanted a more mainstream functional programming language (so that it is easier to google for help). I ended up learning and then teaching Haskell. While I have meanwhile a reasonably good understanding of it, I would for sure not call me a Haskell programmer. One reason is that there is no end in learning Haskell. There are tons of abstract concept to explore and it always feels like once you have mastered one, three are three more to explore. Haskell equates to life-long learning. Well, it was designed to be a research vehicle, and it seems to meet this target.
Go (mid 2010s)
Go came along with its concurrency model, which is heavily based on Hoare’s communicating sequential processes. Wonderful. The syntax looks a bit ad-hoc but Go for sure attracts devlopers who know how to write good and robust server software. As a systems person, well, go is out of reach for many of the boxes I am dealing with. So I took notice of it but continued to write C code.
Rust (early 2020s)
Rust came along and in 2020 I felt it is time to take a serious look at it. It is interesting to see many concepts I knew from Haskell being part of a system programming language. To learn Rust, I started to rewrite some of my existing C code in Rust. Since Rust’s type system is really strict (compared to C’s loose type system) and library writers take things serious, this is an illuminating experience. By rewriting my C code in Rust, I identified many corner cases that my C code would not handle well. An example: C code sorts an array of floating point numbers by simply calling qsort(). Trying to sort a vector of floating point numbers in Rust in the naive way gives you a compiler error since there is no total order for floating point numbers, due to the existence of special values such as NaNs.
While rewriting C code in Rust, I realized how much infrastructure code is usually written just to have a maintainable build and testing environment in C. While I moved from autotools (oh boy) to cmake many years ago, working with build tools of modern languages like Go or Rust is such a boost of productivity and a big gain in portability. Even Java with Maven is far from the efficiency modern well integrated build tools achieve.
Languages Ignored
I never got into JavaScript. I know that there are tons of JavaScript developers making a good living out of JavaScript and the various frameworks, both for the client side and the server side. I guess this is simply because I had my scripting language experience in the 1990s and I am pretty much done with it. I love compiled languages, I enjoy native speed, I hate to stumble over simple programming errors at runtime that could have been easily detected before execution started.
Erlang is a language I should have looked at but I never got a real reason to do so. As I wrote above, I sometimes learned a language simply because I needed to teach it and for whatever reason nobody ever asked me to teach Erlang.
I tend to ignore platform or vendor specific languages. I never cared about Objective-C, C#, Kotlin, Swift, you name it. This actually leads to an interesting observation: Most languages I enjoyed learning and using were designed by either individuals or research groups that just wanted to create something better: Pascal (Niklaus Wirth), C (Dennis Ritchie), Algol-68 (IFIP WG 2.1), Tcl (John Ousterhout), Python (Guido van Rossum), Haskell (Haskell Committee).
Smalltalk (Alan Kay, Dan Ingalls, Adele Goldberg) came out of Xerox PARC. While Xerox PARC is an industrial research center, I consider it rather independent from Xerox itself. And I doubt that Xerox ever made money out of the research on Smalltalk they sponsored.
The designers of Java (James Gosling) and Go (Robert Griesemer, Rob Pike, Ken Thompson) received major support from (at that time) big companies. Perhaps they are outliers in my little collection of programming languages I have learned - but then I also did not fall into deep love with these languages at the end
Addendum 2022-02-21
I came across another YouTube pearl today: Bob Martin’s talk about “The Future of Programming”. A great perspective of how we got to where we are, what professionalism means, and why the immense growth of the programmer species makes software engineering hard.