Lambda the Ultimate

Alexander Stepanov: STL and Its Design Principles (Talk presented at Adobe Systems Inc., January 30, 2002)

I've only watched the part beginning at about 1 hr, where Stepanov describes his thoughts on the future of programming (languages). Interesting and entertaining stuff.

Maybe one of you gets around to providing a description of the rest of the video. ;-)

A ‘crutch’ in language design is a solution to a problem of accidental complexity. Such problems wouldn’t exist with (a) the foresight to choose a better abstraction and (b) support for desired abstraction need without sacrificing other valuable properties (such as performance).

dmbarbour's new Freedom and Crutches blog post details an interesting point of language design. I found it very relevant to LtU and would be interested in more examples of crutches.

Named parameters are given as example. They help to alleviate long parameter lists, but would be unnecessary if the offending functions were reformulated with better abstractions, packing more parameters together in semantically meaningful compounds. Named parameters, he says, also have negative effects on the language:

For example, designers choosing named parameters rarely consider the impact on first-class functions and point-free function composition.

It's interesting that neelk recently used a very related argument against N-ary function types. If the alternative to n-ary functions is tuples, the alternative to named parameters is passing a record with named field. It is quite difficult, however, to do that "without sacrificing performance" -- you would need value tuples and structures, which brings important implementation subtleties.

What other crutches do you know? How should they be avoided?

I'm wondering if there are also cases of two language features that are, taken independently, not crutches, being both beneficial, but combined together create a crutch-like feature overlap.

Edit: when discussed a given language feature, please try to provide some concrete example of (one of) its intended use case(s). It always help discussion to be less abstract, and it's often interesting to ask oneself: "what is the core of this example? could a simpler facility accomplish this more specific case?".
Of course, I'm very bad at providing examples myself. Do as I say, not as I do.