Computing stuff tied to the physical world

Goodbye JeeMon

In Software, Musings on Jun 6, 2012 at 00:01

As long-time readers will know, I’ve been working on and off on a project called JeeMon, which bills itself as:

JeeMon is a portable runtime for Physical Computing and Home Automation.

This also includes a couple of related projects, called JeeRev and JeeBus.

JeeMon packs a lot of functionality: first of all a programming language (Tcl) with built-in networking, event framework, internationalization, unlimited precision arithmetic, thread support, regular expressions, state triggers, introspection, coroutines, and more. But also a full GUI (Tk) and database (Metakit). It’s cross-platform, and it requires no installation, due to the fact that it’s based on a mechanism called Starkits.

Screen Shot 2012 05 23 at 19 26 10

I’ve built several version of this thing over the years, also for small ARM Linux boards, and due to its size, this thing really can go where most other scripting languages simply don’t fit – well under 1 Mb if you leave out Tk.

One of (many) things which never escaped into the wild, a complete Mac application which runs out of the box:

Jeex128

JeeMon was designed to be the substrate of a fairly generic event-based / networked “switchboard”. Middleware that sits between, well… everything really. With the platform-independent JeeRev being the collection of code to make the platform-dependent JeeMon core fly.

Many man-years have gone into this project, which included a group of students working together to create a first iteration of what is now called JeeBus 2010.

And now, I’m pulling the plug – development of JeeMon, JeeRev, and JeeBus has ended.

There are two reasons, both related to the Tcl programming language on which these projects were based:

  • Tcl is not keeping up with what’s happening in the software world
  • the general perception of what Tcl is about simply doesn’t match reality

The first issue is shared with a language such as Lisp, e.g. SBCL: brilliant concepts, implemented incredibly well, but so far ahead of the curve at the time that somehow, somewhere along the line, its curators stopped looking out the window to see the sweeping changes taking place out there. Things started off really well, at the cutting edge of what software was about – and then the center of the universe moved. To mobile and embedded systems, for one.

The second issue is that to this day, many people with programming experience have essentially no clue what Tcl is about. Some say it has no datatypes, has no standard OO system, is inefficient, is hard to read, and is not being used anymore. All of it is refutable, but it’s clearly a lost battle when the debate is about lack of drawbacks instead of advantages and trade-offs. The mix of functional programming with side-effects, automatic copy-on-write data sharing, cycle-free reference counting, implicit dual internal data representations, integrated event handling and async I/O, threads without race conditions, the Lisp’ish code-is-data equivalence… it all works together to hide a huge amount of detail from the programmer, yet I doubt that many people have ever heard about any of this. See also Paul Graham’s essay, in particular about what he calls the “Blub paradox”.

I don’t want to elaborate much further on all this, because it would frustrate me even more than it already does after my agonizing decision to move away from JeeMon. And I’d probably just step on other people’s toes anyway.

Because of all this, JeeMon never did get much traction, let alone evolve much via contributions from others.

Note that this isn’t about popularity but about momentum and relevance. And JeeMon now has neither.

If I had the time, I’d again try to design a new programming environment from scratch and have yet another go at databases. I’d really love to spend another decade on that – these topics are fascinating, and so far from “done”. Rattling the cage, combining existing ideas and adding new ones into the mix is such an addictive game to play.

But I don’t. You can’t build a Physical Computing house if you keep redesigning the hammer (or the nails!).

So, adieu JeeMon – you’ve been a fantastic learning experience (which I get to keep). I’ll fondly remember you.

  1. are you planning to work on a jeemon replacement in the future? which programming language would you use then? just as a side note, I love Tcl because I could achieve some useful things without being a real programmer myself and I have really enjoyed the Tcl wiki since the old days…I am a fan of your work past, present and future. Thanks.

    • Thx for your kind words. Yes, I would like to work on a JeeMon replacement – but don’t wait up for it, I won’t announce anything before there is something of substance. And that may take a while – it’s not at the top of my list right now. Programming language choice? Dunno – I’ve seen em all. Plenty to choose from…

  2. I am a newcomer to “JeeWorld”, have just built my first few JeeNodes and started planning to implement JeeMon. I am enjoying the rediscovery of both electronics and programming. I trust JeeMon will stay around (if only with peer-based support) until its next-generation replacement arrives? You have made a great contribution to the world, jcw, so I hope you don’t let the frustration dampen your spirits!

    • Thx. Yes, JeeMon will stay around. It’s in use in a couple of projects here, and I know a few people are using it.

  3. Personally, I would with C or Python. C because it is :) Python because is easy to learn, easy to debug, OO from the scratch and multiplatform.

  4. The RaspberryPi is nearly standing before my door (I hope :-) ) and I planed to use JeeMon on that as a central “server” – so your post about stopping the project came at the right moment – before spending time setting it up.

    Do you know of any other software like JeeMon & Co to build a home controlling system which is also usable with your famous JeeNodes?

  5. Well, I have never used JeeMon and the other modules. I plan to acquire also quite a lot of data for home automation. Quite a while ago I read an article about http://www.solarvista.de/. They use Nagios to acquire, process, store and visualize sensor data (see Anlage Neuried – Baubeschreibung). Nagios or its fork Icinga are apparently well-maintained open source software – originally to monitor servers – that “only” needs to be adopted to the desired use. Not knowing all the features of JeeMon, it looks to me as if might be worth to have a look at it as a possible basis for a replacement for JeeMon without the need to completely rewrite from scratch.

  6. I used and tried JeeMon several times, but every time I used it or had to change little things I found it very very very very difficult to understand the Tcl language.

    I recently switched to HomeSeer. Completely something different of course compared to JeeMon, but now I can concentrate myself again on the JeeNodes as interfacing a JeeLink to HomeSeer has been done before…

    So Goodbye JeeMon, it has been nice working with you ;-)

  7. I’m also slowly trying to setup some homeautomation. And have been following: http://www.houseagent.nl/. It should have jeelabs support in the near future. Its written in Python.

  8. Would be a sad heading, if not content. Well, I’m sure some people knew Tcl is dead by 2005. Please choose Python – that’s the Lisp for the real world. And thanks for the blog – reads like an adventure book.

  9. As a long-time tcl user, I’d like to thank JCW for his inspiring contributions to the tcl language culture, especially tclkit/starkit technology and metakit. With these two tools I once wrote, in a very short time, a complete multi-platform GUI program that included a very large database (built-in to the executable) as a single starkit executable, which required no library installation or special run-time. I doubt I could have done so in another environment.

  10. Only good things can come from this move.

  11. Well, I hear what you are saying – the two points you make, about Tcl not keeping up, and about people’s perceptions on Tcl being incorrect.

    Last year my teenage son was on a school holiday, loitering with not a lot to do, so I set him a very simple programming task, got him to program it up in about 10 different languages (including Python, Ruby, Perl, Tcl, C, Java, C++, etc). The solution was just a bit of looping, involved a few variables, and printing to the screen. He hadn’t programmed before (and not since as well!).

    His favourite was Python. The reason? Easiest to understand and least characters to type. Simple as that. Pyhton also has a good reputation, you can do just about anything with it, it has good libraries for doing all kinds of things, so it’s a bit of a no brainer from the perspective of a new programmer.

    So all those great features that Tcl has, some you mentioned in your blog, don’t get ‘discovered’. Oh well!

    I think Tcl is a bit “scripty” (if that’s a valid word), with it’s command based syntax, variable and command substitution. And that puts a lot people off straight away I think.

    I code more in Java and C than Tcl, but I actually like Tcl syntax. I’m using Tcl in some open source projects, for very good reason – Tcl seems to be a very good fit for what I want to do.

    Take a look at ttask, and in particular the arduino uno build script at http://pdt.github.com/ttask.html.

    I like the fact the build script, although written in a programming language, doesn’t look like it’s written in a programming language, if that makes any sense. I like the fact that the script is filled with a command based syntax, not too dissimilar to the commands one would type in to a terminal. I think Tcl is very appropriate for that project. (btw, thanks also for tclkit :)

    I’m also using Tcl in a testbenching environment. For example, see http://pdt.github.com/script-tb_uart_tx_ex.html . Tcl is itself very malleable, and as a result, with Script-tb, I can write testbenches using tcl very succinctly (and quickly!). If you look at the binary and johnson counter examples, equivalent VHDL and Pyhton test benches are shown, and I prefer the Tcl testbench to both the alternatives, for obvious reasons (at least to me :)

    With regards to your JeeMon, if you wanted it to become more popular, you could have given it more of a chance by putting up more documentation, good quality documentation. Is there a good introductory example somewhere, with a home network, with say some JeeNodes controlling some blinds, and such things? Some nice screen shots? Something like that would be very useful. I know Tcl, but wouldn’t be able to work out how to use JeeMon from your website, but maybe I didn’t look hard enough for the documentation…

  12. Working with very small embedded Linux machines, I had a similar problem of finding a good scripting language that people could extend. Perl, Python, etc are all too heavy for many environments and Tcl seemed to fit the bill until I noticed the OpenWRT project was using Lua.

    Lua has been amazing for me. It’s small, very fast, very easy to bind to C.

  13. I also wonder what will you use as a replacement. For my own work I try to base things on HTML5 with a small server in Lua (you used Lua quite a lot in the past, didn’t you?). I even have quite a lot of things already working. :)

  14. I tried some Jeenodes – I have followed the Jee project almost from the start.. brilliant work except when it comes to making it accessible to a larger group of users – TLC broke my back and Im pretty sure im not the only one. I have set up systems with php, sh, rrd but TLC was to much for me and I never got a “hello world” to work – Jeenode is like Lego for me, but the manual is written i latin . I hope to see a server-side system soon that can make use of Jeenodes for us non latin-speaking non-programmer types – we are the 99% ;-)

    Regards Mikkel

Comments are closed.