Good overview of PBWiki's corporate wiki business.

Age distribution of StackOverflow users (hat tip mfeathers)

I mentioned that I think StackOverflow is totally amazingly wonderful, right? :-)

Interesting. Reia's Tony Arcieri debunks Erlang's "single assignment" propaganda.

I guess someone could argue that once you have multiple assignment you're going to be more tempted to write a longer chain of actions as a sequence of statements rather than composing it out of multiple functions ... and this may be a bad thing.

But I've ranted often enough against languages which think its their job to constrain programmers that it better not be me who makes that argument.

Update : I'd like to see Frederik's question about closures (in the comments of that blog-post) answered though.

Update 2: Ulf Wiger points out that it got answered by Robert Virding later in the comments.

Follow on from yesterday's "Python / Haskell crossbreed" post. Both Al "Folknology" and Gleber point me at the Reia programming language. A Python / Ruby like scripting language on top of the Erlang Open Telecom Platform (Erlang's parallel virtual machine).

Very sweet ... I've subscribed to the mailing list to find out more.

Prediction I made :

I predict that in five years time, the hot language will either be a version of Python which has adopted ideas (Pattern matching arguments, Monads, immutability etc.) from Haskell; or a Haskell-like language which has borrowed some syntactic sugar from Python.

Don't know if I entirely believe that, but it's a good conversational gambit. And there's a certain logic to it if you look at the languages visually.

I'm personally, more into investigating Erlang at the moment, mainly because it seems more practical. The fast, parallel virtual machines are here and ready to go. But I could see myself looking back at Haskell too if it seemed to be gaining momentum.

I guess I also like the Erlang story on concurrency through message passing rather than transaction memories. And perhaps the whole typing thing is overdone in Haskell, although I can certainly see that it buys you more in that context than in, say, an OO language.

But I'd really love to see someone come up with mashup of the best bits of Python, Erlang and Haskell. It would *look* more or less like Python, although would find some-way to do multi-line lambdas etc. Like Haskell and Erlang it would have pattern matching arguments, functions defined over several definition statements, and immutable state. Like Erlang there'd be processes and messages as standard. Like Haskell, monads. Classes might be more like Haskell.

How might a language like this look?

 class Tree(val,left,right)
 def size(None) : 0
 def size(Tree(_,left,right)) :
    1 + size(left) + size(right)

Note that what's in brackets after the word Tree is neither a super-class (as in Python) nor a list of types as in Haskell nor a definitive list of field names. It's something more like information that a Tree is a tuple of three elements. And that by default they're called val, left and right.

These default names for the elements of the tuple can be over-ridden in functions which deconstruct a Tree using patterns. For example, the size function doesn't care about the initial val element and so leaves it blank.

I just thought of trying to make size a method of the class Tree. The syntax might then look something like this :

 class Tree(val,left,right) :
    def size(Tree(_,left,right)) : 
       1 + left.size() + right.size()

Where, obviously, the object itself is still (as in Python) explicitly passed as the first argument to the method, but instead of being called "self" we pick it up with the pattern of another Tree constructor and so it gets broken into _,left and right.

But where do we put the None / empty tree clause? My first thought was something like this :

 class Tree(val,left,right) :
   def size(None) : 0
   def size(Tree(val,left,right)) :
       1 + left.size() + right.size()

But that's not quite going to work. If this really were a more statically typed language like Haskell, and we knew that left and right were always Trees, this would be OK. But as we're trying to go for Pythonic duck-typing we have a problem. We would still like left.size() to mean, "pass the method selector size() to the object left" and then let the class of left decide how to handle it. But where left is None we have no idea which class to use to call. We could have a multitude of classes which define size(None); which would we pick?

Note that this is not the pattern-matching's fault. We'd have the same problem here :

 class Tree(val,left,right) :
    def size(self) : 
      if self is None : 0
      else : 
        1 + self.left.size() + self.right.size()
         

We could get around the problem by disallowing methods which take a single None argument, effectively forcing the programmer to write something like this :

 class Tree(val,left,right) :
   def size(Tree(_,None,None)) : 0
   def size(Tree(_,None,right)) : 1+right.size()
   def size(Tree(_,left,None)) : 1+left.size()
   def size(Tree(val,left,right)) :  
       1 + left.size() + right.size()

But this starts looking somewhat clunky.

We might make it a bit less awkward by providing conditional evaluation to the left and right subtrees. Based on Python's current conditional expression syntax that would look something like this :

 class Tree(val,left,right) :
    def size(Tree(_,left,right)) : 
       1 + (left.size() if left else 0) +  
           (right.size() if right else 0)

Or maybe we have to accept a static type system closer to Haskell's. Perhaps the types, in this case, contribute to Haskell's terseness.

Alternatives to Google Application Engine

Hey. I wonder what YML is.

Kira is a language which compiles to PHP

Oh Ho! What's New in Python 2.6

The Java.next world

Composability and productivity

A pompous statement from the Voodoo Tiki God

Swarm. A true distributed language

StackOverflow discussion on good in-browser code-editors. Worth following.

DesktopZen :-)

I'm expounding my usual "late-bound" tabs model of IDEs again, over on StackOverflow.

... late binding between the buffer in the editor and actual concrete thing you're working on, gives the editing environment more flexibility and power.

Think this is out of date? One place where the idea is back with a vengeance is in the browser, where you don't have 1-1 correspondence between tabs and web-pages. Instead, inside each tab you can navigate forwards and backwards between multiple pages. No-one would try to make an MDI type interface to the web, where each page had it's own inner window. It would be impossibly fiddly to use. It just wouldn't scale.

Personally, I think IDEs are getting way too complicated these days, and the static binding between documents and buffers is one reason for this. I expect at some point there'll be a breakthrough as they move to the browser-like tabbed-buffer model where :

a) you'll be able to hyperlink between multiple files within the same buffer/tab (and there'll be a back-button etc.)

b) the generic buffers will be able to hold any type of data : source-code, command-line, dynamically generated graphic output, project outline etc.

Take a look at AppJet. An educational take on the IDE in a browser.

George Monbiot has a good piece on pursuing the work you want.

So my final piece of advice is this: when faced with the choice between engaging with reality or engaging with what Erich Fromm calls the "necrophiliac" world of wealth and power, choose life, whatever the apparent costs may be.