Mad Max with car. © Warner Bros. Pictures

we were actually trying for a qualitative shift in belief structures—a new Kuhnian paradigm in the same spirit as the invention of the printing press—and thus took highly extreme positions which almost forced these new styles to be invented.

— Alan Kay, The Early History of Smalltalk

As I’ve become more familiar with the history of projects like Sketchpad, Smalltalk, and Self, I’ve been fascinated by the qualitative difference in approach their builders brought to programming system design, compared to most recent languages. These were systems that flowed out of a distinct philosophy and the intent to change the world. If existing language or interaction paradigms were insufficient to realize the goal, new ones had to be invented. If the implementation couldn’t keep up, new implementation techniques had to be created.

Among other advances, we have this approach to thank for the HotSpot compiler, technology originally created to make dynamic programming in Self feasible on 1980s hardware.

By contrast, most programming languages I’ve worked with professionally were born from much less ambitious visions. Usually, the vision amounted to “help programmers serve the computer more easily”, or sometimes “be like $older_language, only a little less painful”. My language of choice for the last ~10 years, Ruby, is very much in this vein. Most of the design decisions that cause me to love it turn out to be difficult to explain to someone who has learned to program in Ruby. Things like “optional semicolons” and “open classes” are less exciting if you haven’t spent the preceding five years coding in Java or C#.

Programming in 2015 feels a bit like Mad Max sometimes. Most of the “new hotness” technologies are cobbled-together bits of older technologies. And where there is innovation, it is often in service to the cold gods of performance or predictability, rather than opening new vistas of computer-mediated creation. Witness the rise of languages like Go (“C with GC and CSP”), Rust (“C++, but less horrible”), Elixir (“Erlang, but less horrible”), and Clojure (“Lisp without the cruft and mutability”).

These are all great languages, with a lot to recommend them. They are languages I use and enjoy. But they are are languages that exist because someone said “I like programming as we know it, I just want to change X and Y”. Or, alternately, “I’m tired of programmers screwing X up. Let’s disallow it completely.”. These are fundamentally derivative ideas.

Building incremental improvements on old things is good and important work. But in the 60s, 70s, and 80s, people like Alan Kay and Ivan Sutherland dreamed bigger, and even their “failures” changed the face of programming and computing. I wish I could point to areas where this kind of transformational, philosophically-driven innovation is being performed today. But if it’s happening, I haven’t come across it.

Published by Avdi Grimm


  1. Would you count ?

  2. Check out intentional software. It’s hard to find detailed information online though.

  3. I’ve add this mad max feeling in the context of Rails and JavaScript heavy projects: runners, builders, packers, linters, deployment tools, …

    Go and elixir feel very consistent in this regard with their go / mix / iex toolbelt.

    Evolution takes many forms and from a generation to the next, the criteria & pressure of selection may shift. I believe tooling and interoperability to be among top criterias.

    Oh, and maybe you could compare this “madmax” effect to the “heterosis” phenomenon.

  4. I am, at least, trying!
    It’s a meta-editable website; everything you see there including the editor is editable at the site. It compresses the entire web stack into a single language, so you don’t need to learn much of anything to make a database-driven web app or use cloud-based APIs. It doesn’t attempt to be “nextgen” instead it’s better understood as making the last gen simple.

    For a demo, I used it to make something new:
    which lets anyone send SMS text messages from Minecraft redstone signals. It’s less than 500 lines of code in total.

    To see it being programmed for my next demo:

    The philosophy behind it I would describe as “Nintendo builds the 100 year language”. Like I said, I’m trying! I’m motivated by the incredible difficulty of programming. I’d rather see amateurs build stuff and it’s not really possible for an amateur to build a web app these days despite how much easier it has become.

    • Whoah! That definitely looks like something along the lines of what I’m talking about.

      Thanks for your reply. I’m going to queue this up for a closer look.

      • Thanks for looking! Please note the neat feature in the documentation: you can add an example to a Sandbox, then interactively edit the example from the documentation immediately.

        Don’t hesitate to ask a question, I’m curious to see someone beat on it in a new way.

  5. I’d be curious to know your thoughts about Perl6 – it’s both exactly what you’re critical of “it’s like C/shell/whatever, but easier”, but it’s also got a lot of very serious (and time consuming to the order of most of a decade) language design and thinking put into it…

    • As a language nerd—and as an old-time Perl hacker—I’m quite interested in it. But that’s sort of the point of this article: there’s plenty going on for the language nerd in me to be happy about. Lots of incremental advances in how programmers can write text files to tell computers what to do.

  6. What about Idris?

    Basically it’s Haskell with dependent types, but it’s sort of astonishing how much code can be automatically completed and inferred when you get the signatures right.

    • Idris is a terrific example of what I’m talking about. From a language design nerd’s perspective (such as my own) it’s brilliant. But it’s just another, slightly improved way for programmers to write text files in order to get the machine to understand them. By asking programmers to specify ever more advanced type contstraints, it’s basically asking programmers to be even more esoteric high priests than ever before. It’s what I meant by serving the “cold gods of predictability”.

  7. What about Subtext: and Dedalus: There are lots of great ideas to help developers solve problems, but I guess most developers want to continue writing down each and every tiny step the computer must do.

  8. looks pretty interesting. It is an old concept, but looks like they’re doing a good job of modernising it. I came across it here

    • Interesting! I’ve done some work in a visual dataflow programming language in the past, and found it a somewhat problematic paradigm. But I’ll definitely take a closer look at this. Thanks!

  9. It’s hard to be truly innovative; paradigm shifts (e.g., Kuhn) are tricky.

    It’s hard for me to see a major change in programming that hasn’t already been at least explored: I’ve thought visualizing large code spaces and providing even stronger contextual awareness is the next step–but I’ve seen countless experiments come and go without any sticking power. Even some of the beautiful things I’ve seen come out of research papers don’t have the staying power to be transformative.

    Lipsticking the pig is all we’ll have for the immediate future: without that lipstick building something transformative is probably too hard to get started.

    • I think the key is that Kay et. al. were never really thinking about “changes in programming”. They were thinking about how humans use computers to accomplish goals, with “programming” as just a (possible) piece of the puzzle.

      I’ve been reminded by some of the other comments here that there ARE a few scattered individuals and groups still working along similar lines.

  10. Working on it. I’ll keep you posted.

  11. I understand the advantages of plain text, but I’m surprised by how little interactive graphical representations of code are used to refactor it. I think the next big jump will be to retain a clean and simple text representation, but you’ll move between various graphical representations of code. For example, when exploring new code, it would be nice to explore it in terms of various interactive UML diagrams. And when debugging, I’d like all code that isn’t related to a particular failed test case to be cleanly removed. I’ve no idea how to do this for programming, but I’ve had a go for maths.

    Ket ( is a new way of performing algebra on a computer. It’s a text editor but for algebra. It displays lists of equations in regular maths notation (mark-up) and is written in plain text (mark-down).

    What makes it different is that, with experience, you can solve algebra problems as quickly as on paper, but with the advantage of undo, copy/paste, a built in calculator and algebra-simplification.

    Algebra consists of a series of transformations and combinations of equations. As a result, the editor is built around ‘modal editing’ — making a lot of quick and simple edits.

    To facilitate this, editing can be done with a keyboard or mouse. Click-and-drag algebra is available, for example dragging a term in a product to the other side of an equation to divide through by it. And common operations (like duplicating an expression) can be performed by mouse gesture (right-drag up). But for faster and more general editing, various (Vim-like) keyboard commands exist to rapidly edit an expression.

    Ket is a structure editor which represents an equation as a tree (i.e. a list of lists). Each branch of the tree is a function that contains other functions (or operands). It is obvious that such a tree structure also represents a line of a functional program.

  12. Also check out crystal, it’s essentially a statically typed and compiled ruby.

  13. […] >> Programming in a Mad Max Wasteland [] […]

  14. There’s a huge amount of work going on right now on what I will loosely call “principled higher-order imperative programming”. You may not hear about it because it’s research in progress in academia (and we know it usually takes two or three decades before such research gets out into the wild). For example, self-adjusting computation and the propagator programming model and much more. We have seen nothing yet. Twenty years from now, I guarantee people will be going “how come we didn’t pay attention to what was going on”? People are quietly tackling hard problems all over the map, and it’s not necessarily out on Twitter or GitHub (although some is, and that’s cool, because collaboration is great).

  15. […] “Trying to use it wrong”. That’s a red flag for me. It’s a phrase that’s often indicative of the deep-seated meme that we just need to do a better job of serving the machines. A lot of programmers believe this, either consciously or unconsciously. A lot of programming languages are built on this idea. […]

  16. […] “Trying to use it wrong”. That’s a red flag for me. It’s a phrase that’s often indicative of the deep-seated meme that we just need to do a better job of serving the machines. A lot of programmers believe this, either consciously or unconsciously. A lot of programming languages are built on this idea. […]

  17. This is really inspirational and I love to hear the new philosophies of programming.
    I find those people and ideas are hard to find.
    I feel like there are too many people to listen to and the big companies seem to push the languages and ideas now.

    This makes me a little sad but I would love to see software and languages that change the world.


Leave a Reply

Your email address will not be published. Required fields are marked *