Just remembered Paul Graham's essay from earlier in the year. It really spoke to me (what with my bias towards the agile, experimental, piecemeal, wiki-natured, wabi-sabi way of design).

Of course it's my road-map for the ongoing development of Mind Traffic Control.

Day 2 of Mind Traffic Control in public.

Development continues with MTC exporting OPML

Mind Traffic Control roll-out continues.

Nothing spectacular in terms of numbers, but friends are making interesting comments and suggestions; and some strangers are discovering it via the Twitter announcement.

Eikeon pointed to twemes as a place to search for the #tag #MTC on Twitter.

Good chat with Folknology. He's encouraging me to open up the data. Hence I did CSV export of your tasks. Al, likes RSS/Atom but I still need to find out whether feed-readers can do the required Google login to get at a non-public feed.

Rup3rt weighed in with a number of comments starting :

Wow an invisible list machine almost like a gumball/toy dispenser ...

and continuing

I like to see what is ahead but it is good with the delegation - I can line up things for the estagiarios. This is great for non-negotiables like driving instructions, recipes.

* The font for "This task was delegated to you .. may report the sender for blacklisting and delete this task" is a bit big

* I would like a difficult autoaddress (1gg23ff3d3reedd@mindtrafficcontrol.appspot.com) to delegate tasks by email and maybe I could get other tasklists to feed into MTC using this (to just top it up with priority1 or todotoday tasks)

* Maybe paste a list of (line break delimited) tasks that are automatically added

* Maybe show in a widget

* Maybe show total number of tasks

* How would time estimates of task duration fit in? It could be a diversion to see "You have 13 hours of traffic to negotiate")

Good suggestions. I'll be interested to know what everyone else thinks.

But here are some initial thoughts :

Font issue, yep. Mailing tasks in to Mind Traffic Control would be great; a very useful addition. But I'm not yet sure I can do it on the Google Application Engine.

I might be able to do it using another hosting service but that's introducing a lot of new complexity into the system : running two different hosting services, writing scripts on the old-skool one to pass emails it receives into MTC in some way, being responsible for security (how do I stop spammers mailing tasks to you via the system?) etc. Going to take a while to figure that one out.

Importing other formats and / or entering multi-line, multi-task lists is easier and more likely to appear soon. I'll definitely go for the multi-line input box in the short-term future. I'd be interested to hear what formats readers currently use for to-do lists so that I can import them. I immediately think OPML, of course. But are there others?

Widgets ... actually I've been playing with OpenSocial and Orkut Widgets for my other GAE project. It's cute ... but I'm not yet sure what I'd put in a MTC widget.

Task counts and time estimates I'm ambivalent on. I don't want to make MTC a paranoia inducing space where you arrive on the front page to be presented with something saying "Welcome to Mind Traffic Control. You have 280 outstanding tasks". On the other hand, I see that people would like some sort of overall measure of what they have to do. More thinking on this.

Finally, there's a couple of issues of "philosophy", particularly why I'm resistant to letting you flag tasks with "priorities" but leaving that for the next post when I'll be more coherent.

Softlaunch ... no fanfare ...

Mind Traffic Control

This is my first Google Application Engine application. A kind of next-action list for the Twitter generation.

Basic instructions :

1) You need a Google account to login (eg. Gmail) ... it's a GAE app.

2) There's a blue box for inputting tasks you need to do. Once you start entering them, Mind Traffic Control will show you your next action.

3) At which point you have a choice. Say you did it. Delay it (push it to the back of the queue). Delegate it to another user. Defer it to a future date. Or delete it altogether.

4) Keep going.

There are a couple of ideas behind this. First, that people have been getting too hooked up on the idea of "organizing" their tasks and actions into lists. But organization itself isn't really an end, it's a means towards making sure you remember and discover your tasks, as a means towards the ultimate end of getting stuff done. So instead of thinking of tasks as list-management, Mind Traffic Control treats tasks as un-structured flows.

The real focus is on capturing the tasks as quickly and easily as possible. So, inspired by Twitter and Folknology's Rel3, the input box is always there at the top of your page.

The other focus is when the task is presented to you. At this point you need all your options to quickly route the task. In a more static system we might say route into particular "bins" but here it might be better to say "channels" (unless it's the ultimate sink of "done" or "deleted".

Another idea ... it's meant to be the simplest workflow that could possibly work. Just short messages which can be routed. Everything else has to be constructed by humans on top of this. But as, once again, we've seen with twitter, it looks like humans are pretty good at filling out these communication channels.

Anyway, off to bed ... will write more posts here soon ...

please have a try with Mind Traffic Control, and if you have any comments, feel free to post them here.

I've now been playing with GAE for a couple of weeks, and it's still looking pretty good. I've now got an Orkut developer account so I can make Orkut widgets tethered to a GAE based service.

Meanwhile looks like GvR has been doing some cool stuff within Google with internal development tools, and has just released it to the outside world, thanks to GAE giving us access to BigTable etc.

The change in mindset needed for GAE

Zed Shaw's take on GAE is entertaining.

Now this is very cute :

[(f.title,f.key()) 
    for f in db.GqlQuery("select * from Film order by title")]

See that? A GQL (query language for GAE) query object automatically supports iteration, so you can use it in a list comprehension.

OK ... better start finding out about Google App. Engine

Damn! Don't think I was in the first 10,000 applicants for a beta ... got the downloadable development environment though ... watch this space ...

Update : Actually, I did get one ... :-)

Ruby on Javascript VM?

Sometimes you need to take a step back from a problem, to see the forest for the trees.

GeekWeaver was being held up by something that seemed a rather complicated knot; one that I've wrestled with a number of times but never really untangled to my satisfaction.

So last night I decided to restart with a clean slate. I didn't look at the existing code or existing unit-tests. Didn't even open my IDE or project file.

I just started up IDLE and in a single file, redid the whole thing from scratch, in a fast test-driven stylee.

Amazingly I think I've come out with a cleaner solution, messing around with fewer classes and no attempt to over-re-use with inheritance. The whole thing took about two hours total. Of course, it's not quite finished, and still needs to be integrated back into the main codebase. But I like it a lot more. It's shorter and easier to understand.

Sometimes (at a certain granularity) old code *is* more of a burden than an asset. Understanding what it does and what you can do it is a cognitive cost that outweighs its value. Don't be afraid to throw code away when you need to.

Caveat for small granularities. Obviously rewriting an entire application from scratch is a different matter.

Sweet Expressions ... great idea for making S-Expressions more like other, more readable programming languages

without losing their power (such as generality, macros, quasiquoting, homoiconicity, and easily-manipulated program fragments).

Hat-tip Folknology

Wow! I need to get into Buildout.

Update : Good blog-post accompaniment

Very interesting. Recently my "ProgrammingInWiki" page on WardsWiki seems to have come back to life. Along with a companion WikiIDE.

A WikiDE is, of course, something I've been working on in the background for some time. But I'm far from having anything to show yet. So if these guys get there first, good luck to them.

I just want to be able to start working this way.

Damien Katz has more interesting comments about Erlang's "ugliness".

(hat-tip @Folknology)

I've been wondering what Ward Cunningham's been up to at Eclipse. Jon Udell is on the case : Interesting tools for software developers.

Apparently's Ward's now at a wiki-startup. (Mark Dilley seems to be involved too.)

Cobra seems to be like Python with optional compile-time type-checking and other quirks removed.

It also has contracts, which ensure certain conditions when calling a function. However, wearing my new Erlangish hat, I wonder what contracts buy you over pattern-matching arguments?

Unit testing built in to functions is interesting. Not sure what I think of that .... yes, it's useful and convenient. But a) it may clutter up clean code (I tend to let a certain amount of messiness leak into my unit-tests, that I don't let into my code); b) it's not so easy to see how it can be used for test-driven development - how can I write my test before my class? And, worst of all, c) I tend to use unit-tests when refactoring and moving functionality from one class to another.

It's very simple to change a :


x = MyClass()
self.assertEquals(x.f(4),10)


into


x = MyClass2()
self.assertEquals(x.f(4),10)


and have my unit-tests already defining the new target I'm aiming for.

But if the test is is actually *part* of MyClass, then that's going to require more premeditated moving stuff around during my experimental refactoring.

I'm way too busy now ... but I'm having some kicking ideas about my own grandiose bid to improve programming ...

... think GeekWeaver in an SdiDesk-alike editor (obviously).

Then imagine that *everything* is a template.

That's the way that GeekWeaver is already going. Everything is a template (ie. has named slots that can be filled). Function calls are just the injection of a data-block into that template. Another way of putting it, all objects know how to handle the "call" message with a data-block as argument, even if they don't do anything very useful with it.

But now imagine that all the types of things you can get in SdiDesk ... text pages, grids, network diagrams, are also templates. And you can plug and pipe them together any way you like. One page can hold a table, another a network diagram-shaped template, and a third can be specified as the result of injecting the first into the second.

Hmmm ... this definitely looks like it's going in the right direction.

Somehow I feel I should be exploring WikidBase

Looks clever ... and in Python.

Here's a question ... why is Erlang so ugly?

I don't mean that in a pejorative way (not much, anyway). I mean, I really love what it does. I'm totally impressed with Erlang's power and simplicity. I'm writing simulations which are about a quarter of the size of the Python equivalent. So this is not to be taken as a criticism of Erlang which I'm definitely committing myself to, this year. Rather this is some random speculation about programming language aesthetics.

Erlang is wonderfully concise. And yet, somehow, unlike Python, unlike Haskell, it just doesn't come across as beautiful. It's confusing. It looks cluttered.

A couple of lines look fabulous. But the simplicity doesn't scale.

At first guess, there seem to be three issues.

a) As people have noted, the record type is ugly. It is. And counter-intuitive to use in patterns (although I may just be stupid).

b) In general I think it's good and brave thing to take a stance *against* objects. But I haven't figured out how to do encapsulation (data-hiding, abstract types)

Sure, I can define polymorphic functions (one clause at a time per input type) which is a lot shorter and more powerful than overloaded methods in Java. But it has the effect of jumbling all my data-types together. Which just feels *wrong* to me. (Of course, maybe that's some residual OOness in my thinking.)

But I think that may be part of the bigger issue :

c) erlang doesn't seem to have resources for "programming in the large". And, ironically, because erlang is so powerful, that problem becomes visible at a smaller scale - precisely because in erlang "large" programs are actually "small".

Or rather, the only resource is "modules" (which means breaking up into multiple files - always an extra overhead.)

But if you avoid breaking things up into files, the opposite problem becomes apparent. I can do the equivalent of a small Java class (let's say something around 50-80 lines) in about 6 to 10 lines of Erlang. But 10 lines of erlang is too small for a separate file. So I'll add the next 10 line packet of functionality to the same file. By the time I'm up to 4 or 5 packets that would be handled as different classes in Java or Python I may have written only about 50 lines of code ... but it's all running together!

There's no higher level of organization to distinguish and separate the code. In Python I often put 5 or 6 small-medium classes in a single file or around 300-500 lines. But the indentation and editor make these reasonably distinct and identifiable. In contrast, my equivalent 200 lines of Erlang have no visual cues to break them up. I can't use functions as a visual element because pretty much every line is a new function (except when I'm doing I/O, which has its own "issues").

I'm left with using comments but my editor (Komodo), excellent in many ways, doesn't actually know Erlang and so doesn't colour them differently. And, in general, because functions are powerful, they *are* short : one or two lines. But those lines are typically much denser than Python. Even if a dedicated editor would colourize them, I'm not convinced that's such a big win at this density. On the other hand, I don't want to artificially scatter them out into multiple lines. I'm not trying to recreate Python with a slightly less appropriate syntax. I want to take advantage of Erlang's power and conciseness.

But I wonder what the right aesthetics for a language as high level, dense and abstract as Erlang is. Haskell looks cleaner to me - maybe because it does abstract data-types right. But can it solve the problem of organizing your larger-scale things? Lisp is no role-model. ML and its offspring have always repelled me visually. (Nothing can be more ugly, dispiriting and patronizing in a programming language than an explicit "begin" statement.)

Suggestions, anyone?