There should be more people like James Mickens

Warning: in an attempt to blog more in general, and maybe less seriously so, here’s some lighter material than usual. I hope that at some point the usual material will be preceded by a similar disclaimer, announcing some “heavier material than usual”.

I’m a fan of James Mickens. I wish there were more people like James Mickens (well, turns out that there are, kind of, but that’s beside the point). James Mickens is a man who combines genius, benevolence and humor into a grand holistic theme that will take mankind to new heights.

James looks like this:


And he writes like this:

I don’t know all of the answers in life, but I do know all of the things which aren’t the answers, and JavaScript falls into the same category as Scientology, homeopathic medicine, and making dogs wear tiny sweaters due to a misplaced belief that this is what dogs would do if they had access to looms and opposable thumbs.

And like this:

Anyways, my point is that browsers are too complex to be trusted. Unfortunately, youth is always wasted on the young, and the current generation of software developers is convinced that browsers need more features, not fewer. So, we are encouraged to celebrate the fact that browsers turn our computers into little Star Wars cantinas where everyone is welcome and you can drink a blue drink if you want to drink a blue drink and if something bad happens, then maybe a Jedi will save you, and if not, HEY IT’S A STAR WARS CANTINA YESSSSS.

And like this:

These are not the best people in the history of people, yet somehow, I am supposed to stitch these clowns into a rich cryptographic tapestry that supports key revocation and verifiable audit trails

That’s all. Go watch his talks and read his papers:

There’s plenty more, of course, and Goog^H^H^H^HDuckduckgo is your friend.


Hoare’s billion dollar idea

Folks, I propose that we forgive Tony Hoare for his billion dollar mistake. Yes, he invented null, and of course all the trouble that got us in is his fault. Fortunately, he also invented CSP, one of the many formalisms for dealing with multiple things happening at the same time. I believe that CSP may end up being his multi-billion dollar idea, more than repaying his null debt to society.

Complicated Scientific Papers

In the time when Hoare invented CSP (1978), every CS professor came up with his own formal language for roughly the same thing. CSP however, has two particularly fantastic features that separate it from the crowd.

First of all, while CSP itself is pretty theoretical and fundamental in nature, most people combine the CSP primitives to roughly the same higher-level building blocks, and these are pretty easy to understand. Secondly, and most importantly, these building blocks are actually in programming languages! Sure, it took us programmers more than 35 years to figure it out (okok except Joe Armstrong, who did it in 8), but still, it’s there!

I’m talking, of course, about channels and processes like they exist in Go, Erlang, Clojure (core.async) and a bunch of other languages. Nitpickers will immediately complain that Erlang doesn’t really have channels because it follows the Actor model instead, but you can simulate channels with actors and you can simulate actors with channels, so I’m going to completely gloss over that difference from here onwards. The most important part are processes and we have those in all these languages.

Processes are awesome!

The idea of a process is a piece of code that actively does something and occasionally tells others about it. It looks and feels a bit like a thread, except that you don’t have to think about how much a resource hog threads can be. Also, because you’re not supposed to use shared data, you don’t have to think about mutexes and all that other stuff either. You use messages for sharing data.

For example, in a UI application, you could have a process that polls for mouse click events. “Wait”, I hear you say, “don’t mouse clicks usually come from some sort of event loop? Why poll?”. Indeed they do, but the fun about processes is that you don’t really care about that. Even if in some weird UI system, you’d need to actively poll for mouse clicks, you can make the process work exactly the same from the outside.

This mouse-click-poller process could report clicks, with some additional event information, on a channel, and any other process that is interested in mouse clicks and receive messages on that channel. This feels a bit like normal event listening, but the fun is that the mouse-click-poller can also do some other processing on the event. Maybe make the event object easier to consume for listeners, do some post-processing or cleanup work, and the listeners don’t need to change how they work at all.

This is fantastic separation of concerns, and allows for excellent composability. You could have a process that listens on channels of mouseup, mousedown and mousemove events and produces drag events on another channel, for instance.

Cute little robots with opinions

Many other programming languages allow you to do similar things. For example, C# gave birth to the excellent Rx library and has fancy language-level async/await support which allow you do so a similar thing. In fact, composing multiple lower level mouse events into drag events is sort of the “Hello World” of Rx. As another example, you can’t call yourself a competent JavaScript developer these days without embracing promises or streams something comparable. These are all great tools for dealing with asynchronicity and concurrency, but I feel like they all, at least in some ways, make a program more complex to understand. I want my program to be simpler.

Being able to treat everything that has some sort of active behavior to it as a separate process is a truly liberating experience. I first had it when learning Elixir, a language based on Erlang, in which such processes are a native feature. Many programmers had it when learning Go and writing their first goroutine. I find that “behavior”, as vague a concept as it is, is a much more important thing than “asynchronicity”. Therefore, I believe that is not the right solution to add language level support for things like “async methods” (C#) or “async return values” (JavaScript promises, Scala futures, etc). As a caller of functions, I shouldn’t really care whether something is async or not, I should care whether I’m interfacing with this independent, active thing over there (like a cute little robot with an opinion) or a simple function that turns some input into some output (like the calculator on my desk) (okok the calc.exe in my Run dialog). Cute little robot? Process. Calculator? Function.

The world’s most popular programming language

You can imagine my happy joy when I finally got around to reading James Long’s excellent blog post on putting CSP processes in JavaScript. If you do any frontend coding, do yourself the favor of at least skimming through his post. To me, this style of programming feels so much better and cleaner than promises or callbacks or all that mess, that I can hardly fathom it. Fair enough, it requires ES6 generators, which in turn require either hyper-modern browsers, or a Node.js fork built by irresponsible hippies, or compilers like Regenerator which produce horrible JavaScript. But hey, we have source maps anyway, so who cares about what the browser sees?

I truly believe that the future of anything that has asynchronous or concurrent behavior, which is nearly any piece of performant software really, lies in the concept of CSP-like processes. Processes are to futures, tasks, async/await, and promises what garbage collection is to malloc() and free(). The latter burden the programmer with, in my eyes, unnecessary implementation details in the vast majority of cases. I want to organize my program into a number of cute little robots, not into a big bag of functions that may or may not have asynchronous behavior and oops you forgot to catch() that promise and what the hell just happened in which order again?

Processes are the future, futures are not, and it is now.

I am going to use JS-CSP in all my future frontend projects. I’m going to avoid languages on the backend that don’t either natively have processes or have a great library that supports it. Dear C#, I truly love you, but you’re out the door for me until you get your concurrent act together. Processes are great, all the other stuff is not, and I have CSP to thank for it.

Is CSP going to be Tony Hoare’s billion dollar idea? I think that maybe it already is.

Named parameters for humanity!

I had a little insight today.

Many modern languages, including my current favourite toy C#, support passing parameters by name. For example, consider a method like this:

public State MoveRobotArm(
    double position, 
    bool throwOnErrorState = true, 
    bool simulated = false)

Notice how its last two parameters have default values, which means we can omit them if we want. We can now call this method like this:

    var state = MoveRobotArm(50.0, simulated: false);

We’re skipping the second parameter and assigning a value to the third. This is what named parameters were intended for. However, it’s also remarkably readable! Now, if you came across code like this:

    MoveRobotArm(50.0, true, true);
    var state = MoveRobotArm(0.0, false, true);
    if(state != State.OK) ...  // handle errors

Would you be able to guess what the MoveRobotArm calls do? There’s some things to deduct. The number is probably a position, and given that we throw away the return value of the second MoveRobotArm call, we’re either crappy coders or one of the booleans help manage unexpected situations.

Recently, I started writing such code like this instead:

    MoveRobotArm(50.0, throwOnError: true, simulated: true);
    var state = MoveRobotArm(0.0, throwOnError: false, simulated: true);
    if(state != State.OK) ...  // handle errors

It’s a minor difference, but it makes the code much more readable. You don’t need to look up the signature of MoveRobotArm to figure out what’s going on.

The self-documenting power of named parameters works especially well when booleans are used as flags. You could also write an Enum for each option and have it be equally self-documenting, but that feels like a lot of boilerplate. This is the same, but with comparably little boilerplate. Similarly, when methods take many parameters of the same type, it is very helpful to the reader if the parameters are named on invocation.

Down the rabbit hole

Note from the editor: That was the end of the blog post. The rest is just mindless rambling.

I’m starting to think that it would be a nice idea for some new programming language to force callers to name arguments be default. I think it’d make 80% of code more readable (and hardly more cumbersome to write, assuming you have a decent IDE). But not always: you wouldn’t want to have to write Math.sin(value: 5.0) for instance, it’s ridiculous.

So you need an escape for allowing unnamed parameters, but we can leave it up to the author of the function to decide whether to allow that or not, using some extra syntax.

Essentially, for most current programming languages, function parameters are an ordered list of mixed types. I’m proposing that it’s, by default, an unordered collection of name-value pairs (i.e. a struct, object, record, whatever). You can then have syntax to allow one or more unnamed, ordered, parameters as well, if you really want to. You’d get maybe something like:

    void CallMyMother(int phoneNumber, string message) ...
    // OK:    CallMyMother(phoneNumber: 123456, message: "Hi Mom!");
    // OK:    CallMyMother(message: "Hi Mom!", phoneNumber: 123456);
    // ERROR: CallMyMother(123456, "Hi Mom!");

    string Diff([string a, string b], bool caseSensitive = false) ...
    // OK:    var diff = Diff("aaabb", "aaacc");
    // OK:    var diff = Diff("aaabb", "aaacc", caseSensitive: true);
    // ERROR: var diff = Diff("aaabb", "aaacc", true);

    double Sin([double value]) ...
    // OK:    var slope = Sin(2.0);
    // ERROR: var slope = Sin(value: 2.0);

Something like that. I’d like that.

IoC containers: prozac for software architectures

I think Inversion of Control (and Dependency Injection, basically the only decent way to do IoC in OO languages) is a great idea. We do it all over our Izooble codebase, for example: it enables testability and encourages us to keep independent things separated. I believe that Dependency Injection is one of the few good design patterns that still make sense in modern OO languages. I suspect that it, too, will at some point be superseded by a programming language designer’s great idea, but right now I can’t imagine what that would be.

What I do think is wildly overrated, is IoC containers. I don’t see their added value over explicitly injecting a dependency into a class’s constructor. It’s the singleton antipattern in disguise, and with an IoC container it’s very difficult to see what is going on, because, magic. It’s even worse when the IoC container is configurable with something other than code (e.g. Spring.NET’s horrible, horrible, horrible XML abomination), because that actively encourages messing around with live servers* instead of fixing your damn deployment pipeline.

If you avoid IoC containers, you’ll typically end up with a Main method that instantiates a whole bunch of objects and passes them to other objects again. That Main method is an excellent summary for your entire application’s architecture. You can see how all the important components are tied together at a single glance.

Now, when your application grows, when you do this, two things tend to happen:

  1. Some class constructors, those high in the composition hierarchy, may need a very large amount of injected constructor parameters, just to pass them through to a class way down the tree. Well that’s cumbersome.
  2. Your Main method becomes a ginormous 100-line list of new operators.

Somehow, people take this as a sign that they need an IoC container, so they can hide the monolithic, highly coupled contraption they inevitably grew their application into.

The real solution, of course, is to fix the architecture. Split the application into multiple independent components that only have few dependencies on each other. In fact, you can use a nearby whiteboard to trivially turn your Main method into a tree diagram so you can see how to best cut your application into pieces. Maybe you’ll need to reverse some dependency arrows here and there (events to the rescue – or Observer if it’s 2002 and all you have is Java). You’ll end up with a bunch of independent parts, with the old content of Main spread across constructors of Facade-style entry point classes in these parts. Congratulations, you just forced yourself to fix your architecture by stubbornly avoiding IoC containers.

I really don’t understand why some programmers insist on hiding their bad designs from their own view. It’s like they don’t want to know that things are becoming a mess. IoC containers are to architecture what .NET regions are to classes.

* Or robots, or machines, or whatever your software runs on.