Computing stuff tied to the physical world

TK – Programming

In Software on Jun 21, 2012 at 00:01

Welcome to the Thursday Toolkit series, about tools for building Physical Computing projects.

Time for a different subject. All the tools discussed so far have been about electronics and computing hardware.

But what about the flip side of that computing coin – software?

As mentioned recently, software has no “fixed point”. There’s no single center of its universe. Everything is split across the dimension of programming language choice. We’re operating in a computing world divided by language barriers – just like in the real world.

Here’s the language divide, as seen on GitHub (graph extracted from this site):

Screen Shot 2012 06 20 at 19 51 36

Here’s another one, from the TIOBE Programming Community Index:

Screen Shot 2012 06 20 at 22 28 27

(note the complete lack of correlation between these two examples)

It’s easy to get carried away by this. Is “my” language up? Or is it down? How does language X compare to Y?


Programming language choice (as in real life, with natural languages) has huge implications, because to get to know a language really well, you have to spend 10,000 hours working with it. Maybe 9,863 if you try really hard.

As we learn something, we get better at it. As we get better at something, we become more productive with it.

So… everyone picks one (or perhaps a few) of the above languages and goes through the same process. We learn, we evolve, and we gain new competences. And then we find out that it’s a rabbit hole: languages do not inter-operate at a very low level. One of the best ways to inter-operate with other software these days is probably something called ZeroMQ: a carefully designed low-fat interface at the network-communication level.

The analogy with real-world spoken languages is intriguing: we all eat bread, no matter what our nationality is or which language we speak (bear with me, I’m simplifying a bit). We can walk into a shop in another country, and we’ll figure out a way to obtain some bread, because the goods and the monetary exchange structure are both bound to be the very similar. Language will be a stumbling block, but not a show stopper. We won’t starve.

In the same way, you can think of information exchanges as bread. If we define appropriate data structures and clear mappings to bits and bytes, then we can get them from one system to the other via libraries such as ZeroMQ.

Which brings me to the point I’m trying to make here: programming language choice is no longer a key issue!

What matters, are the high-level data structures we come up with and the protocols (in a loosely defined manner) we use for the interactions. The bread is what it’s about (data). Money is needed to make things happen (e.g. ZeroMQ), and programming languages are going to differ and change over time anyway – so who cares.

We should stop trying to convince each other that everything needs to be written in one programming language. Humanity has had plenty of time to deal with similar natural language hurdles, and look where we stand today…

I feel reasonably qualified to make statements about languages. I speak four natural languages more or less fluently, and I’ve programmed in at least half a dozen programming languages for over two years each (some for over a decade, and with three I think may have passed that 10,000 hour mark). In both contexts, I tend to favor the less widespread languages. It’s a personal choice and it works really well for me. I get stuff done.

Then again, this weblog is written in English, and I spend quite a bit of my time and energy writing in C. That more or less says it all, really: English is the lingua franca of the (Western) internet, and C is the universal language used to implement just about everything on top with. That’s what de facto standards are about!

So what will I pick to program in for Physical Computing, embedded micros, laptops, and the web? The jury is still out on that, but chances are that it will not be any of the first 12 languages in either of those two lists above.

But no worries. We’ll still be able to talk to each other and both have fun, and the software I write will be usable regardless of your mother’s tongue – or your father’s programming language :)

Let’s focus on our software design structures, and our data exchange formats. The rest is too ephemeral.

  1. But I the hobbyist will still have to invest quite a bit of time learning the quircks of yet another programming language if I want to be able to use the idea/function/program written in it. I can read most languagues without extra training but actually programming in them or adapting other people’s programs in that language and using their toolchains are a whole different ballgame. So, as a hobbyist with another goal than pure programming, I like to a) have command of the most-encountered languages and b) avoid the time and effort of having to learn the more obscure ones. Software is where everyone invents it’s own hammer, just to be able to create a chair. So choice of language is still a key factor for the “means-to-an-end” hobbyist. I do agree that explaining the structure/function/program is something that does not need code at all.

    • Understood. I hope the following can be accomplished: a binding in one or more of the popular languages, to communicate with a system written in language X. No matter which “mainstream” language I were to pick, I’d still get comments from people using another mainstream language. Suppose your world is Python – and I decide to go with Javascript and Node.js ? It’s similar to MySQL: the world is not forced to use C in their applications.

      There is really no other way: I pick what works well for me (who knows, it might even be your favorite language!), and we focus on interoperability from day 1. That’s exactly what the ZeroMQ designers did. I can easily write a couple of popular-language bindings/wrappers/proxies/stubs – whatever you want to call them – but the whole system needs to be language agnostic. A telephone system connects the world – it does not dictate the language (bit weak as an analogy).

  2. I always think of cars in that perspective. You really pick a car for two reasons:

    1. Because it’s suitable for the job
    2. Out of personal preference

    If you have a large family, you won’t buy a car that will fit only 2 persons inside. When you’re driving off road, you don’t pick a ferrari.

    The same thing goes for programming languages: you pick the right tool for the job based on it’s suitability, and your personal preference.

    Apart from maybe suitability, there is no “bad” choice.

    • Agreed – but I think you’ve essentially moved the issue into the term “suitability”. With middleware, there may not be overlap in what each side considers suitable.

  3. Thanks for the 0MQ pointer, JCW! I wish we could use it for communications between interrupt service routines and main program on our JeeNodes ;-)

  4. Found a very nice introduction, with Python examples to try, on ZeroMQ at

  5. jcw I think your going down the right path here. I good backplane (like zeromq) that that can easily bind differing tools together is what I am looking for. It allows different and unexpected tools to be integrated.

    In fact zeromq would probably my choice too. Light weight doesn’t try to do too much. Lots of bindings.


  6. JCW, I thoroughly agree. I’ve been using a similar messaging system for a while – mqtt ( in conjunction with node, python, etc

  7. I understand this message in part to be a followup to your announcement that you were abandoning Tcl for JeeMon. I ascribe at least part of Tcl’s unpopularity to the fact that a good many Tcl’ers picked up on the idea early that programming language doesn’t matter: remember that SWIG, MIME, and even parts of the idea of browser extensions were born in the Tcl world in the early 1990s. The attitude of, “sure, if you don’t like Tcl, whatever, we’ll work out a way to interface to your stuff,” is sensible but doesn’t sell the language!

    And that said, I still have that attitude. I’m interested to see where you go with Lua or Forth or whatever language turns out to be right for your tiny-platform scripting. Which makes me part of the problem with Tcl that you were complaining about. Sorry.

    And like you, I live in English and C, with occasional forays into other computer and human languages. I’ll always have a soft spot for Tcl and I’ll likely continue to try to advance its development – because it’s a good fit to the way I think about programming – but I recognize that it’s one amongst many.

Comments are closed.