Programming languages are stuck in the 80s
Maybe I’m “beating a dead horse” here, but I haven’t thought about programming languages in this particular way before, so I decided to share the thought anyway:
Most programming languages I know are designed like it’s still 80’s, and all we have are textual interfaces, and single-core CPUs.
Well, the last part isn’t entirely correct so to speak - many languages have support for multithreading, it’s just the fact that they often still list it as a feature even though we have multi-core CPUs in the home segment for 25 years now. And even if the support for parallelization is present, you often have to go out of your way to use it. Moreover, we now have GPU computing, and a lot of stuff gets computed on GPUs today, but how many programming languages have native support for that in their standard library? Even if not for GPU computing, how many languages do you know that have a way to display a window without relying on an external library that basically contains bindings to some toolkit written in C?
Look, Java, despite all the hate, can create a window with AWT. You might still wonder, why am I saying this like it’s something special? Well, because if you look at most other languages’ standard libraries, you’ll see that even if they have a lot of useful stuff, like networking, OS stuff, etc - it’s really nothing special as of today. All this stuff is there and has been there since the 80s. Except, some languages from the 80s still have more features.
I know, more languages have GUI facilities. Microsoft’s C# has facilities for GUI programming for the Windows operating system. Apple’s Swift has SwiftUI, which is one of the main ways to do GUI for Apple products. I guess Kotlin has Compose, and there’s Dart with Flutter, but I have mixed feelings about these platforms, so I’ll not delve into them. Linux… we’ll get to that.
Notice how both C# and Swift are basically platform-specific? It would be strange for these languages not to have a GUI library of sorts, because if the vendor language doesn’t provide you with one how else would you do GUI for that system? Similar thing with Kotlin and Flutter but they’re more phone-oriented, and the situation there is a bit different than on the desktop.
Well, C programmers have written multiple toolkits, like GTK, and C++ programmers have Qt, which looks decent, but then, these are not part of the language. And for Linux, this means that there’s no central way to do GUI - the most popular choices are GTK and Qt, but if you choose GTK you’ll have poor integration with Qt-based desktops, and vice versa. In simpler cases, you can use something like SDL, and just create a window, and then draw anything you want. It’s a shame though, that this isn’t just available in the language. A language that is being used for both writing a kernel, the userspace, and the GUI running in that userspace - the language itself doesn’t have the means to create a simple window. I mean, there’s Vala, but c’mon.
Nowadays, Rust people, whose main focus is to rewrite everything in their language of choice (what language is it, btw?), are reinventing GUI toolkits all over again. Why doesn’t Rust have its own GUI library that supports all of the major operating systems? Especially given the origin of Rust is a web browser - in other words, rendering graphics should be pretty natural to Rust. Can a language really call itself modern without an inbuilt GUI library, in a world where everything runs with some kind of GUI?
The same goes for pretty much any other language that calls itself “modern” - you can call yourself that all you want, but if you can’t do something that most languages from the ’80s could, then define “modern”. And don’t come to me with all this “modern approach to programming” - garbage-collected bytecode interpreter isn’t modern. If you have a JIT and state-of-the-art GC algorithm, your VM is highly dynamic and modifiable, we can talk, but then again - does your language provide anything more than the other ones apart from subjectively nicer syntax and opinionated standard library? Pretty much all new languages are toy projects - rare few really do bring new things to the table, and deserve being called modern.
There’s an amazing talk, which I realized contains mostly everything I wanted to say in this post but in a better form: Stop Writing Dead Programs. I do recommend watching it and trying out the technologies mentioned in the talk. Many of these had a major influence on how I see most languages these days.
But let’s get back to GUI’s for a bit - what’s funny, actual languages from the 80’s didn’t have this problem.
Take for example Smalltalk - it had a lot of GUI capabilities pretty much since it was developed. Remember Xerox? They had Smalltalk with a GUI interface running on Xerox Alto in 1979! Since then we had all kinds of GUI systems available, yet so few languages took advantage of that.
Symbolics had Lisp Machines running GUI in the 80’s. Lisp itself was about 20 years old by that time, yet it got GUI support pretty much instantly everyone started doing GUI! After a bit of digging, I found that MIT Scheme had graphics support at least since 1995, but definitively since even earlier - I just couldn’t find any documents before version 7.3 to confirm. But I’m sure of it because it was used in the SICP book, and its first edition had the graphics programming section in it since the 1980s. Racket, one of the modern Schemes, has a GUI programming library bundled with the language, if you choose so. And it supports all major operating systems.
Tcl is yet another example. It’s from the 90s, but it also had GUI programming capabilities via the Tk toolkit since 1991.
I mean, sure - it’s obvious now why command line utilities, and TUI libraries are still hot even today, in 2024! Because most languages only know how to talk to standard out! Then we have curses, various TUI toolkits written in Rust or Go of all things, and still using an emulator for VT100 - a piece of tech from 1978. I guess, targeting VT100 is easier, than targeting some specific toolkit/window manager/display server/whatever, yet some languages manage somehow?
And today you don’t have to do even that - we have cross-platform browsers that run everywhere. Take JavaScript - another language many people openly hate. Yes, it has quirks in the design, and yes it has performance issues, yet we use it every day because it can draw on the screen in the browser! And visuals are the main way we perceive the world Wide Web. And a lot of people I know, fell in love with programming because they can actually see the results of their code immediately!
People realized that we had such poor options for GUI programming with all these system languages, GUI toolkits, static types, yada yada, and made Electron. Kudos to them, now we can build GUIs in JavaScript, without relying on any particular toolkit for better or worse.
I don’t have any false beliefs in browsers being a proper way to do this kind of stuff - if anything, I want a web browser to be a simple thing. A web browser. Not another glorified VT100 that, instead of parsing escape codes, parses JavaScript. I don’t want to run software in a browser. If you need a cross-platform way to write apps with facilities similar to what the current state of the web provides - use something other than the browser. Even Electron would be a better fit.
I know, I know, Electron is just stripped down (maybe not) Chromium, but I still think it’s better than running in a browser because it’s still a separate thing. Browsers have a specific workflow built in, and when the app tries to override it, it always works horribly (think shortcuts). Recently, with the introduction of WebAssembly and WebGPU now we have the option to draw something in the browser using other languages than JavaScript, and maybe even with more performance. Maybe in a few years, we’ll get something slimmer than Electron, with a better dynamic language that will utilize WA, and thus will become the next application platform. Though I don’t want to be too optimistic.
Speaking of application platforms, Emacs is one such application platform, again from the 80s. Look at it this way, Emacs has a runtime with GC and compilation to machine code, some GUI capabilities, and a language that can change how Emacs works almost without any limits. People have been writing applications for Emacs for many years now.
Like browsers, Emacs runs on multiple systems, and applications developed for Emacs run on different systems, if you don’t use platform-specific stuff too much. However, Emacs can’t really compete with browsers in terms of user interactivity. Well, you can have interactive stuff, it’s just janky. If you see someone saying things like Org Mode is basically Jupiter Notebook on steroids - ask them to create sliders in Org Mode that dynamically update variables in a code that is then plotted in 3D in real-time. You can do 3D plots in Org Mode, sure, interacting with 3D plots is the problem.
I mean, I’m glad I can plot the data and display the graph as an inline image in the REPL while working on some project, but can we have this instead? I’d like to see projects like Glamorous Toolkit for more languages. Now, that’s modern.
I’ve spent a major part of this post talking about GUI specifically because, well, all of my devices have a GUI, yet I can’t pick a language and draw a window with it. Recently I made a post speculating how Emacs could get a GUI library, and while I understand that this is ambitious, I still think having a decent GUI library and arbitrary drawing capabilities as a part of the language can make a great application platform.
OK, I understand, that making something good with these in-house GUI libraries is often a daunting task. Most Java AWT apps I’ve used look horrible. Same for JavaFX, Swing, etc. C# kinda can make a decently looking app, if decent means looking like all other Windows apps in your book. And other GUI libraries, that try to mimic OS GUI guidelines, like Racket’s library are fine, but you can’t really make an appealing app with that either, because you do want to design an app for each respective system, follow their guidelines, and so on. Not only that - OS GUIs are getting worse by the year too. And I think desktop OS GUIs are getting worse partly because of advancements in mobile GUIs.
The smartphone industry gave another shake to GUI programming because it is a different medium with different control schemes, and thus we have new ways to do GUI. And platform languages, as I mentioned, have decent GUI programming support. Yet, people still often just want to bring something like React Native, because it is easier to make an interface in it, and ship it to all platforms, instead of developing several GUIs. So we have the Electron situation on our hands all over again.
But I don’t want you to think that I believe that GUI is the only thing that makes a language modern - no, of course not. Just, let’s put it this way - go and research a bit of programming language history, and you’ll probably find a lot of interesting things. Like the fact, that JIT compilation was a thing in APL of all things in 1979. Forty-five years ago.
Anyway, what I wanted to say with this post is simple. We already have 65+ years of programming language history, yet, most new languages seem to completely ignore most of it, repeating what’s been done in the earliest years, calling it modern.