····@emf.emf.net (Tom Lord) wrote in message news:<··············@corp.supernews.com>...
> Lisp dialects fail in business because their advocates challenge the
> people who sign checks too much.
More realistically, Lisp/Scheme/etc fail because:
- they are not considered new/cool (except by their devotees of
course)
- they don't have billion dollar companies pushing them(e.g. Sun:Java)
- most companies follow the crowd
- most companies only pay for crap programmers
- despite all the passionate argument to the contrary, and contrived
examples aside, they simply don't match the performance of C/C++ for
real world applications (no doubt someone will point out a Paul Graham
article right about now about Lisp being a secret weapon)
- all those parenthesis REALLY ARE a pain in the butt
- Lisp advocates often seem too defensive (like they are embarressed
about dirty secret)
- there are not enough Erik Naggums to go around
>
> They like things that make them go. (ask a Star Trek NG fan).
>
> -t
Fortunately, Lisp (and most Lisp programmers) is quite secure in itself;
it doesn't need a billion-dollar organization to back it and doesn't
need any missions to save the world, in order to feel worthwhile.
Can't say the same for "Shinji Ikari"
;-)
On Fri, Sep 06, 2002 at 05:53:27AM -0700, Shinji Ikari wrote:
> ····@emf.emf.net (Tom Lord) wrote in message news:<··············@corp.supernews.com>...
> > Lisp dialects fail in business because their advocates challenge the
> > people who sign checks too much.
>
> More realistically, Lisp/Scheme/etc fail because:
> - they are not considered new/cool (except by their devotees of
> course)
> - they don't have billion dollar companies pushing them(e.g. Sun:Java)
> - most companies follow the crowd
> - most companies only pay for crap programmers
> - despite all the passionate argument to the contrary, and contrived
> examples aside, they simply don't match the performance of C/C++ for
> real world applications (no doubt someone will point out a Paul Graham
> article right about now about Lisp being a secret weapon)
> - all those parenthesis REALLY ARE a pain in the butt
> - Lisp advocates often seem too defensive (like they are embarressed
> about dirty secret)
> - there are not enough Erik Naggums to go around
>
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
In comp.lang.scheme Shinji Ikari <······@swirve.com> wrote:
: ····@emf.emf.net (Tom Lord) wrote in message news:<··············@corp.supernews.com>...
:> Lisp dialects fail in business because their advocates challenge the
:> people who sign checks too much.
: More realistically, Lisp/Scheme/etc fail because:
: - they are not considered new/cool (except by their devotees of
: course)
: - they don't have billion dollar companies pushing them(e.g. Sun:Java)
: - most companies follow the crowd
: - most companies only pay for crap programmers
: - despite all the passionate argument to the contrary, and contrived
: examples aside, they simply don't match the performance of C/C++ for
: real world applications (no doubt someone will point out a Paul Graham
: article right about now about Lisp being a secret weapon)
: - all those parenthesis REALLY ARE a pain in the butt
: - Lisp advocates often seem too defensive (like they are embarressed
: about dirty secret)
: - there are not enough Erik Naggums to go around
I think these past few weeks have taught me a lot about CLS and CLL.
It has taught me that I should not really "be" in the lisp/scheme
community as defined by these two newsgroups because it isn't about
writing code to get things done. It is about something else, which is
less important to me.
I feel like these two places as approached from someone who wants to join
"the community" has a poisoning effect(especially CLL and its irrational
hatred of CLS) and frankly, I got better things to do than argue...
...like writing code.
Bye.
-pete
Peter Keller <·······@data.upl.cs.wisc.edu> writes:
> I think these past few weeks have taught me a lot about CLS and CLL.
>
> It has taught me that I should not really "be" in the lisp/scheme
> community as defined by these two newsgroups because it isn't about
> writing code to get things done. It is about something else, which is
> less important to me.
In c.l.l. the most useful, respected contributors have gotten an awful
lot of things done. I can't speak for c.l.s. but I bet it's much the
same. Perhaps one can't identify those people at first glance.
Because Lisp makes language construction and little language solutions
so easy, it does tend to attract people whose main interest is flaming
about those topics.
> I feel like these two places as approached from someone who wants to join
> "the community" has a poisoning effect(especially CLL and its irrational
> hatred of CLS) and frankly, I got better things to do than argue...
>
> ...like writing code.
Bully for you.
> Bye.
>
> -pete
You might find the #lisp channel on FreeNode IRC more to your liking.
Tim
* Peter Keller
| and frankly, I got better things to do than argue...
| ...like writing code.
Like telling people that you have better things to do than tell them that
you have better things to do. Yeah, we buy that, wholesale. Anyone who has
to tell people he is better than other people, could not possibly be honest.
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
* ······@swirve.com (Shinji Ikari)
| - despite all the passionate argument to the contrary, and contrived
| examples aside, they simply don't match the performance of C/C++ for
| real world applications [...]
I have seen three cases up close and personal where the system was built
using Common Lisp and then some idiot manager decided to reimplement it in
C++ (and two cases in Java) precisely to get better performance for the
application (but not for the programmers), better replaceability of the
programmers, and more managability of the whole project, only to discover
that it takes about five times as long to reimplement something in C++ as it
took to design and implement the first system in Common Lisp, it does not
perform noticeably better along any relevant axes, the complexity in C++
makes the programmers just as irreplaceable, and there is no managerial gain
to use C++ over Common Lisp, but at this point, they have decided on C++ and
work very hard to make it look like a good choice because they would look
like utter morons if they could not even pretend that it was a bad choice.
The end result is, however, that a project becomes irreplaceable when it has
been coded in C++ because it cannot easily be modified and nobody dares
start another project to reimplement it until it is much too late and all
the old folks who remember the modifiable, adjustable, reprogrammable Lisp
system have all quit or been fired. The someone can come in an suggest that
it be reimplemented in Common Lisp, again, and save people a lot of money in
the process, until the next manager comes along and claims that the cost of
the Common Lisp system is too high, they cannot find other Common Lisp
programmers, and even though their current resident genius seems happy, they
never know when he'll be stolen by another company or quit, or, God forbid,
be run over by a bus, so they have to reimplement it, in Java this time, or
perhaps C#.
| - there are not enough Erik Naggums to go around
Yeah, I should get started with the cloning, already.
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
Erik Naggum <····@naggum.no> wrote in message news:<················@naggum.no>...
> * ······@swirve.com (Shinji Ikari)
> | - despite all the passionate argument to the contrary, and contrived
> | examples aside, they simply don't match the performance of C/C++ for
> | real world applications [...]
>
> I have seen three cases up close and personal where the system was built
> using Common Lisp and then some idiot manager decided to reimplement it in
> C++ (and two cases in Java) precisely to get better performance for the
> application (but not for the programmers), better replaceability of the
> programmers, and more managability of the whole project, only to discover
> that it takes about five times as long to reimplement something in C++ as it
> took to design and implement the first system in Common Lisp, it does not
> perform noticeably better along any relevant axes, the complexity in C++
> makes the programmers just as irreplaceable, and there is no managerial gain
> to use C++ over Common Lisp, but at this point, they have decided on C++ and
> work very hard to make it look like a good choice because they would look
> like utter morons if they could not even pretend that it was a bad choice.
That entire paragraph was just one sentence! Anyway, I have had
exactly the same experience, in this case a MS visual Basic app
reimplemented in C++ & MFC for better performance, etc, etc, only to
discover that the developers created a bloated piece of crap that was
slower than the original VB app and that constantly crashed. The
lesson is that bad programmers are a pox on any development effort,
but management keep hiring and promoting them.
...
> Then someone can come in an suggest that it be reimplemented
> in Common Lisp, again, and save people a lot of money in the
> process, until the next manager comes along and claims that
> the cost of the Common Lisp system is too high, they cannot
> find other Common Lisp...
Maybe the secret is good, clean system documentation or some sort of
formal specification so the app can be rewritten ad infinitum. How
about a code generator that can spew forth code diarrhea in whatever
the latest "cool", brain-dead language is?
...
> so they have to reimplement it, in Java this time, or
> perhaps C#.
Unfortuantely Java has such inertia that it'll be part of the
corporate IT culture for years to come. Graduates are coming out of
Uni thinking Java is the one true language. Oh, the horror...
>
> | - there are not enough Erik Naggums to go around
>
> Yeah, I should get started with the cloning, already.
Like
[Followup posted to comp.lang.lisp only]
On 6 Sep 2002 05:53:27 -0700, ······@swirve.com (Shinji Ikari) wrote:
> More realistically, Lisp/Scheme/etc fail because:
[...]
> - despite all the passionate argument to the contrary, and contrived
> examples aside, they simply don't match the performance of C/C++ for
> real world applications (no doubt someone will point out a Paul Graham
> article right about now about Lisp being a secret weapon)
No. I will point out the C/C++ Users Journal articles expressing concerns
about C++ performance. And if performance is so critical, why are certain
well known scripting languages so popular?
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
······@swirve.com (Shinji Ikari) wrote in message news:<····························@posting.google.com>...
> ····@emf.emf.net (Tom Lord) wrote in message news:<··············@corp.supernews.com>...
> > Lisp dialects fail in business because their advocates challenge the
> > people who sign checks too much.
>
> More realistically, Lisp/Scheme/etc fail because:
> - they are not considered new/cool (except by their devotees of
> course)
> - they don't have billion dollar companies pushing them(e.g. Sun:Java)
> - most companies follow the crowd
> - most companies only pay for crap programmers
> - despite all the passionate argument to the contrary, and contrived
> examples aside, they simply don't match the performance of C/C++ for
> real world applications (no doubt someone will point out a Paul Graham
> article right about now about Lisp being a secret weapon)
It's hard to use Lisp to match the performance of C or C++ for
real world *subroutines*. The picture is not that clear when you
are talking about entire applications, in which the C or C++ code
badly reinvents half of Common Lisp (in accordance with Greenspun's
Tenth Law). In my experience, when you try to introduce complex
data manipulation and complex abstractions into C++, the performance
starts to suck. One effect is awkward class frameworks that spend
most of their time dispatching among themselves, while doing
little actual work inside their methods. Another effect is the
mindless conversion between multiple representations of the same thing,
as data passes among subsystems. It's not one thing, but just
a general degradation due to many factors, which come to light
with years of programming experience.
That you can get a quicker Fast Fourier Transform hacked up in C
is immaterial, because the ways in which that function connects to the
rest of the program is trivial, and it can be inserted into a higher
level programming language.
If a C compiler is the best tool for a subproblem, there is no reason for
a Lisp programmer to eschew it. But this does not generalize to using
a micro-optimization tool for the entire application.
> - all those parenthesis REALLY ARE a pain in the butt
Writing a program is a pain in the butt because it is work.
It's less work in Lisp, but it's still work.
The only times I find those parenthesis a pain, I realize that the pain comes
not from them but from my self conscious awareness that I'm doing something
stupid to be typing so much and nesting so deeply, when the problem being
solved seems simple by contrast, and when I suspect that some nice trick
could wipe away the complexity.
> - Lisp advocates often seem too defensive (like they are embarressed
> about dirty secret)
My approach is to be abusive toward C++, Java and related trash.
There is nothing to be defensive about in Lisp; it's simply the best.
Anything you can do in Java or C++ can be done far more easily in Lisp
using basically the same naive approach, and even better using a smart
approach that cannot be expressed in Java (other than by way of
Turing equivalence---build a horribly inefficient Java interpreter
for the language which expresses what you want).