For about a month now, I've been experimenting with a new way to develop code. No more edit-run-debug cycles. No more shell commands, scrolling output, or command history. Here's a screenshot of how I work:



Click for full image - my real setup uses larger windows, filling an 1680x1050 screen.

The top-left is a Camino browser, with underneath it an iTerm window showing the stdout/stderr log. On the right is the TextMate editor. This is all MacOSX, clearly.

The text on the screen explains a bit what's going on. The reason this works so well, is that I'm developing inside a running process - something people working in Common Lisp and Smalltalk/Squeak take for granted. To work on some stuff, I add a new test page with a mix of comments and embedded Tcl calls. The central motto here is: Render == Run. Unlike interactive commands, the test page does all the steps needed to reach a certain state, and shows any output I want to see along the way. On a separate page in the browser, I can browse through all namespaces, variables, arrays, open channels, loaded packages, and more (what "hpeek" did, but far more elaborate). Apart from crashes and startup-related changes to the code, the server-based development process is never stopped. I can add calls to try out new code, and then decide after-the-fact what details to look into. Then, I just edit and hit F6 to fix or finish the code, whatever. Last but not least, one of the test pages runs a Tcl test suite, which gets added to as soon as the newest code stabilizes a bit. So again, it's a matter of keeping that page open in the browser and hitting F6.

This approach has already paid for itself many times over (the "cost" being only my time spent on it, evidently).

People who've visited me at home know that I'm a huge fan of total silence. I've taken considerable steps to end up with an office which is totally quiet (and consumes virtually no power as a nice side-effect). An obvious tip: turn off what you don't constantly need. Better still: make stuff turn off by itself after a certain time. Slightly less obvious but very effective: use 2.5" USB-powered external HD's where possible (on my NSLU2-based server, and attached to my MacBook Pro for Time Machine backups). Disk capacity is no longer an issue.

As I said, the result is perfect - and music is fun again, even at a very low volume.

Which makes this post hilarious ;)

Cool, it looks like I'm in very good company with my position on threading - Mark Roseman singles out exactly my point:

"Now that the best and the brightest have spent a decade building and debugging threading frameworks in Java and .NET, it’s increasingly starting to look like threading is a bad idea; don’t go there. I’ve personally changed my formerly-pro-threading position on this 180º since joining Sun four years ago."

See Tim Bray's weblog for more.

Update: more good company - Donald Knuth has this to say:

I won’t be surprised at all if the whole multithreading idea turns out to be a flop, [...]

and about multicore:

How many programmers do you know who are enthusiastic about these promised machines of the future? I hear almost nothing but grief from software people, [...]

Read the interview for context.

I am going to break the golden rule that I should keep my personal views to myself at all times. I suppose this rule evolved because knowing where someone stands on certain matters might offend people with different opinions, and blogs like these should be about work and work-related views.

Well, I don't care. The professional world we live in is so detached from the human condition by now, that I need to draw a line. Not a day goes by where I don't think about world events and the personal tragedy associated with them. The buck stops here. I no longer want to blog about "fun stuff" without exposing that other side of me.

The article that led to all this is an interview with Robert Fisk. Which made me realize that today, wars are waged by proxy - the actors are a bunch of young kids we don't know, and the witnesses tell stories we hear little about. Soldiers and reporters (oh, and some collateral damage). With our televisions and computers as the ultimate proxy.

I try to imagine the reality on the ground in a conflict zone such as the middle-east, from any perspective. And I can't really. Imagine growing up or growing old in such a context. Day to day, for years on end. The mind boggles. When I merely broke my leg a few months back, an immense safety net of family, friends, medical care, compassion, personal attention, and empathy unfolded itself. Then, in accurate lock-step with my recovery, that same safety net retreated, going on standby again just as automatically. Life is darn good here, not according to some metric, but because of the knowledge that no matter what happens, life will still eventually work out ok. It's hard to imagine two situations further apart than life over here and life over there. The horror being that much of this is due to armed, man-made, conflict. Why, with all our culture and technology, are we as a whole still living in medieval times?

The injustice on this planet is obscene.

Google is entering the web application service business, a bit like Amazon's S3 + EC2, but going considerably further by also including a Ruby On Rails mechanism (based on Python and Django, though). This 10-minute video gives an fantastic overview:



It's particularly interesting to see how the workflow comes together with just TextMate and Safari, there is no explicit compile or even save, it's all based on a single mechanism: Render == Run. Which, as it turns out, is exactly how I've been doing my own small-scale web app development - based on an internal package called Mavrig. This is the way to build web apps, if you ask me, all the way to the deployment approach used at the end of the above video.

Ok, so "all" I have to do now is finish Vlerq and Mavrig, to show how Tcl + Metakit technology can achieve the same effectiveness, but with an order of magnitude less complexity than Python + Django (+ SQLite in local mode, presumably).

I wonder how long it'll take for this to show up on iPhones and iPod Touches...