Subject: Re: C++ briar patch (Was: Object IDs are bad) From: Erik Naggum <erik@naggum.no> Date: 1997/05/16 Newsgroups: comp.lang.scheme,comp.lang.lisp,comp.lang.misc,comp.lang.functional,comp.lang.c++ Message-ID: <3072791535069493@naggum.no> * Harley Davis | These modern apps we whine about are bloated not because of their | programming language, but simply because they try to do too much at once, | implementing far more features (and Easter eggs, and scripting languages, | etc.) than any normal mortal ever uses. ... They are huge, complicated | monsters, which, I'm willing to bet, would be equally bloated in any | programming language - probably even more bloated in Lisp if written by | the same quality of programmers. well, how much are you willing to bet? how would we settle this? should I make unfounded conjectures, too, and somebody in the audience toss a coin? | Writing high-quality, efficient, non-memory-intensive code in Lisp (and, | of course, in any language, but in Lisp the temptation to write | inefficient code is great, as Siskind pointed out) is a challenging task, | requiring high skill levels and an excellent understanding of underlying | implementation issues. what utter nonsense! there is no "temptation to write inefficient code"! where do you _get_ such silly ideas? a temptation is something people are too weak to resist. nobody walks up to Lisp programmers and says "hey, let's make this inefficient!" and when they answer "gee, that sounds cool, but is it really a good idea?" go on with "aw, nobody will notice, anyway". there's temptation to be lazy in any language, but there's no _temptation_ in Lisp to focus on efficiency _before_ correctness. in C/C++, there is, because it takes so much _more_ effort to write _correct_ and efficient code in C++ than it does in Common Lisp. 40% of effort will give you fast and "correctable" C++ or correct and "optimizable" Common Lisp. | Few programmers are up to the task. For many years, Ilog was the largest | Lisp vendor in Europe, and believe me, I saw mounds of absolutely | horrendous Lisp code written by supposedly well-educated and | knowledgeable programmers, the cream of the crop of European programmers. yeah, funny how 350 million people can produce so few good programmers when 250 million people can produce so many, isn't it? | If these guys had written Microsoft Word, it wouldn't be a 20 megabyte | brontosaurus - it would be a 50 megabyte brachiosaurus. there is no evidence to suggest this, other than your own disappointment and perhaps bitterness. in fact, there is much evidence to suggest that when a project grows large, there will be much duplication of effort if the abstractions are wrong or if they fit the original purpose too tightly. the most expensive error a designer or programmer can make is premature optimization. given this, it is ill-conceived to argue against those who do _not_ make this mistake on the grounds that those who do make it write faster code, because it will be doing the wrong thing faster, not the right thing faster. until you have hard evidence that 50M Lisp applications would take 20M in C/C++, or that 20M C/C++ applications would take 50M in Lisp, I suggest you accept the probability that 20M Lisp application would take 50M in C/C++ and that 50M C/C++ applications would take 20M in Lisp as _equally_ large (or small). #\Erik -- if we work harder, will obsolescence be farther ahead or closer?