According to this analysis (with all the caveats about rushed work, low n, etc), there are roughly three differentiated “domains of competence” according to the people who write posts in job boards:

• A “narrow web domain”: ajax, dhtml, hibernate, apache, tomcat, spring, corba, rails, java, ruby, perl, php
• A “wide web domain”:html, javascript, css, xml, mysql, cms, xhtml, c, cctv, ethernet, django, turbogears, flex, flash, coldfusion, xslt, lamp, mssql, soap, clusters, hpc, jboss, jetty, subversion, snmp, samba, excel, sybase, smarty, postgresql, rpc, plone, openerp, zope
• A “server domain” (more sharply distinct from the rest): c++, boost, dns, firewalls, jython, unix, oracle, sql, solaris, ip, api, tcp, openssl, linux, svn

The labels I chose are of course largely arbitrary, but the grouping itself is less so, and not obviously derived from technological reasons. The “server domain” is more or less self-explanatory (although not devoid of weirdness), but why are the two first categories grouped as they are? Off the top of my head, I think that this reflects the existence of a more programming-oriented web domain among Python-mentioning jobs where dynamic languages are notorious and relatively large deployments are expected (hence the “enterprise” java technologies), and a large and heterogeneous “bag domain” of web-related technologies where everything goes. Needlessly to say, this description falls apart quite quickly (“clusters” and “hpc” belong to this bag domain, where they should logically go somewhere else), but, still, it seems to be a workable first approximation.

Looking at a finer granularity, things become much clearer. You have, for example, a “dynamic languages” cluster, and a very well defined “classic websites” cluster (html, javascript, css, xml, mysql).

It would be interesting to see how well these clusters (specially at the finer granularity levels) correlate with actual demands during work, but I’m not sure where to get that data from.

Which suggests the question of why the hell should I have to choose? Isn’t there an IDE that, say, rewrites on the fly a LISP list making educated guesses about what will get applied when? E.g., it could render (inc a) as inc(a), and so on. And it could go the other way around, rendering (I use the word deliberately) the parse tree of Python code into a LISP format that would make it easier to think about and write code manipulation code. I read something about such a project a long while ago, although I have yet to track it back — essentially, specific languages are conventions to describe computations, so we should be able to render any particular computation into whatever language is most convenient to the task at hand. Compilers do that, which is nice for the CPU, but my brain spends time dealing with programs, too.

For a much worse example, here is a quick and brain-dead version of “apply” I just wrote that allows you to do things like


dataparser = [ stripped, split(','), (str, int, capitalized) ]
for line in datafile:
    print apply(dataparser, line)


The important lines are the last three; once you have your basic functions (and leaving aside questions of arity, debugging, types, and such), you shouldn’t need to write scaffolding code in order to compose them in simple ways. In this example, the dataparser = [ stripped, split(','), (str, int, capitalized) ] line simply says “this is the function that applies stripped, then split(‘,’), and then str, int, and capitalized to each of the three elements of the result tuple.” There’s a large number of simple scripts that use this sort of process a lot, and I feel that even if it’s not really that much of an issue to explicitly define the composed function, it compounds over a large number of tasks, and subtly discourages reuse of components and strategies and, most importantly, makes it subtly harder to work over the process.

By the way, I think Ruby is more powerful in this regard, although still not elegant at all. And, as EWD would say, elegance is nothing else but another word for conceptual usability; inelegant tools lead to solutions that cannot be understood by either designers or implementators; lack of understanding leads to undying bugs, unsound algorithms, and multi-decade technological dead-ends.

It’s sad that we have spent so much time fiddling with useless functionality in software, that taking out flexibility actually improves your productivity.

#!/usr/local/bin/python

class Undefined:
    pass

class Maybe:
    def __init__(self, x=Undefined):
        self.value = x

    def apply(self, f):
        if not self.is_defined:
            return Maybe()
        else:
            return Maybe(f(self.value))

    def __repr__(self):
        if not self.is_defined:
            return '<Undefined>'
        else:
            return repr(self.value)

    @property
    def is_defined(self):
        return not self.value is Undefined

def monad_aware(f):
    def fprime(x):
        return x.apply(f)
    return fprime

if __name__ == '__main__':

    @monad_aware
    def double(x):
        return 2*x

    x = Maybe()
    print double(x)
    assert(not double(x).is_defined)

    x = Maybe(2)
    print double(x)
    assert(double(x).is_defined)
    assert(double(x).value == 4)

Pastebin link

And why not? Why should values be passive? (Note that accessors are a bit like half-monads; but full monads can do whatever the hell they want with functions, way beyond playing with what they see.)

[Very simple abstract setup, describing an ensemble of physical systems through a probability distribution over phase space, and dynamics by a differential equation.] Then, the well-known Liouville equation describes the dynamics of this distribution. For this type of evolution the Kullback-Leibler information measure provides a convenient way to measure the distance between two distinct probability distributions P1 and P2 because, remarkably, it is invariant under dynamical changes prescribed by the Liouville equation.

I’m not a physicist, but I feel compelled to annotate that — in the style of chess games — with a (!) (although I don’t think this is really a physics result). The Kullback-Leibler is a well-known (if not the) information distance between distributions, but I had no idea that it was preserved by such a wide range of dynamic systems.

Classical No-Cloning Theorem