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?
·········@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! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@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
···@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.
Chris Double <·····@double.co.nz> writes:
> ···@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
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
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
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.
"thelifter" <·········@gmx.net> wrote in message
·································@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.
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 ····@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
On 02 Aug 2002 19:52:23 -0400, Camm Maguire <····@enhanced.com> wrote:
>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,
Five questions:
1) Is it also run on Linux? ( Probably a stupid question, but I should
ask.)
2) Does it run PCL/clossette/whatever?
3) How ell does it support FFI?
4) I was under the impression that GCL was no longer actively
maintained.
5) Is there some documentation ( just to clarify the CLtL1 vs CLtL2
issues)>
Greetings!
Thaddeus L Olczyk <······@interaccess.com> writes:
> On 02 Aug 2002 19:52:23 -0400, Camm Maguire <····@enhanced.com> wrote:
> Five questions:
> 1) Is it also run on Linux? ( Probably a stupid question, but I should
> ask.)
Yes. Currently all Debian architectures save hppa.
> 2) Does it run PCL/clossette/whatever?
PCL -- yes. Don't know anything about clossette.
> 3) How ell does it support FFI?
GCL compiles to C, and therefore has a straightforward interface to
foreign functions via a C calling sequence. There are examples in the
source distribution.
> 4) I was under the impression that GCL was no longer actively
> maintained.
There is a small, but active, volunteer development effort ongoing.
Please check out http://savannah.gnu.org and ·········@gnu.org.
> 5) Is there some documentation ( just to clarify the CLtL1 vs CLtL2
> issues)>
Yes, documentation is provided in info format. You can find it in the
gcl ftp directory on savannah.
Take care,
--
Camm Maguire ····@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Hi there.
> > 2) Does it run PCL/clossette/whatever?
>
> PCL -- yes. Don't know anything about clossette.
I built Closette once with GCL on Windows but didn't use it for anything. I
believe that it is relatively limited compared to PCL, but I believe that
Corman Common Lisp based it's CLOS implementation on Closette, so I assume
that there may be an important reason for that.
Cheers
Mike Thomas.
* 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
·········@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
* ·········@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.
Erik Naggum <····@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
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
> 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.
"Dan Corkill" <··········@attbi.com> wrote in message
······················@attbi.com...
> > 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.
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).
In an attempt to throw the authorities off his trail, Dan Corkill <··········@attbi.com> transmitted:
>> 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.
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.
Dan Corkill wrote:
>> 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.
Hm... there is no per seat distribution cost in all free Lisps and at least
LispWorks and Corman Lisp. (Don't know about MCL).
ciao,
Jochen
--
http://www.dataheaven.de
Jochen Schmidt wrote:
>
> Dan Corkill wrote:
>
> >> 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.
>
> Hm... there is no per seat distribution cost in all free Lisps and at least
> LispWorks and Corman Lisp. (Don't know about MCL).
>
> ciao,
> Jochen
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...
Jochen Schmidt <···@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
·········@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
On Fri, 02 Aug 2002 03:20:15 GMT, Johan Kullstam
<··········@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 (·······@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
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.
>--------- 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.
> 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
In article <··································@4ax.com>,
Thaddeus L Olczyk <······@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
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
A long time ago, in a galaxy far, far away, "Paul F. Dietz" <·····@dls.net> wrote:
> 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).
.. And in a _good_ compilation environment, there should be a
peephole optimizer around that can fix up many such problems.
On a lot of architectures these days there's enough "on-the-chip
parallelism" taking place that it makes sense to do some instruction
reordering, and some portion of the optimizer is quite likely to
consider the JMP / BRA instructions that get generated.
--
(reverse (concatenate 'string ··········@" "enworbbc"))
http://cbbrowne.com/info/multiplexor.html
Group Dynamics
"Following Minsky and Schelling, consider a person as a society of
agents. A group is then a larger society of such agents. Understand
groups by examining interactions of coalitions of agents that
cross-cut their grouping into people."
-- Mark Miller
Before I start, let me say that I don't generally advocate goto. I
say this up front because the rest of this post might sound like I
do. I just want to do away with the prejudice.
>> 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).
> .. And in a _good_ compilation environment, there should be a
> peephole optimizer around that can fix up many such problems.
That's not what a peephole optimizer does. A peephole optimizer makes
local changes but does not significantly reorder code. Something that
replaces a store followed by a load (with the same register and memory
location) with just the store might be in a peephole optimizer.
He's talking about reordering code to make the common case all
localized (ie, ideally can be loaded in one fetch to cache).
Let's say I have:
(defun process (x)
;; Pretty much made up, but resembles some of the kernel code in
;; structure.
(unless (< +minimum-x+ x)
(error "Foo!"))
(frob x)
(when (is-barworthy x)
(signal 'bar x)
(frob x :again t))
(when (needs-fixups x)
(fixup x)
(refixup x)
(funcall (gethash (type-of x) *fixups*) x))
(finalize x)
(payload x))
The straightforward implementation of this is fairly obvious. Now,
let's say I know that X will usually be barworthy, but will rarely
need fixups. Then everything within (when (needs-fixups x) ...) will
usually be jumped over, and probably will cause a second cache miss,
not to mention flush the pipeline (if the CPU's branch prediction
isn't being useful... and it often isn't useful).
A lot of the TCP stack is structured like this: lots of corner cases
impeding the main flow. This is a real problem, since the main flow
of TCP processing in the common case can be very, very small: a couple
of dozen machine instructions on a SPARC, for instance.[1] So the idea
is to get the common case all clustered together, and the corner cases
out a ways. With C, goto is a very effective way to do that.
The key here is that the compiler has no a priori knowledge of the
common path. One solution is to let a program record data about the
path to be used on the next compile run. The gcc -fprofile-arcs
option (RTFM for details) does that, but it's unsuitable for a kernel.
Another solution is to let the programmer provide hints as to which
branch will usually be taken. I've never seen any compiler that
explicitly allows this, but I haven't seen a lot of compilers in much
detail.
The third solution is to let the programmer do this. You can order
your cond branches to help promote the common cases, but (particularly
in the kernel and in C) this can become an unruly mess of spaghetti
code with absurdly long levels of indentation. Alternatively, you can
use a few judicious goto's. Believe it or not, they really can make
your code clearer and faster! You have to understand your compiler,
and bear clarity in mind while you code, but it's possible. Look over
TCP/IP Illustrated Volume 2 for some good examples of this.
I don't actually *advocate* goto because anybody experienced enough to
use it well can make their own opinions on goto. I discourage its use
among the young and naive especially. (I used to TA a Pascal class
where the teacher would soundly berate anybody who used goto.) But I
will grudgingly admit that goto-- like eval-- has its place.
Cheers,
joelh
[1] I think it was Van Jacobson who wrote this, but I could be wrong.
Thaddeus L Olczyk wrote:
> >--------- 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?
Thanks for the compliment. This example was just to show that CMUCL isn't
so much slower compared to C++. I also wrote a function using C-arrays
which
was just two times faster.
> 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.
BTW the vectors are initialized and the lisp arrays too.
>
> 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 ).
If I need matrices in C++ I usually use TNT (Template Numerical Toolkit).
In the above example I restricted to using C++-standard libraries.
>
> 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++ ).
Sorry but I'm much more experienced in C++ programming than in CL.
> 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.
·········@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 ···@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]
* 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.
--
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.
On 1 Aug 2002 13:47:14 -0700, ·········@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 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
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.
--
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.
Thaddeus L Olczyk <······@interaccess.com> wrote in
·······································@4ax.com:
> On 1 Aug 2002 13:47:14 -0700, ·········@gmx.net (thelifter) wrote:
>
>In spite 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.
How many times do you morons have to be pointed to the tools that
provide EXACTLY what you demand before you get it through your thick
little skulls that there is no FACT behind your arguments. If you were
willing to do a *little* work of your own - namely, looking, you would
be able to find the tools on your own. I did. But you were even given
the luxury of having them HANDED to you in this newsgroup. Still you
whine. You are quite right that the Lisp community is better off
without
you.
> 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.
$200. Check your facts.
Paul D. Lathrop
I had no trouble finding free Common Lisp implementations
for use on both Windows and Linux when I decided to learn
Common Lisp, heck I even have 2 different ones on Linux.
Granted, it was not the same implementation, but Common Lisp
is standardized, is it not?
Installing CMUCL on Linux was easy, installing Corman on
Windows was easy. I fail to see the problem you depict
at all (probably because there is none).
--
Thomas.
Approaching singularity.
Thaddeus L Olczyk <······@interaccess.com> writes:
> 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.
Gwydion Dylan works on Windows with Win32 bindings, Windows with
Cygwin, Linux, BSDI, FreeBSD, OpenBSD, Solaris, HP-UX, BeOS, MacOS
Classic, MacOS X and Irix; be it on x86, Sparc, PowerPC, S390, HP-PA,
Alpha, MIPS or ARM. IA-64 and NetBSD could probably made work when
demand is there. Did I mention that on MacOS X, you get to choose
between a standalone compiler or a CodeWarrior plugin?
And it's free, as in speech and beer. And we're nice to newbies.
Andreas
--
"In my eyes it is never a crime to steal knowledge. It is a good
theft. The pirate of knowledge is a good pirate."
(Michel Serres)
* Andreas Bogk
| Gwydion Dylan [...]
I went to my local bookstore the other day. I wanted to give a beautifully
bound Bible to a Christian friend of mine. Suddenly, I felt space around me
warp and I was in USENET space. People from comp.lang.scheme offered me a
beutifully bound Torah. People from comp.lang.dylan offered me a beautifully
bound Koran. People from elsewhere on the Net offered me beautifully bound
copies of The Lord of the Rings, Atlas Shrugged, A New Kind of Science, and
then other people chimed in with suggestions for Gray's Anatomy, The Chicago
Manual of Style, and the 25-year anniversary edition of G�del, Escher, Bach,
all of them arguing that if I wanted the most important book, I would want
their suggestions. I scremed, "Enough!", and space just as suddenly warped
back to the bookstore and the very helpful young Muslim woman behind the
counter went to find a soft-leather-bound Bible with gold edges on the India
paper, just like I had wanted and asked for, without unwelcome suggestions or
anyone pretending to know better than me. It was so respectful I almost got
religion, myself.
--
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.
In article <··············@meo-dipt.andreas.org>, Andreas Bogk wrote:
> Thaddeus L Olczyk <······@interaccess.com> writes:
>
>> 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.
>
> Gwydion Dylan works on Windows with Win32 bindings, Windows with
The way you are answering makes it look like you are suggesting
that this is a Lisp compiler.
> And it's free, as in speech and beer. And we're nice to newbies.
That can only be because you think that the newbies have something that you
want.
Kaz Kylheku <···@ashi.footprints.net> writes:
>> Gwydion Dylan works on Windows with Win32 bindings, Windows with
> The way you are answering makes it look like you are suggesting
> that this is a Lisp compiler.
It seems that everybody has his own definition of what a Lisp is and
what not. To some people, it's no Lisp if it ain't Common Lisp. Some
other people feel that Scheme is a Lisp as well. So in order to
answer in a way that doesn't step on anybody's toe, I would say:
Dylan shares the following features with Common Lisp: dynamic typing,
first-class functions, first-class objects, closures, generic
functions with multiple dispatch, automatic memory management,
powerful template-based macros, availability of compilers that
generate high-performance code by using optimistic type inferencing.
Dylan differs from Common Lisp in that it uses a Pascal-like infix
syntax, doesn't provide "eval" or "compile", has no procedural macros,
and no MOP.
Whether that's within your epsilon of "a Lisp" I don't know.
Personally, I'd like to have a compiler available at run-time when I
need it, and I want to have procedural macros. That wouldn't be
standard Dylan anymore, of course :).
>> And it's free, as in speech and beer. And we're nice to newbies.
> That can only be because you think that the newbies have something that you
> want.
Yeah, spare time to find our compiler bugs :).
Andreas
--
"In my eyes it is never a crime to steal knowledge. It is a good
theft. The pirate of knowledge is a good pirate."
(Michel Serres)
Hi Andreas,
Andreas Bogk <·······@andreas.org> writes:
> Dylan shares the following features with Common Lisp: dynamic typing,
[...]
> Dylan differs from Common Lisp in that it uses a Pascal-like infix
> syntax, doesn't provide "eval" or "compile", has no procedural macros,
> and no MOP.
the differences between Common Lisp, Scheme, and Dylan are well-known.
Of course, it is nice to hear a Dylan developer call Dylan a `Lisp',
particularly since recent Gwydion Dylan projects seem to be targeted at
making the compiler support more Lisp-like features, which is great.
However, _currently_ Gwydion Dylan does not support COMPILE, run-time
redefinition of functions, or procedural macros. Please be careful with
Gwydion Dylan advocacy in a discussion that centers around _Common Lisp_
and its features specificially.
In article <···············@vanilla.rz.fhtw-berlin.de>, David Lichteblau wrote:
> Hi Andreas,
>
> Andreas Bogk <·······@andreas.org> writes:
>
>> Dylan shares the following features with Common Lisp: dynamic typing,
> [...]
>> Dylan differs from Common Lisp in that it uses a Pascal-like infix
>> syntax, doesn't provide "eval" or "compile", has no procedural macros,
>> and no MOP.
>
> the differences between Common Lisp, Scheme, and Dylan are well-known.
>
> Of course, it is nice to hear a Dylan developer call Dylan a `Lisp',
> particularly since recent Gwydion Dylan projects seem to be targeted at
> making the compiler support more Lisp-like features, which is great.
>
> However, _currently_ Gwydion Dylan does not support COMPILE, run-time
> redefinition of functions, or procedural macros. Please be careful with
> Gwydion Dylan advocacy in a discussion that centers around _Common Lisp_
> and its features specificially.
It doesn't matter what Dylan supports or not; even if it has the
semantic equivalent of every Lisp feature, it's still not Lisp.
A Dylan implementation can be a Lisp implementation if it has a front
end that accepts Lisp programs, mapping them onto its
interpreter and compiler architecture.
You people think that this is some kind of emotional debate, as if
calling something ``Lisp'' is some kind of stamp of approval.
No, it's simply a matter of accuracy. If ``Lisp'' refers to any
dynamic language with certain features, what word shall we use
for that subset which excludes such things as Dylan and Scheme?
Why can't we just have the word ``Lisp'' for that subset, the term ``dynamic
language'' for the entire class, and ``Dylan'' and ``Scheme'' for particular
instances?
From: Christopher C. Stacy
Subject: Re: Why I can't use Lisp.
Date:
Message-ID: <u8z3mhyrh.fsf@dtpq.com>
>>>>> On Sun, 4 Aug 2002 16:23:44 +0000 (UTC), Kaz Kylheku ("Kaz") writes:
Kaz> It doesn't matter what Dylan supports or not; even if it has the
Kaz> semantic equivalent of every Lisp feature, it's still not Lisp.
Does Dylan have symbols?
······@dtpq.com (Christopher C. Stacy) writes:
> >>>>> On Sun, 4 Aug 2002 16:23:44 +0000 (UTC), Kaz Kylheku ("Kaz") writes:
> Kaz> It doesn't matter what Dylan supports or not; even if it has the
> Kaz> semantic equivalent of every Lisp feature, it's still not Lisp.
>
> Does Dylan have symbols?
Depends on what you mean by symbols.
Do you mean a datatype called symbol? Sure.
But then, there are languages that have an integer data type that we don't
think of as having "integers".
For sake of argument, I'll here claim Dylan doesn't have symbols. Not that
there isn't another possible point of view, and I fully expect someone to
raise it in response--but just to say I'm comfortable having that exchange.
Here's my claim:
To me, symbols have (at least) two parts:
- they are interned, canonical strings
[dylan has this, and so does java--java calls them
canonical strings, I think--it's been a while since i checked]
- they are not not mired in syntax.
I'll be further provocative by alleging that, to me, let's ay "in my heart",
X is a symbol if and only if X can be used unadorned as a name in data
and code.
(So, in my mind, symbols like |THIS IS A SYMBOL| are allowed in the datatype
symbol but emotionally, in my heart, they are "cheating" and are not what
symbol processing is really about... they're just an accomodation to
practicality. I'm not saying symbol operations won't work on them, I'm
just saying that they don't represent the spirit of what symbol processing
was about--more like an exception that was patchily added afterward to
accomodate cases never really intended origionally.)
Dylan uses the notation #"foo" for what lisp would call foo.
To me, this is just not a symbol. I strongly believe that had this been
the notation of symbols, important programs like Eliza and Macsyma would
have risked never having been written (or would have looked very different).
Processors that are supposed to take
'(I AM NOT FEELING WELL TODAY)
as an argument but have to take
#{#"I", #"AM", #"NOT", #"FEELING", #"WELL", #"TODAY"}
are just not, to me offering the same capability.
Processors that should take
'(+ x (- y 3))
but instead take
#{#"+", #"x", #{#"-", "y", 3}}
are again missing the point.
That small degree of willful failure to do user engineering means that
interactive experimentation is virtually ruled out. IMO, no one is going
to find it "fun" to simply sit around and try things. And so a great deal
of accidental discovery will be lost... or, so I claim.
JMO. YMMV.
Kent M Pitman <······@world.std.com> writes:
> Processors that are supposed to take
> '(I AM NOT FEELING WELL TODAY)
> as an argument but have to take
> #{#"I", #"AM", #"NOT", #"FEELING", #"WELL", #"TODAY"}
> are just not, to me offering the same capability.
Well, neither expression syntax is one a naive user would choose to
communicate with a supposed-to-be-intelligent program. Here's the
Dylan code that takes a string, and returns a collection of symbols:
let (#rest words) = split("\\s", line)
map(curry(as, <symbol>), words);
Voila, an improvement over using s-expressions as the input of Eliza.
> That small degree of willful failure to do user engineering means that
> interactive experimentation is virtually ruled out. IMO, no one is going
Hm, don't think so. But I've already noticed that my mileage does
vary :).
Andreas
--
"In my eyes it is never a crime to steal knowledge. It is a good
theft. The pirate of knowledge is a good pirate."
(Michel Serres)
Andreas Bogk <·······@andreas.org> writes:
> Kent M Pitman <······@world.std.com> writes:
>
> > Processors that are supposed to take
> > '(I AM NOT FEELING WELL TODAY)
> > as an argument but have to take
> > #{#"I", #"AM", #"NOT", #"FEELING", #"WELL", #"TODAY"}
> > are just not, to me offering the same capability.
>
> Well, neither expression syntax is one a naive user would choose to
> communicate with a supposed-to-be-intelligent program. Here's the
> Dylan code that takes a string, and returns a collection of symbols:
>
> let (#rest words) = split("\\s", line)
> map(curry(as, <symbol>), words);
>
> Voila, an improvement over using s-expressions as the input of Eliza.
>
> > That small degree of willful failure to do user engineering means that
> > interactive experimentation is virtually ruled out. IMO, no one is going
>
> Hm, don't think so. But I've already noticed that my mileage does
> vary :).
But you've made my point.
You have turned them in to string processing applications.
To be honest, I don't think anyone who starts with split("\\s" line)
is going to target symbol as their final datatype. I bet they'll
write it using strings.
Further, the application involves even more string processing to get
"x+y*z"
to work. One of the virtues of starting with s-expressions was that
it allowed the people with this idea to skip to the part where they
were working on the idea, unimpeded by the UI issues that would be needed
in order to get to a workable representation. (+ x (* y z)) is "good enough"
even if "x+y*z" is arguably more natural to some. But having to write a
parser for "x+y*z" is annoying. And it's DOUBLY annoying because you
know the Dylan language HAS such a parser and does not reveal it to the
end user as an ordinary part of doing business.
Kent M Pitman <······@world.std.com> writes:
> To be honest, I don't think anyone who starts with split("\\s" line)
> is going to target symbol as their final datatype. I bet they'll
> write it using strings.
And I bet there's no READ that doesn't treat its input as a string
internally.
Of course, clueless users who don't know the value of symbols should
be slapped with the manual.
> to work. One of the virtues of starting with s-expressions was that
> it allowed the people with this idea to skip to the part where they
> were working on the idea, unimpeded by the UI issues that would be needed
> in order to get to a workable representation.
An s-expression parser written in Dylan is readily available.
> parser for "x+y*z" is annoying. And it's DOUBLY annoying because you
> know the Dylan language HAS such a parser and does not reveal it to the
> end user as an ordinary part of doing business.
Oh, how I agree. Once GD 2.4 is released, I'll take a chainsaw and
liberate the compiler's parser.
Andreas
--
"In my eyes it is never a crime to steal knowledge. It is a good
theft. The pirate of knowledge is a good pirate."
(Michel Serres)
Andreas Bogk <·······@andreas.org> writes:
> Kent M Pitman <······@world.std.com> writes:
>
> > To be honest, I don't think anyone who starts with split("\\s" line)
> > is going to target symbol as their final datatype. I bet they'll
> > write it using strings.
>
> And I bet there's no READ that doesn't treat its input as a string
> internally.
>
> Of course, clueless users who don't know the value of symbols should
> be slapped with the manual.
But this is again my point. Only some of the input is going to come
from input lines. Some of it wants to be literal program data. And
if you don't have symbols (and lists) IN MANAGEABLE SYNTACTIC FORM in
your language, you won't have users including them as literal data as
many places in programs as they need to.
> > to work. One of the virtues of starting with s-expressions was that
> > it allowed the people with this idea to skip to the part where they
> > were working on the idea, unimpeded by the UI issues that would be needed
> > in order to get to a workable representation.
>
> An s-expression parser written in Dylan is readily available.
You remind me here of my (very well meaning) physics teacher in high
school who when I suggested I might want to repeat the
Michaelson/Morley (sp?) experiments for measuring the speed of light
using mirrors said "why don't you use an oscilloscope"? To me, that
seemed a strange question to ask since it was probably callibrated
somewhere along the way with a knowledge of the speed of light, and seemed
of defeat the whole purpose of the experiment.
I'm talking here about how important it is to have s-expressions in the
language because of the invention it promotes by accidentally using such a
simple device for routine play in your program, and you're saying back to me
"you can have the sophisticated understanding that this simple device is
available". Sure, *I* can because I know the importance of using it. But
the people I'm talking about are people who don't know this importance and
won't be using s-expressions.
Separating M (or D) -expressions from S-expressions is not a recipe for
creating the "data is program / program is data" thing. It's a way of
saying "data is data / program is program", which isn't the same thing at
all.
Does that make Dylan a non-Lisp? I dunno. I'm not sure what's
criterial to Lisp. Maybe I think the desire to BE a Lisp is criterial
to Lisp, and maybe I think Dylan doesn't have that. I've seen no
active desire to be called a Lisp and some active desire to not be
called a Lisp by certain key Dylan folks over the years, and that
seems to me to be more interesting... But at least at the level of
programming, having separate tools (parsers, printers, etc.) for
managing programs and managing data is relatively unlispy...
> > parser for "x+y*z" is annoying. And it's DOUBLY annoying because you
> > know the Dylan language HAS such a parser and does not reveal it to the
> > end user as an ordinary part of doing business.
>
> Oh, how I agree. Once GD 2.4 is released, I'll take a chainsaw and
> liberate the compiler's parser.
Well, that certainly won't hurt.
In article <··············@meo-dipt.andreas.org>, Andreas Bogk wrote:
> Kaz Kylheku <···@ashi.footprints.net> writes:
>
>>> Gwydion Dylan works on Windows with Win32 bindings, Windows with
>> The way you are answering makes it look like you are suggesting
>> that this is a Lisp compiler.
>
> It seems that everybody has his own definition of what a Lisp is and
> what not. To some people, it's no Lisp if it ain't Common Lisp. Some
> other people feel that Scheme is a Lisp as well.
Some people feel, others think. The history of Lisp has produced four surviving
flavors. Firstly, there are ANSI Common Lisp, ISO Standard Lisp (ISLisp). These
have actual ISO document numbers. Then there is EuLisp and Emacs Lisp. In this
newsgroup, an unqualified ``Lisp'' refers to Common Lisp. ISLisp is a very
rarely used dialect. EuLisp is a dialect based on Scheme, maintained by a
community of users in Europe. Emacs Lisp is unique to a computing environment
centered around a popular text editor. Thus if you want to talk about these
latter three, you have to make yourself clear by invoking their fully qualified
name.
> Dylan shares the following features with Common Lisp: dynamic typing,
> first-class functions, first-class objects, closures, generic
> functions with multiple dispatch, automatic memory management,
> powerful template-based macros, availability of compilers that
> generate high-performance code by using optimistic type inferencing.
According to this reasoning, we can conclude, for instance, that C is really
Pascal, or that C# is Java, based on sharing features.
If we squint our eyes hard enough, everything is everything else.
Both cars and fish have aerodynamic shapes, and consume oxygen.
So cars are really fish!
> Dylan differs from Common Lisp in that it uses a Pascal-like infix
> syntax, doesn't provide "eval" or "compile", has no procedural macros,
> and no MOP.
Dylan differs from Lisp in that if I have a Lisp program and I want
to run it, a Dylan implementation won't do it for me. So if I'm looking for a
Lisp compiler, it's completely irrational to be told that there is a nice Dylan
compiler I can use.
> Whether that's within your epsilon of "a Lisp" I don't know.
Absolutely not. Here is a basic litmus test. If it barfs on
(cons 'a 'b), it's not a Lisp, okay? Can we at least have that much
sanity? Or do words mean nothing anymore?
Words are tools for thought. The more you smear the definition of a word to
encompass more and more concepts, the more useless it becomes. Thoughts then
become sterile templates operating on vacuous ideas.
Lisp is not a synonym for ``dynamic language''. It's an instance, not
the entire class.
I don't understand why Dylan people need to be accepted by the Lisp
community. It must be some kind of inferiority complex at work.
The indiscriminate lust for newbies is more evidence of that.
> Personally, I'd like to have a compiler available at run-time when I
> need it, and I want to have procedural macros. That wouldn't be
> standard Dylan anymore, of course :).
How would you know what is standard Dylan or not? Remember, the word ``Dylan''
can refer to whatever you want. There *is* no precision! Scheme is Dylan!
Dylan is Lisp! TeX is C (proof: both have curly braces for blocks).
>>> And it's free, as in speech and beer. And we're nice to newbies.
>> That can only be because you think that the newbies have something that you
>> want.
>
> Yeah, spare time to find our compiler bugs :).
For that, you need experts, who can spot the difference between a behavior
and its specification. Newbies don't know how to spot a compiler bug; when
something goes wrong, they just blame themselves, and then massage the code
until it works. The problem is then forgotten.
How many compiler bugs will a twit like ``thelifter'' find for you?
Kaz Kylheku <···@ashi.footprints.net> writes:
> Some people feel, others think. The history of Lisp has produced
> four surviving flavors. Firstly, there are ANSI Common Lisp, ISO
> Standard Lisp (ISLisp). These have actual ISO document numbers. Then
> there is EuLisp and Emacs Lisp.
I'd certainly see the criteria by which these four are Lisp, and all
other languages are not.
> In this newsgroup, an unqualified ``Lisp'' refers to Common Lisp.
Would you mind referring to Common Lisp as Common Lisp when you
actually mean it, and use Lisp when talking about the family of
languages? That would make it much easier for me to follow your
argumentation.
>> Dylan shares the following features with Common Lisp: dynamic typing,
> According to this reasoning, we can conclude, for instance, that C is really
> Pascal, or that C# is Java, based on sharing features.
No. I was just pointing out similiarities between Dylan and Common
Lisp. If you look at C# and Java, you will notice that they are very
similiar too.
> Dylan differs from Lisp in that if I have a Lisp program and I want
> to run it, a Dylan implementation won't do it for me. So if I'm
> looking for a Lisp compiler, it's completely irrational to be told
> that there is a nice Dylan compiler I can use.
I suspect most people asking for a Lisp compiler are really asking for
a compiler that gives them all the features they've heard Lisp would
have. In other words, more "Lisp the family" than Common Lisp.
> Absolutely not. Here is a basic litmus test. If it barfs on
> (cons 'a 'b), it's not a Lisp, okay? Can we at least have that much
> sanity? Or do words mean nothing anymore?
Hm. I've just checked the implementation of L. Peter Deutsch on the
PDP-1. It barfs on the above expression. Now of course that's a LISP
and not a Lisp...
> Lisp is not a synonym for ``dynamic language''. It's an instance, not
> the entire class.
No, Common Lisp is an instance of Lisp, which is a subclass of
"dynamically typed language".
> I don't understand why Dylan people need to be accepted by the Lisp
> community. It must be some kind of inferiority complex at work.
If you look at the history of Dylan, you will see that the roots of it
are in the Lisp community. The very same people who brougt you the
Common Lisp standard, CLIM, CMU CL, and a lot of other things worked
on Dylan, and it was supposed to be the next big thing after Common
Lisp, and an improvement over it.
Something bad must have happened on the way, I suspect it must have to
do with Apple's marketing department and dumbing down the language
ever so slightly, until most of the Lisp community rejected it as "not
powerful enough".
Then there's the area of compiler implementation. Lots of the tricks
applicable to any of the Lisp (or not) dialects are applicable to
Dylan.
> How would you know what is standard Dylan or not?
There's the Dylan Reference Manual.
> Remember, the word ``Dylan''
> can refer to whatever you want. There *is* no precision! Scheme is Dylan!
> Dylan is Lisp! TeX is C (proof: both have curly braces for blocks).
That's why I'm talking in terms of specific features. This does
produce something like a distance metric, and I can say things like
"Dylan is much more like Common Lisp than like Java".
>> Yeah, spare time to find our compiler bugs :).
> For that, you need experts, who can spot the difference between a behavior
> and its specification. Newbies don't know how to spot a compiler bug; when
Well, newbies tend to break your software in interesting ways, and
sometimes they even report it.
Of course, experts would be highly welcome too. Native backend
generator with abstract machine description anyone?
Andreas
--
"In my eyes it is never a crime to steal knowledge. It is a good
theft. The pirate of knowledge is a good pirate."
(Michel Serres)
Kaz Kylheku <···@ashi.footprints.net> writes:
> Some people feel, others think. The history of Lisp has produced
> four surviving flavors. Firstly, there are ANSI Common Lisp, ISO
> Standard Lisp (ISLisp). These have actual ISO document numbers. Then
> there is EuLisp and Emacs Lisp.
I'd certainly like see the criteria by which these four are Lisp, and
all other languages are not.
> In this newsgroup, an unqualified ``Lisp'' refers to Common Lisp.
Would you mind referring to Common Lisp as Common Lisp when you
actually mean it, and use Lisp when talking about the family of
languages? That would make it much easier for me to follow your
argumentation.
>> Dylan shares the following features with Common Lisp: dynamic typing,
> According to this reasoning, we can conclude, for instance, that C is really
> Pascal, or that C# is Java, based on sharing features.
No. I was just pointing out similiarities between Dylan and Common
Lisp. If you look at C# and Java, you will notice that they are very
similiar too.
> Dylan differs from Lisp in that if I have a Lisp program and I want
> to run it, a Dylan implementation won't do it for me. So if I'm
> looking for a Lisp compiler, it's completely irrational to be told
> that there is a nice Dylan compiler I can use.
I suspect most people asking for a Lisp compiler are really asking for
a compiler that gives them all the features they've heard Lisp would
have. In other words, more "Lisp the family" than Common Lisp.
> Absolutely not. Here is a basic litmus test. If it barfs on
> (cons 'a 'b), it's not a Lisp, okay? Can we at least have that much
> sanity? Or do words mean nothing anymore?
Hm. I've just checked the implementation of L. Peter Deutsch on the
PDP-1. It barfs on the above expression. Now of course that's a LISP
and not a Lisp...
> Lisp is not a synonym for ``dynamic language''. It's an instance, not
> the entire class.
No, Common Lisp is an instance of Lisp, which is a subclass of
"dynamically typed language".
> I don't understand why Dylan people need to be accepted by the Lisp
> community. It must be some kind of inferiority complex at work.
If you look at the history of Dylan, you will see that the roots of it
are in the Lisp community. The very same people who brougt you the
Common Lisp standard, CLIM, CMU CL, and a lot of other things worked
on Dylan, and it was supposed to be the next big thing after Common
Lisp, and an improvement over it.
Something bad must have happened on the way, I suspect it must have to
do with Apple's marketing department and dumbing down the language
ever so slightly, until most of the Lisp community rejected it as "not
powerful enough".
Then there's the area of compiler implementation. Lots of the tricks
applicable to any of the Lisp (or not) dialects are applicable to
Dylan.
> How would you know what is standard Dylan or not?
There's the Dylan Reference Manual.
> Remember, the word ``Dylan''
> can refer to whatever you want. There *is* no precision! Scheme is Dylan!
> Dylan is Lisp! TeX is C (proof: both have curly braces for blocks).
That's why I'm talking in terms of specific features. This does
produce something like a distance metric, and I can say things like
"Dylan is much more like Common Lisp than like Java".
>> Yeah, spare time to find our compiler bugs :).
> For that, you need experts, who can spot the difference between a behavior
> and its specification. Newbies don't know how to spot a compiler bug; when
Well, newbies tend to break your software in interesting ways, and
sometimes they even report it.
Of course, experts would be highly welcome too. Native backend
generator with abstract machine description anyone?
Andreas
--
"In my eyes it is never a crime to steal knowledge. It is a good
theft. The pirate of knowledge is a good pirate."
(Michel Serres)
Andreas Bogk <·······@andreas.org> wrote:
> Kaz Kylheku <···@ashi.footprints.net> writes:
>
>> Some people feel, others think. The history of Lisp has produced
>> four surviving flavors. Firstly, there are ANSI Common Lisp, ISO
>> Standard Lisp (ISLisp). These have actual ISO document
>> numbers. Then there is EuLisp and Emacs Lisp.
>
> I'd certainly like see the criteria by which these four are Lisp,
> and all other languages are not.
The fact that they contain the four letters "L", "i", "s", and "p"
might be considered signals of some sort.
Dylan isn't called Lisp, not by much of anybody. While there are
similarities in some of the semantics, and Lisp folk were involved in
its design, it's still pretty clearly not "Lisp":
-> It doesn't normally offer a REPL;
-> Programs aren't expressed in the form of lists.
Is it potentially of interest to people interested in Lisp? Surely.
But it's still not "Lisp."
If it's arguable that Scheme isn't "a Lisp," then Dylan certainly
isn't.
>> In this newsgroup, an unqualified ``Lisp'' refers to Common Lisp.
> Would you mind referring to Common Lisp as Common Lisp when you
> actually mean it, and use Lisp when talking about the family of
> languages? That would make it much easier for me to follow your
> argumentation.
That is an unfortunate and common confusion.
I agree that people should say "CL" when the context doesn't make it
manifestly clear that that's what's meant.
If someone is asking about how to "use MOP in Lisp," that's a
conversation that is pretty clearly likely to be about Common Lisp.
But in more 'generic' discussions, such as this one, where Emacs Lisp
and ISLisp and such are _certainly_ legitimate instances of languages
under discussion, and where Scheme might even be near enough to fit,
it certainly does _not_ suffice to just say "Lisp."
>>> Dylan shares the following features with Common Lisp: dynamic typing,
>> According to this reasoning, we can conclude, for instance, that C
>> is really Pascal, or that C# is Java, based on sharing features.
> No. I was just pointing out similiarities between Dylan and Common
> Lisp. If you look at C# and Java, you will notice that they are
> very similiar too.
The similarities aren't nearly as near as those that allow people to
suggest that comp.lang.apl should be inclusive of "other Array
Programming Languages such as J, K, and Nial."
I'd think that there is room for discussions about the similarities
and differences between Dylan and Lisp. Just as someone might want to
discuss the differences between C# and Java. And comp.lang.lisp is
probably a reasonable forum for such a discussion (you know which
one!).
But to consider that Dylan should be considered an instance of a "Lisp
language" seems to be going ab it too far.
>> Dylan differs from Lisp in that if I have a Lisp program and I want
>> to run it, a Dylan implementation won't do it for me. So if I'm
>> looking for a Lisp compiler, it's completely irrational to be told
>> that there is a nice Dylan compiler I can use.
> I suspect most people asking for a Lisp compiler are really asking
> for a compiler that gives them all the features they've heard Lisp
> would have. In other words, more "Lisp the family" than Common
> Lisp.
That's fine, and if someone suggested an ISLisp or EuLisp or Emacs
Lisp, or, for that matter, REP, compiler, that would be fair game.
I'd take mention of a REP compiler as more of a _joke_ than anything
serious, but it certainly fits.
Mentioning Dylan in such a context doesn't seem reasonable.
>> Absolutely not. Here is a basic litmus test. If it barfs on
>> (cons 'a 'b), it's not a Lisp, okay? Can we at least have that much
>> sanity? Or do words mean nothing anymore?
>
> Hm. I've just checked the implementation of L. Peter Deutsch on the
> PDP-1. It barfs on the above expression. Now of course that's a LISP
> and not a Lisp...
.. And that's a perfectly good waggish response.
(cons 'a 'b) is something that works perfectly well in a whole raft of
Lisp-related languages, including CL, REP, and even Scheme. It is
amusing that you have found an implementation that rejects it.
The serious point of the litmus test is that (cons 'a 'b) does
something reasonably appropriate in all of (list 'CL 'Scheme 'REP).
Dylan is sufficiently "not like Lisp" that (cons 'a 'b) doesn't work
there.
>> Lisp is not a synonym for ``dynamic language''. It's an instance,
>> not the entire class.
> No, Common Lisp is an instance of Lisp, which is a subclass of
> "dynamically typed language".
And since Smalltalk is also dynamically typed, as is Python, we
presumably should be including them, as well?
The fact that it's _not_ reasonable to include them as being "Lisps"
suggests that maybe evaluating things based on dynamically-typed
subsets of languages isn't a meaningful way to divide things up.
>> I don't understand why Dylan people need to be accepted by the Lisp
>> community. It must be some kind of inferiority complex at work.
>
> If you look at the history of Dylan, you will see that the roots of
> it are in the Lisp community. The very same people who brought you
> the Common Lisp standard, CLIM, CMU CL, and a lot of other things
> worked on Dylan, and it was supposed to be the next big thing after
> Common Lisp, and an improvement over it.
>
> Something bad must have happened on the way, I suspect it must have
> to do with Apple's marketing department and dumbing down the
> language ever so slightly, until most of the Lisp community rejected
> it as "not powerful enough".
Moving from prefix to infix isn't forcibly "dumbing down," but is
certainly a controversial change that will turn off people that
thought that part of the charm of Lisp was in its syntax.
> Then there's the area of compiler implementation. Lots of the
> tricks applicable to any of the Lisp (or not) dialects are
> applicable to Dylan.
.. Which is something I'd think worth discussing, if the discussion
thread is about "cool compiler implementation tricks."
>> How would you know what is standard Dylan or not?
>
> There's the Dylan Reference Manual.
>
>> Remember, the word ``Dylan'' can refer to whatever you want. There
>> *is* no precision! Scheme is Dylan! Dylan is Lisp! TeX is C
>> (proof: both have curly braces for blocks).
> That's why I'm talking in terms of specific features. This does
> produce something like a distance metric, and I can say things like
> "Dylan is much more like Common Lisp than like Java".
Based on the (cons 'a 'b) litmus test (which is pretty flimsy, but so
are litmus strips), Scheme is rather like Common Lisp, and Dylan and
Java are, by that test, not at all like Common Lisp.
You can choose not to agree with that test; the wider point is that
for things not to fall into a pointless dispute, there needs to be
_some_ sort of test to agree on.
The really _simple_ one, mentioned up top, would involve the
predicate:
(defun lisp-p (language)
(search "lisp" (string-downcase language)))
(loop
for lang in '("common lisp" "elisp" "Scheme" "Dylan" "ISO Lisp")
do (format t "Language ~A ~A a Lisp~%"
lang
(if (lisp-p lang)
"is" "is not")))
Language common lisp is a Lisp
Language elisp is a Lisp
Language Scheme is not a Lisp
Language Dylan is not a Lisp
Language ISO Lisp is a Lisp
> Of course, experts would be highly welcome too. Native backend
> generator with abstract machine description anyone?
Isn't this something you should take to comp.lang.dylan?
--
(concatenate 'string "cbbrowne" ·@acm.org")
http://cbbrowne.com/info/advocacy.html
"The right honorable gentleman is reminiscent of a poker. The only
difference is that a poker gives off the occasional signs of warmth."
-- Benjamin Disraeli on Robert Peel
Christopher Browne <········@acm.org> writes:
> Andreas Bogk <·······@andreas.org> wrote:
> > Kaz Kylheku <···@ashi.footprints.net> writes:
> >
> >> Some people feel, others think. The history of Lisp has produced
> >> four surviving flavors. Firstly, there are ANSI Common Lisp, ISO
> >> Standard Lisp (ISLisp). These have actual ISO document
> >> numbers. Then there is EuLisp and Emacs Lisp.
> >
> > I'd certainly like see the criteria by which these four are Lisp,
> > and all other languages are not.
>
> The fact that they contain the four letters "L", "i", "s", and "p"
> might be considered signals of some sort.
In the very beginning of _The Structure of Evolutionary Theory_, when
Stephen J. Gould tries to define what he means by Darwinism, he writes
some about the history of ideas. The logic behind picking the
criteria for what it means to be a Darwinist applies here, I think:
Goldilocks's "just right" position between these extremes will
strike nearly all cooperatively minded intellectuals, committed to
the operationality and advance of their disciplines, as eminently
sensible: shared content, not only historical continuity, must
define the /structure/ of a scientific theory; but this shared
content should be expressed as a /minimal list/ of the /few defining
attributes/ of the theory's /central logic/ -- in other words, only
the absolutely essential statements, absent which the theory would
either collapse into fallacy or operate so differently that the
mechanism would have to be granted another name.
Dylan fails on two points to qualify as a Lisp: it does not share
historical continuity, and its abandonment of s-expressions causes it
to operate quite differently. Dylan *was* an intentional break from
Lisp: the lack of the letters l-i-s-p in its name is a result of that.
S-expressions are not sufficient to make something a Lisp, but surely
they are part of the central set of ideas that makes a language a Lisp
dialect. To label Dylan a Lisp reduces the term to meaninglessness.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
In article <···············@id-125932.news.dfncis.de>,
Christopher Browne <········@acm.org> writes:
> ...
> Dylan isn't called Lisp, not by much of anybody. While there are
> similarities in some of the semantics, and Lisp folk were involved in
> its design, it's still pretty clearly not "Lisp":
> -> It doesn't normally offer a REPL;
> -> Programs aren't expressed in the form of lists.
this is not necessarily a criterion: the Lisp1.5 manual by mccarthy
used an "external syntax" tha was pretty much algol like, and i
vaguely remember having heard/read about a Lisp2 project (I think it
was at stanford) that also used a very algol like syntax. you could
argue that dylan is a lisp in that tradition (which seems not to have
gained much following in the lisp community)
when i first read a (somewhat superficial) description of dylan, my
first impression was that someone tried to redo common lisp with a
more conventional syntax. this impression was strengthened by the
original specs that called for two syntaxes, one of them actually
quite lisp like
hs
--
don't use malice as an explanation when stupidity suffices
··@heaven.nirvananet (Hartmann Schaffer) wrote:
> In article <···············@id-125932.news.dfncis.de>,
> Christopher Browne <········@acm.org> writes:
>> ...
>> Dylan isn't called Lisp, not by much of anybody. While there are
>> similarities in some of the semantics, and Lisp folk were involved in
>> its design, it's still pretty clearly not "Lisp":
>> -> It doesn't normally offer a REPL;
>> -> Programs aren't expressed in the form of lists.
>
> this is not necessarily a criterion: the Lisp1.5 manual by mccarthy
> used an "external syntax" tha was pretty much algol like, and i
> vaguely remember having heard/read about a Lisp2 project (I think it
> was at stanford) that also used a very algol like syntax. you could
> argue that dylan is a lisp in that tradition (which seems not to have
> gained much following in the lisp community)
>
> when i first read a (somewhat superficial) description of dylan, my
> first impression was that someone tried to redo common lisp with a
> more conventional syntax. this impression was strengthened by the
> original specs that called for two syntaxes, one of them actually
> quite lisp like
I agree that there are manifest similarities.
There are also manifest differences.
The computing world would probably be a better place if Dylan had
gotten more popular instead of some combination of
[Java|Tcl|Perl|C++]. (I'd tend to think that Ada offers nice things
over those options, too, but that's another story.)
This all doesn't make Dylan "Lisp."
--
(reverse (concatenate 'string ·············@" "enworbbc"))
http://www.ntlug.org/~cbbrowne/sap.html
Q: What's the difference between MicroSoft Windows and a virus?
A: Apart from the fact that viruses are supported by their authors,
use optimized, small code and usually perform well, none.
-- Rogier Wolff <·········@et.tudelft.nl>
Christopher Browne <········@acm.org> writes:
> Dylan isn't called Lisp, not by much of anybody. While there are
I know some people who do, and some people who don't even consider
Scheme to be a Lisp.
> its design, it's still pretty clearly not "Lisp":
> -> It doesn't normally offer a REPL;
The commercial compiler from Functional Objects does. The Gwydion
folks realize the need, and as of the hacking session of last weekend,
one can say:
$ d2c -i
gwydion> local fac(n :: <integer>) n == 0 & 1 | n * fac(n - 1) end; fac(5);
evaluated expression: {literal extended-integer 120}
> -> Programs aren't expressed in the form of lists.
Strictly speaking, in Lisp, Programs are expressed as s-expressions,
and there's a canonical representation of the parse tree as lists.
This is of course of a certain elegance.
On the other hand, you're calling library functions for parsing and
writing s-expressions anyways, so the complexity of parsing and
writing is something that doesn't matter to the user. What does
matter is how easy it is to do something useful with the parse tree,
and I can think of less elegant solutions than a generic function that
dispatches on the particular syntactical element in question.
If the presence of s-expressions is the litmus test, then Dylan
certainly isn't a Lisp. But saying "it's a lot like Lisp, just that
it doesn't have s-expressions" would be justified, I think.
> Dylan is sufficiently "not like Lisp" that (cons 'a 'b) doesn't work
> there.
Yes, it's called pair(#"a", #"b") over here.
>> No, Common Lisp is an instance of Lisp, which is a subclass of
>> "dynamically typed language".
> And since Smalltalk is also dynamically typed, as is Python, we
> presumably should be including them, as well?
Neiter Python nor Smalltalk has generic functions.
> The really _simple_ one, mentioned up top, would involve the
> predicate:
>
> (defun lisp-p (language)
> (search "lisp" (string-downcase language)))
Well, at least there would be no dispute about evaluating this
predicate :).
>> Of course, experts would be highly welcome too. Native backend
>> generator with abstract machine description anyone?
> Isn't this something you should take to comp.lang.dylan?
On the off chance that somebody who is able to write such a beast
*and* has enough free time at his hand is reading this, he's welcome.
Andreas
--
"In my eyes it is never a crime to steal knowledge. It is a good
theft. The pirate of knowledge is a good pirate."
(Michel Serres)
In article <··············@meo-dipt.andreas.org>, Andreas Bogk wrote:
> Christopher Browne <········@acm.org> writes:
>> -> Programs aren't expressed in the form of lists.
>
> Strictly speaking, in Lisp, Programs are expressed as s-expressions,
> and there's a canonical representation of the parse tree as lists.
We actually think of the list structure itself as being the source code for the
Lisp program. That's easy to slip into when the notation is so close to the
structure.
> This is of course of a certain elegance.
>
> On the other hand, you're calling library functions for parsing and
> writing s-expressions anyways, so the complexity of parsing and
> writing is something that doesn't matter to the user. What does
> matter is how easy it is to do something useful with the parse tree,
A close correspondence between the notation and the structure does actually
matter. It means that you don't have to expend a lot of mental effort
in converting between how something is printed, and what it is. Even if you
have a parser, that doesn't mean that that built-in parser is the only
procedure that will be doing parsing. *People* will still be parsing that
representation in their heads when they read and write it! They read and write
one thing, but have to think another. For example, if x + y represents the
tree (+ x y), then you have to remember that extracting the first element of x
+ y actually yields x and not +. Now multiply that little problem by dozens of
symbols and levels of nesting, across a large body of code. Moreover, if a
representation travels outside of the context of that programming language
which has a parser for it, a difficult grammar could be an impediment. It may
be very well that *you* have a formatter and parser, but someone using a
different language, who needs to interoperate with your software, does not have
that parser and formatter! Lastly, the performance of formatting and parsing
may be an issue. A lot of programs are going to be doing it all over the place,
so it's not something that you can dismiss as rarely executed functionality.
In article <··············@meo-dipt.andreas.org>, Andreas Bogk wrote:
> On the other hand, you're calling library functions for parsing and
> writing s-expressions anyways, so the complexity of parsing and
> writing is something that doesn't matter to the user.
Incidentally, would you say that since it's possible to make calculators that
work in base 23, there is no practical problem in getting people to work
with numbers in base 23? ;)
Kaz Kylheku <···@ashi.footprints.net> writes:
>> On the other hand, you're calling library functions for parsing and
>> writing s-expressions anyways, so the complexity of parsing and
>> writing is something that doesn't matter to the user.
> Incidentally, would you say that since it's possible to make calculators that
> work in base 23, there is no practical problem in getting people to work
> with numbers in base 23? ;)
No, I'm saying it's possible to make calculators that work in base 16,
and there is no practical problem since the user interface will still
be in base 10. I have even heard that some engineers actually prefer
working in base 16, even though they only have 10 fingers.
Andreas
--
"In my eyes it is never a crime to steal knowledge. It is a good
theft. The pirate of knowledge is a good pirate."
(Michel Serres)
In article <··············@meo-dipt.andreas.org>, Andreas Bogk wrote:
> Kaz Kylheku <···@ashi.footprints.net> writes:
>
>> Some people feel, others think. The history of Lisp has produced
>> four surviving flavors. Firstly, there are ANSI Common Lisp, ISO
>> Standard Lisp (ISLisp). These have actual ISO document numbers. Then
>> there is EuLisp and Emacs Lisp.
>
> I'd certainly like see the criteria by which these four are Lisp, and
> all other languages are not.
They are not; they are simply languages with the word Lisp contained in their
name, and perhaps some historic connection. I would never say ``Lisp'' if I
meant EuLisp, ISLisp or Emacs lisp.
I said these are four surviving flavors. ISLisp survives in the form
of an up to date ISO standard. EuLisp is, presumably, being actively
developed, and Emacs lisp in in wide use.
Of course there are historic dialects. The language to which McCarthy pointed,
and uttered ``Lisp'' was Lisp at the time. But today, that word no longer
refers to his language, except in well-established a historic context.
So when we say that McCarthy invented Lisp, we don't mean Common Lisp;
the mention of the inventor's name establishes the historic context
which causes Lisp to refer to the first dialect which he invented.
>> In this newsgroup, an unqualified ``Lisp'' refers to Common Lisp.
>
> Would you mind referring to Common Lisp as Common Lisp when you
> actually mean it, and use Lisp when talking about the family of
> languages?
Yes, I would mind. This is just unnecessary verbiage. If I mean something other
than Common Lisp, like some historic, or surviving but insignificant dialect, I
will qualify it accordingly, or at least let it be inferred from an obvious
context.
I will change, but only after the newsgroup is renamed to
comp.lang.common-lisp, right after Corman Lisp becomes Corman Common Lisp,
Xanalys LispWorks becomes CommonLispWorks, and the domain registered by the
Association of Lisp Users becomes www.common-lisp.org along with a new logo
which somehow blends in the word Common.
The definitions of programming language names change. For example Fortran
refers to Fortran 90. If you mean Fortran 77, then you have to say that,
unless it is made obvious by context, like ``in 1983, I worked on a Fortran
program'' which cannot possibly mean Fortran 90. C now refers to C99, with
complex numbers, variable length arrays, designated initializers and other
things. Ada refers to Ada 95, which is the most recent standard as far as I
know, not, in any case, to Ada 83.
Time does not stand still, no matter how many new facts are refused
by how many minds, in hopes of staying young.
Kaz Kylheku <···@ashi.footprints.net> writes:
> In article <··············@meo-dipt.andreas.org>, Andreas Bogk wrote:
> > Kaz Kylheku <···@ashi.footprints.net> writes:
> >
> >> Some people feel, others think. The history of Lisp has produced
> >> four surviving flavors. Firstly, there are ANSI Common Lisp, ISO
> >> Standard Lisp (ISLisp). These have actual ISO document numbers. Then
> >> there is EuLisp and Emacs Lisp.
> >
> > I'd certainly like see the criteria by which these four are Lisp, and
> > all other languages are not.
>
> They are not; they are simply languages with the word Lisp contained in their
> name, and perhaps some historic connection. I would never say ``Lisp'' if I
> meant EuLisp, ISLisp or Emacs lisp.
This denies the term "Lisp" any use. If it simply means "Common
Lisp", why keep it? The fact is that these languages do share a
common set of ideas, and a common history, whence the string "Lisp" in
their names. And for what it's worth, in the Emacs community, the
term "Lisp" is used constantly to refer to Emacs Lisp.
[...]
> The definitions of programming language names change. For example Fortran
> refers to Fortran 90. If you mean Fortran 77, then you have to say that,
> unless it is made obvious by context, like ``in 1983, I worked on a Fortran
> program'' which cannot possibly mean Fortran 90.
Well, Fortran has the advantage that they changed the name from
FORTRAN to Fortran with the switch from 77 -> 90, so in writing
anyway, I can say that I have a soft spot for FORTRAN, but I really
wouldn't reccomend that a biologist learn Fortran.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
In article <···············@hurricane.OCF.Berkeley.EDU>, Thomas F. Burdick
wrote:
> Kaz Kylheku <···@ashi.footprints.net> writes:
>
>> In article <··············@meo-dipt.andreas.org>, Andreas Bogk wrote:
>> > Kaz Kylheku <···@ashi.footprints.net> writes:
>> >
>> >> Some people feel, others think. The history of Lisp has produced
>> >> four surviving flavors. Firstly, there are ANSI Common Lisp, ISO
>> >> Standard Lisp (ISLisp). These have actual ISO document numbers. Then
>> >> there is EuLisp and Emacs Lisp.
>> >
>> > I'd certainly like see the criteria by which these four are Lisp, and
>> > all other languages are not.
>>
>> They are not; they are simply languages with the word Lisp contained in their
>> name, and perhaps some historic connection. I would never say ``Lisp'' if I
>> meant EuLisp, ISLisp or Emacs lisp.
>
> This denies the term "Lisp" any use. If it simply means "Common
> Lisp", why keep it?
Because it's shorter, and therefore more convenient!
I'm only saying that the symbol Lisp has a default binding, which is to Common
Lisp, in the absence of any overriding context. It does not have refer to
exactly one thing, in every context and for all time.
(define-symbol-macro lisp '(common lisp))
The short name should default to the most popular, successful, feature-rich,
best-of-breed language which claims to be some kind of Lisp. That is perfectly
fair and rational.
It's the name of a programming *language* not the name of a family. When you
say ``I wrote it in Lisp'', it can't possibly mean ``I wrote it in a whole
family of languages at the same time''. If someone wants to use Lisp to refer
to a family, then that requires a special context in which that use is clear.
It's the wrong use for the default context, because there is an expectation
that the name refers to a concrete language; a system of symbols in which you
can write a working program.
Family is a loaded word; it implies we should all be chummy and get along
as some kind of community, and stand together against the Big Bad World or some
nonsense like that. I don't feel that I'm in any family with Scheme users, or
Emacs lisp users or the EuLisp lunatics. Or for that matter with Common Lisp
users. A stranger who happens to know Common Lisp is not automatically my
friend.
> The fact is that these languages do share a
> common set of ideas, and a common history, whence the string "Lisp" in
> their names. And for what it's worth, in the Emacs community, the
> term "Lisp" is used constantly to refer to Emacs Lisp.
Again, context. In their scope, they have a different binding for this
convenient symbol:
(symbol-macrolet ((lisp '(emacs lisp))) ...)
Why shouldn't Emacs users just use the short name among themselves? But when
an Emacs user steps outside of that scope, he or she cannot continue to use
that word to refer to Emacs Lisp.
* Andreas Bogk
| I suspect most people asking for a Lisp compiler are really asking for a
| compiler that gives them all the features they've heard Lisp would have. In
| other words, more "Lisp the family" than Common Lisp.
Your suspicions are wrong. Someone who comes asking for a Lisp compiler does
/not/ want Scheme or Dylan. They know how to ask for Scheme and Dylan if
they want it. Really. Trust me. Nobody /ever/ comes to comp.lang.lisp to
field their inquiries into Dylan and accidentally happen to call it "Lisp".
That is one real test of whether something is or is not a Lisp. However,
your disgracefully disrespectful attitude that you are right about this and
everybody else, especially seasoned users of the language in the community
you disrespect, is really annoying. You think you know better than every
single living Lisp programmer. What gall! What immeasurable arrogance!
What utter cluelessness!
| No, Common Lisp is an instance of Lisp, which is a subclass of "dynamically
| typed language".
Look, we have multiple inheritance here, and no one superclass is /defining/.
| If you look at the history of Dylan, you will see that the roots of it are in
| the Lisp community.
Which you *abandoned* because you no longer wanted to support Lisp!
What we in the Lisp community, if I may be so bold as to speak for the
numerous people who take exception to your classification, and who and whose
learned opinions you dismiss out of hand and purposefully ignore, do not
consider Dylan a Lisp. Deal with it. Stop annoying people so much. Listen
to what people tell you. Figure it out. Sheesh, dude, this is /not/ hard.
| The very same people who brougt you the Common Lisp standard, CLIM, CMU CL,
| and a lot of other things worked on Dylan, and it was supposed to be the next
| big thing after Common Lisp, and an improvement over it.
But you chucked the syntax, you frigging dimwit! You /left/ the Lisp community
with that choice. You are not competing with Common Lisp, you are not at all
"improving" on Common Lisp by taking away something that many people really,
really value in Common Lisp. That you think so and are apparently unable to
back down from your religious belief is so amazingly annoying that I wish I
could slap your stupid face and hope you snap out of it. Sadly, you have
demonstrated such amazing cluelessness and the arrogance to go with it that
the impression here, if I may again interpret the /massive/ rejection of your
claims to be a consensus, is that Dylan is the language of choice for people
who are /utterly/ unable to deal with counter-information. You and that
other bozo from the Dylan camp keep arguing /here/ in order to /convince/ people
who have no interest in your language whatsoever that it is somehow a Lisp,
when /one look/ at Dylan will reveal that it /lifted/ a number of concepts from
real Lisps, /spit/ on their syntax tradition and those who much prefer it over
yeat another Algol-Pascal-whatever derivate, and then you people have the
/chutzpah/ to tell people you disrespect and ridicule that your stolen lemon of
a language is an "improvement" over Common Lisp! Sure, you think so, and you
can think so as much as you like in comp.lang.dylan.advocacy, but if you have
to go running like a missionary to convert the heathens to your belief, you
tell everybody that Dylan is the kind of language that is used by people who
have no working brain, it is for /believers/ and /non-thinkers/ who accept your
bogus claims at face value. "Yeah, it really is a Lisp because Andreas Borg
says so", but resistance is not futile. We /shall not/ be assimilated.
Appealing to authority by imputing similarity between different products just
because the same people worked on them is such a ridiculous denigration of
their intelligence and their work ethics that I am almost speechless. How
/dare/ you assume that people choose Common Lisp because persons X, Y, and Z
worked on it? How /dare/ you imply that persons X, Y, and Z are unable to
accomplish more than one useful thing in their entire life, so if they do two
things, they must somehow be the same? How /dare/ you implicitly indicate
that persons X, Y, and Z are unable to change direction in their life at will?
Jesus, idiots like you make me /angry/! And now that I had taken nearly a
month off the newsgroup because I found that more than anything else, I wrote
articles to clarify my own thinking instead of wanting to help the morons who
are never satisfied, anyway. I wrote and filed, but did not post, many a
response, and it was so liberating to know that I would be relieved of the
idiotic, hostile responses. Over the past week or so, I have posted what
I believe to be more insightful than blabbering, but cretin like yourself
really do make me realize that newsgroups are mostly for trolls and idiots.
Look at how many responses you have received! And only because you are so
blindingly stubborn and /wrong/. Be right about something, and nobody says a
word, write something insightful that required much thought on your end, and
you are guaranteed silence (but occasionally some uplifting mail). But say
something utterly boneheaded that pisses people off simply because it is so
stupid that people who make such rabid mistakes must be corrected, and you
get to control the whole goddamn agenda in the newsgroup for a while.
But people like you, Andreas Bogk, are truly incorrigible. You are a waste
of time for anyone to respond to. You are unable to deal with contradictory
information or opinions. Your purpose here is to annoy and /pester/ people
with your retarded beliefs that you are certainly /not/ prepared to discard in
the face of overwhelming rejection.
| That's why I'm talking in terms of specific features. This does produce
| something like a distance metric, and I can say things like "Dylan is much
| more like Common Lisp than like Java".
I like to see distance metrics graphically.
|--------------------------------------------------------------------------|
idiot ^ common lisp programmer
you
The fact is, your Dylan programs look like one of those rejected languages
that did /not/ become that celebrated commercial success called "Ada".
Grow a damn clue! Dylan proselytizing and marketing is /not/ welcome here,
yet people flock to tell you this because you are so helplessly unintelligent
that you stick to your beliefs no matter what people tell you. Why? Why do
we all (me included) get so upset about such /fucking morons/ that we just
/have/ to post some rebuttal? These people are positively /brimming/ with
bovine excretions, yet neither putridity nor the methane deters people from
trying to make it into something else. Get this: */they will never get it/*.
USENET has been fertilized so heavily that it is no longer fecund. And all
that that methane does on USENET is cause spontaneous combustion.
See on you all August 15, provided you can stop responding to the nutjobs.
--
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.
Andreas Bogk <·······@andreas.org> writes:
> > I don't understand why Dylan people need to be accepted by the Lisp
> > community. It must be some kind of inferiority complex at work.
>
> If you look at the history of Dylan, you will see that the roots of it
> are in the Lisp community. The very same people who brougt you the
> Common Lisp standard, CLIM, CMU CL, and a lot of other things worked
> on Dylan, and it was supposed to be the next big thing after Common
> Lisp, and an improvement over it.
From a vendor's point of view: In the mid-90's we at Franz were
interested in Dylan as a new tack on the Lisp community. It
obviously had its roots in Lisp, and we were interested in seeing
what the plans were. Java had not yet come into its own, and there
was a nice hole that looked like it could be filled nicely by Dylan.
And Apple had approached us to see if they could find a good home for
Dylan (they were looking to cut costs by cutting projects).
So a couple of us from Franz went to Apple to talk to the developers
there, and we asked a bunch of questions. The major points I remembered
were:
1. Dylan was at the time a long way from being viable as a production
language, even though it had many bells and whistles and close to a
Developer Release. If we had taken Dylan on, we would have had a lot
of work to do to roll it out, even after DR1.
2. The original Dylan specs had allowed for both C-like and paren
style syntax, but the developers on all Dylan projects were moving to
get _away_ from paren-based syntax, and by the time DR1 had come out
that bridge had already been burned by Apple. I'm not sure what the
state of the other Dylan development groups had done by that time, but
in order for us to take Dylan on, we would have had to make a decision
to buck the stated desire of the Dylan community to lose the Lisp-like
syntax.
3. Macros were not yet completely developed, and it was told to us
that they would likely be text-based pattern-matching and substitution.
We would have had to buck that trend as well.
We went away from there deciding that Dylan was not a good match for a
Lisp company to take on. The distance from where we would have wanted
to take it was not the problem, but the direction in which it was
headed, instead.
> Something bad must have happened on the way, I suspect it must have to
> do with Apple's marketing department and dumbing down the language
> ever so slightly, until most of the Lisp community rejected it as "not
> powerful enough".
I think we rejected it as "not Lisp enough".
I view Dylan as lisp-like, but certainly not as a Lisp.
--
Duane Rettig Franz Inc. http://www.franz.com/
555 12th St Suite 1450 Oakland, CA 94607 http://www.555citycenter.com/
Phone: (510) 452-2000; Fax: (510) 452-0182 ·····@franz.com
Kaz Kylheku <···@ashi.footprints.net> writes:
> Some people feel, others think. The history of Lisp has produced four surviving
> flavors. Firstly, there are ANSI Common Lisp, ISO Standard Lisp (ISLisp). These
> have actual ISO document numbers. Then there is EuLisp and Emacs Lisp. In this
> newsgroup, an unqualified ``Lisp'' refers to Common Lisp.
It remember when Le Lisp, Xlisp and Portable Standard Lisp used to be
mentioned/discussed in comp.lang.lisp. I haven't seen any mentioned
here in a while, let alone Cambridge Lisp. However, I still haven't
got used to thinking of ``Lisp'' as ``Common Lisp'' in this group
despite what the FAQ says. Note to myself to try harder :-)
"Stephen J. Bevan" wrote:
>
> Kaz Kylheku <···@ashi.footprints.net> writes:
> > Some people feel, others think. The history of Lisp has produced four surviving
> > flavors. Firstly, there are ANSI Common Lisp, ISO Standard Lisp (ISLisp). These
> > have actual ISO document numbers. Then there is EuLisp and Emacs Lisp. In this
> > newsgroup, an unqualified ``Lisp'' refers to Common Lisp.
>
> It remember when Le Lisp, Xlisp and Portable Standard Lisp used to be
> mentioned/discussed in comp.lang.lisp. I haven't seen any mentioned
> here in a while, let alone Cambridge Lisp. However, I still haven't
> got used to thinking of ``Lisp'' as ``Common Lisp'' in this group
> despite what the FAQ says. Note to myself to try harder :-)
What about Autolisp?
Paul
"Paul F. Dietz" <·····@dls.net> writes:
> "Stephen J. Bevan" wrote:
> > It remember when Le Lisp, Xlisp and Portable Standard Lisp used to be
> > mentioned/discussed in comp.lang.lisp. I haven't seen any mentioned
> > here in a while, let alone Cambridge Lisp. However, I still haven't
> > got used to thinking of ``Lisp'' as ``Common Lisp'' in this group
> > despite what the FAQ says. Note to myself to try harder :-)
>
> What about Autolisp?
My list above wasn't meant to be exclusive, it was just some of the
Lisps I used in the past and which were once discussed here. None of
them had a separate newsgroup devoted to them and so comp.lang.lisp
was a natural place to discuss them. Depending on exactly what the
issue was with Autolisp then comp.cad.autocad may or may not be a
better place to discuss it. If it was something generically Lispy
then comp.lang.lisp seems fine to me -- though perhaps not to others
given the warning in the FAQ.
On 1 Aug 2002 13:47:14 -0700, ·········@gmx.net (thelifter) wrote:
> It's because there are no good compilers for free.
Could you elaborate on the benchmarks, tests and code disassemblies that
made you reject existing Common Lisp development environments?
> CLISP(generates only byte-code) and CMUCL(runs only on Unix). So how
> are you guys expecting anyone to use it?
Funny you should wonder about that. Lisp is the second oldest language
still in use, and it is 44 years old. It survived all sorts of fads and
market crises.
> Other functional languages are better off. Take Ocaml for example, it
Common Lisp is more than just a functional language.
> 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?
Could you elaborate on the sources on which your claim about the efficiency
of generated code is based?
> 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 quote suggests that inexperienced programmers are likely to write
inefficient code, not that experts can't write efficient code. Common Lisp
is not a language "for dummies", and it is not optimized for beginners.
Note also that the section from which the quote is taken is titled "Totally
Inappropriate Data Structures", and it is under "2.0 Lisp's _Apparent_
Failures" (emphasis added).
You are right that Gabriel's paper mentioned above is interesting. But you
forgot to quote some other relevant parts. Subsection "1.2 Good
Performance", which is under "1.0 Lisp's Successes", also says:
Common Lisp performs well. Most current [i.e. in 1989] implementations
use modern compiler technology, in contrast to older Lisps, which used
very primitive compiler techniques, even for the time.
[...]
In fact, Common Lisp performs well on benchmarks compared to C.
So, what was your point?
Incidentally, your apparent inability to deal with context may make it
difficult for you to understand Common Lisp's multiple namespaces.
> 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
What kind of application does require such speed? What project are you
working on?
> 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?
What about an assembler? There are a lot of such free tools.
> Lisp, a language that works nice in theorie only?
Thanks, but there was no need to remind that you are a troll.
Even if Common Lisp is the perfect language for your project, and you
eventually find a development environment that fits your needs, I strongly
suggest that you don't use it. Your attitude can do no good to Lisp.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
In article <····························@posting.google.com>, 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).
You are implying that ``runs only on Unix'' and ``good compiler'' are
opposites, which you are free to believe, but don't assume that everyone
accepts it as truth.
> So how
> are you guys expecting anyone to use it?
I can't speek for all ``you guys'', but I don't expect anyone to do anything. I
couldn't care less if I'm the last Common Lisp programmer on the planet, as
long as I have a way, in that case, to maintain the programming environment I
need.
> Other functional languages are better off. Take Ocaml for example, it
> comes with a native code compiler for free.
Just one? What are the players in the Ocaml world? Who are the vendors?
Now count the vendors of Lisp systems.
What does it mean for a language to be better off? Why does it matter?
Is a language a living thing? Would you want people to be badly off, for
the sake of a programming language being better off?
> 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. "
But nobody would write the matrix code that way, only someone who
didn't know that Lisp has built-in multi-dimensional arrays.
What part of the paragraph heading ``Totally Inapprpropriate Data Structures''
has the author not made clear enough for you?
You can write stupid code in any language; if stupid code can also
be beautiful in Lisp, so what? That's only an advantage, because it
means that if you aren't constrained by performance, you can just
express yourself in the most convenient way to get the results.
Consider that if you wrote matrix multiplication using linked lists
in C++ or Java, it would be so contorted, that the reader of the
code would not even recognize it to be matrix multiplication.
Moreover, removing the stupidity from the program would probably
be quite hard, involving irrelevant changes all over the place.
The number one concern in programming is correctness and reliability.
The number two is maintainability. Performance isn't even number three.
> What help are the higher level structures of Lisp if afterwards I have
> to hand-optimize everything to make efficient code?
You don't have to hand-optimize everything, because it is very, very rare for
the time spent running a program to be equally distributed throughout that
program. Usually, most of the time is spent in a few places, which are
sometimes called ``hotspots''. If you don't know that, you have yet to
advance to the rank of programming newbie. Optimizing hotspots doesn't
call for the destruction of the higher level structure of your software.
> 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?
Idiot, Windows is a proprietary system. If you write a program for Windows, you
must use that proprietary system, and all the users of that program must use it
as well.
If you don't mind paying for and using a proprietary operating system, why
object to proprietary tools? Or are you stupid enough to believe that
just because your computer came with Windows preinstalled, it was free?
Or maybe you feel that for some reason Microsoft deserves your business, but a
Lisp vendor does not?
I simply don't follow the chain of reasoning.
You want someone to buy and license Windows, so that they could use it to
develop tools for it, and give those tools away to you, right? These people
have to bootstrap themselves with proprietary tools at some point. You think
that Cygwin magically ran on Windows from day one without the help of any
proprietary tool?
Even the Linux kernel needed proprietary tools at the beginning.
Very early versions were compiled with a Borland C compiler,
because that is what Minix used. Oh yeah, and Minix isn't free
software either. Only when the kernel was robust enough to host
GCC was the switch made to that compiler.
Some people do make free software for Windows, like Cygwin, but you have no
right to demand others to serve you.
There are no impediments against writing free, open source software in Common
Lisp. If your users want to run that software on some proprietary platforms,
and they want to make it run it as efficiently as possible, they can license
the proprietary Lisp systems needed to do that. If they are not smart enough
to port the software to these Lisp systems, they should be willing to pay you
to do it for them, and provide you with the tools that you claim you cannot
afford.
Note that a number of proprietary Lisp vendors allow you to use their
tools free of charge. Some have reduced functionality, some do not.
But what is available is good enough to actually port a program to
target these systems.
For example, one vendor's system has the limitation that you cannot make a
standalone executable. But that doesn't prevent you from getting the program to
work.
Thus if you are really short on cash, you can delay the purchase until you have
conquered some of your other risks, like getting the program working, and
finding potential customers.
> Thanks for any help...
>
> --------------------------------
> Lisp, a language that works nice in theorie only?
Lisp is a language that works nicely, for non-whining, non-loser, non-idiots
who work for a living.
You know, there was a day when CLISP and CMUCL didn't exist;
they exist because motivated people took *action* instead of sitting
around lamenting how there are no liberated Lisp implementations.
Since these people took action, the freedom to determine their implementation
requirements was also their own. The CLISP designers went to a bytecode
model, leaving native code generation to a later stage. The CMUCL designers
targetted UNIX. Changing these decisions requires more *action*,
not whining.