Lambda the Ultimate

The domain is proof theory, the theme is "Eliminate Bureaucracy", the LtU angle is that if we can eliminate bureaucracy from proof theory, then we open the floodgates to applications of proof theory to computer science. That's the theory anyway...

Check out:

1. The workshop homepage;
2. The SD05 wiki page at Greg Restall's wiki;
3. Fancy going to Lisbon in July? slashdot journal thread...
4. LtU node #551 wherein Greg and I chatted about the workshop...

We've been talking about how good a lot of the stuff in computer science over the past 50 years or so has been. Here are links to some excellent free online archives that I've found out about.

• MIT AI Lab publications
• EWD archive
• CMU AI Repository (notable for its real and well-written Lisp source code)
• Stanford computer science technical reports and technical notes.
• www.its.os.org

Please let us know what good stuff you find in here, and if you know some other good free archives. There's a huge amount of good stuff tucked away waiting to be rediscovered on LtU.

So here's what he did: he recruited an elite strike team of coders (who, if you were to believe his slideshow, dressed like ninjas) and put them in a "hidden facility" to experiment with new ways of giving the user powerful tools and generating tons of dynamic content without armies of content creators.

From time to time it's good to remember that we live in The Age of Programmability.

To all employers out there: It is us, who know most about programmability and programming models. If you don't want to stay behind, hire programming language mavens...

[a domain specific language] tends to look like boxes and arrows on a screen. It’s a graphical modelling language with metadata underneath; and very importantly, metadata that’s domain specific. So if your domain is that of a business process, then the metadata is recognisable XML that describes business processes with tags that will say ‘process’ or ‘activity’, or whatever. It will be customised to your job.

How close are we to a world where every paper on programming languages is accompanied by an electronic appendix with machine-checked proofs? To gauge progress in this area, we issue here a set of challenge problems, dubbed the POPLmark Challenge, chosen to exercise many aspects of programming languages that are known to be difficult to formalize.

A valid solution to the challenge will consist of appropriate software tools, a language representation strategy, and a demonstration that this infrastructure is sufficient to formalize the challenge problems.

The POPLmark team explains,

We are not ourselves automated reasoning experts but rather potential users; our impression is that current tools are almost at the point where they can be used routinely. It's time to bring mechanized metatheory to the masses - go to it!

Guido van Rossum comments on the elimination of map(), filter(), reduce() and lambda from Python 3000:

About 12 years ago, Python aquired lambda, reduce(), filter() and map(), courtesy of (I believe) a Lisp hacker who missed them and submitted working patches. But, despite of the PR value, I think these features should be cut from Python 3000.

He believes map and filter are unnecessary because there are list comprehensions. But what about reduce ? It seems Guido doesn't believe in folds:

So now reduce(). This is actually the one I've always hated most, because, apart from a few examples involving + or *, almost every time I see a reduce() call with a non-trivial function argument, I need to grab pen and paper to diagram what's actually being fed into that function before I understand what the reduce() is supposed to do. So in my mind, the applicability of reduce() is pretty much limited to associative operators, and in all other cases it's better to write out the accumulation loop explicitly.

And then, with these functions gone, there is no use for lambdas, he argues.

I find it positive, in general, when designers eliminate features from a programming languages, if they are rarely used, but maybe he is being too harsh on reduce(); it may be my predilection for functional programming getting on the way, though.

via PLNews

If you have been following Booch's recent presentations, you'll recognize many of the slides. Only towards the end does AOP come up.

Relate to PLs are the slides about simplicity in languages, programing models, the discussion of abstraction, and of course AOP.

The presentation was already mentioned in the LtU forum.