Lambda the Ultimate

There was a discussion recently in artima.com about features that C++ must have. Stroustrup kindly responded to some messages, but the overall tone was "that is it". But the fact is that C++ has some "big" problems, and bold decisions are needed.

If we don't want the cutting edge we know where to find it. To my mind conservative design is not appropriate for Haskell or any other interesting programming language.

while i think that conservatism is necessarily part of the nature of standardization processes, i believe that the reasoning to block language features should be done in a very sensible way.

the current incarnation of c++ suffers from major issues. the largest, namely the lack of many necessary standard library components, is actively targeted with the upcoming version. here the standard comitee has clearly seen the need to drop conservatism in favor of competitiveness. it is good to see that even previously discarded features like multithreading are accepted regardless of the obvious portability issues to some target platforms.

unfortunately the same issues do not resolve so well at language level. features seen in other comparable languages are slowly, if at all seeing their way into c++. there are missing features which draw projects from c++ to other languages where standard proposals drag their way for years now. think about reflection or lambda for example.

imho templates are a good example that a sound language feature can be very successful even if it is far from perfect. historically templates have been dragged into the language in a pragmatic decision to allow the development of generic types, where back then unsolved issues did not hinder the integration.

maybe standardizations sometimes strives for a little bit too much of perfection. ;)

It seems silly to standardize anything without an implementation. A working implementation focuses discussion and makes the abstract concrete (by bringing up implementation issues, usability issues, etc.)

That's not to say committees should ignore users; but the users really need to be talking to the compiler makers, not the standards committees.

Seriously, it's not like SPJ hasn't shown them the way. :)

Herb's proposal was discussed and voted down. This comp.std.c++ thread discusses the issue in detail.

Standards committees make very bad development groups. (Yes, that is an understatement.) If you want historical examples, look at C, C++, the ISO, or the IETF. For every success, like Haskell's type classes, there are a goodly number of failures, like trigraphs and the OSI thing.

Haskell may be a bit of a special case, since what is conservative for Haskell is beyond the cutting edge everywhere else, but how hard would it be for anyone suggesting an unimplemented idea to actually implement it and then get some experience with it in real code before proposing it as a standard? That ought to be the minimal amount of preparation required for a committe's consideration.

Consider the risks: features added to the standard language that are difficult to implement, unused, or that preclude future improvement, or are simply ugly. Not to mention language fragmentation.

I think Larry Wall had a good idea when soliciting ideas for Perl 6: to propose the inclusion of a new language feature, you also had to propose the removal of an existing one.

Admittedly Perl is a target-rich environment for language features, but the notion carries the intent of removing cruft while keeping the language up-to-date.