Lambda the Ultimate

I'm on a campaign, I'm joining a revolution, and it's guiding maxim is this...

"Simplicity is the Price of Reliability, a price which I'm now fully prepared to pay."

The full quote comes from The Emperor's Old Clothes C.A.R. Hoare 1980 ACM Turing Award Lecture

"The price of reliability is the pursuit of the utmost simplicity. It is the price the very rich find most hard to pay."

While more features go into a language, in particular threading, I cannot write reliable programs, since the language compiler / interpretor itself becomes ever more complex.

So I'm on a hunt for the some other language to be my prime tool.... and Threading is at the top of my list of "features not to have".

I've learnt my limitations... unlikely most programmers, I know I'm not smart enough to code reliably in C / C++ like languages. (I didn't say I'm less smart than most programmers, merely that unlike most programmers I know I'm not smart enough.)

The code implementing Rubies interpretor is, ahh, um, threaded through with support for threading...

Common Lisp has the simplicity of Syntax but is a horrendous sprawl of semantics.

Scheme is near the top of my list, but I suspect a touch more expressiveness in semantics may make large programs simpler.

Scala appeals... but building it ontop of JVM strikes me as a very very bad start.

I'm begging for suggestions.

On Monday, July 13th the C++ standards committee voted "Concepts" out of consideration for C++0x.

First, skepticism regarding the feasibility and usefulness of concepts intensified the antipathy towards this proposal. Some people expressed concerns about compile-time and runtime overhead. Second, the creators of the Concepts proposal tried desperately to improve and patch Concepts. The last nail in the coffin was Bjarne Stroustrup's paper "Simplifying the Use of Concepts" from June. It's a masterpiece in terms of presenting Concepts but it also scared folks. The general sense was that concepts were broken, the committee was not sure what the correct direction was to fix them, and it would probably take several more years to come up with a reasonable fix that would achieve consensus. Considering that Concepts were originally designed to simplify C++, a critical mass of committee members agreed in July 2009 that it was time to bid Concepts goodbye.

Edit:

For more on the meeting see "The View (or trip report) from the July 2009 C++ Standard Meeting" part 1 and part 2

Edit 2:

Bjarne Stroustrup on The C++0x "Remove Concepts" Decision.

Ever wanted to learn a little Prolog? Want to learn what it's good for? Join us at the next FringeDC Meeting. Afterwards, we'll stop at a nearby restaurant for some food and to discuss programming.

The meeting will be held at the Clark&Parsia offices in downtown DC near the Convention Center(clarkparsia.com/contact)

FringeDC is a group in Washington DC interested in fringe programming languages (Lisp, Haskell, Erlang, Prolog, etc.) Anyone is welcome to join our meetings!

www.lisperati.com/fringedc.html

Andrei Alexandrescu: Iterators Must Go, BoostCon 2009 keynote.

Presents a simple yet far-reaching replacement for iterators, called ranges, and interesting "D" libraries built on it: std.algorithm and std.range.

Ranges pervade D: algorithms, lazy evaluation, random numbers, higher-order functions, foreach statement...

(Related: SERIES, enumerators, SRFI 1, and The Case For D by the same author)

Doug Lea: A Java Fork/Join Framework, Proceedings of the ACM 2000 conference on Java Grande.

This paper describes the design, implementation, and performance of a Java framework for supporting a style of parallel programming in which problems are solved by (recursively) splitting them into subtasks that are solved in parallel, waiting for them to complete, and then composing results. The general design is a variant of the work−stealing framework devised for Cilk.

This work is about to be incorporated into Java 7 as jsr166y:

Parallel*Array (often referred to as PA) and its planned follow-ons for sets and maps, provide an easier/better way of routinely programming to take advantage of dozens to hundreds of processors/cores: If you can think about a programming problem in terms of aggregate operations on collections of elements, then we can automate parallel execution. This generally pays off if either you have lots of elements, (in which case, it works well even if the operations are small/cheap), or if each of the operations are time consuming (in which case it works well even if there are not a lot of elements). To take advantage of this though, the aggregate processing must have a regular structure, which means that you must be able to express things in terms of apply, reduce, filter, map, cumulate, sort, uniquify, paired mappings, and so on.