Home

The Future(s)

No obvious connection between these links, other than future(s). First up is The future will be about programming languages an MP3 recording of a talk from Ted Neward:

During this [hour long] Jazoon keynote Ted Neward talks about why the next five years in IT will be about languages. The programming language virtualization, tools, linguistic focus and expressiveness are different forces that are coming of age. Not to mention the impact of the over-used and over-hyped Domain-Specific languages.

Though I wanted to enjoy a talk that touches on the importance of PL diversity, (with mentions of FP, AOP, Lisp, Ruby, Groovy, Intercal, and Ook), I didn't really gather much new. The audience is Java programmers, so perhaps the ideas are a tad revolutionary for that crowd. Still, might be of interest to those who want to know how PL innovations might play out in Java land.

On a different note, one possible way to gather prognistications is to conduct a poll asking readers about the Top 10 programming languages of the future. But then you end up with answers that look disturbingly similar to what people are doing in the present. Hopefully Ehud's query will yield more intriguing results.

Finally, there are a couple of articles on futures as a PL feature for concurrent programming: Futures in Objective-C and Microsoft's planned library to Optimize Managed Code For Multi-Core Machines which has tasks and futures. Alice ML demonstrates that futures can be a powerful PL feature. But we do run square into the question of whether providing a feature as a library really gives the same level of expressiveness that one gains from integrating it into the core of a language. Still, it's nice to see futures starting to come into wider play.

By Chris Rathman at 2007-09-24 23:51 | General | other blogs | 12212 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Futures as library

But we do run square into the question of whether providing a feature as a library really gives the same level of expressiveness that one gains from integrating it into the core of a language.

I don't know if it's any sort of answer (not even a data point, but is probably an anecdote), Mahlee does futures for Javascript and is specifically designed to be a library. This is possible because Javascript has very good introspection and dynamic programming which means that object proxies can be created at runtime.

Compare that with the C++ futures that the Mahlee implementation uses. It's satisfying from a functional programming perspective, but the layer above which handles OO message passing is hampered because C++ doesn't have enough introspection (even the new proposed changes don't go far enough) to be able to create proxies automatically. This leaves having to do explicit binding which is verbose and ugly.

It'd be interesting to see if the new AST macros in D will let it go as far as Javascript does in this area.

An implementation of Mahlee for Windows is available. This is the first time I've publicly given out the download link so I suppose this is a Lambda the Ultimate exclusive :) It doesn't attempt to garbage collect old messages yet, but the threading is absolutely rock solid -- at least I've never been able to get it fail (other than the expected deadlock when there is a cycle in the dependency graph between futures).

By Kirit at Tue, 2007-09-25 02:05 | login or register to post comments

Futures Market

Speaking of 'futures', what might be interesting is a futures market for languages - instead of just arguing, we could bet real money.

http://home.inklingmarkets.com/market/show/6481

This is something I put together (this market, not the site), but since it doesn't use real money, it's not worth much in terms of predictions.

The big problem is to find a concrete way to determine the winner with any precision.

By David N. Welton at Tue, 2007-09-25 06:54 | login or register to post comments

The big problem is to find a

The big problem is to find a concrete way to determine the winner with any precision.

That's easy... The winner will be the first language to get a dedicated LtU department by end of 2008.

By Ehud Lamm at Tue, 2007-09-25 07:06 | login or register to post comments

TIOBE

My first cut on such a contract would be something like "Will language X be in the top 10 in the TIOBE index on date Y", where top 10 is chosen as a crude approximation of "You can find a job in it". Their methodology is well-enough defined to be usable for this task.

I'd go long on Groovy, Scala, and Erlang for 10 year contracts, short Ruby and C++.

By Dave Griffith at Tue, 2007-09-25 09:56 | login or register to post comments

Expressiveness of futures

But we do run square into the question of whether providing a feature as a library really gives the same level of expressiveness that one gains from integrating it into the core of a language.

Technically, I don't think there is much of a question: futures as pervasive primitives give you implicit dataflow synchronisation. That is not the case with library implementations - proper dataflow synchronisation requires that every built-in operation of the language is aware of futures. Achieving it on top of a language without futures (or other forms of dataflow variables, e.g. logic variables) would need whole-program transformation.

But as far as I'm concerned, the jury is still out on deciding whether this additional expressiveness is actually useful enough in practice to warrant the substantial operational and implementational overhead, and the induced semantic complications and unpredictability. The situation is very similar to lazy evaluation as the primary computation regime vs poor man's laziness using explicit closures.

By Andreas Rossberg at Tue, 2007-09-25 11:47 | login or register to post comments