Mad Max with car. © Warner Bros. Pictures

Programming in a Mad Max Wasteland

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.

37 comments

    1. Oooo cool. Love the goals of that project, and hope it works out, though it will make my skills using vim to bang together code and munge text much less marketable!

  1. 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.

      1. Oh yes, they are but one of their distinctive trait is tooling, from the beginning. Both have strong lineage, home schooled by strong parent figures too.

  2. I am, at least, trying! http://boomtree.com
    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: https://boomtree.com/r2p
    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: https://www.youtube.com/watch?v=odRHjaHD4gk

    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.

    1. 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.

      1. 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.

  3. 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…

    1. 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.

    1. 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”.

    1. Good call. I’ve been following Jonathan Edwards for a while, and I do believe he “gets it” as far as what I’m talking about in this article.

    1. 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!

  4. 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.

    1. 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.

  5. 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 (http://sourceforge.net/projects/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.

    1. I’ve blogged about Crystal before. It’s another example of what I’m talking about. I think it’s great, but it’s just “Ruby, only static”.

  6. 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 http://www.umut-acar.org/self-adjusting-computation http://plum-umd.github.io/adapton/ and the propagator programming model http://groups.csail.mit.edu/mac/users/gjs/propagators/ 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).

  7. 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.

Comments are closed.