Communication over Implementation

Last week I wrote a post about some of the statements that percolate in my mind when designing Ioke. What I didn’t mention was that these ideas are things I use to judge other programming languages too. I would say that this philosophy pretty much captures my views on programming languages. (The post in question is here: The Ioke Philosophy). So, this post is of course not complete, and I don’t think I would ever be able to write something that is totally complete.

One of the things missing – and I did allude to it in the post – was a statement that has grown on me a bit. I did a presentation about Ioke last week, and at that point I decided I needed to talk about this some more. The statement in question is what I call Communication over Implementation. This turns out to be pretty important for programming languages in general, at least in my experience.

One of the things I’m fond of saying when talking about programming languages, is that programming languages – just like natural languages – are about communication. And we don’t necessarily always think clearly about who we are communicating with. The immediate and intuitive reaction to programming languages is that they are supposed to communicate with the compiler/interpreter/cpu. That is of course true, but it is also incidental in many cases. There are many ways in which you can communicate with the machine to get it to achieve something. So the question becomes what other parties should you consider when communicating.

The next most obvious party would be yourself. If you ever need to read your code, you need to write code in such a way that you can read it later on. This constrains the way you write code quite severely. There are reasons we don’t write much code in assembly language or JVM bytecodes anymore. Yes, at some level these descriptions are extremely nice communication towards the executing machine, but they are so bad at communicating with human stakeholders that the balance generally ends up in favor of more readable languages.

When communicating with human stakeholders the thing I focus most on is intent. If your code/text communicates the intent of what you are trying to do in a good way, this makes it easier to read. There are many movements that focus on how to do this well, where domain domain design and clean code are the two that immediately comes to mind for me.

So coming back to the title. For me, implementation is a special sort of communication – that kind of communication that is supposed to be functional and describe what should actually be done in deterministic instructions to a machine. As long as this communication is functional enough – meaning that the machine does more or less the right thing – there is much leeway in how the code can be written to make other kinds of communication easier. And that is the core of this argument. A language should make it easy to communicate with other stakeholders than the machine, since those other forms of communication with code is actually much more important than only the implementation pieces. Yes, if the implementation works your program might run for a while – but if no one can read the code it can’t be maintained, it can’t be understood except in a black box way, and the utility of the system will be limited.

Go the other way. If you have a program that communicates badly with the machine (but still well enough according to the above definition), but it is written in a clearly communicating way, this means that it is easier to grow the system, it is easier to fix it or implement it more correctly. It can also easier be replaced since the program communicates what it is doing.

There are exceptions to this principle. But we seem to to favor languages that are focused on implementation and only incidentally on communication. This is the wrong choice and it need to be fixed. Communication is at the core of programming, and should also be the focus of it.

9 Comments, Comment or Ping

  1. Right!

    May 19th, 2009

  2. This is exactly right.
    I have seen it written in a number of places that code should be written to be read by people (I have a blog post that explains some mechanics, hopefully relevant)
    There is also the similar principle regarding Essence over Ceremony. It’s hard to be expressive if your language insists you place noise words all over the place.

    May 19th, 2009

  3. Haha, sounds like you’ve been to one of my Aesthetic Programming tutorials ;-) Needless to say, the sentiments of this post align perfectly with the message I try to get across and I therefore totally agree with you.

    Another way of stating this is by saying that I believe that the pursuit of conceptual efficiency is at least as important as computational efficiency. That is to say that achieving conceptual efficiency allows you to more effectively communicate the concepts to your target audience. Doing this well means that the audience has to perform very little thinking and interpretation to understand what you’re trying to communicate. I imagine this as a bullet of pure thought-stuff from one mind to another with no interference as it flies through the air; clearly not fully achievable but a meritable goal to chase.

    I truly believe that there is great benefit in this field if more people start perceiving programming as a form of communication. Let’s just hope that others also realise this sooner rather than later.

    May 19th, 2009

  4. Seo Sanghyeon

    I think this amounts to saying that programming languages are user interfaces. Therefore programming languages should be *designed*, and programming language creators should learn principles of good design.

    And you know, user interfaces are more messy to code than algorithms. This is not a fault. It just represents that users (human beings) are more complex than machines.

    May 19th, 2009

  5. vc

    The first file i’ve read was ikanserve / src / ioke / ikanserve.ik

    10 lines total. First line:
    IKanServe = Origin mimic ; module

    bind(handle(Condition Error Load, fn(c, “no application defined” println. invokeRestart(:ignoreLoadError))),

    Surely this is communicating something but certainly not with a human:)

    This “expressiveness” is a good illustration of frightening “worse is better” principle in action.

    May 28th, 2009

  6. VC: What’s the problem meant to be?

    May 28th, 2009

  7. vc

    Code looked too low level to me, intent of code is not clear enough. Sorry, Jason, I was wrong. That was my first impression, now I became more familiar with Ioke and I don’t think that’s a real problem. After all I can write some macro to make any syntax I like for this task.

    June 1st, 2009

  8. Paolo Lim

    kind of like readability over efficiency. : )

    June 2nd, 2009

Reply to “Communication over Implementation”