| |||||||||||||
lambda functionslambda functionsPosted Dec 13, 2005 22:26 UTC (Tue) by pimlott (guest, #1535)In reply to: lambda functions by ncm Parent article: The Boost C++ Libraries
The point is not how pretty it is (although it's remarkable how well they've done), but rather that it was possible to do this entirely in the library. In practical terms, it means that Boost's lambda library makes advanced techniques available for use in an industrially useful language.... in a limited, difficult to use, and unreliable form. But at least it makes C++ slightly less painful. It's hard to make a language powerful enough not to need fancy features coded in its core.You consider lambda a fancy feature, but you don't consider multiple inheritance or the rules for implicit type conversion and copy constructors and overloading fancy features? That's a skewed perspective. any directly-useful core-language feature that doesn't map to a machine instruction or two indicates a language design failureThat's an arbitrary standard (especially as CONS, CAR, and CDR map to machine instructions on some processors). At most, it matters to a tiny fraction of programs. You already acknowledged that OCaml has performance on par with C++ despite not mapping directly to machine code (and despite many fewer people working on OCaml compilers). .Most languages taken seriously in academia repeat LISP's failures, which suffices to explain why they are not taken seriously in industry, and why there is *still* no credible alternative to C++ for industrial use.Come on--this is an industry that is terrified by new ideas (unless they're old ideas reintroduced with some new buzzword). C++ owes its current status to momentum and widespread support, not to any intrinsic quality. Companies that have used "academic" languages for "industrial use" have been quite successful.
(Log in to post comments)
lambda functions Posted Dec 13, 2005 23:36 UTC (Tue) by ncm (subscriber, #165) [Link] 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] 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.
|
|||||||||||||