Computing stuff tied to the physical world

Ahavascript

In Software on Dec 16, 2012 at 00:01

I learned to program in C a long time ago, on a PDP11 running Unix (one of the first installations in the Netherlands). That’s over 30 years ago and guess what… that knowledge is still applicable. Back in full force on all of today’s embedded ┬ÁC’s, in fact.

I’ll spare you the list of languages I learned before and after that time, but C has become what is probably the most widespread programming language ever. Today, it is the #1 implementation language, in fact. It powers the gcc toolchain, the Linux operating system, most servers and browsers, and … well, just about everything we use today.

It’s pretty useful to learn stuff which lasts… but also pretty hard to predict, alas!

Not just because switching means you have start all over again, but because you can become really productive at programming when spending years and years (or perhaps just 10,000 hours) learning the ins and outs, learning from others, and getting really familiar with all the programming language’s idioms, quirks, tricks, and smells.

C (and it its wake C++ and Objective-C) has become irreplaceable and timeless.

Fast-forward to today and the scenery sure has changed: there are now hundreds of programming languages, and so many people programming, that lots and lots of them can thrive alongside each other within their own communities.

While researching a bit how to move forward with a couple of larger projects here at JeeLabs, I’ve spent a lot of time looking around recently, to decide on where to go next.

The web and dynamic languages are here to stay, and that inevitably leads to JavaScript. When you look at GitHub, the most used programming language is JavaScript. This may be skewed by the fact that the JavaScript community prefers GitHub, or that people make more and smaller projects, but there is no denying that it’s a very active trend:

Screen Shot 2012-12-14 at 15.53.14

In a way, JavaScript went where Java once tried to go: becoming the de-facto standard language inside the browser, i.e. on the client side of the web. But there’s something else going on: not only is it taking over the client side of things, it’s also making inroads on the server end. If you look at the most active projects, again on GitHub, you get this list:

Screen Shot 2012-12-14 at 15.57.09

There’s something called Node.js in each of these top-5 charts. That’s JavaScript on the server side. Node.js has an event-based asynchronous processing model and is based on Google’s V8 engine. It’s also is phenomenally fast, due to its just-in-time compilation for x86 and ARM architectures.

And then the Aha-Erlebnis set in: JavaScript is the next C !

Think about it: it’s on all web browsers on all platforms, it’s complemented by a DOM, HTML, and CSS which bring it into an ever-richer visual world, and it’s slowly getting more and more traction on the server side of the web.

Just as with C at the time, I don’t expect the world to become mono-lingual, but I think that it is inevitable that we will see more and more developments on top of JavaScript.

With JavaScript comes a free text-based “data interchange protocol”. This is where XML tried to go, but failed – and where JSON is now taking over.

My conclusion (and prediction) is: like it or not, client-side JavaScript + JSON + server-side JavaScript is here to stay, and portable / efficient / readable enough to become acceptable for an ever-growing group of programmers. Just like C.

Node.js is implemented in C++ and can be extended in C++, which means that even special-purpose C libraries can be brought into the mix. So one way of looking at JavaScript, is as a dynamic language on top of C/C++.

I have to admit that it’s quite tempting to consider building everything in JavaScript from now on – because having the same language on all sides of a network configuration will probably make things a lot simpler. Actually, I’m also tempted to use pre-processors such as CoffeeScript, Jade, and Stylus, but these are really just optional conveniences (or gimmicks?) around the basic JavaScript, HTML, and CSS trio, respectively.

It’s easy to dismiss JavaScript as yet another fad. But doing so by ignorance would be a mistake – see the Blub Paradox by Paul Graham. Features such as list comprehensions are neat tricks, but easily worked around. Prototypal inheritance and lexical closures on the other hand, are profound concepts. Closures in combination with asynchronous processing (and a form of coding called CPS) are fairly complex, but the fact that some really smart guys can create libraries using these techniques and hide it from us mere mortals means you get a lot more than a new notation and some hyped-up libraries.

I’m not trying to scare you or show off. Nor am I cherry-picking features to bring out arguments in favour of JavaScript. Several languages offer similar – and sometimes even more powerful – features . Based on conceptual power alone, I’d prefer Common Lisp or Scheme, in fact. But JavaScript is dramatically more widespread, and very active / vibrant w.r.t. what is currently being developed in it and for it.

For more about JavaScript’s strengths and weaknesses, see Douglas Crockford’s page.

So where does this leave me? Easy: a JS novice, tempted to start learning from scratch!

Tomorrow, some new considerations for middleware…

  1. Love your products and have followed your blog from the start.

    You mightCheck out Bitlash Commander (https://github.com/billroy/bitlash-commander) for my take on a javascript-based node.js server to support the Arduino and company.

    Best,

    -br http://bitlash.net

    • Thanks for the interesting link! I couldn’t yet make it work smoothly on MacOSX (display quirks on Safari, and no response to the setup button on either Safari or Google Chrome) – but then again, I only gave it a very quick try so far. I also haven’t hooked up an Arduino or JeeNode with Bitlash yet. Will have a closer look to try and understand what’s going on.

  2. I think another lesson of C/Unix is defining the role of the operating system en libraries: Not just a ‘hardware abstraction layer’ but enabling to use the same program (Space Travel) on a different system (PDP-7->PDP-11) with no or only minor modifications. They didn’t provide record filesystems etc just ‘stream of bytes’ to the application, ‘blocks of bytes’ to the OS.

  3. A few weeks ago I started rebuilding my domotica software using node.js using a distributed architecture where everything communicates using MQTT. It is working quite well.

  4. Re: Commander: Happy to follow up about bugs and problems either on the GitHub issue tracker or via email.

    Best regards,

    -br

  5. I use NodeJS on my Raspberry PI for parsing my entire JeeNode-Network-Data :)

    http://www.sysrun.de/2012/12/projekt-der-zitronenwachter/

  6. In addition: There are great Modules out for NodeJS. For example bencode de/encoder and much more. Helped me a lot

  7. Nice. JS is looking better and better for this sort of stuff… can you elaborate on the software setup you’re using? I’m currently looking into SocketStream on NodeJS.

  8. You can take a look in my code: https://github.com/sysrun/node-homemanager

    No Userinterface right now, only parsing and COSM

  9. I have also been using Node.js to build a home automation system. I will open source it in Q1 2013 after adding timers, and plots of historical states. I have selected Node.js because I wanted an interface for mobile devices, updated live using push notifications. Keeping many open idle TCP connections is easy with Node.js.

Comments are closed.