Why I can't use Lisp.

199 views
Skip to first unread message

thelifter

unread,
Aug 1, 2002, 4:47:14 PM8/1/02
to
It's because there are no good compilers for free.
If you want a free Lisp system you have to choose between
CLISP(generates only byte-code) and CMUCL(runs only on Unix). So how
are you guys expecting anyone to use it?

Other functional languages are better off. Take Ocaml for example, it
comes with a native code compiler for free.

I agree that Lisp is probably one of the best languages around if not
the best. But what does that help if you can't generate efficient code
with it?

Of course this won't matter if your application doesn't need speed.

A lot of people talk about the nice abstractions that Lisp enables,
but what if that produces slow, lousy code. Look at this interesting
article:

http://www.ai.mit.edu/docs/articles//good-news/subsubsection3.2.2.4.html
"This example is bitterly sad: The code is absolutely beautiful, but
it adds matrices slowly. Therefore it is excellent prototype code and
lousy production code. You know, you cannot write production code as
bad as this in C. "

What help are the higher level structures of Lisp if afterwards I have
to hand-optimize everything to make efficient code?

Now the last practical question:
Inspite of all those points I want to use Lisp for a project of mine.
Speed will be crucial, and I want to generate native code for both
Windows and Linux. I don't have money to buy one of the expensive
proprietary systems, so which compiler can I use if there is one at
all?

Thanks for any help...

--------------------------------
Lisp, a language that works nice in theorie only?

Frode Vatvedt Fjeld

unread,
Aug 1, 2002, 5:03:35 PM8/1/02
to
thel...@gmx.net (thelifter) writes:

> What help are the higher level structures of Lisp if afterwards I
> have to hand-optimize everything to make efficient code?

Even if one were to accept your false premise (that beautiful,
high-level code necessarily produces inefficient programs), the
following would be true: For most applications, only a tiny percent of
the code is actually speed critical. So replace "everything" with "a
little bit".

That there exists code that someone considers to be beautiful but
inefficient, shouldn't really say much to anyone.

--
Frode Vatvedt Fjeld

Wade Humeniuk

unread,
Aug 1, 2002, 5:29:49 PM8/1/02
to

"thelifter" <thel...@gmx.net> wrote in message
news:b295356a.02080...@posting.google.com...

> It's because there are no good compilers for free.
> If you want a free Lisp system you have to choose between
> CLISP(generates only byte-code) and CMUCL(runs only on Unix). So how
> are you guys expecting anyone to use it?
>
> Other functional languages are better off. Take Ocaml for example, it
> comes with a native code compiler for free.
>
> I agree that Lisp is probably one of the best languages around if not
> the best. But what does that help if you can't generate efficient code
> with it?

In your opinion what language/compiler/platform/OS/design/style can be used to produce
efficient code? You are going to to have to define efficient.

>
> Of course this won't matter if your application doesn't need speed.
>
> A lot of people talk about the nice abstractions that Lisp enables,
> but what if that produces slow, lousy code. Look at this interesting
> article:
>
> http://www.ai.mit.edu/docs/articles//good-news/subsubsection3.2.2.4.html
> "This example is bitterly sad: The code is absolutely beautiful, but
> it adds matrices slowly. Therefore it is excellent prototype code and
> lousy production code. You know, you cannot write production code as
> bad as this in C. "
>
> What help are the higher level structures of Lisp if afterwards I have
> to hand-optimize everything to make efficient code?
>
> Now the last practical question:
> Inspite of all those points I want to use Lisp for a project of mine.
> Speed will be crucial, and I want to generate native code for both
> Windows and Linux. I don't have money to buy one of the expensive
> proprietary systems, so which compiler can I use if there is one at
> all?

Use the LispWorks Personal Edition until you are satisfied that it will meet your
requirements and sooth your doubts. I assume you spent money to get your computer, why
not spend money to buy some quality software?

http://www.lispworks.com

Wade

Just as a side note, what kind of app are you running that it has to run on Windows and
Linux? (I assume it has nothing to do with matrix multiplication). They seem pretty
exclusive with apps that run on one not needing to run on the other.

Thomas F. Burdick

unread,
Aug 1, 2002, 5:34:07 PM8/1/02
to
thel...@gmx.net (thelifter) writes:

> It's because there are no good compilers for free.

Bullshit! There aren't any good native-code compilers that satisfy
your unreasonably restrictive requirements. But I'll get to that in a
minute...

> If you want a free Lisp system you have to choose between
> CLISP(generates only byte-code) and CMUCL(runs only on Unix). So how
> are you guys expecting anyone to use it?

And OpenMCL and ECLS. And for no-$ you can use Corman Lisp, and
there's trial versions of the commercial Lisps. It's *remarkable* how
much quality stuff is being given away. On Windows, you can buy the
full Corman environment for dirt cheap. On the Mac, for a little
more, you can get MCL. LWW costs about what one would expect for a
quality development product on Windows, plus you can also buy it for
Unix. Sure, ACL is probably expensive, but in this context, if you're
price-sensitive, you've got lots of other options.

> Other functional languages are better off. Take Ocaml for example, it
> comes with a native code compiler for free.

Common Lisp isn't a functional language. Isn't there only one Ocaml
implementation, anyhow?

[snip]


> http://www.ai.mit.edu/docs/articles//good-news/subsubsection3.2.2.4.html
> "This example is bitterly sad: The code is absolutely beautiful, but
> it adds matrices slowly. Therefore it is excellent prototype code and
> lousy production code. You know, you cannot write production code as
> bad as this in C. "
>
> What help are the higher level structures of Lisp if afterwards I have
> to hand-optimize everything to make efficient code?

You don't. That is one man's opinion that it's hard to write
efficient code in Lisp. I disagree, I think it's about as easy as in
any language. It's true that it's easy to write extremely inefficient
code in Lisp, but it's also easy to think before you write.

One thing that *is* possible in Lisp, that's not in most other
languages, is to write elegant code that's *also* efficient. And it's
not that hard. It's harder than writing dirty, efficient code, sure,
but I do it all the time (but then, I'm a disassembler addict).

> Now the last practical question:
> Inspite of all those points I want to use Lisp for a project of mine.
> Speed will be crucial, and I want to generate native code for both
> Windows and Linux. I don't have money to buy one of the expensive
> proprietary systems, so which compiler can I use if there is one at
> all?

First, LispWorks isn't particularly expensive. Secondly, and more
importantly, you're laboring under a false assumption that you
probably got from other languages: you're assuming you need to pick a
single implementation for all platforms. You don't. Common Lisp is a
big language, and you can do a remarkable amount without leaving the
standardized language. Why not use CMUCL on Linux, and Corman on
Windows. That'll cost you $0, or $100 if you buy Corman (I think[*]).
The implementation-specific portions of your app are likely to be a
tiny fraction of the code, so porting should be very very easy,
especially if you keep it in mind from the outset.

[*] I think I remember Corman Lisp being $100, but I can't check
because they weem to have taken the web site down. I don't understand
why people do this: why can't you leave the old site up while you
design the new one? You can google for an address to write to in the
meantime. It's a good thing that cluefullness as a language
implementor and cluefullness as a website maintainer aren't related.

--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'

Tim Bradshaw

unread,
Aug 1, 2002, 6:00:38 PM8/1/02
to
* thelifter wrote:
> It's because there are no good compilers for free.
> If you want a free Lisp system you have to choose between
> CLISP(generates only byte-code) and CMUCL(runs only on Unix). So how
> are you guys expecting anyone to use it?

How can anyone use perl, or python? Yet somehow they manage.

> http://www.ai.mit.edu/docs/articles//good-news/subsubsection3.2.2.4.html
> "This example is bitterly sad: The code is absolutely beautiful, but
> it adds matrices slowly. Therefore it is excellent prototype code and
> lousy production code. You know, you cannot write production code as
> bad as this in C. "

This well-known quote is nothing to do with the compiler of course,
it's to do with crap choice of data structures. So why are you
bringing it in here?

> Inspite of all those points I want to use Lisp for a project of mine.
> Speed will be crucial, and I want to generate native code for both
> Windows and Linux. I don't have money to buy one of the expensive
> proprietary systems, so which compiler can I use if there is one at
> all?

On linux there is CMUCL, on Windows there's Corman lisp, both
native-code systems. Or you can use the free versions of the
commercial systems. Or, if you care so much about it you could
*contribute to one of the free systems* instead of whining. Not, I
expect, that this will satisfy you, since you're just a troll, or
doing a very good impression of one.

--tim

Jochen Schmidt

unread,
Aug 1, 2002, 6:35:29 PM8/1/02
to
thelifter wrote:

> It's because there are no good compilers for free.
> If you want a free Lisp system you have to choose between
> CLISP(generates only byte-code) and CMUCL(runs only on Unix). So how
> are you guys expecting anyone to use it?

Nobody is expecting anybody to use it - Everybody has to decide themselves
if they need/want to use Lisp.

> Other functional languages are better off. Take Ocaml for example, it
> comes with a native code compiler for free.

Well - depends on what you count as better - there is only a single
implementation of Ocaml - there are plenty of Common Lisp implementations
to choose from.

I think the problem you outline might be a different one. It is generally no
problem for people to buy tools if they want to make money out of it. A
need for "gratis" tools is mainly in those areas where one only wants to
play with it. Most (all?) Common Lisp vendors offer free editions of their
products for non-commercial use. Some of them do not offer all features of
the full editions but Corman Lisp for example does come fully functional
and even with source!

If you only want to play with Common Lisp you can use CMUCL or SBCL on Unix,
OpenMCL on Mac and Corman Lisp on Windows which are all native-code
compilers.

If you want to earn money with Applications written in Common Lisp then the
cost of a commercial lisp-system will be minor I think.

> I agree that Lisp is probably one of the best languages around if not
> the best. But what does that help if you can't generate efficient code
> with it?

Well - you can!

> Of course this won't matter if your application doesn't need speed.
>
> A lot of people talk about the nice abstractions that Lisp enables,
> but what if that produces slow, lousy code. Look at this interesting
> article:
>
> http://www.ai.mit.edu/docs/articles//good-news/subsubsection3.2.2.4.html
> "This example is bitterly sad: The code is absolutely beautiful, but
> it adds matrices slowly. Therefore it is excellent prototype code and
> lousy production code. You know, you cannot write production code as
> bad as this in C. "

I think you did not see the point (sorry). Writing production code is
difficult - regardless of which language you use. Language which offer
better means of abstraction like Lisp enable you to delay important
decisions until you know enough about your problem to do it right.
So the above comment was not about Lisp being unable to write production
code similar efficient to C but it was about C being unable to do rapid
development in this style. It contains a warning that one should not think
that the mere use of Lisp suddenly makes writing production level code dead
easy.

> What help are the higher level structures of Lisp if afterwards I have
> to hand-optimize everything to make efficient code?

It simply an optimization problem. In C you come with zero knowledge and try
to figure out how to do it efficiently from the first line on. In Lisp you
develop the program and you collect enough information about the problem to
enable you to decide about the _right_ optimizations.
So:
1) You do less optimizations which gain nothing
2) You do fall less easily into a local minima

Coding in C is a bit similar to a simple Greedy search - directly running
into the next local minima. Lisp enables you to collect enough information
to increase your chance of finding the global minima.

> Now the last practical question:
> Inspite of all those points I want to use Lisp for a project of mine.
> Speed will be crucial, and I want to generate native code for both
> Windows and Linux. I don't have money to buy one of the expensive
> proprietary systems, so which compiler can I use if there is one at
> all?

See above.

> --------------------------------
> Lisp, a language that works nice in theorie only?

No.

ciao,
Jochen

--
http://www.dataheaven.de

Erik Naggum

unread,
Aug 1, 2002, 7:14:34 PM8/1/02
to
* thel...@gmx.net (thelifter)

| It's because there are no good compilers for free.

It is because you are unable to make money on what you do, and that again is
because have nothing to offer anyone. This may be by nature of by choice,
but you will get nowhere unless you start to think in terms of what the other
guy wants from you in order to give you want.

| Look at this interesting article:

It was published in 1991.

| Inspite of all those points I want to use Lisp for a project of mine.

You have not given us any indication whatsoever why you would benefit from
using Common Lisp over any other language, why anyone would benefit from
helping you, nor why anyone would benefit from the work you say you would
want to do in Common Lisp. The conclusion is pretty solid: You have nothing
to offer anybody but a demand that they provide the means for you to have fun.

| I don't have money to buy one of the expensive proprietary systems, so which
| compiler can I use if there is one at all?

In other words, you have no funding, no competence, and no customers. Then
you are unhappy that nobody will support your project at their expense so you
can reap all the benefits without investing anything other than your time,
which is evidently not exchangeable for money even if you did something else.
This lack of ability to delay gratification is alarming. It means that you
do not even control the patience to work on something else that will provide
you the means to purchase a Common Lisp system from which you can make free
executables and make money off of it, nor the patience to use a personal or
trial edition to demonstrate to somebody that they should pay for it for you.

| Thanks for any help...

Have you actually asked the vendors of commercial systems what you could do
together to solve your "problem"? I hazard a guess that you have not. From
your style and the sheer absence of information, I hazard a guess that you
are the whining type, meaning that whining has gotten you something and
somewhere in your past, probably where you are now. You should realize that
there is a pretty low upper limit to what you can achieve with whining. Your
parents may have caved in to your incessant whining, but that does not mean
that anyone else will cave in if you only whine long enough.

If you now feel like defending yourself, you have missed the point entirely.

BTW, in my book, a "lifter" is a thief.

--
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.

Dan Corkill

unread,
Aug 1, 2002, 7:22:54 PM8/1/02
to
> If you want to earn money with Applications written in Common Lisp then the
> cost of a commercial lisp-system will be minor I think.

True at the development end, but the distribution licensing/cost
can be a significant issue. How many applications are being
developed in Java mostly due to the perceived distribution
advantages? Unless it is a very high-priced commercial
application, the per-seat distribution cost dominates over
development time and expense.

Joel Ray Holveck

unread,
Aug 1, 2002, 7:49:04 PM8/1/02
to
Is this a troll?

> It's because there are no good compilers for free.

I use CMUCL and love it.

> If you want a free Lisp system you have to choose between
> CLISP(generates only byte-code) and CMUCL(runs only on Unix).

Are you sure that CLISP's bytecode is worse than the next language's
native code? The first bytecode system I used was written to improve
efficiency. It works for JVMs today (okay, bad example), and the x86
instruction set is a bytecode that gets massaged into RISC
instructions by the CPU.

Anybody who's ever sat down with a profiler knows that 95% of the CPU
is taken up by 5% of the code. So take a guess what your 5% will
be[1]. Write a Lisp implementation. Write an implementation in a
different language. Benchmark them.

Others have pointed out alternatives if you want Windows; I won't go
there.

> So how are you guys expecting anyone to use it?

We use it. I use Lisp for my job all the live-long day. I have
friends who do too. I expect people can use it, because I know people
who use it.

> I agree that Lisp is probably one of the best languages around if not
> the best. But what does that help if you can't generate efficient code
> with it?

Ah, but what type of efficiency are you looking for? Today's market
shows over and over again that a 5% performance increase doesn't mean
squat if you're six months slower to market. (See also
http://www.paulgraham.com/paulgraham/avg.html for a case study on this
point: Yahoo! Store.)

Look in the "Efficiency" section of the Camel Book. (If you don't
know what the Camel Book is, find a friend who knows Perl.) There's
lots of types of efficiency: we know about time efficiency and space
efficiency, but what about programmer efficiency? I can get a lot
more work done using Lisp in a month than using C in a month[2]. What
about maintainer efficiency?

You can sometimes trade one for another. I can sometimes spend twice
as long writing the code to get a 2x speed increase at runtime.
Because of Lisp's faster development times, you can spend more time
improving your algorithm instead of doing memory management.

Because I can express myself more clearly in Lisp, I can write more
straightforward-- and often faster-- algorithms. I can also
experiment with different algorithms very easily, or modify and tweak
the best algorithms I use. When I'm working in an area where there's
been little commercial experimentation, this is very important.
(See http://world.std.com/~pitman/PS/Hindsight.html for information on
how Lisp can help you write code more quickly.)

Because of this, I'd expect that Lisp gets me *more* speed than other
languages, given that I'm operating within deadlines, budgets, etc.
(After all, I found the time to respond to this troll, didn't I?)

> Of course this won't matter if your application doesn't need speed.

Such as... say... circuit switches?
http://web.archive.org/web/19971013232242/http://www.harlequin.com/news/press/archive/pr-att.html
(This discusses AT&T using a real-time Lisp implementation to handle
ATM build-ups and tear-downs.)

> A lot of people talk about the nice abstractions that Lisp enables,
> but what if that produces slow, lousy code. Look at this interesting
> article:

If the hardware store gives you some rope, and you tie a noose and
hang yourself with it, don't blame the hardware store's. Don't blame
the rope.

You can write a bubble sort in any language. That doesn't mean that
the language is bad. The fact that Lisp gives you more power doesn't
mean you should ignore efficiency.

> What help are the higher level structures of Lisp if afterwards I have
> to hand-optimize everything to make efficient code?

As mentioned above, 95% of the CPU time is spent in 5% of the code.
Hand-optimize that 5%. Since you were able to write the code quickly
using Lisp, you'll have plenty of time to optimize it-- if you find
you still need to.

What's more, you can naturally experiment with better structures and
algorithms, allowing you to macro-optimize for the big (polynomial)
wins, rather than micro-optimizing for little (linear) wins because
your language won't let you adapt easily.

> Now the last practical question:
> Inspite of all those points I want to use Lisp for a project of mine.

Then why on earth didn't you say so in the first place? If you want
to find a good compiler, ask "What's a good compiler for FOO?". Don't
say "Your language sucks! Now, point me to a good compiler!"

> Speed will be crucial, and I want to generate native code for both
> Windows and Linux.

Unlike most languages, it's okay to use different implementations for
different deployments. I sometimes develop my Lisp programs on an
entirely different system than I deploy them on-- far greater
differences than Win vs Linux.

joelh

[1] Anybody who's ever sat down with a profiler knows that this guess
will likely be wrong, but that's okay.

[2] And not because I know Lisp better... I've been using C for rather
a while longer.

Jochen Schmidt

unread,
Aug 1, 2002, 8:15:18 PM8/1/02
to
Dan Corkill wrote:

Hm... there is no per seat distribution cost in all free Lisps and at least
LispWorks and Corman Lisp. (Don't know about MCL).

Brad Miller

unread,
Aug 1, 2002, 7:57:07 PM8/1/02
to

"Dan Corkill" <danco...@attbi.com> wrote in message
news:3D49C2CD...@attbi.com...

That's true, but AFAIK, at least two commercial lisps either don't charge or
have a one time charge for distribution licenses (I'm thinking of Digitool's
MCL and Xanalys LispWorks).


Dan Corkill

unread,
Aug 1, 2002, 8:34:30 PM8/1/02
to

MCL Redistribution Licenses are similar. My point wasn't that CL
didn't have free distribution licenses, but rather that for other
than limited high-priced applications the development software cost
is a tiny part of the commercial equation. Too often, CL is dismissed
out-of-hand because it is perceived as delivery expensive...

Christopher Browne

unread,
Aug 1, 2002, 10:10:46 PM8/1/02
to
In an attempt to throw the authorities off his trail, Dan Corkill <danco...@attbi.com> transmitted:

The problem with _that_ thesis is that the "J2EE" environments are
often rather expensive themselves.

Sun and BEA and IBM and the likes send out "account managers" to
customers, which has the essential result that pricing represents
Complex Numbers That You Know Are Big, and by that, I don't mean (sqrt
-750000).

The cost and complexity of the Java environments is quite stunning,
all in all.
--
(concatenate 'string "cbbrowne" "@acm.org")
http://cbbrowne.com/info/oses.html
"Anyone who says you can have a lot of widely dispersed people hack
away on a complicated piece of code and avoid total anarchy has never
managed a software project." Andrew Tanenbaum, 1992.

Raffael Cavallaro

unread,
Aug 1, 2002, 10:23:41 PM8/1/02
to
thel...@gmx.net (thelifter) wrote:
> Lisp, a language that works nice in theorie only?

Shouldn't that be (thetroller)?

Johan Kullstam

unread,
Aug 1, 2002, 11:20:15 PM8/1/02
to
thel...@gmx.net (thelifter) writes:

> It's because there are no good compilers for free.
> If you want a free Lisp system you have to choose between
> CLISP(generates only byte-code) and CMUCL(runs only on Unix).

If it is freeness which you want (as in beer or source),
CMUCL runs on linux (which is technically not Unix). Linux is free.

If you run windows, then you should be used to paying, at least a
small amount, for software. You bought windows didn't you?

> So how
> are you guys expecting anyone to use it?

If you are using windows, why not try Corman lisp? Its price is
certainly low enough to be near free. I mean, you paid more for
windows. Also Corman seems to support his lisp (I have no personal
experience but he does comment here form time to time) and I think he
even gives out some sources.

> Other functional languages are better off. Take Ocaml for example, it
> comes with a native code compiler for free.

So does lisp. CMUCL just happens to not be on a platform of your
choice.

> I agree that Lisp is probably one of the best languages around if not
> the best. But what does that help if you can't generate efficient code
> with it?
>
> Of course this won't matter if your application doesn't need speed.
>
> A lot of people talk about the nice abstractions that Lisp enables,
> but what if that produces slow, lousy code. Look at this interesting
> article:
>
> http://www.ai.mit.edu/docs/articles//good-news/subsubsection3.2.2.4.html
> "This example is bitterly sad: The code is absolutely beautiful, but
> it adds matrices slowly. Therefore it is excellent prototype code and
> lousy production code. You know, you cannot write production code as
> bad as this in C. "
>
> What help are the higher level structures of Lisp if afterwards I have
> to hand-optimize everything to make efficient code?
>
> Now the last practical question:
> Inspite of all those points I want to use Lisp for a project of mine.
> Speed will be crucial, and I want to generate native code for both
> Windows and Linux. I don't have money to buy one of the expensive
> proprietary systems, so which compiler can I use if there is one at
> all?

Try Corman lisp on windows and CMUCL on linux.

> Thanks for any help...
>
> --------------------------------
> Lisp, a language that works nice in theorie only?

--
Johan KULLSTAM

Friedrich Dominicus

unread,
Aug 2, 2002, 1:39:59 AM8/2/02
to
t...@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:

> On Windows, you can buy the
> full Corman environment for dirt cheap.
> On the Mac, for a little
> more, you can get MCL.

That's not true anymore
Corman Lisp US$ 200
MCL US$ 95


> LWW costs about what one would expect for a
> quality development product on Windows, plus you can also buy it for
> Unix.

I think too that the price for LispWorks is adequate.


> Sure, ACL is probably expensive, but in this context, if you're
> price-sensitive, you've got lots of other options.

Well the last time I asked I got not very promising figures...


>
> > Other functional languages are better off. Take Ocaml for example, it
> > comes with a native code compiler for free.
>
> Common Lisp isn't a functional language. Isn't there only one Ocaml
> implementation, anyhow?

Yes there is just one Ocaml implementation but it's quite good.

>
> > Now the last practical question:
> > Inspite of all those points I want to use Lisp for a project of mine.
> > Speed will be crucial, and I want to generate native code for both
> > Windows and Linux. I don't have money to buy one of the expensive
> > proprietary systems, so which compiler can I use if there is one at
> > all?
>
> First, LispWorks isn't particularly expensive. Secondly, and more
> importantly, you're laboring under a false assumption that you
> probably got from other languages: you're assuming you need to pick a
> single implementation for all platforms. You don't.

Well you don't but it makes live definitly easier. You can use things
e.g from LispWorks which are not part of the standard but work across
Operating System boundaries while using LispWorks. I have to say that
I hate this "I want it all, *and* for free" attitude. How much does
you get charged for while asking for implementation services? And how
long have one in the US or Europe to work to buy a commercial licence?

I would really like to see that people do that calculation on their
own, and to not come jsut along lamenting how expensive all things
are...

> Common Lisp is a
> big language, and you can do a remarkable amount without leaving the
> standardized language. Why not use CMUCL on Linux, and Corman on
> Windows. That'll cost you $0, or $100 if you buy Corman (I think[*]).
> The implementation-specific portions of your app are likely to be a
> tiny fraction of the code, so porting should be very very easy,
> especially if you keep it in mind from the outset.

Well if he does write an application with GUI stuff you do not get
along that easy ...


regards
Friedrich

Friedrich Dominicus

unread,
Aug 2, 2002, 1:49:44 AM8/2/02
to
Jochen Schmidt <j...@dataheaven.de> writes:

>
> > I agree that Lisp is probably one of the best languages around if not
> > the best. But what does that help if you can't generate efficient code
> > with it?
>
> Well - you can!

Definitly.


>
> > Of course this won't matter if your application doesn't need speed.
> >
> > A lot of people talk about the nice abstractions that Lisp enables,
> > but what if that produces slow, lousy code. Look at this interesting
> > article:
> >
> > http://www.ai.mit.edu/docs/articles//good-news/subsubsection3.2.2.4.html
> > "This example is bitterly sad: The code is absolutely beautiful, but
> > it adds matrices slowly. Therefore it is excellent prototype code and
> > lousy production code. You know, you cannot write production code as
> > bad as this in C. "
>
> I think you did not see the point (sorry). Writing production code is
> difficult - regardless of which language you use. Language which offer
> better means of abstraction like Lisp enable you to delay important
> decisions until you know enough about your problem to do it right.
> So the above comment was not about Lisp being unable to write production
> code similar efficient to C but it was about C being unable to do rapid
> development in this style. It contains a warning that one should not think
> that the mere use of Lisp suddenly makes writing production level code dead
> easy.

Well it's a kind of mind-set which comes along with different
langauges. E.g in C you sacrify safety for speed. Just an example then
handling of "Strings"
strcpy (source,target);
is as fast as can be I assume but nothing prevents you from running
over bounds. I just have encountered such a thing yesterday in one of
the libraries I wrote. Which fair enough is a sort of safer String
facility for C...

The other point is that you can nearly see through C code and spot the
problematic points. It's easy to forgot in Lisp.
(append is just an example.

Well one should assume that programmers have an idea on how some
things are implemented but it seems this is a somewhat forgotten
thing. Just drop together some pieces and you got a progam ...

>
> > What help are the higher level structures of Lisp if afterwards I have
> > to hand-optimize everything to make efficient code?
>
> It simply an optimization problem. In C you come with zero knowledge and try
> to figure out how to do it efficiently from the first line on.

Ah well I see my comments were probably not necessary...


>
> Coding in C is a bit similar to a simple Greedy search - directly running
> into the next local minima. Lisp enables you to collect enough information
> to increase your chance of finding the global minima.

Well another thing is Microoptomization. C people are usually after it
like hell....

>
> > Now the last practical question:
> > Inspite of all those points I want to use Lisp for a project of mine.
> > Speed will be crucial, and I want to generate native code for both
> > Windows and Linux. I don't have money to buy one of the expensive
> > proprietary systems, so which compiler can I use if there is one at
> > all?

Ignorance does not buy you anything. And as programmer you should be
able to calculate too. So why don't you decide what you want to do and
check than if you can't use the alternatives which were pointed out.

Friedrich

Friedrich Dominicus

unread,
Aug 2, 2002, 1:55:36 AM8/2/02
to
Erik Naggum <er...@naggum.no> writes:

>
> | Inspite of all those points I want to use Lisp for a project of mine.
>
> You have not given us any indication whatsoever why you would benefit from
> using Common Lisp over any other language, why anyone would benefit from
> helping you, nor why anyone would benefit from the work you say you would
> want to do in Common Lisp. The conclusion is pretty solid: You have nothing
> to offer anybody but a demand that they provide the means for you
> to have fun.

Well better put than I was able to do.


>
> | I don't have money to buy one of the expensive proprietary systems, so which
> | compiler can I use if there is one at all?
>
> In other words, you have no funding, no competence, and no customers. Then
> you are unhappy that nobody will support your project at their expense so you
> can reap all the benefits without investing anything other than your time,
> which is evidently not exchangeable for money even if you did something else.
> This lack of ability to delay gratification is alarming. It means that you
> do not even control the patience to work on something else that will provide
> you the means to purchase a Common Lisp system from which you can make free
> executables and make money off of it, nor the patience to use a personal or
> trial edition to demonstrate to somebody that they should pay for
> it for you.

A bit harsh but fully on the point IMHO. I guess I put it away in a
collection and cite from it, every now and then.

Regards
Friedrich

Chris Double

unread,
Aug 2, 2002, 1:53:49 AM8/2/02
to
t...@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:

> [*] I think I remember Corman Lisp being $100, but I can't check
> because they weem to have taken the web site down. I don't understand
> why people do this: why can't you leave the old site up while you
> design the new one? You can google for an address to write to in the
> meantime. It's a good thing that cluefullness as a language
> implementor and cluefullness as a website maintainer aren't related.

It's up as far as I can see:

http://www.corman.net

or

http://www.cormanlisp.com

Chris.

Rolf Wester

unread,
Aug 2, 2002, 6:43:51 AM8/2/02
to
thelifter wrote:
> It's because there are no good compilers for free.
> If you want a free Lisp system you have to choose between
> CLISP(generates only byte-code) and CMUCL(runs only on Unix). So how
> are you guys expecting anyone to use it?
>
> Other functional languages are better off. Take Ocaml for example, it
> comes with a native code compiler for free.
>
This is only true if you don't want to use the interactive interpreter.
This is much slower. In CMUCL you have high speed and interactive
dynamic development.

> I agree that Lisp is probably one of the best languages around if not
> the best. But what does that help if you can't generate efficient code
> with it?
>


Concerning efficiency I don't think that the difference between CMUCL
and C++ is as big as you seem to expect. I tried matrix matrix
multiplication routines in CL and C++ (pure C-code is about two times
faster but C-arrays are also much more low level). The results are
listed below (I used a 120 MHz Pentium PC running under Linux):


----- CL -------------------------------------

(defun matmul (mat1 mat2)
(declare (optimize (speed 3) (debug 1) (safety 1)))
(declare (type (simple-array double-float (* *)) mat1 mat2))
(let* ((n1 (array-dimension mat1 0))
(n2 (array-dimension mat1 1))
(mat3 (make-array (list n1 n2) :element-type 'double-float)))
(declare (type fixnum n1 n2))
(declare (type (simple-array double-float (* *)) mat3))
(loop for i fixnum from 0 below n1 do
(loop for j fixnum from 0 below n1 do
(let ((sum 0.0d0))
(declare (type double-float sum))
(loop for k fixnum from 0 below n1 do
(setf sum (+ sum (* (aref mat1 i k) (aref mat2 k j)))))
(setf (aref mat3 i j) sum))))
mat3))


(defun main (n)
(declare (type fixnum n))
(let ((mat1 (make-array (list n n) :element-type 'double-float
:initial-element 1.0d0))
(mat2 (make-array (list n n) :element-type 'double-float :initial-element
2.0d0)))
(let ((mat3 (matmul mat1 mat2)))
(declare (type (simple-array double-float (* *)) mat3))
(format t "~A ~%" (aref mat3 10 10)))))


(time
(main 200))

400.0d0
Evaluation took:
7.53 seconds of real time
6.38 seconds of user run time
0.05 seconds of system run time
0 page faults and
968648 bytes consed.
NIL


--------- C++ --------------------------------------------

#include <vector>
#include <iostream>

int main()
{
int n1 = 200;
int n2 = 200;

vector< vector <double> > mat1(n1);
vector< vector <double> > mat2(n1);
vector< vector <double> > mat3(n1);

int i,j,k;

for(i=0; i < n1; i++)
{
mat1[i] = vector<double>(n2, 1.0);
mat2[i] = vector<double>(n2, 2.0);
mat3[i] = vector<double>(n2, 0.0);
}

for(i=0; i < n1; i++)
{
for(j=0; j < n2; j++)
{
for(k=0; k < n1; k++)
{
mat3[i][j] += mat1[i][k] * mat2[k][j];
}
}
}
cout << mat3[10][10] << endl;
cout << mat3[10][200] << endl;

return 0;
}

g++ -O3 -o matmul_cpp matmul.cpp

time ./matmul_cpp
400
3.41429e-311

real 0m6.555s
user 0m5.600s
sys 0m0.050s

------

Besides this please notice that

cout << mat3[10][200] << endl;

doesn't issue an error but nonsense. CMUCL checks array indices, C++
doesn't.


Rolf Wester


P.S.: It would be interesting to know how well other CL implementations
(LispWorks, Corman, ACL, ECLS etc.) perform in case of the above example.

Thomas F. Burdick

unread,
Aug 2, 2002, 3:46:54 PM8/2/02
to
Chris Double <ch...@double.co.nz> writes:

Oh how embarassing, I was looking at the wrong URL. Thankfully,
cluefullness as a programmer isn't related to cluefullness as a
web-luser :-P

Roger Corman

unread,
Aug 2, 2002, 5:29:43 PM8/2/02
to
On Fri, 02 Aug 2002 03:20:15 GMT, Johan Kullstam
<kulls...@attbi.com> wrote:

>If you are using windows, why not try Corman lisp? Its price is
>certainly low enough to be near free. I mean, you paid more for
>windows. Also Corman seems to support his lisp (I have no personal
>experience but he does comment here form time to time) and I think he
>even gives out some sources.

All the sources except the source code for the IDE are included in the
package. It is completely functional without the IDE.

We try to offer excellent support--even for users who have not
purchased a license. We follow this newsgroup, the corman lisp message
board, and respond to mail (sup...@cormanlisp.com).

When anybody discovers serious issues, we try to post a patch within
24-48 hours. I believe this is better support than most software
products offer.

Having said all this, we are taking one week off (Aug. 5 - 9) and will
respond to messages received during that time as soon as we return to
the office.

Roger

Camm Maguire

unread,
Aug 2, 2002, 7:52:23 PM8/2/02
to
Greetings! Just a note to the original author that GCL runs on
windows, produces native code, and is free as in beer *and speech*.

Its only CLtL1 compliant at present, but we're working on that ....

Take care,
--
Camm Maguire ca...@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah

Thaddeus L Olczyk

unread,
Aug 2, 2002, 8:24:54 PM8/2/02
to
On 1 Aug 2002 13:47:14 -0700, thel...@gmx.net (thelifter) wrote:

>Inspite of all those points I want to use Lisp for a project of mine.
>Speed will be crucial, and I want to generate native code for both
>Windows and Linux. I don't have money to buy one of the expensive
>proprietary systems, so which compiler can I use if there is one at
>all?

You trolls how dare you act this way.
Every few weeks one of you comes in with the same
demand, a free or cheap Lisp compiler that works on both
Windows and Linux.

Don't you trolls realize that the Lisp community has better
things than to cater to your every whim and desire? Especially
the totally unreasonable ones. Never mind that Perl, Ruby, Python,
C++, Java, Smalltalk, Ocaml and several other languages have no
trouble providing this. This is Lisp and the Lisp community has better
things to do than provide you stupid trolls with adequate tools.

You should be thanking God that you have the privileged of providing
the Lisp community with $100000 (oops since you want both Windows
and Linux double that ) for just the chance to do development with
Lisp. If you don't well then the Lisp community is better off without
you and your kind. That's their attitude and look at how much it has
done them to this point.

And just what would it buy to even pretend to help you trolls. Why you
trolls might start learning Lisp. Which might start managers thinking
that there is a pool of Lisp programmers out there to hire, and just
like happened to Perl and Python, they might start Lisp projects.
Couldn't have that.

You see there's Gabriel's rule ( The best technology is not the most
popular one ), and a "corollary" ( not really but people do stretch
the logic ) to it ( The less popular the technology the better it is).
If Lisp were ever to become popular, then members of the Lisp
community couldn't go around saying "I'm a Lisp programmer so
therefore I'm one of the best." Instead they might actually be forced
to prove how good they are.

So stay away little troller. You're just going to spill the boat over.
The Lisp community would rather the language just slowly died.

Thaddeus L Olczyk

unread,
Aug 2, 2002, 8:25:02 PM8/2/02
to
>--------- C++ --------------------------------------------
>
>#include <vector>
>#include <iostream>
>
>int main()
>{
> int n1 = 200;
> int n2 = 200;
>
> vector< vector <double> > mat1(n1);
> vector< vector <double> > mat2(n1);
> vector< vector <double> > mat3(n1);
>
What moron would use vector for matrices?
The overhead kills you. Aside from the fact
that vecotr is just a sumb way of doing this.
BTW the matrices are never initialised ( didn't catch it in the lisp
either ) which makes the whole thing rather dumb and the compiler
would be right to remove the whole thing.

If I were to do any kind of matrix stuff in C++ I would use
GMCL ( described in Generative Programming: Eisenecker and Czernacki )
or MTL ( it's successor ). In both cases they may come out slower in
these simple trials ( all though I think there is a good chance that
performance will be high ).

However in calculating expressions like (mat1+mat2)*mat3
+(mat2+mat3)*mat1, both libraries will burn ruber, so to speak.

All this shows is most people who try to do language comparisons
x vs y are morons.

They turn out to be experts in one ( in this case lisp ) and suck at
the other ( C++ ). The result is code noone should ever write in the
later language resulting in the former winning ( which is the one the
person is expert in and usually the one that the person wants to
win--suprise! ).

Reminds me of the web page comparing OCaml and C. The guy boasts
that he even used "goto's" to hand optimise the C. Too stupid to
realise that goto's tend to wreak havoc with optimisers.

Joel Ray Holveck

unread,
Aug 2, 2002, 9:20:36 PM8/2/02
to
> They turn out to be experts in one ( in this case lisp ) and suck at
> the other ( C++ ). The result is code noone should ever write in the
> later language resulting in the former winning ( which is the one the
> person is expert in and usually the one that the person wants to
> win--suprise! ).

The October 1999 CACM included a study by Prechelt which used
programmers who preferred the languages they were using to compare
Java and C++.

There's a followup paper by Erann Gat, "Lisp as an Alternative to
Java" at http://alvin.jpl.nasa.gov/gat/lisp-study.html.

> Reminds me of the web page comparing OCaml and C. The guy boasts
> that he even used "goto's" to hand optimise the C. Too stupid to
> realise that goto's tend to wreak havoc with optimisers.

It's not as bad as people make it out to be... check out the assembly
produced sometime. I'm not advocating goto, but I don't discourage it
for this reason.

joelh

Hartmann Schaffer

unread,
Aug 2, 2002, 9:54:11 PM8/2/02
to
In article <gftkkuk75550tt5ii...@4ax.com>,
Thaddeus L Olczyk <olc...@interaccess.com> writes:
> ...

> Reminds me of the web page comparing OCaml and C. The guy boasts
> that he even used "goto's" to hand optimise the C. Too stupid to
> realise that goto's tend to wreak havoc with optimisers.

since when?

hs

--

don't use malice as an explanation when stupidity suffices

Paul F. Dietz

unread,
Aug 2, 2002, 10:22:01 PM8/2/02
to
Hartmann Schaffer wrote:

> > Reminds me of the web page comparing OCaml and C. The guy boasts
> > that he even used "goto's" to hand optimise the C. Too stupid to
> > realise that goto's tend to wreak havoc with optimisers.
>
> since when?

Perhaps the troll Mr. Schaffer is responding to is too stupid
to think that someone might have used the -S option in the compiler
to actually determine the effect of those gotos.

BTW, I understand the Linux kernel makes use of gotos to microoptimize
speed-critical parts of the code (moving rarely executed code out of
line so it doesn't waste cache space, for example).

Paul

Don Geddis

unread,
Aug 2, 2002, 11:16:00 PM8/2/02
to
thel...@gmx.net (thelifter) writes:
> A lot of people talk about the nice abstractions that Lisp enables,
> but what if that produces slow, lousy code. Look at this interesting
> article:
> http://www.ai.mit.edu/docs/articles//good-news/subsubsection3.2.2.4.html
> "This example is bitterly sad: The code is absolutely beautiful, but
> it adds matrices slowly. Therefore it is excellent prototype code and
> lousy production code. You know, you cannot write production code as
> bad as this in C. "
> What help are the higher level structures of Lisp if afterwards I have
> to hand-optimize everything to make efficient code?

Did you even bother to read the page that you're quoting from? The previous
sentence is:

What's worse is that in the particular application, the matrices were
all fixed size, and matrix arithmetic would have been just as fast in
Lisp as in FORTRAN.

Note that the author is complaining about the programmer, not about Lisp.
"Matrix arithmetic would have been just as fast in Lisp as in FORTRAN,"
if only the programmer bothered to think about what he was doing.

Bad programmers can implement bad algorithms in any language. This example had
nothing to do with the Lisp language.

-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org d...@geddis.org
In the history of Mars, the Martians probably went through a cowboy stage just
like we did. And they're just as ashamed of it as we are.
-- Deep Thoughts, by Jack Handey [1999]

Erik Naggum

unread,
Aug 3, 2002, 12:11:51 AM8/3/02
to
The most important, if not the only, difference between the Common Lisp world
and that of most other languages is that it is /perceived/ to be impossible to
get anything done with the free Common Lisp systems; you cannot even /learn/
Common LIsp using the free Common Lisp systems; not even the Trial Edition of
Allegro CL or the Personal Edition of LispWorks will satisfy the "newbie" who
wants to use Common Lisp.

I have no idea where this /perception/ comes from or how it originated, but it
is apparently deeply ingrained in people who know nothing about Common Lisp
and refuse to learn or listen. The amazingly stupid people who remain newbies
for their entires lives seem to be upset about something related to commercial
systems, but I actually wonder what it might be. I think it /might/ be envy.

Do you /need/ the power of the expensive commercial systems to use Common Lisp?
No. What is it that people /miss/ when they claim that they cannot use Common
Lisp for their applications while they /could/ use just about any other language?
I actually do not know, nor do I know where to start to understand this issue.

Allow me to illustrate why I fail to understand this issue with a past project
of mine. I developed a system for real-time distribution of financial news
for a wire service using Common Lisp that depended on multiprocessing support
in the Common Lisp environment, in particular the ability to listen for
activity on more than one socket. We chose a commercial Common Lisp. The
reasons why we made this choice should be illumiating.

The real-time nature of the application means that it was not CPU-intensive,
and thus did not need preemptive multitasking between the processes. What
made it so convenient to use multi-threading in the Common Lisp environment
was the shared memory. It would have been possible to use the file system to
share information between processes and to use a control connection to each
process and then to implement a broker for messages between the processes. It
would be a different design that might have required more time to implement,
but it would most certainly be doable. The application would need to be
implemented as an event dispatcher in each process, and it would have to be
taught how to listen for activity on several sockets (as in the select system
call) if the Common Lisp system did not already know how to do that. I
estimate that this complexity would have meant an additional month of
development time, but it would also have meant that we would have needed more
powerful hardware, since the memory requirements would be much higher and the
processing power to deal with the interprocess communication (IPC) would be
significantly higher.

However, my system was to replace an overly complex system that basically did
a tremendous amount of IPC and which had serious problems and shortcomings
because of the constraints of the IPC methodology used, such as starting and
stopping parts of the system independently. (You would think not, but it was
written by an idiot.) It would have been a hard sell if I had argued that I
would replace the existing mess with another mess of approximately the same
magnitude. So what I sold the project on was in fact that I could make all
this a lot simpler in Common Lisp and thus remove the manual monitoring
required by the frequently failing system. In this regard, it was indeed the
benefits of the commercial Common Lisp environment that made the project.
This was a highly commercial project, with high risk and high benefits. It
had to succeed in a hostile environment,I would have to bring all the clients
of the news wire on board with a new communication protocol to solve major
problems in the previous design, and I needed all the confidence that money
could buy -- in this case, it was for sale in the form of a commercial Common
Lisp system.

The commercial Common Lisp development environment was dwarfed the other costs
involved. (We were much less happy with the "runtime" licensing, but the time
and money I spent on that was still worth the cost compared to reimplementing
it with a lesser environment, again mostly because of the confidence required
in the multi-threading support.) /However/, had this /not/ been a project to
salvage a wire service that would in all likelihood have faced survival issues
if it had continued to crash and involve lots of manpower to keep it running,
and I had been hired to do the original project, instead, I could easily have
taken a chance on a "free" environment first, and in case of problems or costs
or failure, have purchased "safety" in a supported commercial environment.

I included this fairly long exposition of this project to show that I chose a
commercial Common Lisp environment with commercial values in mind. I would
have to implement some of the things I would have gotten with that commercial
environment if I used a free environment, and I would have to make myself an
expert in the performance of IPC and socket communication and streams in
Common Lisp, and many other internal details. I have become that expert over
time, but I was not ready to do it at that time. So another commercial value
is development and testing time before deployment. I wager that these are
/not/ issues for the free environments, /nor/ of their usability. If you /can/
afford to develop this for yourself, you should do it. If you can /neither/
afford to develop it yourself /nor/ purchase it from someone who has, you had
better realize that you should not take on the project.

What /is/ missing in the perception of the immature and inexperienced Common
Lisp programmers is that /even/ if you had to do the internal stuff you would
have to do in any other programming language and /even/ if this non-portable
and implementation-dependent, you are /less/ system-dependent and /less/
forced to work at the internal /level/. This is hard to empathize enough to
those who have made up their mind that they should get everything for free
before they can even /start/ to think about using Common Lisp, but Common Lisp
offers so much more convenience in the higher-level logic of the application
and so much better ways to think about the system-dependency issues and the
native operating system support that it is not worth the effort for anyone to
sit down and "standardize" the missing features. It is not the same level of
pain and suffering it is in other languages. Too many programmers would want
a different take on the too many operating systems that might offer them that
it would not make sense to "standardize" a huge number of features.

It would, in fact, be detrimental to many development efforts to have to rely
on many software packages from independent sources. The reason many of the
other programming languages do all these things is that they are single-vendor
and single-implementation and can very easily merge independent projects into
the common fold and people are willing to hand over copyrights and ownership
to this single vendor. This is utterly infeasible in the multi-vendor, multi-
implementation world of Common Lisp where some people actually make money from
supplying just these kinds of tools. In fact, many programmers are annoyed
that a vendor has chosen to join the "open source" community to undermine
their own customers' ability to make money on similar efforts, and because the
supposed "open source" is so heavily dependent on internal coding practices.

It may be difficult for outsiders and newcomers to understand this, but the
commercial /success/ of Common Lisp has made it less appealing for people to
give stuff away. It is /because/ Common Lisp is so eminently able to make money
for those who use it that programmers and managers are reluctant to give away
the genius and hard work behind the kind of quality and solid design that we
are used to in the Common Lisp world. It is because of the high level of pain
and suffering to do relatively simple things that people share the burden in
other languages -- the comparable implementation in Common Lisp is far simpler
and more elegant. On the other hand, Common Lisp programmers are finicky lot
and woudl most probably want a different take on the same features from the
operating system or other libraries -- satisfying them all would be an additional
cost that would be hard to recover. Common Lisp is on a level /between/ the
"free" languages that are quite painful to use and the commercial success of a
mass-market language where you can make money on third-party libraries.

Those who are new to Common Lisp seldom realize that it is such a different
language from the rest of the crop -- it is almost a different crop. This may
sound arrogant to people who have not used Common Lisp for real projects. I
may sound hopelessly out of touch with other languages and their advantages to
those who come from environments where the cost of learning everything you
need is much higher than the cost of implementing it in Common Lisp. Those
who succeed with Common Lisp are usually very bright people with experience in
solving hard problems by making them simpler in surprising ways. To many of
them, the boneheaded brute force of many other languages are /distasteful/,
not features. Simplicity of implementation is generally not a value, because
the elegance of use is what matters to users. Common Lisp programmers are far
more /practical/ than the average lot, who are often more self-indulgent and
childishly delighted that anyone uses their code or rewards them for their
hacks or compact form of expression. Common Lisp has, in essence, a whole
different value system.

I have said that Common Lisp is the language you graduate into. Common Lisp
is what you get to use when you have been a good programmer for a while and
grew tired of all the cruft. Common Lisp programmers usually know dozens of
languages and are not afraid to use them when practical, but because the cost
of using a specialized language can sometimes be very high, such as when you
have to keep track of which particular version of "language" and libraries and
system libraries and kernels and whatnot in order to keep your system running.
Knowing lots of languages also means that you are able to integrate them with
ease and use particular libraries from particular languages more easily because
you have a deeper understanding of the issues involved and a much broader
knowledge of your actual needs. Instead of being blinded by the glitz and the
hype factors, Common Lisp programmers are generally more /practical/ and
solution-oriented than the random youngsters who want attention and try to get
it by giving away their time to strangers.

However, if you are the perennial newbie, you will never understand this. All
you see is that your perennial newbiehood is rejected and your opinions are
not validated by group hugs and cheers. Neither are you able to write code
that anyone will applaud, so being a newbie in Common Lisp is not the kind of
"fun" it is to be a newbie in Python or Perl or whatever, where everybody is
no more experienced than you are and you can impress just about anyone if you
are above average. Common Lisp requires more of you, but when you have grown
up to meet those requirements, it is also extremely rewarding. If you remain
on the unmet side of those requirements, your task is to meet them, not to
sulk over the rejection or wax apologetical about your lacking prowess: Your
task should simply be to realize that it takes more than you got, then either
decide to return later when you have what it takes, or decide to take on the
task of learning what it takes. If you hang around feeling inferior, you will
do nobody any good, especially not yourself. Despite the nervousness of some
Germans, I consider it proper to make it clear to people that they should make
this choice, but for some reason, some people prefer to sulk and whine than
sit down and figure out what it takes to become a member in good standing.

Common Lisp is not a "free" language in that it takes no effort to learn.
Common Lisp is not a "free" language in that you can as easily discard it.
Common Lisp is not a "free" language in that you will be unchanged by it.
Common Lisp is not an investment-free language, but neither it is profit-free.

Frank A. Adrian

unread,
Aug 3, 2002, 12:59:19 AM8/3/02
to
Thaddeus L Olczyk wrote:

> You trolls how dare you act this way.
> Every few weeks one of you comes in with the same
> demand, a free or cheap Lisp compiler that works on both
> Windows and Linux.
>
> Don't you trolls realize that the Lisp community has better

> things [to do] than to cater to your every whim and desire?

>
> So stay away little troller.

Wow! Thad finally said something sensible (if you clip enough). Now if
he'd only listen to his own words - especially the last line...

faa

Erik Naggum

unread,
Aug 3, 2002, 1:10:21 AM8/3/02
to
* Don Geddis

| Bad programmers can implement bad algorithms in any language. This example
| had nothing to do with the Lisp language.

Actually, it might. If you learn one way to do things in Common Lisp, it is
generally simpler and more elegant than anything you can do in any other
language. This makes some people lapse into that comatose state where they
are satisfied with what they have and cease to look further for more options.

At some point, we all have to stop being vigilant about more options, lest we
not get anything done at all, but what would be clumsy in any other language
may feel sufficiently elegant to an inexperienced Common Lisp programmer.
That it is syntactically superior to almost everything may belie the fact
that it is algorithmically inferior to almost anything.

Some people keep doing what they are good at instead of looking for new
things until they conclude, after careful determination, that they should go
back to what they are good at. /E.g./, I gave up on user interfaces as I had
neither the inclination nor the time to become good at it. If I were a
medical doctor, I would be an internist, not a dermatologist. I think it is
crucial to a substantially correct assessment of one's abilities that one has
a pretty good knowledge of the outer bounds of one's capacity, but that is
again because I believe that being satisfied with being good at something far
less than capacity will in time be deeply frustrating, instead.

I see Common Lisp as the best language there is for exploring one's own
abilities in programming, because one does not first meet an upper limit on
the amount of fundamentally useless arcana one can internalize. When people
write stupid code in Common Lisp, I almost feel as if they are betraying both
the abilities of the language and their own.

I sometimes wish it was harder to do stupid things in Common Lisp, but that
would mean it would be harder to do smart things that nobody thought of
before, too, and that is precisely what Common Lisp does not want to do.

Christopher Browne

unread,
Aug 3, 2002, 1:23:49 AM8/3/02
to