lambda functions

Posted Dec 13, 2005 23:36 UTC (Tue) by ncm (guest, #165)
In reply to: lambda functions by pimlott
Parent article: The Boost C++ Libraries

Inheritance (of whatever variety) and automatic conversions certainly are "fancy features". They don't belong in the core of a language. A language more powerful than C++, and less encumbered with legacy compatibility, would have them in the standard library. Lambda is hardly a feature at all -- it's a notational detail -- and probably *does* belong in the core language.

By "directly useful", I mean operations that actually perform computation, resource management, control flow, and I/O, as opposed to primitives that organize code (e.g. types). Everybody's long since conceded that I/O belongs in the library. That was a radical notion until C thrashed Pascal. Threads were supposed to be built in, too, until C thrashed Ada too. Progress in language design lies in discovering that apparatus previously considered indispensable amounts to trivial applications of a more powerful core primitive.

CONS may be one or two instructions, but CONS implies garbage collection, which is enormously more intrusive than Ada's failed built-in threads. The presence of CONS in the core language concedes that the language is incapable of coding resource management as a library facility. GC is actually worse than that: even if the language is otherwise up to the job, GC interferes so as to make it impossible anyhow.

The MLs are almost expressive enough to take on C++, but are encumbered with too many of LISP's fundamental mistakes.

The belief that C++ was a shoe-in, and is now thoroughly entrenched, is the most pathetic sort of sour grapes. C, in the 80s, and now C++, got used because they have proven useful and usable where they are needed. Academic languages aren't used precisely because they have turned out not to be so. Instead of whining about industry's supposedly dogged conservatism, try rethinking your own dogmas. That's what science and engineering are all about: when experience says your idea is wrong, reject the idea, not the experience.

The world needs a language more powerful and cleaner than C++. It won't be built by people who can't even understand why C++ succeeds, or why its academic competitors have failed over and over again.

Companies that have used academic languages successfully have either used them as fancy scripting languages (e.g. Yahoo stores) or depend heavily on calling out to libraries coded in an industrial language (e.g. ITA Software). LISPies like to say that Python and Ruby are really just dressed up LISP, but they're wrong: LISP is really just stripped-down Python.

lambda functions

Posted Dec 14, 2005 2:26 UTC (Wed) by pimlott (guest, #1535) [Link] (1 responses)

Ok, I took your previous post as anti-lambda and pro-everything-in-C++, which was clearly mistaken. I absolutely agree that a language should be built on a minimal set of primitives, but I strongly disagree that they need be close to the machine.

I'm not sure why you say that CONS implies garbage collection; there could be free-cons. Your suggestion that memory management should be in a library is plausible for many languages; however, GC seems to be required for pure (or mostly pure, as in ML) functional languages, so in these cases GC must be in the core. Funtional languages usually have special constructs or a library for manually managing memory, when required. "GC makes it impossible" seems extreme to me.

Re "sour grapes": In my experience, the industry is indeed doggedly conservative--every language decision I have seen has been based on familiarity, programmer availability, risk-aversion, or political acceptability, never on technical merit per se. Not that these are unfounded considerations, but all work against new languages. And I could as easily lampoon your Panglossian dismissal of historical contingency. "Worse is Better" argues that C won because it was easier to implement, and ran well on small machines, not because it was better. Is this implausible to you?

Re ITA: I was not aware that they relied heavily on non-LISP code; I'll have to look that up.

lambda functions

Posted Dec 14, 2005 2:39 UTC (Wed) by pimlott (guest, #1535) [Link]

Funtional languages usually have special constructs or a library for manually managing memory, when required.

I take that back somewhat: They have ways to explicitly allocate, deallocate, and modify references, but they don't have ways to use your own allocator, so far as I know.