Down the Memory Lane of Programming Languages

I saw this prompt through my Twitter feed, and decided to join in on the fun:​

1994: QBASIC (elem school)
1998: Pascal (high school)
1999: Delphi
2000: Scheme (college)
2004: C++ (first job)
2008: PHP (web dev)
2009: Python + JavaScript (front end)
2010: Java (@Google)
2011: Ruby (on Rails) (@Square)
2012: CoffeeScript https://t.co/gpE0XAqXCa

— Allen Cheung (@allenmhc) May 23, 2020

In fact, I’m going to take it a step further and annotate each row with color commentary, while I try to remember the state of those programming ecosystems at the time. This’ll be a pretty long, nerdy blog post.

QBASIC (1994). I was in 3rd or 4th grade in elementary school, and my dad introduced me to a BASIC programming book and paired it up with some time on the family 286 PC. I had no idea what I was doing, beyond copying 30–40 lines at a time from the printed page to the QBASIC IDE/text editor. I did stick with it through elementary and into secondary school, when I got good enough with GOTO statements and simple VGA drawings and animations and RND to build a rudimentary RPG that was part Chrono Trigger and part…Final Fantasy I combat with ASCII art. After at least a few thousand lines of code, the game’s code somehow got corrupted and I lost a few months of work, a rather tough lesson on the importance of backups, or at least, saving files multiple times1.

Pascal (1998). My high school offered a Computer Science class2, so given how much time I spent half-assing my way to make the computer do something when I was younger, I jumped at the opportunity.

Pascal was a good language to learn about Computer Science fundamentals. It was somewhat similar to C in being a declarative programming language, but featured slightly friendlier syntax that didn’t scare students away with char**s. Then again, it might well be that we only scratched the surface of what the language offered, as the teacher that year struggled with student engagement as most of them took advantage of computer lab availability to play games.

Delphi (1999). BASIC : Visual Basic :: Pascal : Delphi. Our high school curriculum naturally segued from Pascal into Delphi, which enabled us to build GUIs in Windows, but also—in theory anyway—could leverage other parts of the stack like databases and networking. That said, beyond this brief period of progression from Pascal for educational purposes, I’ve never since encountered its usage in a professional software development setting. Surprisingly, when I looked up what’s happening with Delphi in more recent times, it’s apparently is still within the top 20 of all programming languages in 2020.

Scheme (2000). For a time, the undergrad CS curriculum at Cal borrowed its teaching materials from MIT’s legendary classes, including the Structure and Interpretation of Computer Programs textbook and Scheme—an esoteric, almost academic LISP dialect—as the programming language to teach core CS concepts. Whereas most programming is declarative and iterative nature, Scheme is unabashedly functional and recursive; I think professors saw how different programming in Scheme is as a feature, intentionally distinct from the other paradigms that their undergrads would have encountered by themselves or in their high school CS classes.

It seems like that in 20 years, the classes have been updated to use Python as the primary programming language, though Scheme is still a part of the coursework.

C++ (2004). My first job out of school was maintaining and enhancing a bespoke GUI framework for a Bloomberg terminal competitor for the finance industry. The product was built as a Windows program3, which was first written in the 90s in Visual C++ and thus kept as that for the next decade and a half.

C++ is known as a language with a thousand sharp edges, and it cut both ways for a bunch of us new grads learning how to program professionally for the first time. On one hand, there were much easier ways to build server-client software in Windows, where something like C# and .NET at the time would have made development significantly faster and less error-prone. On the flip side, for new grads eager to learn and who didn’t know any better, putting in the extra time and effort to learn more of the ins and outs of the language and framework seemed totally natural. As I haven’t gone into software industries that would necessitate the performance optimizations (e.g., games, high-frequency trading), I haven’t had occasion to revisit C++ and its more modern developments.

PHP (2008). I had dabbled with PHP on my own, building and rebuilding my bespoke blog engines for the sake of learning web development. It eventually led me to my first web developer job at a startup—a path that I’ve since leveraged into many other startups—which itself led into transitioning into management. On some level, I’m grateful for PHP in making it so easy to learn and build simple CRUD websites.

Back in 2008, in the early days of web sites and web apps, inlined PHP & JavaScript4were still the norm; web development has yet to invent the massive, evolving stack of tooling and language compilation and package dependency managers and deploy pipelines. The ability to plop a few lines of PHP on a page—although it was already of questionable security practice—to render webpage interface elements encouraged a very fast development and feeback iteration loop that facilitated quick, self-directed learning. Sure, PHP’s syntax was horrible and core libraries lacked much cohesion or consistency5, but subsequent efforts since to improve how it scales, both from a number of developers standpoint but also just raw speed, has kept it relevant all these years later.

Python + JavaScript (2009). Just as PHP & JavaScript was a common web development pairing, Python was also a popular choice at the time for server-side development, and has kept up its popularity in the intervening decade. One of the startups I worked for actually migrated from PHP to Python, taking advantage of the ecosystem around Python for other general backend tasks.

On the front end, JavaScript was starting to come into its own as a client-side language for web browsers, powerful enough to substitute native desktop applications and updated with a simple page reload. Google’s Chrome browser was first released in 2008, and a big deal at the time was how much faster its v8 JavaScript engine was in comparison to other browsers— an advantage that supercharged adoption of Google’s own web apps, and keeps the browser popular even today. And instead of a hundred competing JS frameworks, the choices were delightfully simple: either write jQuery straight, or use Backbone.js to add a little more structure.

Java (2010). I don’t have particularly fond memories of Java. I had to pick it up as a part of my college coursework, but didn’t use the language professionally until my stint at Google. My bias stems from the now open source Google Web Toolkit (GWT) framework, a Java-based framework for rendering websites that my manager at the time imposed onto our team mostly because he was a Java developer. Java is already known to be a verbose language; using it to wrap around what eventually translates to JavaScript web code is just a couple too many layers removed from the actual user interface. That said, I do recognize that the JVM is a powerful common runtime, and purely server-side Java is a pretty common and reasonable technology choice.

Ruby on Rails (2011). Square introduced me to Rails. I had a taste of Model-View-Controller (MVC) web frameworks before via Python, but Rails for me took that idea and just ran with it. I learned a bunch of core development concepts by the way of Rails: Object Relational Mappings, schema migrations, Behavior-driven Development and Testing, library and versioned dependency management, etc. On top of the pure technology bits, the Rails practitioners I worked with also brought on tenets of Extreme Programming, to the tune of development practices like pair programming, test-driven development, open contribution models, and the like.

My time with Rails was honestly a good one, and I suspect that’s in large part due to its sweet spot in terms of development scale. Ruby itself is meant to be fun for programmers to write, and the monolithic Rails framework is designed for speedy development via common conventions; combined, it takes only small teams of engineers to get a lot of features done. Rails starts creaking with too many developers and expectations of scale and performance, which itself signifies a much larger engineering organization and company.

CoffeeScript (2012). I really shouldn’t have included CoffeeScript on my list. It was a flash-in-the-pan language, a Python/Ruby look-a-like with concise syntax whose biggest benefit was compiling into common JavaScript patterns (e.g., for loops and function definitions), particularly before browsers widely supported ES6. In hindsight, CoffeeScript didn’t save that much typing, but the cost was inscrutable JavaScript behaviors from misaligned white space. It has become a rite of passage for a front-end team to blog about decaffeinating from CoffeeScript back to JavaScript.

—

Of course, after all of this language accumulation and evolution, I transitioned from software engineering into management, in which I’ve picked up entirely new skillsets like email composition and extreme calendaring and spreadsheet programming6.