Lambda the Ultimate

The first segment of the talk has some tasty anecdotes to explain how far we've come.

The middle segment introduces some of the problems Steele has been wrestling with regarding parallel programming, and how best to describe (for human and machine consumption) how to think about it. The "accumulator paradigm" stands out as a particular hint of something gone wrong for the parallel programmer. There are some interesting quips in here about things like "why didn't Fortress start from Haskell" and "Say, just how important are associative operators, anyway?"

The finale segment shows off some Fortress niceness.

The parting words are interesting.

The talk is presented here with video and slides..

If I may speculate or editorialize or otherwise just make my own notes here, briefly, if for no other reason than to encourage you to watch the video and figure out why I'm wrong:

I note the prominent "Oracle" brand on the slides and, free associating, it reminds of something related:

Stonebraker (perhaps someone might offer some links) had some recently semi-infamous criticisms of so-called no-SQL databases. His recent work, last I heard, was on SQL solutions for column-oriented stores of very huge data sets. He is keen on stuff like like ACID properties. He sees (my weak paraphrase, not his words) stuff like map-reduce hype as a disappointing giant step backwards in the public discourse.

Oracle, among other things, is in the database business and I would guess is concerned about the kinds of issues that Stonebraker talks about.

Codd wanted, in his abstract formulations, a practical separation between a logical model of data and the physical realization of operations over this, plus transactional properties, plus a "relational" foundation that was so abstract in conception that SQL is but an example, not a final word. Indeed, SQL is horribly dated for its failure to be cleanly integrated with a surrounding and more general programming language. The way it is used in various web frameworks is generally disappointing. Personally, I would guess it is that awkward integration that, until recently, fed a lot of no-sql hype.

The Fortress project has landed in a potentially great place[*] for it. Steele's notions of parallel programming discussed in the talk, married to big data.... Perhaps something interesting will come of it.

[*]: Although I do not think it is good if Steele's work going forward can not respect and hopefully advance the cause of software freedom. At Sun, the Fortress project had a very good chance of doing so, as far as I can tell. This matters for language theory academics and others in a forum like this because, presumably, we are not here to kibbitz for the purpose of providing free insight to a company that will use that insight to harm the freedom of ourselves and others.

Parametric Prediction of Heap Memory Requirements, by Victor Braberman, Federico Fernandez, Diego Garbervetsky, Sergio Yovine:

This work presents a technique to compute symbolic polynomial approximations of the amount of dynamic memory required to safely execute a method without running out of memory, for Java-like imperative programs. We consider object allocations and deallocations made by the method and the methods it transitively calls. More precisely, given an initial configuration of the stack and the heap, the peak memory consumption is the maximum space occupied by newly created objects in all states along a run from it. We over-approximate the peak memory consumption using a scoped-memory management where objects are organized in regions associated with the lifetime of methods. We model the problem of computing the maximum memory occupied by any region configuration as a parametric polynomial optimization problem over a polyhedral domain and resort to Bernstein basis to solve it. We apply the developed tool to several benchmarks.

We've briefly discussed analyses to predict heap usage here on LtU, but I can't seem to find them. Anyone with a reference handy, please post in the comments!