I know, someone shoot me in the head, I've gone nuts,
but I'm looking for a FREE lisp compiler for the PC.
Win95/Win98 or DOS is ok.
Must be able to compile to native code, and create C/C++ linkable object
files.
Prove to me lisp is worth it.
--
Bagherra <jaebear @ frenzy.com>
http://www.frenzy.com/~jaebear
"There's a snake in my boot!"
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
Bagheera, the jungle scout <········@my-deja.com> writes:
> I know, someone shoot me in the head, I've gone nuts,
> but I'm looking for a FREE lisp compiler for the PC.
> Win95/Win98 or DOS is ok.
>
> Must be able to compile to native code, and create C/C++ linkable object
> files.
On UN*X you can get CMUCL (http://www.cons.org). On the PC platform
you can get several trial system, but to actually get a native
compiler you must shell out some Euros.
> Prove to me lisp is worth it.
Pretty simple. Try to extend your C/C++ syntax to handle some special
construct you just came up with. Or, to be even nastier, suppose you
were writing an OO window system. You have several types of windows
and several types of events. Now write a function that does (in C++)
process_event(WindowClass, EventClass);
Careful. The function must dispatch (i.e. be 'virtual') on *both*
arguments. Come back here in three weeks and show us what you came up
with. :) (Actually there is a way to respond to this question in
three hours - allowing some reading of Coplien's and Lippman's books,
along with some basic CL stuff like Keene's "OO Programming in CL":
the answer is very simple in this case).
Did I tickle you enough?
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
In article <··············@copernico.parades.rm.cnr.it>,
Marco Antoniotti <·······@copernico.parades.rm.cnr.it> wrote:
>
>
> Bagheera, the jungle scout <········@my-deja.com> writes:
>
> > I know, someone shoot me in the head, I've gone nuts,
> > but I'm looking for a FREE lisp compiler for the PC.
> > Win95/Win98 or DOS is ok.
> >
> > Must be able to compile to native code, and create C/C++ linkable
object
> > files.
>
> On UN*X you can get CMUCL (http://www.cons.org). On the PC platform
> you can get several trial system, but to actually get a native
> compiler you must shell out some Euros.
I already have $800 worth of compilers. Unless you can point me to a
lisp compiler for under $20, I'm not interested.
> > Prove to me lisp is worth it.
<snip trvial C++ problem>
Anything you can do in lisp, I can do in C++. Or any other language for
that matter. True you could get language specific on me and say
something like "make a pointer in Java"...yeah well, you can't, but
there are ways to emulate that behavior. I am very experienced in
several programming languages, and I just wanted a cost analysis of Lisp
that would explain to me why it is worth buying.
I need analysis on things like learning curve (the people I work with
all learned C++ fairly rapidly, but we are all struggling with
perl...for comparison), included software, optimizations on the native
binary generation, and things like that.
Right now I just want to use lisp because it seems to be the only
langauge AI books speak (and the one that went left field to write a
book using C++ didn't learn C++ well enough before they wrote the book).
So I am at an empasse. I want an affordable lisp compiler for Windows,
or an INTELLIGENT explanation of why it is worth what companies charge
for it (on average, it is about 3x the cost of a GOOD professional C++
compiler).
--
Bagherra <jaebear @ frenzy.com>
http://www.frenzy.com/~jaebear
"There's a snake in my boot!"
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
[newsgroups trimmed to comp.lang.lisp only]
Bagheera, the jungle scout <········@my-deja.com> writes:
> I already have $800 worth of compilers. Unless you can point me to a
> lisp compiler for under $20, I'm not interested.
You could try Corman Lisp (see http://www.corman.net/). There's a
fully functional evaluation version available from the web site. I
personally have not used it; I have no idea how it compares to other
commercial offerings from Franz, Harlequin, or Digitool.
If you actually want to learn about Lisp a little bit, I recommend the
following books:
Paradigms of Artificial Intelligence Programming: Case Studies in
Common Lisp, by Peter Norvig
ANSI Common Lisp, by Paul Graham
On Lisp, by Paul Graham
-matt
>>>>> "Bag" == Bagheera, the jungle scout <········@my-deja.com> writes:
Bag> I already have $800 worth of compilers. Unless you can point me
Bag> to a lisp compiler for under $20, I'm not interested.
Er, what I think you mean to say is that you've _spent_ $800 on
compilers. What they are _worth_ is a separate question.
Bag> Prove to me lisp is worth it.
Not my job. Sorry.
If I were you (and depending on what you are trying to do), I'd ditch
the native code requirement for the time being and try out CLISP
(<http://clisp.cons.org>). After you've begun to understand Common
Lisp, then you might be more willing to spend money on it. Or maybe
not.
In other words, prove it to yourself.
Bag> Anything you can do in lisp, I can do in C++.
snicker.
--
Russell Senior ``The two chiefs turned to each other.
·······@teleport.com Bellison uncorked a flood of horrible
profanity, which, translated meant, `This is
extremely unusual.' ''
Bagheera, the jungle scout wrote:
> ...
> Right now I just want to use lisp because it seems to be the only
> langauge AI books speak (and the one that went left field to write a
> book using C++ didn't learn C++ well enough before they wrote the book).
Ahh, but there is a REASON for that. My view is that good AI authors
could certainly use any programming language, and would certainly learn
well whichever one they choose.
The reason that so many good AI authors choose Lisp is, as I understand
it, because they are interested in expressing concepts, paradigms,
algorithms, etc., in the most natural language (whatever that means) for
the problem at hand. Now, here's the important thing: NEITHER C++ NOR
LISP NOR PROLOG NOR ANY OTHER PROGRAMMING LANGUAGE IS THE MOST NATURAL
LANGUAGE FOR EXPRESSING EVERY APPLICATION. However, only Lisp brings
the whole considerable power of the programming language to bear on the
subproblem of CREATING the most natural language for expressing an
application.
AI authors don't write in Lisp. They write in application-specific
languages that are easily constructed in Lisp and embedded within Lisp.
Your question about seeking a compiler, as opposed to a language
implementation or development environment suggests that there may be an
important subtelty here that is escaping you. When working with C/C++,
the technique for creating an application-specific language involves,
for example, using C/C++, lex, yacc, etc., to create a compiler for the
new application-specific language. One then writes programs in that
language, which may have nothing to do with C or C++. Any experience
with C/C++ may or may not help another person in learning the new
application-specific language because they may be totally unrelated.
By contrast, new languages are easily embedded in a running Lisp by
extending it, not by replacing it. The application runs within the new
language which itself runs within the Lisp system. There is no need to
write a new compiler, IDE, graphics system, debugger, etc., nor any need
to reinvent the standard math, file-system, etc., libraries. (This last
point is subtle, too. In Lisp, all the Lisp library utilities, for
example, operate on tagged data. The application-specific library
doesn't have to do anything special to make the application-specific
data types be tagged to, and they can coexist and be used with functions
in the standard Lisp library.)
For more information about Lisp, including books appropriate to AI,
comparisons with other languages, and listings of available
implementations, see http://www.lisp.org.
Bagheera, the jungle scout <········@my-deja.com> writes:
>
> I already have $800 worth of compilers. Unless you can point me to a
> lisp compiler for under $20, I'm not interested.
You spent $800 on other compilers, but don't want to spend more than
$20 on a Lisp compiler? Probably, you should stick with the compilers
you've got :-)
> Anything you can do in lisp, I can do in C++.
This is certainly true in some sense, but it is a totally meaningless
argument when you are comparing languages. In fact, why not get a
refund for the $800 and simply write your programs in machine code?
> I am very experienced in several programming languages, and I just
> wanted a cost analysis of Lisp that would explain to me why it is
> worth buying.
To make an informed decision regarding the suitability of Lisp for
your situation you would have to understand the language. This will
require some effort. Judging by the tone of your posting, you are not
willing to invest in such an effort, neither financially nor in terms
of the effort it takes to understand the language. In that case, my
advise is to stick with a language you know. If you really want to
evaluate the Lisp family of programming languages, I suggest you
invest in a good book or two, and get one of the evaluation packages
from a Lisp vendor. They all have free evaluation systems for Windows.
Joachim
--
·······@kraut.bc.ca (http://www.kraut.bc.ca)
·······@mercury.bc.ca (http://www.mercury.bc.ca)
On Thu, 02 Sep 1999 22:16:30 GMT, Bagheera, the jungle scout wrote:
> Marco Antoniotti <·······@copernico.parades.rm.cnr.it> wrote:
>> Bagheera, the jungle scout <········@my-deja.com> writes:
>> > I know, someone shoot me in the head, I've gone nuts,
>> > but I'm looking for a FREE lisp compiler for the PC.
>> > Win95/Win98 or DOS is ok.
There are a couple.
>> > Must be able to compile to native code, and create C/C++ linkable
>> > object files.
>> On UN*X you can get CMUCL (http://www.cons.org). On the PC platform
>> you can get several trial system, but to actually get a native
>> compiler you must shell out some Euros.
>I already have $800 worth of compilers. Unless you can point me to a
>lisp compiler for under $20, I'm not interested.
Plenty of free ones to learn on. If you want more than that, you have to
pay for it, either by money or development effort.
>> > Prove to me lisp is worth it.
><snip trvial C++ problem>
Multiple dispatch with optimization is far from trivial -- the fact that
you think it is only shows your own inexperience.
>Anything you can do in lisp, I can do in C++. Or any other language for
>that matter. True you could get language specific on me and say
>something like "make a pointer in Java"...yeah well, you can't, but
>there are ways to emulate that behavior. I am very experienced in
>several programming languages, and I just wanted a cost analysis of Lisp
>that would explain to me why it is worth buying.
Then ask for a cost analysis. It _sounded_ like you wanted a free
compiler which did everything you wanted, and you wanted the privledge of
acting snippy toward us in the meantime. Sorry, you wanna act like our
master you have to pay us :).
>I need analysis on things like learning curve (the people I work with
>all learned C++ fairly rapidly, but we are all struggling with
>perl...for comparison), included software, optimizations on the native
>binary generation, and things like that.
Okay.
Lisp has an IMMENSE number of functions, but a VERY simple language. The
total learning effort will be less than C++ with STL (I can't say how
much; my information is anecdotal and vague).
Lisp, as a language, offers you TONS of instantly useful utilities -- the
memory management alone is worth the learning curve. Add in CLOS and it's
a real lifesaver.
The Lisp language specification contains a huge number of useful functions
-- so as a library Lisp is very complete. You'll find that you have to do
less work to get any given thing finished.
Perl sucks, BTW. Use Python instead, if you can get away with it. If you
wind up using Lisp elsewhere, though, you'll likely find yourself using
Lisp for your scripting tasks as well -- it's a very flexible language.
>Right now I just want to use lisp because it seems to be the only
>langauge AI books speak (and the one that went left field to write a
>book using C++ didn't learn C++ well enough before they wrote the book).
I hate that kind of thing. I also dislike pessimistic introductory books
-- when I'm learning a language I want to feel that I'm learning a good
thing, not something sucky :).
>So I am at an empasse. I want an affordable lisp compiler for Windows,
>or an INTELLIGENT explanation of why it is worth what companies charge
>for it (on average, it is about 3x the cost of a GOOD professional C++
>compiler).
The main reason, of course, is that comanies charge what the market will
bear. The market for Lisp compilers tends to realize that a good Lisp
contains a LOT of useful things which no C++ compiler has -- and even a
bad one compiles a more complete language than the best C++ compiler can.
>Bagherra <jaebear @ frenzy.com>
--
-William "Billy" Tanksley
* Bagheera, the jungle scout <········@my-deja.com>
| Anything you can do in lisp, I can do in C++.
sure, but I think people generally expect you to do it in finite time.
| So I am at an empasse. I want an affordable lisp compiler for Windows,
| or an INTELLIGENT explanation of why it is worth what companies charge
| for it (on average, it is about 3x the cost of a GOOD professional C++
| compiler).
well, assume most companies pay their programmers a lot of money. if you
could save 50% on the time it took to complete a project, that'd be worth
half a lot of money, which equals _way_ more than the difference between
the cost of the compilers.
the reason most managers don't believe it is that they don't actually
know what their programmers spend their time on or that it could be spent
much more wisely. incidentally, doubling he programmer efficiency is
considered weak performance, but it's what you'll get for the first
project or two. with very experienced programmers in both C++ and Lisp,
you get a factor of 3 to 5 improvement in Lisp's favor, but with people
who have spent a year learning their respective language, you should
expect a factor 5 to 10 improvement in Lisp's favor. the irony is that
it's harder to find very experienced C++ programmers than to find very
experienced Lisp programmers, and they cost a _lot_ more.
also, a single good Lisp programmer can easily do more than 20 moderately
good C++ programmers in the same time. the reason is team communication
overhead, which is necessary because doing C++ stuff all alone is too
hard, and you also need to finish in reasonable amount of time. that's
why you don't see a lot of advertising for Lisp folks, but a whole lot of
advertising for C++ folks.
#:Erik
--
save the children: just say NO to sex with pro-lifers
Erik Naggum wrote:
>
> * Bagheera, the jungle scout <········@my-deja.com>
> | Anything you can do in lisp, I can do in C++.
>
> sure, but I think people generally expect you to do it in finite time.
>
> | So I am at an empasse. I want an affordable lisp compiler for Windows,
> | or an INTELLIGENT explanation of why it is worth what companies charge
> | for it (on average, it is about 3x the cost of a GOOD professional C++
> | compiler).
>
> well, assume most companies pay their programmers a lot of money. if you
> could save 50% on the time it took to complete a project, that'd be worth
> half a lot of money, which equals _way_ more than the difference between
> the cost of the compilers.
I agree about this.
>
> also, a single good Lisp programmer can easily do more than 20 moderately
> good C++ programmers in the same time.
but not about this. This is an opinion and not a fact I guess. And maybe
you underestimate the C++ programmers. There are surely some under them
for whom the other way is as true. I don't have the knowledge and
experience to fill this with numbers but some others have found out that
under programmers the differences can be very large. But to say this
holds for all Common Lisp Programmers is a wild guess.
BTW my opinion towards Common Lisp or another functional language is
clear. It's a good idea for any programmer to know at least one
imperative (or even object-oriented) language and a functional language.
Another think I think holds is that there aren't a lot of comparisions
between e.g C++ and other Languages. I guess we all could learn form
that.
Regards
Friedrich
* Friedrich Dominicus
| This is an opinion and not a fact I guess.
not just opinion, but the evidence is anecdotal, not fundamental. the
reason it doesn't sound unreasonable to me, and in fact sounds reasonable
is that when you need, say, 5 times as many programmers to handle the
amount of work necessary, you get interaction costs and team overhead
that slows everybody down to a quarter of their top speed alone. but you
can hardly _do_ C++ work alone, except for fairly small things, like
three to six months. if you were to spend 15 to 30 months like that,
you'd have really a hard time. a Common Lisp programmer can get the
system working in a short time, learn a lot from and develop the software
with its users when it's still quite malleable. that's too hard to do in
C++, so you also spend more time designing the system before-hand. all
of this means more time and the demand to get it coded and deployed means
more programmers, which means more team interaction overhead. all of
this really adds up.
| And maybe you underestimate the C++ programmers.
(1) you can't underestimate C++ programmers. (the snotty version ;)
(2) no, but you can't hire top-notch C++ programmers for projects like
this. top-notch C++ programmers generally develop fundamental stuff like
libraries and interface tools, not applications.
#:Erik
--
save the children: just say NO to sex with pro-lifers
Erik Naggum wrote:
>
> * Friedrich Dominicus
> | This is an opinion and not a fact I guess.
>
> not just opinion, but the evidence is anecdotal, not fundamental.
^^^^^^^^^
That means to me. Hey I don't have numbers I just tell you some stories.
That's an opinion so much said.
>
the
> reason it doesn't sound unreasonable to me, and in fact sounds reasonable
> is that when you need, say, 5 times as many programmers to handle the
> amount of work necessary, you get interaction costs and team overhead
> that slows everybody down to a quarter of their top speed alone. but you
> can hardly _do_ C++ work alone, except for fairly small things, like
> three to six months.
<irony>
So C++ is better suited for cooperative work. Now I understand why e.g
KDE is written using C++ an not Common Lisp. You just can code CL alone
;-) And fair enougth that desktop has found it's place on a lot of
computers. I don't have heard or seen one of this things for CL. All
that lead to the conclusion, that you can't use CL for that.
</irony>
So this is a conclusion from your mail. Do programming on you own with
Common Lisp but if you want to work with other uses C++. (that is
ancecdotal evidence)
>
> | And maybe you underestimate the C++ programmers.
>
> (1) you can't underestimate C++ programmers. (the snotty version ;)
and of cours you can't overestimate Common Lisp programmers. They are
per defintion supirior to all other crap which is around. ;-).
Interesing enought the crap buils stuff which is used for many and the
all-so supierour Lispers ...
Grining
Friedrich
* Friedrich Dominicus
| So this is a conclusion from your mail. Do programming on you own with
| Common Lisp but if you want to work with other uses C++.
you aren't this stupid, are you? nobody wants to hire more people than
necessary, but they have to if they hire C++ programmers, because one guy
can't cut it. one guy often can get it done in Common Lisp. this is
supposed to be an advantage. I didn't say anything at all about what the
programmer wants, but I see that you don't need to base your conclusions
about what other people say on anything they have actually _said_, so you
won't understand that I have contradicted you _before_ you concluded what
you did, and you won't understand that I do now. end of discussion.
| Interesing enought the crap buils stuff which is used for many and the
| all-so supierour Lispers ...
only people with serious inferiorioty complexes think others are "all so
superior" just because they are better than them at something and aren't
afraid to say so (but neither do they do so without cause). good people
enjoy the competence of others. you obviously don't.
| Grining
| Friedrich
it's "grinning", you moron, and it fits you very well to misspell it, too.
#:Erik
--
save the children: just say NO to sex with pro-lifers
Erik Naggum schrieb:
>
> * Friedrich Dominicus
> | So this is a conclusion from your mail. Do programming on you own with
> | Common Lisp but if you want to work with other uses C++.
>
> you aren't this stupid, are you? nobody wants to hire more people than
> necessary, but they have to if they hire C++ programmers, because one guy
> can't cut it. one guy often can get it done in Common Lisp.
This is what you we're talking about and you drop just some anecdotes
here I try to persiflage but you didn't get it. So I won't try that
again.
>this is
> supposed to be an advantage. I didn't say anything at all about what the
> programmer wants, but I see that you don't need to base your conclusions
> about what other people say on anything they have actually _said_, so you
> won't understand that I have contradicted you _before_ you concluded what
> you did, and you won't understand that I do now. end of discussion.
>
> | Interesing enought the crap buils stuff which is used for many and the
> | all-so supierour Lispers ...
>
> only people with serious inferiorioty complexes think others are "all so
> superior" just because they are better than them at something and aren't
> afraid to say so (but neither do they do so without cause). good people
> enjoy the competence of others. you obviously don't.
I do, if you would read some messages from me you should be able to
recognize that. I just can't stand the attitude that all others are
idiots and my impression is that that is your opinion toward anyone who
uses C++. But I won't start flaming just because others have other
opinions and that's what I wrote you just drop in your opinion and it
seems to me that you have problems with anyone who's not using CL. But
you just tell stories. I just asked for reports on comparisons between
different languages. That's all.
>
> | Grining
> | Friedrich
>
> it's "grinning", you moron, and it fits you very well to misspell it, too.
What is a moron and what does misspelling have to do with a discussion.
I was just smiling at myself about that arrogance towards C++
programmers. But I guess I really do not want to know what a moron is.
You mail is very unpleasant to read and you just drop in opinions and
claims that they are true because you know. I do think that is poor
style.
So either you calm down and really answer questions or flag your
comments as anecdotal but not as a fact which they aren't.
Grinning even move brightly
Friedrich
* Friedrich Dominicus <···················@inka.de>
| I just can't stand the attitude that all others are idiots
none such exists. your willingness to go from "some" to "all" is your
very own logical flaw. I suggest you take responsibility for it.
| and my impression is that that is your opinion toward anyone who uses C++.
your impression is precisely that -- your impression. it is not my
responsibility to correct people who aren't even able to _read_ stuff
they don't agree with.
| But I won't start flaming just because others have other opinions and
| that's what I wrote you just drop in your opinion and it seems to me that
| you have problems with anyone who's not using CL.
it seems that way to you because you don't think, but rather want to fit
things into predetermined prejudices. again, your very own problem.
| Grinning even move brightly
and you speak about _other_ people's attitude problems? geez. but, hey,
I understand why you think in terms of attitude. you're the pro, here.
now, find a mirror and enjoy your grinning, but spare us more of it.
#:Erik
--
save the children: just say NO to sex with pro-lifers
Erik Naggum wrote:
>
> * Friedrich Dominicus <···················@inka.de>
> | I just can't stand the attitude that all others are idiots
>
> none such exists. your willingness to go from "some" to "all" is your
> very own logical flaw. I suggest you take responsibility for it.
Ok I do that.
After this side-step towards flaming could we forget the last mails and
you just give me an answer on the question which was asked. I said you
don't have numbers and that you put in you opinion. You opinion might be
right or wrong, I believe you are possibly more on the right side. And
yes I do think that Common Lisp is a better choice as C++ ever will and
can be, just for the record: we don't have comparisons and because we
doN't have we just are guessing. That's quite ok but I personally think
that it would be a good idea having some comparisons.
1) Ease of learning (on different levels)
2) Development Effort
3) Maintenance costs
4) Tool support
...
a lot more. You can fill in you favourites.
Now my wild guesses: I think that Common Lisp is a better choice in
point 2 and three I'm not sure about 1. I do think that 4) is found for
C++ other points can be addes and that really would be helpful to see
for different languages. But I see this does not fit the subject of this
thread.
So I suggest you calm down and think about the real question
Regards
Friedrich
In article <·················@inka.de>, ···················@inka.de wrote:
> 1) Ease of learning (on different levels)
With the right approach CL is much easier to learn.
> 2) Development Effort
Easy win for the Lisp side.
> 3) Maintenance costs
***Big*** win for the Lisp side.
> 4) Tool support
Depends. Lisp has tool building as one of
its fundamental paradigms. Many tools you
can write on your own in little time.
Real Lisp users are not afraid to do this.
Others are different to get - for example
interfaces to certain (proprietary) protoc
On Sat, 04 Sep 1999 18:37:45 +0200, Rainer Joswig wrote:
>In article <·················@inka.de>, ···················@inka.de wrote:
>> 1) Ease of learning (on different levels)
>With the right approach CL is much easier to learn.
As a person who JUST learned Lisp and had just previously learned C++
after having used it for a while, I have to agree with you. Lisp has the
fundamental advantage of being simple as a language, and its library is no
harder to learn than C's.
--
-William "Billy" Tanksley
In article <······················@dolphin.openprojects.net>, ········@dolphin.openprojects.net wrote:
> On Sat, 04 Sep 1999 18:37:45 +0200, Rainer Joswig wrote:
> >In article <·················@inka.de>, ···················@inka.de wrote:
>
> >> 1) Ease of learning (on different levels)
>
> >With the right approach CL is much easier to learn.
>
> As a person who JUST learned Lisp and had just previously learned C++
> after having used it for a while, I have to agree with you. Lisp has the
> fundamental advantage of being simple as a language, and its library is no
> harder to learn than C's.
Often Lisp is being learned in an University context (often using Scheme).
Unfortunately quality varies and many courses are not teaching
Scheme, but Computer Science - so students get some wrong
impressions (primitive tools, esoteric concepts, difficult
to learn, not usable for practical concepts, etc.).
But in reality learning Lisp can (and should) be very easy
to learn (powerful interactive environments, good documentation, elegant
concepts, designed by people who really understood their
field, ...). Everybody who then wants to move on from
simple Lisp introductions should read a book like
PAIP from Peter Norvig.
It also helps to talk to some knowledgeable people to get some
guideance (or even take a Lisp course, like Franz is offering
them). Make sure that those teachers really adapt to
the learning pace of the students. Big Lisp systems
can be a overwhelming - I remember when I first sat
in front of a Lisp machine - it didn't understand anything
I was doing - yet we were supposed to help porting
a natural language system to ZetaLisp (from UCI Lisp or InterLisp)
using a semi-automatic porting tool. Well, the debugger
was not my friend at that time.
······@lavielle.com (Rainer Joswig) writes:
> > 2) Development Effort
>
> Easy win for the Lisp side.
Totally true, but newcomers may not experience this unless they allow
themselves to work in a diffrent way than they may be used too.
First, you might need to change your editor, to one which supports
lisp indenting and paren matching, and hopefully a Lisp listener.
Emacs is the obvious choice. I luv emacs and ILISP, the tab
completion, the form evaluation and compiling, the debugging, all come
together to make develoment much easier.
Humor me for a second with my rough distinction between programming
and coding. I see programming as the act of abstracting, designing,
pondering, trying things, and "writing" things. I see coding as the
work of putting this into machine understandable form, syntax checks,
remembering variable and function names, typing the stuff in, editing
source code. The split is an inuitive one, not a strong, factual
one. I hate coding, it's mind-numbing and is the number one force of
friction for me when developing. Lisp systems, with real interfaces
like emacs and ILISP (and the others that vendors provide) make coding
a much easier task, and greatly reduce the amount of friction I need
to overcome in order to encode an idea into a system.
I see several things contributing to the Lisp systems ability to
reduce coding friction. Interactive development is the biggest one,
and it really pays off if you take a functional approach to your
design. At any point you can test a fragment code, no recompile, no
big testing harness needed, no test proggies. This alone prolly gives
me a two-fold performance increase, and that's a modest estimate.
The simple syntax and editor support for it is another one. Fewer
syntax errors and less complex editing (once you learn sexpr-based
movement and editing in emacs) result in more productivity for me.
Symbol completion, integrated documentation and help mean that I don't
have to switch to another application to read the help, and don't have
to navigate some hypertext document with the accursed mouse. Looking
up a functions documentation or arglist is trivial and almost a
reflex. Less errors from guessing and less time wasted hunting for
docs. The result is even more increased productivity.
There are a dozen other advatnages to Lisp itself, but I wanted to
just focus on the advatanges of the developm3ent environments that
come with it. We can talk about the power of macros, the fullness of
the language and other things later, a newcomer is not going to be
able to experience those too deeply at first.
> > 4) Tool support
>
> Depends. Lisp has tool building as one of
> its fundamental paradigms. Many tools you
> can write on your own in little time.
> Real Lisp users are not afraid to do this.
> Others are different to get - for example
> interfaces to certain (proprietary) protoc
I've been experiencing this first hand over the last few days. The
friction one must overcome to put a new tool into play is greatly
reduced when working with Lisp.
--
Craig Brozefsky <·····@red-bean.com>
Free Scheme/Lisp Software http://www.red-bean.com/~craig
"riot shields. voodoo economics. its just business. cattle
prods and the IMF." - Radiohead, OK Computer, Electioneering
In article <··············@piracy.red-bean.com>, Craig Brozefsky <·····@red-bean.com> wrote:
> Totally true, but newcomers may not experience this unless they allow
> themselves to work in a diffrent way than they may be used too.
> First, you might need to change your editor,
You mean they were not already using "Emacs"? ;-)
> to one which supports
> lisp indenting and paren matching, and hopefully a Lisp listener.
> Emacs is the obvious choice. I luv emacs and ILISP, the tab
> completion, the form evaluation and compiling, the debugging, all come
> together to make develoment much easier.
Emacs and Ilisp is not that bad. Actually I think
some of the integrated environments are *much*
more productive when you start developing complex
software (I know that some wizards just stay with
Emacs). I always tell people that they need to develop
tools to handle the complexity - having visual tools is
a way to go for a lot of people. A program should be developed
in parallel with the tools necessary to develop it
(browsers, algorithm animation, inspectors, regression
testers, logging tools, ...).
> Humor me for a second with my rough distinction between programming
> and coding.
Well, what *I* look for are executable specifications
of the problem domain. Lisp then provides a notation
for writing down specifications. So the gap
between "programming" and "coding" will approach zero.
To give an example from CL-HTTP's
web walker: What the author did was to create
a language to declare ACTIONS, ACTIVITIES and
CONSTRAINTS in the domain of walking over
graphs of web pages.
Here is an example for an action that
generates a sorted list of inferior pages
from an URL:
W4:DEFINE-ACTION-TYPE name
(type &key (class 'action-type) documentation)
lambda-list
&body body
[macro]
Defines a new type of action named NAME whose type
is TYPE. TYPE can be any of: STANDARD,
OPEN-HTTP-STREAM, ENCAPSULATING, GENERATOR
LAMBDA-LIST is the set of arguments passed to the
action function. The lexical variables ACTION
ACTIVITY URL are available within BODY. When CLASS
is a subtype of encapsulating-action-type, the
continuation that executes the encapsulated actions
is invoked within the action function with
(call-next-action &optional action url activity).
Additionally, the first argument after the standard
action arguments must be the inferior actions
during the allocation process.
(define-action-type
generate-sorted-inferiors
(:generator
:documentation "Primary action for walking the inferiors of a URL."
:class generator-type)
(action activity url predicate)
(declare (ignore action))
(values (stable-sort (url-inferiors-satisfying-activity url activity)
predicate)
t))
If you are developing at this level of sophistication, send in your
resume. ;-)
······@lavielle.com (Rainer Joswig) writes:
> > Totally true, but newcomers may not experience this unless they allow
> > themselves to work in a diffrent way than they may be used too.
> > First, you might need to change your editor,
>
> You mean they were not already using "Emacs"? ;-)
It's hard to believe sometimes, but yah.
> Emacs and Ilisp is not that bad. Actually I think
> some of the integrated environments are *much*
> more productive when you start developing complex
> software (I know that some wizards just stay with
> Emacs). I always tell people that they need to develop
> tools to handle the complexity - having visual tools is
> a way to go for a lot of people. A program should be developed
> in parallel with the tools necessary to develop it
> (browsers, algorithm animation, inspectors, regression
> testers, logging tools, ...).
I've never been one for visual stuff. The only good experience I have
had with Visual development is the MSVC++ debbugger, and that was not
an altogether great experience, just the best visual debugger I've
come across so far. I have not had a chance to look at Digitool's or
Symbolic's work, so I'm aware that my assesment of "visual"
development environment has not yet been exposed to the cream of the
crop.
> > Humor me for a second with my rough distinction between programming
> > and coding.
>
> Well, what *I* look for are executable specifications
> of the problem domain. Lisp then provides a notation
> for writing down specifications. So the gap
> between "programming" and "coding" will approach zero.
That is a more subtle explanation of my notion of the friction of
coding being drastically reduced by Lisp. By providing the domain
language, you reduce the code required until it reaches almost
nothing. Since you build the domain language up, layer upon layer,
you have less coding at each layer. This, in combination with the
speed at which one can rattle off a form in nice lisp environment is
really powerful. And an added bonus for me is that each layer is
interesting to me as a design challenge, so my mind is engaged and
active and not bored with "coding" details. This, to me at least, is
a VERY important bonus, because it gives me a very satisfying feeling
while working.
Having just come off a 6 month project in a non-lisp language, the
things that is most immediate in my mind is the grunt work required to
code in this other language because I could not do the neccesarry
programming to reduce the code required in a significant manner.
Because there was not a real macro system (and for other reasons
inherent in the language we were using) I had to do things like
maintain 3 seperate files describing the same componnent. Had this
been done in Lisp, a domain language for describing these components
would have made me only have to describe them once, in one location,
and that would have saved me many many hours synchronizing and
tracking down inconsistencies between the different views of the
component. This was in a language and environment which is quite
possibly the best that "conventional" environments have to offer for
that task, WebObjects.
The last few days of work with CL-HTTP have been refreshing indeed.
--
Craig Brozefsky <·····@red-bean.com>
Free Scheme/Lisp Software http://www.red-bean.com/~craig
"riot shields. voodoo economics. its just business. cattle
prods and the IMF." - Radiohead, OK Computer, Electioneering
In article <··············@piracy.red-bean.com>, Craig Brozefsky <·····@red-bean.com> wrote:
> I've never been one for visual stuff.
Which is atleast surprising. People have a very strong visual
input channel. Using the visual clues like color, animation,
shape, etc. should be highly desirable to help people
designing software.
> come across so far. I have not had a chance to look at Digitool's or
> Symbolic's work, so I'm aware that my assesment of "visual"
> development environment has not yet been exposed to the cream of the
> crop.
LispWorks also has an integrated environment. The new
ACL on Windows has it, too (although it looks "ugly" to me -
I'm a Mac user, though).
> component. This was in a language and environment which is quite
> possibly the best that "conventional" environments have to offer for
> that task, WebObjects.
Interesting.
> The last few days of work with CL-HTTP have been refreshing indeed.
* Rainer Joswig
| Which is atleast surprising. People have a very strong visual input
| channel. Using the visual clues like color, animation, shape, etc.
| should be highly desirable to help people designing software.
"people" come in many shapes and forms. some people work exceedingly
well with languages and language-based formalisms. other people don't,
and work better with visual clues. some people can rotate 3D images in
their head without effort. others can only do it with great effort.
some people can see patterns emerge in words and text right away, such as
spelling mistakes and particular words they are looking for. others fail
to see such patterns, but see irregularities in shape with an amazing
precision. some would say that some people gravitate towards particular
programming languages and even fields of work based on their differences.
believing that all humans share any particular trait, like having "a very
strong visual input channel" is ignoring the obvious: that few people
find more than a handful of people who think exactly like themselves.
I for one loathe visual "clues" beyond excellent layout. anything beyond
that, especially colors and fonts, cause too much emphasis on stuff I'm
not interested in all the time it's visible. drop all the visual crap,
and I can look at what interests _me_ at that particular time, focusing
on whatever I want to focus on. colorizing code is exactly as out of
place as colorizing parts of speech would have been in written text,
which people who can read don't generally do. I'm sure it could help
kids at some time during their mental development as readers, however.
there is much to be said for information visualization, and indeed much
has been said, but the kind of lame toys that we find that tools that are
designed by people who have read none of the literature use are of help
only to people who couldn't find they way around the language without
them, and it's not a good idea to let such people program to begin with.
#:Erik
--
save the children: just say NO to sex with pro-lifers
Erik Naggum <····@naggum.no> writes:
> [...]
>
> I for one loathe visual "clues" beyond excellent layout. anything beyond
> that, especially colors and fonts, cause too much emphasis on stuff I'm
> not interested in all the time it's visible. drop all the visual crap,
> and I can look at what interests _me_ at that particular time, focusing
> on whatever I want to focus on. colorizing code is exactly as out of
> place as colorizing parts of speech would have been in written text,
> which people who can read don't generally do. I'm sure it could help
> kids at some time during their mental development as readers, however.
>
> [...]
I can understand not wanting code colorized. Colorization leads to
search on the part of the programmer. Want to see where your code
calls 'ERROR'? Visually search for pink text
(`font-lock-warning-face' in EMACS parlance). Information concerning
the purpose, usage, or occurrences of a particular word in code is
best provided in a separate buffer or window - and only when it is
needed.
But what about comments? There are usually two types of text in a
file of LISP code - comments and code (or English and LISP...or
English and English). The code is intended for LISP and for the human
reader. The comments are solely for the human reader (barring any
magic comments). I want to see the difference at a glance and without
thinking about it. That is why I like colorized comments. (They
needn't be glaring and gaudy. A drab color with slightly less
brightness than the code color works best for me.)
--
Samir Barjoud
·····@mindspring.com
······@lavielle.com (Rainer Joswig) writes:
> In article <··············@piracy.red-bean.com>, Craig Brozefsky <·····@red-bean.com> wrote:
>
> > I've never been one for visual stuff.
>
> Which is atleast surprising. People have a very strong visual
> input channel. Using the visual clues like color, animation,
> shape, etc. should be highly desirable to help people
> designing software.
Color and animation crap is no option for me. It scared me away from
computers for a decade.
Klaus Schilling
In article <··············@schilling.cys.de>, Klaus Schilling <·····@schilling.cys.de> wrote:
> ······@lavielle.com (Rainer Joswig) writes:
>
> > In article <··············@piracy.red-bean.com>, Craig Brozefsky <·····@red-bean.com> wrote:
> >
> > > I've never been one for visual stuff.
> >
> > Which is atleast surprising. People have a very strong visual
> > input channel. Using the visual clues like color, animation,
> > shape, etc. should be highly desirable to help people
> > designing software.
>
> Color and animation crap
Hey, how did you escape my killfile?
> is no option for me. It scared me away from
> computers for a decade.
That's strictly your problem.
Craig Brozefsky <·····@red-bean.com> wrote:
+---------------
| Having just come off a 6 month project in a non-lisp language, the
| things that is most immediate in my mind is the grunt work required to
| code in this other language because I could not do the neccesarry
| programming to reduce the code required in a significant manner.
| Because there was not a real macro system (and for other reasons
| inherent in the language we were using) I had to do things like
| maintain 3 seperate files describing the same componnent. Had this
| been done in Lisp, a domain language for describing these components
| would have made me only have to describe them once, in one location,
| and that would have saved me many many hours synchronizing and
| tracking down inconsistencies between the different views of the component.
+---------------
You *can* still do a sort of DEFSYSTEM in Lisp, you know, even if you
have to deliver the project in language "Z". Just go ahead and write --
in Lisp -- meta-code that generates the needed sources in "Z", e.g.,
source code, header files, "i18n" message files, whatever. While it's
in your hands, you'll reap the benefits, and even after maintenance
passes over to "Z-only" coders, with a little care on the formats you
generate it won't be any harder for them to maintain (and may even be
easier! -- because of regularities) than code written directly in "Z".
Aubrey Jaffer (author of SCM) talks a bit about that approach in
<URL:http://www-swiss.ai.mit.edu/~jaffer/scm95-2.html> w.r.t. "Schlep",
a small Scheme-to-C "compiler" (one might almost say "macro-expander"!):
"I almost never write C code directly anymore. I only mess with it
to fix bugs. As with all the code I produce for jobs, the new code
for SCM (the only thing recently has been bignum logical operations)
is generated or at least started from the output of my schlep.scm (41k)
compiler.
"I spent some effort to make Schlep produce formatted C code; Most
programmers I work with are not fluent in Scheme and they have to
be able to understand my code contributions."
Writing such a tool isn't a huge effort. I know, since after using Schlep
for a short while I got fed up with its ad hoc Hungarian type system and
lack of macros (other than builtin forms), and started over from scratch
to do something that provides macros and Common Lisp-like "declare". It's
got a smaller core than Schlep, but is more easily extensible and gives
you access to whatever compile-time Lisp or Scheme you have.
Yes, I'll make what I've done available "soon" (so don't bother asking),
but after looking at Schlep and C & X library interface stub generators
for several Scheme implemenations, as well as what I did, I'm firmly
convinced at this point that this is a case where "re-inventing the wheel"
is the *right* thing to do!! That is, the notion of coding in Lisp or Scheme
to get access to the compile-time facilities (macros, I/O, whatever) but
writing out the target code in language "Z" (or "Z", "Y", & "X", if you
have to keep multiple pieces in sync) is truly a "pattern" (in the Gabriel
sense more than the Gang of Four style) that is best employed by bending &
shaping it to your own needs, not something that should be codified in any
kind of one-size-fits-all "product/library/class".
-Rob
-----
Rob Warnock, 8L-846 ····@sgi.com
Applied Networking http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
1600 Amphitheatre Pkwy. FAX: 650-933-0511
Mountain View, CA 94043 PP-ASEL-IA
In article <·················@inka.de>, ···················@inka.de wrote:
> After this side-step towards flaming could we forget the last mails and
> you just give me an answer on the question which was asked. I said you
> don't have numbers and that you put in you opinion. You opinion might be
> right or wrong, I believe you are possibly more on the right side. And
> yes I do think that Common Lisp is a better choice as C++ ever will and
> can be, just for the record:
It's difficult to get numbers for that. Smalltalk and
Lisp are roughly comparable for a lot of projects - while
Lisp is more expressive and used for a lot more
experimental stuff. Smalltalk projects are sometimes
more conventional OO-projects - just read the various
job ads for Smalltalk.
AT&T/Lucent is/was doing ATM switch projects. They
have systems with software written in C and C++. Usually
these products have a staff of, say, 1000 people.
At any one time only a part of the source code
is understood (people moving in and out).
As a a research project they were developing
a system in Lisp and a production version in
C++. The Lisp project had all in all around, say,
(can't remember the exact numbers) hundred people.
The claim was that after years of development the Lisp-based
project was more functional (on-the-fly updating of software
with zero-downtime was a goal), had comparable performance
and needed much less resources (time, developers, money, ...).
Still it was hard to convince management to make products
based on it (which finally happened). I hear
numbers like *seven* times productivity increase in such
large projects. If you get these results - would you
tell your competition?
Also anecdotical evidence shows that single developers
(the mythical "Lisp hacker") or small teams can
get extremely productive creating complex applications.
I know a few people who are on this wizard level
and it is a worthwile goal to have those girls and boys
in a company and let them be productive and have fun. They often
are choosing Lisp as their tool, because Lisp works
like an *amplifier* for them.
Rainer Joswig wrote:
>
> In article <·················@inka.de>, ···················@inka.de wrote:
>
> > After this side-step towards flaming could we forget the last mails and
> > you just give me an answer on the question which was asked. I said you
> > don't have numbers and that you put in you opinion. You opinion might be
> > right or wrong, I believe you are possibly more on the right side. And
> > yes I do think that Common Lisp is a better choice as C++ ever will and
> > can be, just for the record:
>
> It's difficult to get numbers for that.
That was my opinion and that's what I guess is a fact we're more or less
talking about opinions which make it hard not starting flaming as you
can see. That's not good for anyone.
>
> The claim was that after years of development the Lisp-based
> project was more functional (on-the-fly updating of software
> with zero-downtime was a goal), had comparable performance
> and needed much less resources (time, developers, money, ...).
> Still it was hard to convince management to make products
> based on it (which finally happened). I hear
> numbers like *seven* times productivity increase in such
> large projects. If you get these results - would you
> tell your competition?
I would use Lisp and not drop it. So IMO this means the results weren't
so encouriging.
>
> Also anecdotical evidence shows that single developers
> (the mythical "Lisp hacker") or small teams can
> get extremely productive creating complex applications.
I guess this is a well known fact and if I remember correctly even
Brooks in his "mythycal man month " pointes that out. And if one read
about hacker the same numbers re-occur. But that is not bound to any
language. There are people out there which are 10 times more productive
than the average programmer. So this is not a pro or cons for Lisp.
>They often
> are choosing Lisp as their tool, because Lisp works
> like an *amplifier* for them.
The might like C too ;-)
Regards
Friedrich
Friedrich Dominicus <···················@inka.de> writes:
> Rainer Joswig wrote:
> > The claim was that after years of development the Lisp-based
> > project was more functional (on-the-fly updating of software
> > with zero-downtime was a goal), had comparable performance
> > and needed much less resources (time, developers, money, ...).
> > Still it was hard to convince management to make products
> > based on it (which finally happened). I hear
> > numbers like *seven* times productivity increase in such
> > large projects. If you get these results - would you
> > tell your competition?
>
> I would use Lisp and not drop it. So IMO this means the results weren't
> so encouriging.
I don't understand your second sentence; are you talking about results
that have never been disclosed? Or did I miss some posted results in
this thread?
We have many customers which use lisp in precisely the way Rainer described
it, and some are very quiet about it. When we ask them why they don't
come out and say "lisp inside" in order to promote lisp, they tell us
that it gives them a competitive advantage. Thus they have no incentive
to let people know that they are getting amazing things done with lisp,
let alone how much faster they are doing it in lisp than in other
languages.
This is the reason why it is so hard to get hard numbers on productivity
ratios between languages. But really, only two numbers are really
important anyway: the productivity ratio that you yourself see between
two languages, and the productivity ratio that applies when you have
a team, large or small, on your own projects. If you always work alone,
then the second ratio doesn't apply. Also, if your team is divisive and
contentious, then you won't get the productiviy increases by going to
lisp that are bandied around this NG, because if most of the time is
spent arguing, then the language choice doesn't matter.
> > Also anecdotical evidence shows that single developers
> > (the mythical "Lisp hacker") or small teams can
> > get extremely productive creating complex applications.
>
> I guess this is a well known fact and if I remember correctly even
> Brooks in his "mythycal man month " pointes that out. And if one read
> about hacker the same numbers re-occur. But that is not bound to any
> language. There are people out there which are 10 times more productive
> than the average programmer. So this is not a pro or cons for Lisp.
I agree that an expert programmer can be 10x more productive than a
novice in the same language, but I doubt that there is any language
where anyone but the top guru in the language can be 10x more productive
than an _average_ programmer, i.e. one who knows the language and has
had at least a year's experience (or one which you would hire for an
average programming job in the language).
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
Duane Rettig wrote:
> >
> > I would use Lisp and not drop it. So IMO this means the results weren't
> > so encouriging.
>
> I don't understand your second sentence; are you talking about results
> that have never been disclosed? Or did I miss some posted results in
> this thread?
Rainer wrote that dispite the fact that they seemed to be satisfied with
the Common Lisp solution they dropped it for another solutions. So my
guess was that the results weren't so amazing, becaus otherwise the
should have sticked to Common Lisp.
>
> We have many customers which use lisp in precisely the way Rainer described
> it, and some are very quiet about it. When we ask them why they don't
> come out and say "lisp inside" in order to promote lisp, they tell us
> that it gives them a competitive advantage. Thus they have no incentive
> to let people know that they are getting amazing things done with lisp,
> let alone how much faster they are doing it in lisp than in other
> languages.
This might be true for corporations, but I would expect Lisp-Lovers of
scientists to do some comparisons. But I can't find much about that.
>
> This is the reason why it is so hard to get hard numbers on productivity
> ratios between languages. But really, only two numbers are really
> important anyway: the productivity ratio that you yourself see between
> two languages, and the productivity ratio that applies when you have
> a team, large or small, on your own projects.
The first problem is a bit problematic. You have to know at least that
languages and have done some programming in both of them to be able to
compare that. But how many really know very different languages?
Personally I know quite well the imperetive (or even object-oriented)
side. But my knowledge about declarative programming is not very well
founded. And during my day-work I just use Eiffel and just in spare time
I learn Common Lisp (and Scheme) At the moment I estimate that I can do
5-7 times more in Eiffel than in CL or Scheme. The problem is that I
don't have a larger project in which I intend to use CL. But
nevertheless I will try to learn it, it has given me completly new
insights in how programs can be build. And I'm quite sure that that will
help me on my all-day work even while using a non-declarative language.
So I win anyway;-)
> If you always work alone,
> then the second ratio doesn't apply. Also, if your team is divisive and
> contentious, then you won't get the productiviy increases by going to
> lisp that are bandied around this NG, because if most of the time is
> spent arguing, then the language choice doesn't matter.
Good point. Just if the argument is that one is x times more productive
in Lisp than in any other language I think I'm allowed to ask for
numbers.
>
> I agree that an expert programmer can be 10x more productive than a
> novice in the same language, but I doubt that there is any language
> where anyone but the top guru in the language can be 10x more productive
> than an _average_ programmer, i.e. one who knows the language and has
> had at least a year's experience (or one which you would hire for an
> average programming job in the language).
Big problem: what is an average programmer. And who can be called an
excellent programmer. I can't tell where I am, but I think I'm a bit
over average in Eiffel programming and far below average in Common Lisp.
I find my way through C, Python, Modula-2 but I think I'M at best on
average there.
The problem is how to define an average programmer. And does someone
like that still exists? What makes and programmer outstanding? It very
depends on what you honor.
My personal benchmark is programming for maintainability. But other
goals are as good or bad. I'm just thinking that more time is spend in
maintenance than in any other aspect of programming, this should IMO be
as good as possible. Maybe that's a reason why I love Eiffel and start
to like Common Lisp. I thing especially Common Lisp is extremly good in
that. I guess Common Lisp experts will agree. But again this is my
opinion.
Regards
Friedrich
In article <·················@inka.de>,
Friedrich Dominicus <···················@inka.de> writes:
> Duane Rettig wrote:
>
>> >
>> > I would use Lisp and not drop it. So IMO this means the results weren't
>> > so encouriging.
>
>
>>
>> I don't understand your second sentence; are you talking about results
>> that have never been disclosed? Or did I miss some posted results in
>> this thread?
>
> Rainer wrote that dispite the fact that they seemed to be satisfied with
> the Common Lisp solution they dropped it for another solutions. So my
> guess was that the results weren't so amazing, becaus otherwise the
> should have sticked to Common Lisp.
Is there a language problem? I read in Rainer's article that "despite
[much better behavior of the Lisp based product] it was hard to convince
management to make products based on it (which finally happened)". I
conclude from that phrase that it was not dropped. The obstacles were
not technical, but a frequent management attitude. So I still don't
understand your point.
> ...
--
Hartmann Schaffer
It is better to fill your days with life than your life with days
In article <·················@inka.de>, ···················@inka.de wrote:
> Rainer wrote that dispite the fact that they seemed to be satisfied with
> the Common Lisp solution they dropped it for another solutions. So my
> guess was that the results weren't so amazing, becaus otherwise the
> should have sticked to Common Lisp.
Read more carefully. It was a research project and they developed
a lot of technology ***and*** they delivered a large ATM switch
where the software is/was written in Lisp. So the Lisp
thing became a product.
> This might be true for corporations, but I would expect Lisp-Lovers of
> scientists to do some comparisons. But I can't find much about that.
Because these comparisons are very difficult. I haven't even seen
other languages compared (productivity-wise) in a satisfying
way.
I think you are on your own to make up your mind.
> The first problem is a bit problematic. You have to know at least that
> languages and have done some programming in both of them to be able to
> compare that. But how many really know very different languages?
I don't know - but in computer science education you are
supposed to learn the concepts and to be able to do
comparisons on your own.
Rainer Joswig wrote:
>
> In article <·················@inka.de>, ···················@inka.de wrote:
>
> > Rainer wrote that dispite the fact that they seemed to be satisfied with
> > the Common Lisp solution they dropped it for another solutions. So my
> > guess was that the results weren't so amazing, becaus otherwise the
> > should have sticked to Common Lisp.
>
> Read more carefully. It was a research project and they developed
> a lot of technology ***and*** they delivered a large ATM switch
> where the software is/was written in Lisp. So the Lisp
> thing became a product.
Thanks for correcting that.
>
> > This might be true for corporations, but I would expect Lisp-Lovers of
> > scientists to do some comparisons. But I can't find much about that.
>
> Because these comparisons are very difficult. I haven't even seen
> other languages compared (productivity-wise) in a satisfying
> way.
I agree completly but nevertheless I would really like to see such
things. There are so much comparisons but we don't have very much at
hand about the Software tools here.
>
> I think you are on your own to make up your mind.
I've done so. But I really would like to avoid prejudice for the next
things I'll learn. This prejudice about Lisp lead me to the conclusion
not even to give it a try in the past. That is not a very good founded
reason I admit.
>
> I don't know - but in computer science education you are
> supposed to learn the concepts and to be able to do
> comparisons on your own.
See my replies to this thread. I hadn't heard or learned anything about
that during my studying. One of the main points of my study was computer
science ...
So much about bias ;-)
Regards
Friedrich
* Friedrich Dominicus
| Rainer wrote that dispite the fact that they seemed to be satisfied with
| the Common Lisp solution they dropped it for another solutions. So my
| guess was that the results weren't so amazing, becaus otherwise the
| should have sticked to Common Lisp.
this is so obviously invalid "reasonsaing" that it is becoming ever
clearer that you have an agenda against Common Lisp.
the choice of programming language is not a static, blind choice. in
some cases, a system may evolve in Common Lisp because it is very hard
figure out exactly how it should work. if and when it settles down and
one might want to sell it to others in a similar bind as yourself, you
face different requirements that have nothing to do with the language,
and it may be very expensive to do stuff like producing runtime versions
for all the platforms your customers might want it on. if your customers
want source access (which is usual if you aren't too big a provider), you
may also face a requirement to use a more popular language.
| This might be true for corporations, but I would expect Lisp-Lovers of
| scientists to do some comparisons. But I can't find much about that.
the problem is how to trust such comparisons. scientifically-minded
people understand such problems.
| Just if the argument is that one is x times more productive in Lisp than
| in any other language I think I'm allowed to ask for numbers.
no, if you don't accept empirical evidence, you aren't allowed to ask,
either. and as long as you continue to doubt without reason, nobody can
ever hope to answer your question, because it is dishonest, simply a
means to deny that which you cannot deny yourself, either.
#:Erik
--
save the children: just say NO to sex with pro-lifers
Erik Naggum wrote:
>
> * Friedrich Dominicus
> | Rainer wrote that dispite the fact that they seemed to be satisfied with
> | the Common Lisp solution they dropped it for another solutions. So my
> | guess was that the results weren't so amazing, becaus otherwise the
> | should have sticked to Common Lisp.
>
> this is so obviously invalid "reasonsaing" that it is becoming ever
> clearer that you have an agenda against Common Lisp.
>
Rainer corrected that and stated that it become a product. So the didn't
drop Common Lisp. My fault sorry.
>
> | This might be true for corporations, but I would expect Lisp-Lovers of
> | scientists to do some comparisons. But I can't find much about that.
>
> the problem is how to trust such comparisons. scientifically-minded
> people understand such problems.
I think that's very true. Just I expect a bit objectivity from
scientists. But maybe this it is really very problematic to run such
comparisons. Just I would found it very helpful.
>
> | Just if the argument is that one is x times more productive in Lisp than
> | in any other language I think I'm allowed to ask for numbers.
>
> no, if you don't accept empirical evidence, you aren't allowed to ask,
> either.
Even for empirical evidence you need some opinions. I read three of
them. From Rainer, from you and from s.o who started learning Ccommon
Lisp and of course what I learned during that discussion and while
learning Common Lisp for myself.
And there are some nice things called sucks/rocks statistics. Because a
lot of different opinons are filterd out I think one gets a somewhat
better impression.
E.g I read about Python, Perl and some other languages (I don't know if
Lisp was included) but there were very much pros for Perl. So this shows
me that a lot of people like Perl and I guess the same is true for
Common Lisp. This is IMO empirical evidence.
> and as long as you continue to doubt without reason, nobody can
> ever hope to answer your question, because it is dishonest, simply a
> means to deny that which you cannot deny yourself, either.
I just asked for some comparisons. But there aren't. So I can't take a
look at results. I guess that is reason enought to be very cautious
about mentioned things. I learned that while beeing an enthusiastic
Eiffel programmer. If you point out weakness of that language you and
other find out and get very intolerant answers you'll learn to take
anything which comes from that one with more than a grain of salt.
Intolerance is not a good guide in any business.
Regards
Friedrich
In article <·················@inka.de>,
Friedrich Dominicus <···················@inka.de> writes:
> ...
> Eiffel programmer. If you point out weakness of that language you and
> other find out and get very intolerant answers you'll learn to take
Like in probably any other human endeavor, programming has its share of
religious nuts. Unfortunately, this can show in several ways, among
them:
- the symptom tou describe above
- declaring everything(?) you are not accustomed to a weakness which can
produce reactions that can be confused with the first point
> anything which comes from that one with more than a grain of salt.
> Intolerance is not a good guide in any business.
--
Hartmann Schaffer
It is better to fill your days with life than your life with days
* Friedrich Dominicus
| Intolerance is not a good guide in any business.
there are some things towards which people should show no tolerance
whatsoever. I have two such things: incompetence and carelessness. I'm
amazed that you not only want to tolerate them, but actively promote such
flaws, and even more emazed that you get encouraged in your endeavor by
intolerant reactions to your actions. but at least this explains your
grinning, which has puzzled me for some time. thank you for that data.
#:Erik
--
save the children: just say NO to sex with pro-lifers
Erik Naggum wrote:
>
> * Friedrich Dominicus
> | Intolerance is not a good guide in any business.
>
> there are some things towards which people should show no tolerance
> whatsoever. I have two such things: incompetence and carelessness.
I guess we're now drifting towards total off-topic. I guess there are
some different kinds of incompetence and carelessness. So you might
even have toi be tolerant to incompetent people. Of course just to soime
extend. I guess I extended beyond ;-)
> I'm
> amazed that you not only want to tolerate them, but actively promote such
> flaws, and even more emazed that you get encouraged in your endeavor by
> intolerant reactions to your actions. but at least this explains your
> grinning, which has puzzled me for some time.
It amazed me that you can't forgot a word. I guess that is what you
understand under carelessness. I though you were intolerant but you
were thinking I'm careless. So it has been quite a good example of a
misunderstanding. But for me the stuff is through.
Regards
Friedrich
Friedrich Dominicus wrote:
...
> > Also anecdotical evidence shows that single developers
> > (the mythical "Lisp hacker") or small teams can
> > get extremely productive creating complex applications.
>
> I guess this is a well known fact and if I remember correctly even
> Brooks in his "mythycal man month " pointes that out. And if one read
> about hacker the same numbers re-occur. But that is not bound to any
> language. There are people out there which are 10 times more productive
> than the average programmer. So this is not a pro or cons for Lisp.
Come on, if you have read the MMM, you really should not think that a
good choice of tools does not influence productivity. It seems you have
intepreted the comment above as meaning "exceptionally talented
developers can get extremely productive" rather than "Lisp developers
can get extremely productive". Or did you mean to imply that the two
groups are identical? :-)
You were right to refer to MMM, but you have drawn the exact opposite
conclusion. If you are talented, *and* you use a tool of superior
productivity, then the small team efficiency will skyrocket, fueled by
both the multiple of your talent and the tool's productivity.
Think of the surgeon analogy in the book: if the lead doctor is say 4
times more productive as a result of the choice of tools, maybe one team
can do what would otherwise be done by 6-8 teams, and this is true
irrespective of how talented the doctor is, as long as his tools
facilitate the 4x productivity increase.
Of course, there may be people to whom a more sophisticated tool brings
no benefit or maybe even decreased productivity, but it just reveals the
disconnect between the capability of those people and the community the
tool is intended for.
Take care
Robert
Robert Monfera wrote:
>
> Friedrich Dominicus wrote:
> ...
> > > Also anecdotical evidence shows that single developers
> > > (the mythical "Lisp hacker") or small teams can
> > > get extremely productive creating complex applications.
> >
> > I guess this is a well known fact and if I remember correctly even
> > Brooks in his "mythycal man month " pointes that out. And if one read
> > about hacker the same numbers re-occur. But that is not bound to any
> > language. There are people out there which are 10 times more productive
> > than the average programmer. So this is not a pro or cons for Lisp.
>
> Come on, if you have read the MMM, you really should not think that a
> good choice of tools does not influence productivity.
This is clear. But that lead to another discussion. The anser was in
respond to the opinion that one is x-times more productive with Lisp
than with C++. I don't believe that. You have a millions tools for C++,
because of the weaknesses of the language, but if you use them well you
can't say any longer that you are more productive with Lisp + Tools.
>It seems you have
> intepreted the comment above as meaning "exceptionally talented
> developers can get extremely productive" rather than "Lisp developers
> can get extremely productive". Or did you mean to imply that the two
> groups are identical? :-)
The first holds and that was what I wrote.
>
> You were right to refer to MMM, but you have drawn the exact opposite
> conclusion. If you are talented, *and* you use a tool of superior
> productivity, then the small team efficiency will skyrocket, fueled by
> both the multiple of your talent and the tool's productivity.
That's a good point but that is what I tried to state clear whole the
time. The fact that you are more productive with Common Lisp is just
stated as an opinion here and of course that is no suprise, we're in
comp.lang.lisp. But nobody can point out some figures. There are
personal opinions and BTW I think that you are more productive with
Common Lisp than C++ maybe even Eiffel (which in fact I know a bit).
Just that is my personal opinion. I don't have numbers too. And I had a
really hard time to learn the basics of Common Lisp. It's wasn't all to
clear to me. I sometimes get the impression I would not learn it at all.
But I tried again.
So personally for me I think it would be easier to learn C++ than Common
Lisp. I have some background in C and I think I know quite well Eiffel.
So from the C-side I can use what I want about syntax and from Eiffel
what I know about object-oriented programming. There was nothing to
build on for Common Lisp. But I guess with some more programming I'll
get it better over time.
>
> Think of the surgeon analogy in the book: if the lead doctor is say 4
> times more productive as a result of the choice of tools, maybe one team
> can do what would otherwise be done by 6-8 teams, and this is true
> irrespective of how talented the doctor is, as long as his tools
> facilitate the 4x productivity increase.
I agree.
>
> Of course, there may be people to whom a more sophisticated tool brings
> no benefit or maybe even decreased productivity, but it just reveals the
> disconnect between the capability of those people and the community the
> tool is intended for.
I would like to express it this way. If you are a good or even excellent
programmer using imperative languages you will decrease productivity
enormous while switching to declarative programming. The question is how
long does that take and will you then outrock your old programming
style.
My opinion can be read in nearly any thread I participate. I do think it
is a very good idea for any programmer to learn at least on language for
declarative programming. But I think the other way round is true too.
One who used to programm in a declarative language should learn one
imperative language too. Both styles have there merits and problems.
And as you wrote above the right tool makes a difference. So you should
better know some tools.
Regards
Friedrich
* Friedrich Dominicus
| The anser was in respond to the opinion that one is x-times more
| productive with Lisp than with C++. I don't believe that. You have a
| millions tools for C++, because of the weaknesses of the language, but if
| you use them well you can't say any longer that you are more productive
| with Lisp + Tools.
what _would_ make you "believe"? if I have gauged you right, you never
will, no matter what anyone tries to do to answer your questions. what I
don't understand is why you have this vested interest in C++. or is it a
vested interest in knocking Lisp?
| The fact that you are more productive with Common Lisp is just stated as
| an opinion here and of course that is no suprise, we're in
| comp.lang.lisp.
this indicates that you think people choose languages blindly, and then
defend them blindly, which is indeed highly indicative of your opinions
and your treatment of those who disagree with you and try to answer your
questions. it may be true of C++, and it seems it is, but it is not true
or Lisp. people choose Lisp because they have begun to think about some
big issues in programming computers, and because they want to be more
efficient and productive as programmers and systems builders. people
just don't pretend to know Common Lisp because they can get high-paying
jobs that way. you can actually trust someone who says he knows Common
Lisp. imagine trusting someone in the computer business, Friedrich.
| So personally for me I think it would be easier to learn C++ than Common
| Lisp.
that could well be. some people have a very hard time with the simple
and straight-forward. I have seen C++ programmers purposefully write
extremely ugly code in Common Lisp because they wanted "performance", but
they had no actual idea whether their ugly code was better in that regard
-- it was important that it looked "dense" and used a lot of "primitives"
and they cared about milliseconds, but forgot the seconds: a clean
rewrite of their code (with a few declarations) gained a factor 10 on
their code, which they had been micro-optimizing for a week.
| If you are a good or even excellent programmer using imperative languages
| you will decrease productivity enormous while switching to declarative
| programming. The question is how long does that take and will you then
| outrock your old programming style.
people who fear new things will generally behave this way. those who
enjoy them very much won't even understand why you would measure any sort
of _productivity_ during a learning phase. most people learn Common Lisp
on the side and get paid doing other work until they feel competent to go
public with it. then they might surreptiously start using it to gain an
advantage on their peers, such as prototyping, automatic code generation,
code maintenance tools, etc. people do this in Emacs Lisp, too, if they
use Emacs. some people, however, insist on writing all the code manually
and will never trust machine-generated code (except perhaps compilers).
distrust of other people generally comes with distrust of their tools.
#:Erik
--
save the children: just say NO to sex with pro-lifers
Erik Naggum wrote:
>
> * Friedrich Dominicus
> | The anser was in respond to the opinion that one is x-times more
> | productive with Lisp than with C++. I don't believe that. You have a
> | millions tools for C++, because of the weaknesses of the language, but if
> | you use them well you can't say any longer that you are more productive
> | with Lisp + Tools.
>
> what _would_ make you "believe"? if I have gauged you right, you never
> will, no matter what anyone tries to do to answer your questions. what I
> don't understand is why you have this vested interest in C++. or is it a
> vested interest in knocking Lisp?
I would say that people are obviously less productive with LISP because
instead of working they have to spend all of their time flaming C++ and
advocating LISP instead fo writing useful apps... or does that just
apply to YOU?
You can take this to personal mail, it degenerated into a flame war
about 12 messages ago, and I doubt anyone really cares anymore but you.
CU
Dobes
* Dobes Vandermeer
| I would say that people are obviously less productive with LISP because
| instead of working they have to spend all of their time flaming C++ and
| advocating LISP instead fo writing useful apps... or does that just apply
| to YOU?
the persistence among some of the stupider people on this newsgroup to
make wild claims about issues they have no _possible_ way of knowing is
alarming. why can't people just confine themselves to discuss what they
_can_ know something about? surely, you can find something to attack in
what I _have_ said or done, instead of having to _invent_ what you attack
me for. every time I see idiots attack an obvious invention of their own
mind that they want to be me, I have to wonder whether I do nothing wrong
at all, and that seems fairly unlikely, but at least it's good to see
that even the most hostile idiots around can't find an _actual_ flaw.
#:Erik
--
save the children: just say NO to sex with pro-lifers
Erik Naggum wrote:
>
> * Friedrich Dominicus
> | The anser was in respond to the opinion that one is x-times more
> | productive with Lisp than with C++. I don't believe that. You have a
> | millions tools for C++, because of the weaknesses of the language, but if
> | you use them well you can't say any longer that you are more productive
> | with Lisp + Tools.
>
> what _would_ make you "believe"? if I have gauged you right, you never
> will, no matter what anyone tries to do to answer your questions. what I
> don't understand is why you have this vested interest in C++. or is it a
> vested interest in knocking Lisp?
I think that you're right but I don't think that there are comparisons
out there. And I'm surely not interested in Common Lisp. If I would, why
should I try to learn it? Just for the fun? I suggest to anyone who uses
imperative languages (like C++ is) to learn at least one declarative
language as Common Lisp is. That is my opinion. I hardly would think so
if I tried to know down Lips.
>
> | The fact that you are more productive with Common Lisp is just stated as
> | an opinion here and of course that is no suprise, we're in
> | comp.lang.lisp.
>
> this indicates that you think people choose languages blindly, and then
> defend them blindly, which is indeed highly indicative of your opinions
> and your treatment of those who disagree with you and try to answer your
> questions.
I don't think that people choose their favourite language blindly. But I
expect of course a bit bias in a group which deals with that language.
This hold for any group I know. You hardly will find someone in
comp.lang.eiffel who would say Eiffel is a bad language. But that are
opinions and it's terrible difficult to discuss opinions witout numbers.
That't a problem for all languages.
>imagine trusting someone in the computer business, Friedrich.
I like to talk (or write) to people about the different topics. I was
(and surely am biases) about Common Lisp as for any language I know.
First I thought about how terrible the braces are and that keeped me
away from trying to learn Lisp. That was a shame. I think I overcome
this (lucky as I am ;). And now I think it was one of my better ideas to
learn Lisp. I'm now just a bit angry that during my student time (now
some years ago) we never heard something of functional programming, and
or course there wasn't any course about lisp of functional programming.
You learned nice things about van Neumans maschines who things are
stored in registers and the like but nothing about other approaches to
programming than what C was.
And the courses I take about Software Engineering and correctness of
programs just talk about proves to imperative style of programs. And
such not so nice stuff like waterfall-modell etc etc. But imaging
nothing about other approaches. This influences me of course.
>
> | If you are a good or even excellent programmer using imperative languages
> | you will decrease productivity enormous while switching to declarative
> | programming. The question is how long does that take and will you then
> | outrock your old programming style.
>
> people who fear new things will generally behave this way. those who
> enjoy them very much won't even understand why you would measure any sort
> of _productivity_ during a learning phase.
You're right, and that's what I'm trying.
> some people, however, insist on writing all the code manually
> and will never trust machine-generated code (except perhaps compilers).
> distrust of other people generally comes with distrust of their tools.
>
Good point. Just a short note on this. In comp.lang.c I suggested
introducing Garbage Collection and some kind of assertions like I knew
them in Eiffel. I guess you can imaging the answers ...;-)
But is it just distrust isn't it a bit the feeling of beeing in total
control of the development or the machine? I can't tell. Just I get more
and more the impression that the choice of language has much to do with
what you have as goal. E.g. the C-lovers seem to put speed above
anything else. The Common-Lisp lovers maybe flexibilty? For Eiffel it
seemed to be maintainability.
But please take the last comments with a grain (or more;-) of salt. It's
just my impression I get while reading that groups. I guess Lisp-lovers
can put in some better points.
Best regards
Friedrich
* Friedrich Dominicus
| I don't think that people choose their favourite language blindly. But I
| expect of course a bit bias in a group which deals with that language.
| This hold for any group I know. You hardly will find someone in
| comp.lang.eiffel who would say Eiffel is a bad language.
well, you find of people here who think Lisp is a bad language, and it's
a problem that they can't leave Lisp alone, but have to post lots of
inappropriate drivel. I think you're mistaking a language newsgroup for
an .advocacy newsgroup, but that may be easy to explain: c.l.l.advocacy
doesn't exist, so some people think this is where they should do that
kind of stuff, but it is very seldom that you see people talk about such
things until somebody comes along and makes incorrect or unsupported
negative claims about Lisp. since this happens with alarming frequency,
you might be confused about the newsgroup dynamics.
#:Erik
--
save the children: just say NO to sex with pro-lifers
Erik Naggum wrote:
>
> * Friedrich Dominicus
> | I don't think that people choose their favourite language blindly. But I
> | expect of course a bit bias in a group which deals with that language.
> | This hold for any group I know. You hardly will find someone in
> | comp.lang.eiffel who would say Eiffel is a bad language.
>
> well, you find of people here who think Lisp is a bad language, and it's
> a problem that they can't leave Lisp alone, but have to post lots of
> inappropriate drivel.
Possibly I add my stuff to that. So I'll try to avoid that in the
future. Just one question. Where will you find advice if not in the
appropriate news-group?
>since this happens with alarming frequency,
> you might be confused about the newsgroup dynamics.
I think I learned my lesson. Next time I come up with questions about
Common Lisp and not comparisons.
Regards
Friedrich
In article <·················@inka.de>, ···················@inka.de wrote:
> This is clear. But that lead to another discussion. The anser was in
> respond to the opinion that one is x-times more productive with Lisp
> than with C++. I don't believe that. You have a millions tools for C++,
> because of the weaknesses of the language, but if you use them well you
> can't say any longer that you are more productive with Lisp + Tools.
How do you beat rock solid interactive environments like
the ones that are available for Common Lisp? How do you beat
a language where the cost of the change in your code is often
proportional to the size of the change (to cite Jim Veitch)?
In C++ often the cost of a change is proportional to the size
of the *program*.
Even a simple feature like that generic functions are not
bound to classes is huge productivity boost. Or that
classes are first class objects. You need
less workarounds ("patterns") because of expressivity problems
in your language.
> That's a good point but that is what I tried to state clear whole the
> time. The fact that you are more productive with Common Lisp is just
> stated as an opinion here and of course that is no suprise, we're in
> comp.lang.lisp.
Well, you can also abstract similar experiences Smalltalk people
have - since for a lot of areas both are very similar
(strong OOP facilities, interactive environments, ...).
> So personally for me I think it would be easier to learn C++ than Common
> Lisp. I have some background in C and I think I know quite well Eiffel.
I have learned first languages like Basic, UCSD Pascal, Vax Pascal,
6502 assembler, VAX assembler, Modula 2, etc. Lisp was very easy to learn.
> So from the C-side I can use what I want about syntax and from Eiffel
> what I know about object-oriented programming.
Sorry, but there is a lot more about OOP in Common Lisp than
you have in Eiffel. I guess once you start to look a bit
deeper into things like CLOS (or other stuff I'm to lazy to mention)
you might get the idea that you don't know *that* much about
OOP just from knowing Eiffel. Eiffel gives you only one
(IMHO not too sophisticated) way to do OO-stuff. Common Lisp
gives you ten ways.
Rainer Joswig wrote:
>
> In article <·················@inka.de>, ···················@inka.de wrote:
>
> > This is clear. But that lead to another discussion. The anser was in
> > respond to the opinion that one is x-times more productive with Lisp
> > than with C++. I don't believe that. You have a millions tools for C++,
> > because of the weaknesses of the language, but if you use them well you
> > can't say any longer that you are more productive with Lisp + Tools.
>
> How do you beat rock solid interactive environments like
> the ones that are available for Common Lisp? How do you beat
> a language where the cost of the change in your code is often
> proportional to the size of the change (to cite Jim Veitch)?
> In C++ often the cost of a change is proportional to the size
> of the *program*.
I do not know about either Common Lisp or C++ to argument about that. I
hope you don't over-estimate the quality of Common Lisp and
underestimate the cleverness of C++ tool Vendors. ;-)
>
> Even a simple feature like that generic functions are not
> bound to classes is huge productivity boost. Or that
> classes are first class objects. You need
> less workarounds ("patterns") because of expressivity problems
> in your language.
I think this is a good point.
>
> Well, you can also abstract similar experiences Smalltalk people
> have - since for a lot of areas both are very similar
> (strong OOP facilities, interactive environments, ...).
You're right of course, there is a thread in comp.object about that;-)
>
> > So personally for me I think it would be easier to learn C++ than Common
> > Lisp. I have some background in C and I think I know quite well Eiffel.
>
> I have learned first languages like Basic, UCSD Pascal, Vax Pascal,
> 6502 assembler, VAX assembler, Modula 2, etc. Lisp was very easy to learn.
For me starting was really difficult. But I think I'll get it sometime
in the future, thanks to this group and comp.lang.scheme.
>
> > So from the C-side I can use what I want about syntax and from Eiffel
> > what I know about object-oriented programming.
>
> Sorry, but there is a lot more about OOP in Common Lisp than
> you have in Eiffel. I guess once you start to look a bit
> deeper into things like CLOS (or other stuff I'm to lazy to mention)
> you might get the idea that you don't know *that* much about
> OOP just from knowing Eiffel.
This might be true but for I guess C++ and Eiffel are somewhat more
simular than C++/Common Lisp or Eiffel/Common Lisp
> Eiffel gives you only one
> (IMHO not too sophisticated) way to do OO-stuff.
It's your opinion, I disagree (of course) because I think Eiffel is one
of the better OO-languages. But hey I'm biased;-)
> Common Lisp
> gives you ten ways.
Is that now a pro or a cons;-)
Regards
Friedrich
In article <················@inka.de>, ···················@inka.de wrote:
> > Eiffel gives you only one
> > (IMHO not too sophisticated) way to do OO-stuff.
>
> It's your opinion, I disagree (of course) because I think Eiffel is one
> of the better OO-languages. But hey I'm biased;-)
Well, Eiffel has many small variations on the theme of OO
(like "renaming") otherwise it's very similar to, say, Object Pascal.
Control Flow for example is still imperative.
On top of Common Lisp you find many *big* variations
of OO (actors, prototype-based systems, frame systems,
semantic networks, logic-based systems, agents, ...)
and it has extremely general (pro or cons?) OO-support through CLOS
with CLOS in CLOS in several implementations. CLOS thus opens
a design space for object-oriented programming languages.
> > Common Lisp
> > gives you ten ways.
> Is that now a pro or a cons;-)
Depends.
You may also want to consult the Hacker's dictionary for the term
"bondage-and-discipline language"
http://www.tuxedo.org/~esr/jargon/html/entry/bondage-and-discipline-language.html
Rainer Joswig
······@lavielle.com (Rainer Joswig) writes:
> You may also want to consult the Hacker's dictionary for the term
>
> "bondage-and-discipline language"
>
> http://www.tuxedo.org/~esr/jargon/html/entry/bondage-and-discipline-language.html
bondage-and-discipline language n.
A language (such as [4]Pascal, [5]Ada, APL, or Prolog) that, though
ostensibly general-purpose, is designed so as to enforce an author's
theory of `right programming' even though said theory is demonstrably
inadequate for systems hacking or even vanilla general-purpose
programming. [...]
Hmmm. I will rise to the bait.
With Ada at least, I would correct this and say it enforces the *programmer's*
theory of right programming. But that is the whole point isn't it?
I continually see Ada and its strong typing as being slagged as fascist, etc.,
as if programmers must do contortions to get anything useful done with it.
What many people fail to realize is that one is not fighting the compiler per
se, but rather their own confused abstractions.
The real work in an Ada program is to specify your abstractions at a rich
enough level so that the compiler can enforce them and flag as errors those
times when they are not adhered to. That is, the compiler enforces *your*
abstractions. If there is something one finds difficult to do, one does not
hack the type system, but instead improves their abstractions.
This up front work pays off in spades when one as a large system whose pieces,
created by many different people, must fit together. The strong typing in the
language allows tools (i.e. the compiler) to catch routine mistakes.
Now, being in a lisp newsgroup, I must stress that I greatly appreciate the
dynamic languages, and lisp is right up there in my list of favourite
languages. It is just that I see the need to defend the use of static and
strongly typed languages.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
·····@infomatch.com The Rhythm has my soul.
Friedrich Dominicus wrote:
> This might be true but for I guess C++ and Eiffel are somewhat more
> simular than C++/Common Lisp or Eiffel/Common Lisp
So there's no point in getting into C++ if you're enlightened enough to be doing
Eiffel already.
But Common Lisp is orders of magnitude more about doing things the right way
than C++.
Who is "more similar" then?
>
> But Common Lisp is orders of magnitude more about doing things the right way
> than C++.
> Who is "more similar" then?
My completly biased opinion Eiffel /CL ;-)
Very nice answer, I think it is allowed to smile brightly ;-))
Friedrich
Frederich wrote:
> > So personally for me I think it would be easier to learn C++ than Common
> > Lisp. I have some background in C and I think I know quite well Eiffel.
>
>
> > So from the C-side I can use what I want about syntax and from Eiffel
> > what I know about object-oriented programming.
To which Rainer replied
> Sorry, but there is a lot more about OOP in Common Lisp than
> you have in Eiffel. I guess once you start to look a bit
> deeper into things like CLOS (or other stuff I'm to lazy to mention)
> you might get the idea that you don't know *that* much about
> OOP just from knowing Eiffel. Eiffel gives you only one
> (IMHO not too sophisticated) way to do OO-stuff. Common Lisp
> gives you ten ways.
Eiffel was the first language other than Basic I learnt. It's accompanied
with a lot of propaganda about how it's the "purest" OO language. Of course
this is rot. Arguably there is no such single thing as OO - dynamically
typed OO languages and statically typed OO languages are very different
creatures. The programming styles that suit statically typed OO languages
like Eiffel and C++ would be a complete mismatch for Lisp, Smalltalk, or
Python. Despite Eiffel's heavy OO propaganda, it's OO is extremely primitive
compared to any of the major dynamically typed languages.
Jonathan Coupe
Rainer Joswig wrote:
> AT&T/Lucent is/was doing ATM switch projects. They
> have systems with software written in C and C++. Usually
> these products have a staff of, say, 1000 people.
> At any one time only a part of the source code
> is understood (people moving in and out).
> As a a research project they were developing
> a system in Lisp and a production version in
> C++. The Lisp project had all in all around, say,
> (can't remember the exact numbers) hundred people.
A very interesting example indeed. It reminds me of the telecom software
at Ericsson developed in Erlang and which ultimately was released
as a product (though nobody advertised the use of Erlang, except
on the ... functional programming languages' web site)
Marc
>....... And
>yes I do think that Common Lisp is a better choice as C++ ever will and
>can be, just for the record: we don't have comparisons and because we
>doN't have we just are guessing. That's quite ok but I personally think
>that it would be a good idea having some comparisons.
>
>1) Ease of learning (on different levels)
>2) Development Effort
>3) Maintenance costs
>4) Tool support
>
The only productivity comparison I've seen published between programmers
who use Lisp and those who use C++ was in Richard P. Gabriel's essay,
"Productivity: Is there a silver bullet?" Gabriel reckons that "Lisp/CLOS
provides a factor of 1.5 to 4 in productivity over C/C++. I (Gabriel)
based this on my personal experience with large projects --- in both
Lisp and C++ --- but I did not perform rigorous measurements."
I would tend to place more faith in empirical statements like Gabriel's than
in studies that claim to be objective.
I think the productivity gap has less to do with language differences than
with different approaches to problem solving. In Lisp, we see the general
direction of a solution subconsciously --- and we take concrete steps to
reach it. With C++, programming is reduced to a translation of design
notation to language code; misconceptions require programmers to
revisit the design rather than immediately amend the code. I also think
there's a tendency for C++ programmers to take software engineering
too seriously.
I know that's a terrible thing to say - it implies that software engineering
is mumbo-jumbo. I've been reading this book, "Software Engineering:
A Practitioner's Approach" by Roger Pressman, off and on. Some parts
are ok, especially those that describe team management. But vast
tracts are unreadable and sometimes I'll read stuff that makes me
laugh and laugh i.e. "Cyclomatic complexity is a software metric that
provides a quantitative measure of the logical complexity of a program..."
(pages and pages of networks and graphs follow).
Well, anyway, I think that It would be more interesting to compare Lisp with
Smalltalk rather than C++.
-Vinodh
* Friedrich Dominicus
| So I suggest you calm down and think about the real question
the real question is how to wipe the grin off your face the next time
your attitude affects anyone who tries to answer you. since I have no
idea what motivates you besides posting moronic drivel while grinning, I
have no motivation to answer your questions. you see, Friedrich, here on
USENET, good-will is bartered between those who discuss things. you have
used up all the good-will I could possibly have had towards a stranger.
enjoy the other answers to your questions, and _try_ not to be a moron.
#:Erik
--
save the children: just say NO to sex with pro-lifers
Erik Naggum wrote:
>
> * Friedrich Dominicus
> | So I suggest you calm down and think about the real question
>
> the real question is how to wipe the grin off your face the next time
> your attitude affects anyone who tries to answer you.
Now come on Eric. What does that have to do with the question. I
explained why I was grining it was because of the fact that I see you
answer a way that anyone else whos not using Common Lisp is an idiot.
And about such a thing I can't anything else btu grining. I apologize
for that words and now, I won't talk about it again. If you don't take
that it's up to you.
> you see, Friedrich, here on
> USENET, good-will is bartered between those who discuss things. you have
> used up all the good-will I could possibly have had towards a stranger.
> enjoy the other answers to your questions, and _try_ not to be a moron.
I'm so much moron as you are Eric. I was polite, I apologzize for thinks
I've written and you can't stop. See the following ups to the flaming
and you'll see that I don't get on nerves of other just yours. And
that's partly up to you. Because you have just written about ancedotes,
I just pointed that out in a ironic way, which you did not get right. So
I guess that was a bad idea, next time I won't try again.
Have a nice day
Friedrich
* Friedrich Dominicus
| Now come on Eric. What does that have to do with the question.
now you act as if you have a right to answers to your questions and act
as if you don't even understand that I should treat you harshly. I don't
accept apologies from people who provide evidence that they are not even
serious about the apology and who keep doing what they apologize for.
#:Erik
--
save the children: just say NO to sex with pro-lifers
Erik Naggum wrote:
>
> * Friedrich Dominicus
> | Now come on Eric. What does that have to do with the question.
>
> now you act as if you have a right to answers to your questions and act
> as if you don't even understand that I should treat you harshly.
So would it be possible to forgot the trouble and come back to the
discussion? I never have written that I expect an answer but if one
answer I can expect that we talk about the message. So could we now bury
the tomahawk and behave like somewhat reasonable people?
> I don't
> accept apologies from people who provide evidence that they are not even
> serious about the apology and who keep doing what they apologize for.
What am I keeping going on with? I just want to come back the the
subject of this thread and that's all.
Friedrich
>
> it's "grinning", you moron, and it fits you very well to misspell it, too.
I now know what moron means, better I hadn't asked. Interesingly enought
you intelligence seems not brigh enough to recognice irony is. And is
shows how arrogant you are.
So I would suggest you read some mails from me than you might get such
things right.
Till then
Friedrich
In article <················@naggum.no>,
Erik Naggum <····@naggum.no> wrote:
> * Friedrich Dominicus
> | Grining
> | Friedrich
>
> it's "grinning", you moron, and it fits you very well to misspell
it, too.
>
> #:Erik
I'd like to see you write an intelligent, grammatically and lexically
correct post in his native language.
Oh wait, you don't do other languages do you?
--
Bagherra <jaebear @ frenzy.com>
http://www.frenzy.com/~jaebear
"There's a snake in my boot!"
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
Hello!
In article <·················@inka.de>,
Friedrich Dominicus <···················@inka.de> wrote:
>[...]
><irony>
>So C++ is better suited for cooperative work. Now I understand why e.g
>KDE is written using C++ an not Common Lisp. You just can code CL alone
>;-) And fair enougth that desktop has found it's place on a lot of
>computers. I don't have heard or seen one of this things for CL.
For the latter, there's one additional reason: There's AFAIK no
*free* (in the sense of the Open Source definition or the Debian
Free Software Guidelines) CL implementations that allow creation
of standalone binaries. Or at least an *efficient* VM where
you can create self-starting binaries (in the sense that you
can call them by the image name instead of some magic formula like
/path/to/vm /path/to/image -- e.g. by accepting image files beginning
with a #! /path/to/vm line, like ocamlrun does).
I would appreciate to be corrected in that point marked with "AFAIK",
though.
>[...]
Regards, Hannah.
······@schlund.de (Hannah Schroeter) writes:
> Hello!
>
> In article <·················@inka.de>,
> Friedrich Dominicus <···················@inka.de> wrote:
> >[...]
>
> ><irony>
> >So C++ is better suited for cooperative work. Now I understand why e.g
> >KDE is written using C++ an not Common Lisp. You just can code CL alone
> >;-) And fair enougth that desktop has found it's place on a lot of
> >computers. I don't have heard or seen one of this things for CL.
>
> For the latter, there's one additional reason: There's AFAIK no
> *free* (in the sense of the Open Source definition or the Debian
> Free Software Guidelines) CL implementations that allow creation
> of standalone binaries.
There's no *free* C++ implementations that allow creation of
standalone binaries. Nor are there any commercial ones.
There are however confused people that think there are.
Christopher
On Mon, 06 Sep 1999 21:48:11 GMT, Christopher R. Barry wrote:
>······@schlund.de (Hannah Schroeter) writes:
>> For the latter, there's one additional reason: There's AFAIK no
>> *free* (in the sense of the Open Source definition or the Debian
>> Free Software Guidelines) CL implementations that allow creation
>> of standalone binaries.
>There's no *free* C++ implementations that allow creation of
>standalone binaries. Nor are there any commercial ones.
Okay, you're definitely trying to use some kind of weasel-words here.
What are they?
+ "standalone"? I compile an OS under gcc, and that's as standalone as
you can get.
+ *free*? Since you emphasize this I suspected that it was your
weasel-word, but since you mentioned commercial in the same sense you
can't be using one of the odd distinctions we've gotten used to...
Indeed, though, I don't know of any C++ compilers available under a
completely nonrestrictive license.
+ Creation? I dunno.
I would differ with the plain meaning of your argument, but obviously
you're trying to be clever, so that would be silly of me.
>There are however confused people that think there are.
And this post does *not* help.
>Christopher
--
-William "Billy" Tanksley
>>>>> "Reini" == Reini Urban <······@xarch.tu-graz.ac.at> writes:
Reini> However, c++ objects and workflow might be better to understand in c++
Reini> code than in lisp. (at least in my lisp)
Reini> What "dynamic magic" happens at load-time in my lisp is for sure much
Reini> harder to understand than the typical c++ startup process. this is a
Reini> nightmare for cooperation as well. just look at cmucl boots-trapping.
What does CMUCL bootstrapping have to do with any of this? The
difficulty is irrelevant to c++ startup process or "what 'dynamic
magic' happens at load-time in my lisp". You don't go around
rebuilding your c/c++ compiler just for the fun of it. Why would you
do that to your lisp compiler?
Ray
Reini Urban wrote:
>
> Friedrich Dominicus wrote:
> ><irony>
> >So C++ is better suited for cooperative work. Now I understand why e.g
> >KDE is written using C++ an not Common Lisp. ...
>
> This was not fair.
You're righ and even worse it was not meant serious I should have add at
least a ;-) Because of this I get some not so friendly answers from
Eric;-)
>There are much more C++ programmers than for lisp.
> Some really nice projects had to cancelled because of some strange
> language decisions. (Objective C for FreeDesigner, ...) Too less people
> to collaborate. GNU-like collaborating projects in lisp are certainly
> only useful for elisp and AutoLISP, because this is over the critical
> mass.
That there are more C++ programmers than Lisp programmers seems to be
clear, nevertheless you had to see the other mails in context. There was
just talkied about how much more productive on Lisp programmer can be
than a hurd of C++ programmmers. I don't know enougth about either C++
or Lisp to make a found decision. I just think that Common Lisp is
anyway a better choice.
>
> Right now I'm doing a cooperative and dislocated project in Lisp and C++
> together, so i want to add something here. sorry, I know that this is
> well known, but fresh to me and maybe to Friedrich as well.
>
> C++ is much less suited for cooperative work than lisp, esp. if
> communication channels are bad, as in my case. 6-9 hrs timeshift.
If the problems exist very much, why isn't than antther solution
choosen? As explained above, I do not know about C++ to tell something
against or pro. Just one point seems to be clear. Large projects are
done in C++ and there are a million tools out there and even with tools
like the GNU Tools developer have written e.g KDE and it worked quite
fine. But there isn't any GUI-Toolkit I know of which was written in
Common Lisp and is in widespread news for open software projects. And
even worse many of the GUI-Toolkits for Common Lisp are not supported
any longer and look quite a bit old. So why should people which do
programming for the fun of it choose Common Lisp? The advantages do not
seem so large that they would switch from C++, and in fact they prefer
to write software with C++.
>
> Changes in typical lisp code have much less global effects than typical
> C++ code. Functional style leeds to less global constructs, and header
> files are a story of its own.
> It's just easier to change or fix "global" objects in lisp than in c++.
I just can say, it seems not to matter. And I can say the same for
Eiffel. But relatively few are using Common Lisp and Eiffel instead of
C++. So the problem seems not to big for them.
>
> However, c++ objects and workflow might be better to understand in c++
> code than in lisp. (at least in my lisp)
> What "dynamic magic" happens at load-time in my lisp is for sure much
> harder to understand than the typical c++ startup process. this is a
> nightmare for cooperation as well. just look at cmucl boots-trapping.
> c/c++ sample solutions are much easier to find. this helps a LOT!
The same is true for Eiffel, just a non-representative survey under some
bookstores revealed: Many shelves for Hype-Java, fewer for C++, even
fewer for C Eiffel and in two book-stores I just found 1 Common Lisp
book. Of course CLtL. Which seems a bit non-beginner friendly.
I found no comparable book to ANSI C from K&R with solution books. And
another book I asked for, was out of print for MIT-Press. So it's not
damn easy to find stuff for Common Lisp. BTW the handbooks whic come
with Allegro CL und LispWorks are quite good and useful. And the
Hyperspec is really a good organized reference. But this are IMO quite
advanced docs. And not very suitable for a beginner or even worse a
complete beginner to programming.
>
> I spend much more time in the c++ debugger than in the lisp debugger.
> strange. Maybe because I cannot fix anything there, though the new msvc6
> debugging feature (what's the translated name in english? edit and
> continue) is really nice. Almost lispy. but not useful if you debug
> shared libs.
maybe you do more low-level stuff in C++. Just my experience with Eiffel
vs. C lead me to a simular conclusion. Much more time in the C-debugger
than in Eiffel. Although I like to look into it even if all things seem
to run fine.
>
> In summary I wouldn't wish that some of my co-workers should switch over
> to lisp. Some do lisp, some do C++, some do both, some do n... :)
> Both languages and tools have its advantages. Best is to keep all of us
> happy, motivated and productive.
I agree. And that was just what I would like to express. Both have it's
advantages and both sides have excellent programmers. So as long as they
are happy, it might not matter. I think both could learn from another
and my conclusion (you can see it in other mails) too is that a
programmer should learn at least one language from "the other side". I
bet he'll be doing better in the future than.
Regards
Friedrich
* Friedrich Dominicus
| If the problems exist very much, why isn't than antther solution choosen?
| As explained above, I do not know about C++ to tell something against or
| pro. Just one point seems to be clear. Large projects are done in C++
| and there are a million tools out there and even with tools like the GNU
| Tools developer have written e.g KDE and it worked quite fine. But there
| isn't any GUI-Toolkit I know of which was written in Common Lisp and is
| in widespread news for open software projects. And even worse many of
| the GUI-Toolkits for Common Lisp are not supported any longer and look
| quite a bit old. So why should people which do programming for the fun
| of it choose Common Lisp? The advantages do not seem so large that they
| would switch from C++, and in fact they prefer to write software with C++.
using Franz Inc's cbind utility, a fairly new Lisp user (he just got the
Allegro CL Trial edition for Linux) compiled up gtk bindings and wrote
some Lisp source that basically did gtk calls from Lisp in a few hours.
it seems fairly verbose to me, but that was his first approximation.
fairly impressive, still, and if it doesn't take more than this to get
access to such toolkits, what's holding us back is probably only that we
think it's a lot of work. beginners don't know that, so they just do it.
why should people who do programming for fun choose Common Lisp? because
it's a lot _more_ fun programming in Common Lisp! I chose to rebuild my
carreer and switch away from C/C++ when I had to use C++ in a project
(and like so many other programmers, I had heard mostly good things about
it at the time (August 1993)), but the language is really, truly
braindamaged. I was complemented on my design and coding from the few
people I got to know who were seasoned C++ programmers at the time, but
it still took forever to write, there were always unwanted side effects
of the most seamingly innocuous code and no way to have the compiler or
system tell you about them, and the redesigns that had to be made as we
discovered more details of the problem space were so costly the project
didn't reach its goals even with two more programmers on it and almost
twice the time, but we did publish a small useful core and a lot of
useful design papers. this experience had "there has to be a better way"
virtually flashing over us all the time, and I decided to take a good
serious look at Common Lisp, which I had been using for fun off and on
for longer than I har programmed in C. it took me three years of other
useful work (I wrote articles for various newspapers and journals, and
covered various IT-related news events, and also began writing a book
about SGML, which led me to conclude that that language was braindamaged,
too, so I stopped working on SGML) before I could go out there and say
"I'm a Lisp programmer" and expect to be paid for it. since it was clear
to me that I could sustain myself as a writer, and I had no plans to
return to hell and write C++ code ever again, the risks were pretty low
and I could invest my time in Common Lisp, which I really _like_. this
would not have been possible in a _less_ fun language. (now, three years
may seem like a long time, but I want to be really good at whatever I do,
and good articles and columns don't exactly come for free, either.)
| I just can say, it seems not to matter. And I can say the same for
| Eiffel. But relatively few are using Common Lisp and Eiffel instead of
| C++. So the problem seems not to big for them.
they don't know how easy it could be. they expect changes to be so and
so expensive. the result is that fewer changes are made than necessary
for correct operation, broken designs survive into products, and new
versions are harder to get out the door without massive rewrites. this
is how the C++ world works. since C++ people tend to know C++ only,
which is actually good for them when you think about it, they don't see
it as a problem. many other disciplines talk about "baselines" and the
work required to establish them, and it is fair to say that the baseline
for correcting errors in C++ is much, much higher than that for Common
Lisp, but those who have internalized the C++ baseline won't believe the
Common Lisp figures. I think we have some evidence of that right here.
| I found no comparable book to ANSI C from K&R with solution books. And
| another book I asked for, was out of print for MIT-Press. So it's not
| damn easy to find stuff for Common Lisp. BTW the handbooks whic come
| with Allegro CL und LispWorks are quite good and useful. And the
| Hyperspec is really a good organized reference. But this are IMO quite
| advanced docs. And not very suitable for a beginner or even worse a
| complete beginner to programming.
a complete beginner to programming would probably have a hard time
getting a job if all he knew was Common Lisp. those who employ Common
Lisp people tend to expect good knowledge of several languages. it may
therefore be a disservice to a future programmer to teach him the best
language first... several of the good Common Lisp programmers I know who
have been taught Scheme and Common Lisp have asked me time and again to
show them more low-level stuff. new Common Lisp users seem to find the
low-level access "panels" intriguing and opening them to see what's
inside is entertaining and adds a feeling of being in control. then we
put the panels back on and we don't have to _work_ at that level.
#:Erik
--
it's election time in Norway. explains everything, doesn't it?
>
> why should people who do programming for fun choose Common Lisp? because
> it's a lot _more_ fun programming in Common Lisp!
I agree here, even if I do not know either CL or C++ very well. I would
prefer Common Lisp. Just the thought about manual memory handling make
me shive. Another point why I prefer Eiffel ;-)
> I chose to rebuild my
> carreer and switch away from C/C++ when I had to use C++ in a project
> (and like so many other programmers, I had heard mostly good things about
> it at the time (August 1993)), but the language is really, truly
> braindamaged.
I would like to agree but I do not have the knowledge. Just if I look at
C++ like Wiender does in his book "there can be a live other than c++"
makes me think that that can't be a solution I think it's not a good
combination from old-fashioned C stuff on OO-ideas. But other may have
other opinions and good software is written while using (os is it
despite) C++. So there maybe some pros I can't see.
> this experience had "there has to be a better way"
> virtually flashing over us all the time, and I decided to take a good
> serious look at Common Lisp, which I had been using for fun off and on
> for longer than I har programmed in C. it took me three years of other
> useful work (I wrote articles for various newspapers and journals, and
> covered various IT-related news events, and also began writing a book
> about SGML, which led me to conclude that that language was braindamaged,
> too, so I stopped working on SGML) before I could go out there and say
> "I'm a Lisp programmer" and expect to be paid for it. since it was clear
> to me that I could sustain myself as a writer, and I had no plans to
> return to hell and write C++ code ever again, the risks were pretty low
> and I could invest my time in Common Lisp, which I really _like_.
This is a nice story and I would like to hear how others find their way.
I had to admit at first I did not like Lisp at all. But after
re-thinking and reading Structure and Interpretation of Computer
Programs and after reading I think it was Oliver Shrivers essay about
scsh I decided that's now time for me to give it a real try. And I begin
to learn. Now I see a glimpse of advantages in Common Lisp. I hope it
will either grow or that I'll see that it's not worth for me to learn
it. At the moment I tend to think that it will shine someday.
> this
> would not have been possible in a _less_ fun language. (now, three years
> may seem like a long time, but I want to be really good at whatever I do,
> and good articles and columns don't exactly come for free, either.)
It's interesting that you wote that. It take me at least the same amount
of time to get Eiffel somewhat right. And now I can't imaging to use
antother language for my programming. Maybe if I really learn Common
Lisp that will change. But till then I will stay with Eiffel and for
low-level stuff C. I guess for that C is one of the best languages
available.
>
> | I just can say, it seems not to matter. And I can say the same for
> | Eiffel. But relatively few are using Common Lisp and Eiffel instead of
> | C++. So the problem seems not to big for them.
>
> they don't know how easy it could be. they expect changes to be so and
> so expensive. the result is that fewer changes are made than necessary
> for correct operation, broken designs survive into products, and new
> versions are harder to get out the door without massive rewrites. this
> is how the C++ world works. since C++ people tend to know C++ only,
> which is actually good for them when you think about it, they don't see
> it as a problem.
I think this is probable. Just we don't know. If we would place this
questions into a c++ forum, I guess we would know very fast.
>
> | I found no comparable book to ANSI C from K&R with solution books. And
> | another book I asked for, was out of print for MIT-Press. So it's not
> | damn easy to find stuff for Common Lisp. BTW the handbooks whic come
> | with Allegro CL und LispWorks are quite good and useful. And the
> | Hyperspec is really a good organized reference. But this are IMO quite
> | advanced docs. And not very suitable for a beginner or even worse a
> | complete beginner to programming.
>
> a complete beginner to programming would probably have a hard time
> getting a job if all he knew was Common Lisp.
I guess Rainer would say. Common Lisp is not just a language but to
teach the bases of computer sciences.
> those who employ Common
> Lisp people tend to expect good knowledge of several languages. it may
> therefore be a disservice to a future programmer to teach him the best
> language first...
This is IMO a very weak reason.
>several of the good Common Lisp programmers I know who
> have been taught Scheme and Common Lisp have asked me time and again to
> show them more low-level stuff.
That is IMO a good reason. Maybe the feeling to control the machine is
really a very attractive motive for learning programming. I guess C is
very good suited for that and from there the step to C++ seems to be
easier than anything else. Because ++ stands at least for something
better ;-) and ++ must be much better. That the don't learn really other
approaches is anyway not a good thing.
> new Common Lisp users seem to find the
> low-level access "panels" intriguing and opening them to see what's
> inside is entertaining and adds a feeling of being in control. then we
> put the panels back on and we don't have to _work_ at that level.
This is one of the best sentences I read from you. I'm quite happy not
to do this kind of programming in Eiffel too. Just at the moment I'm
working on some file-directory handling and infos for Eiffel and of
course I'm back in C for that.
Regards
Friedrich
On 09 Sep 1999 08:56:11 +0000, Erik Naggum <····@naggum.no> wrote:
> language first... several of the good Common Lisp programmers I know who
> have been taught Scheme and Common Lisp have asked me time and again to
> show them more low-level stuff. new Common Lisp users seem to find the
> low-level access "panels" intriguing and opening them to see what's
> inside is entertaining and adds a feeling of being in control. then we
> put the panels back on and we don't have to _work_ at that level.
Somebody should write the book "C programming with Common Lisp" :)
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
Friedrich Dominicus <···················@inka.de> writes:
> Erik Naggum wrote:
> >
> > * Bagheera, the jungle scout <········@my-deja.com>
> > | Anything you can do in lisp, I can do in C++.
> >
> > sure, but I think people generally expect you to do it in finite time.
> >
> > | So I am at an empasse. I want an affordable lisp compiler for Windows,
> > | or an INTELLIGENT explanation of why it is worth what companies charge
> > | for it (on average, it is about 3x the cost of a GOOD professional C++
> > | compiler).
> >
> > well, assume most companies pay their programmers a lot of money. if you
> > could save 50% on the time it took to complete a project, that'd be worth
> > half a lot of money, which equals _way_ more than the difference between
> > the cost of the compilers.
>
> I agree about this.
>
>
> >
> > also, a single good Lisp programmer can easily do more than 20 moderately
> > good C++ programmers in the same time.
> but not about this. This is an opinion and not a fact I guess. And maybe
> you underestimate the C++ programmers. There are surely some under them
> for whom the other way is as true. I don't have the knowledge and
> experience to fill this with numbers but some others have found out that
> under programmers the differences can be very large. But to say this
> holds for all Common Lisp Programmers is a wild guess.
no. it's not a reflexion upon the C++ *programmers*. they are
assumed competent. it's the *language* C++ that is inferior to lisp
and causes the problem.
consider that i have been programming in C since 1989 and am
reasonably compentent in that language. i've also done some C++ work
in the past 3-4 years although with more of a number crunching bent
than any object orientation style things.
i am a neophyte in lisp. i have been dabbling with common lisp since
december 1998. yet, in february, i found it took me just as long to
write a lisp program (for romberg integration) that it would have to
do it in C++. this was with being mostly incompentant at lisp and
trying to learn functions and data structures to use in lisp.
the lisp code was suprisingly (to me at least) short (in total lines).
if i had to do it again, i know i'd be able to do a similar job in
half the time. this is because i know more lisp now. remember, i am
a mature C programmer (mature as in i know the language well, am
competent in it and *do not expect much improvement*). i am a
novicelisper. lisp really is incredibly easy to use and quick
development. since my program is so short, and since lisp takes care
of memory allocation, bounds checking, type consistency &c, i am
confident it works.
you asked about books. i have
1 _ansi common lisp_ by paul graham
2 _on lisp_ also by paul graham
3 _common lisp the language_ 2nd ed. by guy steele
4 _paradigms in articficial intelligence programming_ by peter norvig
all are excellent but cover different aspects of lisp.
1 is an intro - get this first
2 covers macros (lisp macros are like C++ templates only easier to use
and more powerful)
3 is a reference (not quite ansi but close enough) it has lots of good
explanation and examples
4 gives examples of lisp used for artificial intelligence programming
it's a good place to learn lisp programming style, structure (both
program and data) and method.
btw does anyone have a recommendation for a book on CLOS?
> BTW my opinion towards Common Lisp or another functional language is
> clear. It's a good idea for any programmer to know at least one
> imperative (or even object-oriented) language and a functional language.
>
> Another think I think holds is that there aren't a lot of comparisions
> between e.g C++ and other Languages. I guess we all could learn form
> that.
> Regards
> Friedrich
--
J o h a n K u l l s t a m
[········@ne.mediaone.net]
Don't Fear the Penguin!
In article <··············@sophia.axel.nom>, Johan Kullstam <········@ne.mediaone.net> wrote:
> btw does anyone have a recommendation for a book on CLOS?
The best thing IMHO is "The Art of the Metaobject Protocol".
Funnily the application of CLOS in this book is CLOS
itself. So you learn how CLOS works in terms of CLOS.
But, one should really examine it careful because the programming
style is great and you see how the various facilities of
Common Lisp are supposed to work together.
To reduce the shock, "Object-Oriented Programming in Common Lisp" by
Sonya E Keene may helpful.
If this title is out of print, look around used-book store(or your
nearest university library).
- jwc
Rainer Joswig wrote:
>
> In article <··············@sophia.axel.nom>, Johan Kullstam <········@ne.mediaone.net> wrote:
> ...
> But, one should really examine it careful because the programming
> style is great and you see how the various facilities of
> Common Lisp are supposed to work together.
Bagheera, the jungle scout <········@my-deja.com> writes:
> In article <··············@copernico.parades.rm.cnr.it>,
> Marco Antoniotti <·······@copernico.parades.rm.cnr.it> wrote:
> >
> >
> > Bagheera, the jungle scout <········@my-deja.com> writes:
> >
> > > I know, someone shoot me in the head, I've gone nuts,
> > > but I'm looking for a FREE lisp compiler for the PC.
> > > Win95/Win98 or DOS is ok.
> > >
> > > Must be able to compile to native code, and create C/C++ linkable
> object
> > > files.
> >
> > On UN*X you can get CMUCL (http://www.cons.org). On the PC platform
> > you can get several trial system, but to actually get a native
> > compiler you must shell out some Euros.
>
> I already have $800 worth of compilers. Unless you can point me to a
> lisp compiler for under $20, I'm not interested.
Ahem! Why did you spend 800 USD on (let's see...) Visual C++ and
don't want to spend money on a good CL compiler? (or better, why do
you insist on using a Windos platform, when you can move to Linux?)
>
> > > Prove to me lisp is worth it.
> <snip trvial C++ problem>
I would be really interested to see how you managed to do this in a
general and systematic way in C++. Really interested. Then I would
ask you how much time you spent to set up the infrastructure and debug
it, and how much you will have to spend to extend the example (which
dealt with multi-method dispatch) to a three way "virtual" functions.
process_event(WindowClass, EventClass, DataClass);
I can tell you the cost of doing this thing in Common Lisp: it is the
cost you pay for learning the language, plus the cost of your
compiler. Apart form that, a well rounded 0, nil, nada, NULL.
> Anything you can do in lisp, I can do in C++. Or any other language for
> that matter.
Of course. I am currently writing programs using the white book
Turing Machine specification.
> True you could get language specific on me and say
> something like "make a pointer in Java"...yeah well, you can't, but
> there are ways to emulate that behavior.
Why would you? Pointers are useless and messy. :) I reach for my
garbage collector :) as soon as I see something like
while (*c++) { ... }
> I am very experienced in several programming languages,
But not in the only one that would really make you change your habits.
...
> So I am at an empasse. I want an affordable lisp compiler for Windows,
> or an INTELLIGENT explanation of why it is worth what companies charge
> for it (on average, it is about 3x the cost of a GOOD professional C++
> compiler).
That is the only point you got rigth. Commercial CL compilers do cost
too much w.r.t. C/C++ environments. I agree on that. But this is a
problem for Franz and Harlequin managers and marketing directors.
Bring it up to them.
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
* Marco Antoniotti <·······@copernico.parades.rm.cnr.it>
| Commercial CL compilers do cost too much w.r.t. C/C++ environments.
with respect to the lives and the fortunes they save, they're dirt cheap.
with respect to what they make possible, they're also dirt cheap.
note that ANSI standards also cost way too much compared to toilet paper,
and the're pretty bad quality as toilet paper goes, too.
I recently bought a fountain pen. it cost the equivalent of about 1500
throw-away ball pens. 1500 ball pens would have made me very frustrated,
but this sleek, elegant pen made me happy. I also choose Common Lisp.
#:Erik
--
save the children: just say NO to sex with pro-lifers
* Erik Naggum wrote:
> I recently bought a fountain pen. it cost the equivalent of about 1500
> throw-away ball pens. 1500 ball pens would have made me very frustrated,
> but this sleek, elegant pen made me happy. I also choose Common Lisp.
Actually fountain pens are really like Lisp. They're both kind of
left field -- people look at you a bit oddly when you insist on
writing with one. They're not always compatible with things -- lots
of paper will blot with fountain pen. Modern ballpoints are gradually
working their way up (with spring-loaded balls &c &c) to be half as
nice to write with as a fountain pen. They're expensive. They're
harder to learn how to use. But they're just infinitely preferable.
--tim (1928 waterman ideal which leaks ink all over my hands)
Tim Bradshaw <···@tfeb.org> writes:
> * Erik Naggum wrote:
> > I recently bought a fountain pen. it cost the equivalent of about 1500
> > throw-away ball pens. 1500 ball pens would have made me very frustrated,
> > but this sleek, elegant pen made me happy. I also choose Common Lisp.
>
> Actually fountain pens are really like Lisp. They're both kind of
> left field -- people look at you a bit oddly when you insist on
> writing with one. They're not always compatible with things -- lots
> of paper will blot with fountain pen. Modern ballpoints are gradually
> working their way up (with spring-loaded balls &c &c) to be half as
> nice to write with as a fountain pen. They're expensive. They're
> harder to learn how to use. But they're just infinitely preferable.
>
> --tim (1928 waterman ideal which leaks ink all over my hands)
You wrote this article with a fountain pen? Impressive!
But how did you digitize it?
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
Duane Rettig <·····@franz.com> writes:
> Tim Bradshaw <···@tfeb.org> writes:
>
> > * Erik Naggum wrote:
> > > I recently bought a fountain pen. it cost the equivalent of about 1500
> > > throw-away ball pens. 1500 ball pens would have made me very frustrated,
> > > but this sleek, elegant pen made me happy. I also choose Common Lisp.
> >
> > Actually fountain pens are really like Lisp. They're both kind of
> > left field -- people look at you a bit oddly when you insist on
> > writing with one. They're not always compatible with things -- lots
> > of paper will blot with fountain pen. Modern ballpoints are gradually
> > working their way up (with spring-loaded balls &c &c) to be half as
> > nice to write with as a fountain pen. They're expensive. They're
> > harder to learn how to use. But they're just infinitely preferable.
> >
> > --tim (1928 waterman ideal which leaks ink all over my hands)
>
> You wrote this article with a fountain pen? Impressive!
> But how did you digitize it?
*Nothing* is impossible with the right tools.
--
Raymond Wiker, Orion Systems AS
+47 370 61150
Duane Rettig wrote:
> You wrote this article with a fountain pen? Impressive! But how did you digitize
> it?
You assume that tim wrote this article! He, of course, generated the text using
telepathy using his patented cl thought-to-text transfer system ;-)
Cheers,
:-) will
In article <··············@copernico.parades.rm.cnr.it>,
Marco Antoniotti <·······@copernico.parades.rm.cnr.it> wrote:
> Ahem! Why did you spend 800 USD on (let's see...) Visual C++
Actually we don't have MSVC. We have: Code Warrior, Watcom, Borland
Builder, MASM, and Visual Cafe.
> and don't want to spend money on a good CL compiler? (or better, why
> do you insist on using a Windos platform, when you can move to Linux?)
Linux is not an option. All of our clients use Windows.
Also, in my group of programmers, only 2 of us knows how
to program under unix, and then only with Motif libraries (which are
EXPENSIVE).
> > > > Prove to me lisp is worth it.
> > <snip trvial C++ problem>
>
> I would be really interested to see how you managed to do this in a
> general and systematic way in C++. Really interested.
If it wouldn't violate my NDA, I would happily explain it to you.
> Of course. I am currently writing programs using the white book
> Turing Machine specification.
in the end...it is all machine code.
> Why would you? Pointers are useless and messy. :) I reach for my
> garbage collector :) as soon as I see something like
>
> while (*c++) { ... }
different strokes...
I happen to be very comfortable with pointers, and
know extremely useful things you can do with them.
They happen to be a tool, and if you know how to use
your tools to their full potential, they are useful
tools.
> > I am very experienced in several programming languages,
>
> But not in the only one that would really make you change your habits.
conjecture.
I'm already mildly familiar with Lisp, I had two classes on it
in College, I just want to learn it better so that I can learn
Lisp based AI.
> > So I am at an empasse. I want an affordable lisp compiler for
Windows,
> > or an INTELLIGENT explanation of why it is worth what companies
charge
> > for it (on average, it is about 3x the cost of a GOOD professional
C++
> > compiler).
>
> That is the only point you got rigth. Commercial CL compilers do cost
> too much w.r.t. C/C++ environments. I agree on that. But this is a
> problem for Franz and Harlequin managers and marketing directors.
> Bring it up to them.
Are there any Lisp compilers that offer student discounts?
--
Bagherra <jaebear @ frenzy.com>
http://www.frenzy.com/~jaebear
"There's a snake in my boot!"
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
Bagheera, the jungle scout <········@my-deja.com> writes:
> In article <··············@copernico.parades.rm.cnr.it>,
>
> Linux is not an option. All of our clients use Windows.
> Also, in my group of programmers, only 2 of us knows how
> to program under unix, and then only with Motif libraries (which are
> EXPENSIVE).
Lesstif "expensive"?
> > > > > Prove to me lisp is worth it.
> > > <snip trvial C++ problem>
> >
> > I would be really interested to see how you managed to do this in a
> > general and systematic way in C++. Really interested.
>
> If it wouldn't violate my NDA, I would happily explain it to you.
I have the hunch that you cannot really explain it because.... you
can't do it in C++ :)
> > Of course. I am currently writing programs using the white book
> > Turing Machine specification.
>
> in the end...it is all machine code.
>
> > Why would you? Pointers are useless and messy. :) I reach for my
> > garbage collector :) as soon as I see something like
> >
> > while (*c++) { ... }
>
> different strokes...
> I happen to be very comfortable with pointers, and
> know extremely useful things you can do with them.
Yeah! You can write Common Lisp environments :)
> They happen to be a tool, and if you know how to use
> your tools to their full potential, they are useful
> tools.
Good point. Learn CL using one of the free environments and good
books around and then appreciate the "full potential".
> > > I am very experienced in several programming languages,
> >
> > But not in the only one that would really make you change your habits.
>
> conjecture.
> I'm already mildly familiar with Lisp, I had two classes on it
> in College, I just want to learn it better so that I can learn
> Lisp based AI.
Why not CL based numerical computations. You get almost the same
speed as C with CL (and with C you almost get the same speed as
FORTRAN).
>
> Are there any Lisp compilers that offer student discounts?
>
Check out www.alu.org for a list of vendors.
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
In article <··············@copernico.parades.rm.cnr.it>,
Marco Antoniotti <·······@copernico.parades.rm.cnr.it> wrote:
> Lesstif "expensive"?
Lesstif is not a full implementation of Motif, and it is NOT
"supported".
> > > I would be really interested to see how you managed to do this in
a
> > > general and systematic way in C++. Really interested.
> >
> > If it wouldn't violate my NDA, I would happily explain it to you.
>
> I have the hunch that you cannot really explain it because.... you
> can't do it in C++ :)
*sigh*
I'll give you a hint. It uses RTTI, template classes, function
overloading and inheritance.
> > I happen to be very comfortable with pointers, and
> > know extremely useful things you can do with them.
>
> Yeah! You can write Common Lisp environments :)
if I had to I suppose, but you can do alot more than that.
especially high end optimizations like poking the system
memory and things like that.
> > They happen to be a tool, and if you know how to use
> > your tools to their full potential, they are useful
> > tools.
>
> Good point. Learn CL using one of the free environments and good
> books around and then appreciate the "full potential".
back to my point...what free environments (unice doesn't count), and
especially, what good books. Of the 8 books I've read...they're all
crap. C++ has many more gurus capable of writing (as far as I can
tell). Are they any books on par with C++ Primer Plus (Mitchel Waite
Signature Series)? That is agreed by MANY c++ programmers to be the
BEST introductory manual on the language.
> > conjecture.
> > I'm already mildly familiar with Lisp, I had two classes on it
> > in College, I just want to learn it better so that I can learn
> > Lisp based AI.
>
> Why not CL based numerical computations. You get almost the same
> speed as C with CL (and with C you almost get the same speed as
> FORTRAN).
If I were using pure numerical computations I would use Miranda or ML.
But I don't do pure numerical computations. I am interested in AI, both
game based and data mining. Lisp happens to be the most prolific AI
language, and therefore the easiest to get examples in. If I had my
way, there would be an equal sampling of AI solutions in C/C++, Pascal,
Fortran, and other imperative languages as there are in Lisp.
--
Bagherra <jaebear @ frenzy.com>
http://www.frenzy.com/~jaebear
"There's a snake in my boot!"
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
In article <············@nnrp1.deja.com>, Bagheera, the jungle scout <········@my-deja.com> wrote:
> If I were using pure numerical computations I would use Miranda or ML.
> But I don't do pure numerical computations. I am interested in AI, both
> game based and data mining. Lisp happens to be the most prolific AI
> language, and therefore the easiest to get examples in. If I had my
> way, there would be an equal sampling of AI solutions in C/C++, Pascal,
> Fortran, and other imperative languages as there are in Lisp.
Hey, why don't you go to the comp.lang.prolog folks and leave this
newsgroup alone?
[...]
BTJ> back to my point...what free environments (unice doesn't
BTJ> count), and especially, what good books.
Check out the free trial versions from Harlequin and Franz. For books,
a comprehensive list is at
http://www.elwoodcorp.com/alu/table/books.htm
I would recoomed Graham's "ANSI Common Lisp" and "On Lisp" (probably
in that sequence) and Norvig's "Paradaigms in AI ..." These are the
ones I have and like.
At some point Tanimoto had an AI textbook that [I believe] came with a Lisp
interpreter. If it is still in print, you might want to check it out
also. I should warn you, though, that the copy I am familiar with
came with a dynamic scoping mini-Lisp.
Also check out SICP (Sructure and Interpretation of Computer Programs
by Abelson & Sussman). This book uses Scheme. It is the best inroductory
book I know of. You might want to first check the comments at amazon.com
on this book and see which bunch (lovers and haters of the book) you
identify yourself with.
cheers,
BM
>
> back to my point...what free environments (unice doesn't count), and
> especially, what good books. Of the 8 books I've read...they're all
> crap. C++ has many more gurus capable of writing (as far as I can
> tell). Are they any books on par with C++ Primer Plus (Mitchel Waite
> Signature Series)? That is agreed by MANY c++ programmers to be the
> BEST introductory manual on the language.
You can download trial version from any Common Lisp vendor. And if you
use Linux you even can get free versions. Of course if you want to buy
them you can, just they are really expensive even in contrast to Eiffel
Compilers which used to be quite expensive.
Others have pointed out that even high prices form tools are far
outwaged by payment for programmers. So for learning I guess a free
triela version is quite ok and if you think that suits your needs you
can look further.
Regards
Friedrich
Bagheera, the jungle scout <········@my-deja.com> writes:
> In article <··············@copernico.parades.rm.cnr.it>,
> Marco Antoniotti <·······@copernico.parades.rm.cnr.it> wrote:
> > Lesstif "expensive"?
>
> Lesstif is not a full implementation of Motif, and it is NOT
> "supported".
>
> > > > I would be really interested to see how you managed to do this in
> a
> > > > general and systematic way in C++. Really interested.
> > >
> > > If it wouldn't violate my NDA, I would happily explain it to you.
> >
> > I have the hunch that you cannot really explain it because.... you
> > can't do it in C++ :)
>
> *sigh*
> I'll give you a hint. It uses RTTI, template classes, function
> overloading and inheritance.
Exactly my point. You cannot do it in C++ without (a) a considerable
programming investment (i.e. you must shell out a lot of money) and
(b) not in a general enough way (where "general enough way" is defined
to be the CLOS way).
> > > I happen to be very comfortable with pointers, and
> > > know extremely useful things you can do with them.
> >
> > Yeah! You can write Common Lisp environments :)
>
> if I had to I suppose, but you can do alot more than that.
> especially high end optimizations like poking the system
> memory and things like that.
Whenever I hear the words "poking the system memory" I reach for my
garbage collector. :)
> > > They happen to be a tool, and if you know how to use
> > > your tools to their full potential, they are useful
> > > tools.
> >
> > Good point. Learn CL using one of the free environments and good
> > books around and then appreciate the "full potential".
>
> back to my point...what free environments (unice doesn't count), and
> especially, what good books. Of the 8 books I've read...they're all
> crap. C++ has many more gurus capable of writing (as far as I can
> tell). Are they any books on par with C++ Primer Plus (Mitchel Waite
> Signature Series)? That is agreed by MANY c++ programmers to be the
> BEST introductory manual on the language.
You are sorely right on this point. Apart from Graham's books and
Abelson and Sussman's SICP (which uses Scheme) I believe there are not
very many good and useful books around about CL.
Isn't KMP coming up with one? :)
> > > conjecture.
> > > I'm already mildly familiar with Lisp, I had two classes on it
> > > in College, I just want to learn it better so that I can learn
> > > Lisp based AI.
> >
> > Why not CL based numerical computations. You get almost the same
> > speed as C with CL (and with C you almost get the same speed as
> > FORTRAN).
>
> If I were using pure numerical computations I would use Miranda or
> ML.
What a strange twist of events!
> But I don't do pure numerical computations. I am interested in AI, both
> game based and data mining. Lisp happens to be the most prolific AI
> language, and therefore the easiest to get examples in. If I had my
> way, there would be an equal sampling of AI solutions in C/C++, Pascal,
> Fortran, and other imperative languages as there are in Lisp.
Which BTW, is also "The Ultimate Imperative" language. :)
Cheers
> Bagherra <jaebear @ frenzy.com>
> http://www.frenzy.com/~jaebear
> "There's a snake in my boot!"
>
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
In article <··············@copernico.parades.rm.cnr.it>, Marco Antoniotti <·······@copernico.parades.rm.cnr.it> wrote:
> You are sorely right on this point. Apart from Graham's books and
> Abelson and Sussman's SICP (which uses Scheme) I believe there are not
> very many good and useful books around about CL.
PAIP
Lisp, 3rd Edition
Genera manuals ;-)
>Marco Antoniotti <·······@copernico.parades.rm.cnr.it> wrote:
>> You are sorely right on this point. Apart from Graham's books and
>> Abelson and Sussman's SICP (which uses Scheme) I believe there are not
>> very many good and useful books around about CL.
Rainer Joswig contered:
>PAIP
>Lisp, 3rd Edition
>Genera manuals ;-)
Also strong a NO NO. The typical new lisp books are very good IMHO.
I tried to learn C++ and CL at the same time. Compared to the various
books I read then as beginner I'd say 80% are very good in the lisp
domain and 20% are very good in C++. (very optimistic)
I actually only found Coplien interesting. Reading Stroustrup was a
mess, compared to Kernigan/Ritchie then.
There are even better perl books than C++ books around! :)
~50% good-ness rate but there's less hype and less books.
AutoLISP has 5%, Java 10%.
--
Reini
In article <·················@judy>, ······@sbox.tu-graz.ac.at wrote:
> >Marco Antoniotti <·······@copernico.parades.rm.cnr.it> wrote:
> >> You are sorely right on this point. Apart from Graham's books and
> >> Abelson and Sussman's SICP (which uses Scheme) I believe there are not
> >> very many good and useful books around about CL.
>
> Rainer Joswig contered:
> >PAIP
> >Lisp, 3rd Edition
> >Genera manuals ;-)
>
> Also strong a NO NO. The typical new lisp books are very good IMHO.
For me books like "Paradigms of Artificial Intelligence Programming"
(from Peter Norvig. Go buy one if you don't have it.) and
"Lisp, 3rd Edition" (Winston/Horn) are among the alltime classics.
But guys, you don't just need to buy them - you need to read them
and work your way through them with one hand to the keyboard
of your favorite Lisp system - and, yes, you don't have
to type the source code - but if you want - go ahead.
Get the Lisp experience of an interactive software
design environment - try out your ideas - don't let
the system constrain you.
If your books are looking worn out, the pages are starting
to fade away, you have traces of chinese food on the pages,
your disk is full of edited versions of the code
and you have rewritten your graphical interfaces
to "blocks world" and "Othello" ten times - than you are on the
right track.
The Lisp books are full of ideas - more than you would
get from a meter of other "modern" books, which you can
read in a few hours (huge print, lot's of white space,
reiteration of the last 20 years everywhere, thick paper,
assembled from other sources, ...) and you can throw in the garbage can
can after you read them. There is a reason these other systems
they describe don't have a real garbage collection
- it would trash them immediately.
Reini Urban wrote:
>
> >Marco Antoniotti <·······@copernico.parades.rm.cnr.it> wrote:
> >> You are sorely right on this point. Apart from Graham's books and
> >> Abelson and Sussman's SICP (which uses Scheme) I believe there are not
> >> very many good and useful books around about CL.
>
> Rainer Joswig contered:
> >PAIP
^^^^^^^ what's that?
> >Lisp, 3rd Edition
> I tried to learn C++ and CL at the same time. Compared to the various
> books I read then as beginner I'd say 80% are very good in the lisp
> domain and 20% are very good in C++. (very optimistic)
Now what books are you talking about?
Guess it would be helpful. And I guess this might be something for the
FAQ
Regards
Friedrich
In article <·················@inka.de>, ···················@inka.de wrote:
> Reini Urban wrote:
> >
> > >Marco Antoniotti <·······@copernico.parades.rm.cnr.it> wrote:
> > >> You are sorely right on this point. Apart from Graham's books and
> > >> Abelson and Sussman's SICP (which uses Scheme) I believe there are not
> > >> very many good and useful books around about CL.
> >
> > Rainer Joswig contered:
> > >PAIP
> ^^^^^^^ what's that?
http://www.norvig.com/paip.html
> > >Lisp, 3rd Edition
http://www.ascent.com/books/#Lisp
By the way, what language is Ascent using to write
their software for airport gate management? ;-)
http://www.ascent.com/airports.htm
Friedrich Dominicus wrote:
>> I tried to learn C++ and CL at the same time. Compared to the various
>> books I read then as beginner I'd say 80% are very good in the lisp
>> domain and 20% are very good in C++. (very optimistic)
that c++ books are generally bad and lisp books excellent.
>Now what books are you talking about?
the two coplien books (but one is not language specific), the two
stroustrup, and some more weak ones: one by stephen davis, one by donis
marshall. plus several autocad objectarx related ones. I forgot the
titles of the rest from the library, but i'll try the good one you
mentioned.
not to forget the reference and user manuals. Only MSVC is quite okay
now, but i also translated borland's and watcom's first c++ manuals to
my proprietary help format. just to understand it.
with lisp (books and manuals) it was much easier. perl and python were
the easiest though.
--
Reini
>>>>> "Marco" == Marco Antoniotti <·······@copernico.parades.rm.cnr.it> writes:
Marco> Why not CL based numerical computations. You get almost the same
Marco> speed as C with CL (and with C you almost get the same speed as
Marco> FORTRAN).
This is not always true (same speed as C with CL), as was demonstrated
here a few weeks ago. The DCT code was significantly slower (50% or
more? I don't remember) in Lisp than C, even when both versions had
the same algorithm.
Also, has C finally caught up with Fortran? I thought the aliasing
issues in C prevents C compilers from making the same optimizations
Fortran compilers could do because the language specifies that
aliasing doesn't happen.
Ray
In article <··············@rtp.ericsson.se>,
Raymond Toy <···@rtp.ericsson.se> wrote:
>>>>>> "Marco" == Marco Antoniotti <·······@copernico.parades.rm.cnr.it> writes:
>
> Marco> Why not CL based numerical computations. You get almost the same
> Marco> speed as C with CL (and with C you almost get the same speed as
> Marco> FORTRAN).
>
>This is not always true (same speed as C with CL), as was demonstrated
>here a few weeks ago. The DCT code was significantly slower (50% or
>more? I don't remember) in Lisp than C, even when both versions had
>the same algorithm.
>
Unfortunately, these are meaningless statements. Languages don't have
performance (even the STL has only O() performance requirements),
implementations do. The case I remember of CL beating Fortran was
CMUCL. I really, really doubt Macintosh Common Lisp will; it doesn't
handle floats quite as well.
>Also, has C finally caught up with Fortran? I thought the aliasing
>issues in C prevents C compilers from making the same optimizations
>Fortran compilers could do because the language specifies that
>aliasing doesn't happen.
>
This is being addressed in the C9X standard, which will also introduce
numerous other things that will probably make C9X code slower again
(unless you're careful). I think the C community would be better off
if the C9X process was violently aborted, but to be honest there are
some C experts (including people on the Committee) who disagree.
--
David H. Thornley | If you want my opinion, ask.
·····@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
>>>>> "David" == David Thornley <········@visi.com> writes:
David> In article <··············@rtp.ericsson.se>, Raymond Toy
David> <···@rtp.ericsson.se> wrote:
>>>>>>> "Marco" == Marco Antoniotti
>>>>>>> <·······@copernico.parades.rm.cnr.it> writes:
>>
Marco> Why not CL based numerical computations. You get almost
Marco> the same speed as C with CL (and with C you almost get the
Marco> same speed as FORTRAN).
>>
>> This is not always true (same speed as C with CL), as was
>> demonstrated here a few weeks ago. The DCT code was
>> significantly slower (50% or more? I don't remember) in Lisp
>> than C, even when both versions had the same algorithm.
>>
David> Unfortunately, these are meaningless statements. Languages
David> don't have performance (even the STL has only O()
David> performance requirements), implementations do. The case I
Of course. For these comparisons to make sense, I always assume we're
talking about various implementations of various languages.
David> remember of CL beating Fortran was CMUCL. I really, really
David> doubt Macintosh Common Lisp will; it doesn't handle floats
David> quite as well.
I thought it was Maclisp (not MCL) that beat Fortran on a PDP-11(?)
Ray
* Raymond Toy wrote:
> I thought it was Maclisp (not MCL) that beat Fortran on a PDP-11(?)
PDP10. I wouldn't be surprised if CMUCL could on occasion beat some
Fortran systems either.
--tim
Raymond Toy <···@rtp.ericsson.se> writes:
> >>>>> "Marco" == Marco Antoniotti <·······@copernico.parades.rm.cnr.it> writes:
>
> Marco> Why not CL based numerical computations. You get almost the same
> Marco> speed as C with CL (and with C you almost get the same speed as
> Marco> FORTRAN).
>
> This is not always true (same speed as C with CL), as was demonstrated
> here a few weeks ago. The DCT code was significantly slower (50% or
> more? I don't remember) in Lisp than C, even when both versions had
> the same algorithm.
I said *almost*. As per the DCT example, I believe that pointed out
two things, w.r.t. the implementations used. (1) transforming the
computations into 1-dimension for CMUCL did not help as much as you
would have expected, and (2) CMUCL does not seem to do as much
peep-hole optimization on the produced assembly code as GCC does.
All in all this are not "language inherent" problems. I suppose you
could expect an improvement for CL if many more programmers were
working at it. I.e. it is a matter of "scale" and invesment. I would
venture out to say that it is reasonable to think that CL compilers
have fallen behind C/C++ compiler technology in recent years,
w.r.t. the situation of, let's say, 10 years ago. Of course I have no
real data to support my case. It is just a hunch.
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
>>>>> "Marco" == Marco Antoniotti <·······@copernico.parades.rm.cnr.it> writes:
Marco> All in all this are not "language inherent" problems. I
Marco> suppose you could expect an improvement for CL if many more
Marco> programmers were working at it. I.e. it is a matter of
Marco> "scale" and invesment. I would venture out to say that it
Marco> is reasonable to think that CL compilers have fallen behind
Marco> C/C++ compiler technology in recent years, w.r.t. the
Marco> situation of, let's say, 10 years ago. Of course I have no
Marco> real data to support my case. It is just a hunch.
Sounds about right to me. I also guess that CL compilers haven't
stressed numerical efficiency as other languages, so these
deficiencies show up in these types of tests.
Ray
* Marco Antoniotti
| All in all this are not "language inherent" problems. I suppose you
| could expect an improvement for CL if many more programmers were working
| at it. I.e. it is a matter of "scale" and invesment. I would venture
| out to say that it is reasonable to think that CL compilers have fallen
| behind C/C++ compiler technology in recent years, w.r.t. the situation
| of, let's say, 10 years ago. Of course I have no real data to support my
| case. It is just a hunch.
why even say this if you can't back it up? don't you realize how much
this reinforces the stupid myths? obviously, you speak about CMUCL from
experience, but why not confine your comments to CMUCL? sheesh.
the biggest problem is that disproving your claims or undoing the damage
is very hard work. to win an argument with somebody who believes you, CL
compilers not only have to be as fast as C/C++ compilers, but faster,
with better machine scheduling and register usage and whatnot, otherwise
your negative point will still hold: "CL lags behind C/C++".
I suggest those who care work on ways to improve every single instance of
suboptimal code they can find. if there is a unique preferred order of
some instructions, for instance, notify the compiler writers. you can't
expect them to know _everything_ about every processor, even though you
may think that's what they get paid to do.
(and with all the source access and everything, why not just fix it?)
#:Erik
--
save the children: just say NO to sex with pro-lifers
Erik Naggum <····@naggum.no> writes:
> * Marco Antoniotti
> | All in all this are not "language inherent" problems. I suppose you
> | could expect an improvement for CL if many more programmers were working
> | at it. I.e. it is a matter of "scale" and invesment. I would venture
> | out to say that it is reasonable to think that CL compilers have fallen
> | behind C/C++ compiler technology in recent years, w.r.t. the situation
> | of, let's say, 10 years ago. Of course I have no real data to support my
> | case. It is just a hunch.
>
> why even say this if you can't back it up? don't you realize how much
> this reinforces the stupid myths? obviously, you speak about CMUCL from
> experience, but why not confine your comments to CMUCL? sheesh.
>
> the biggest problem is that disproving your claims or undoing the damage
> is very hard work. to win an argument with somebody who believes you, CL
> compilers not only have to be as fast as C/C++ compilers, but faster,
> with better machine scheduling and register usage and whatnot, otherwise
> your negative point will still hold: "CL lags behind C/C++".
You are right on these accounts. However, I believe that "consumers"
must be "informed". (Where the definition of "informed" is to be
agreed upon). Note that the biggest claim put forth to support the
use of CL over C++ (or other languages) is also not quite provable:
i.e. the fact that "programmer productivity" is improved over C++
productivity. There is no data supporting this claim. Yet I feel
this is really true. All in all, I simply try not to sin for my
omissions :)
Come on. It's not that bad.
> I suggest those who care work on ways to improve every single instance of
> suboptimal code they can find. if there is a unique preferred order of
> some instructions, for instance, notify the compiler writers. you can't
> expect them to know _everything_ about every processor, even though you
> may think that's what they get paid to do.
I do not think that. I do not know that much for sure.
> (and with all the source access and everything, why not just fix it?)
Exactly, becuase I do not know that much. :)
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
* Marco Antoniotti <·······@copernico.parades.rm.cnr.it>
| Note that the biggest claim put forth to support the use of CL over C++
| (or other languages) is also not quite provable: i.e. the fact that
| "programmer productivity" is improved over C++ productivity. There is no
| data supporting this claim.
on the contrary, there are heaps of data to support this claim, but it
does not meet some people's requirements for valid data. of course, any
such data is rife with serious problems. yet, people experience it all
the time, especially if they write _robust_ C++ code. (if they don't,
they may well win on all sorts of counts, but we all know that it's very,
very hard work to make C and C++ programs fail gracefully.)
#:Erik
--
save the children: just say NO to sex with pro-lifers
Erik Naggum wrote:
>
> * Marco Antoniotti <·······@copernico.parades.rm.cnr.it>
> | Note that the biggest claim put forth to support the use of CL over C++
> | (or other languages) is also not quite provable: i.e. the fact that
> | "programmer productivity" is improved over C++ productivity. There is no
> | data supporting this claim.
>
> on the contrary, there are heaps of data to support this claim, but it
> does not meet some people's requirements for valid data.
Could you give us some URLS, papers or the like?
Regards
Friedrich
Friedrich Dominicus wrote:
>
>
> Could you give us some URLS, papers or the like?
>
http://haskell.org/papers/NSWC/jfp.ps
Here's the abstract:
Description of the results of an experiment in which several
conventional programming languages, together with the functional
language Haskell, were used to prototype a Naval Surface Warfare Center
requirement for Geometric Region Servers. The resulting programs and
development metrics were reviewed by a committee chosen by the US Navy.
The results indicate that the Haskell prototype took significantly less
time to develop and was considerably more concise and easier to
understand than the corresponding prototypes written in several
different imperative languages, including Ada and C++.
Haskell was the winner in program length (the C++ version was a factor
of 7 bigger), but something called Relational Lisp won on development
time (about half the Haskell time, and one seventh the time for Ada).
The numbers here are fuzzy, but at least they are numbers and not
anecdotes.
Bob Bane <····@removeme.gst.com> writes:
> http://haskell.org/papers/NSWC/jfp.ps
>
> Here's the abstract:
>
> Description of the results of an experiment in which several
> conventional programming languages, together with the functional
> language Haskell, were used to prototype a Naval Surface Warfare Center
> requirement for Geometric Region Servers. The resulting programs and
> development metrics were reviewed by a committee chosen by the US Navy.
> The results indicate that the Haskell prototype took significantly less
> time to develop and was considerably more concise and easier to
> understand than the corresponding prototypes written in several
> different imperative languages, including Ada and C++.
One of the interesting observations in this paper was that the Haskell program
was written in a functional style (of course), one in which the solution was
expressed in terms of the problem domain very naturally. The Ada and C++
solutions, at least, were not (functional, that is).
I wonder how the Ada or C++ solutions would have faired if they too were also
done in a functional manner. There is nothing preventing this in either
language. Most programmers' mind sets with these languages seems to be to do
things the hard, tedious way. Of course, any memory management required comes
for free with language that has garbage collection, but I suspect that the
imperative language solutions could have been greatly improved.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
·····@infomatch.com The Rhythm has my soul.
Bob Bane wrote:
>
> Friedrich Dominicus wrote:
> >
> >
> > Could you give us some URLS, papers or the like?
> >
>
> http://haskell.org/papers/NSWC/jfp.ps
I have read it before. I can't remember that a Lisp participated. But
yes there are some numbers. Any other hints?
Regards
Friedrich
Bob Bane <····@removeme.gst.com> writes:
> Friedrich Dominicus wrote:
> >
> >
> > Could you give us some URLS, papers or the like?
> >
...
>
> Haskell was the winner in program length (the C++ version was a factor
> of 7 bigger), but something called Relational Lisp won on development
> time (about half the Haskell time, and one seventh the time for Ada).
> The numbers here are fuzzy, but at least they are numbers and not
> anecdotes.
Are there pointers to Relational Lisp?
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
In article <··············@copernico.parades.rm.cnr.it>, Marco Antoniotti <·······@copernico.parades.rm.cnr.it> wrote:
> > Haskell was the winner in program length (the C++ version was a factor
> > of 7 bigger), but something called Relational Lisp won on development
> > time (about half the Haskell time, and one seventh the time for Ada).
> > The numbers here are fuzzy, but at least they are numbers and not
> > anecdotes.
>
> Are there pointers to Relational Lisp?
>
> Cheers
Maybe it's related to LOOM?
Well, a programming benchmark where a Lisp guy cranks out
a working solution on three hours. :-) I think he/she had not
that much time on that day and had a date or something. ;-)
Let the other guys sweat and struggle. It's like
in school when you have a difficult examination and
you shout "ready!" and all the others are still trying
to figure out the meaning of the questions...
We always say here that if you have no time left you do
it in Lisp. If you have more time and more people
you can do it Java. And if you have lots of time, lots
of money and a really large horde of programmers, well then you can
use C++. But we are only a small company, so we have to use Lisp.
On 08 Sep 1999 09:55:16 +0200, Marco Antoniotti
<·······@copernico.parades.rm.cnr.it> wrote:
>> >
>> > Could you give us some URLS, papers or the like?
>> >
>
>> Haskell was the winner in program length (the C++ version was a factor
>> of 7 bigger), but something called Relational Lisp won on development
>> time (about half the Haskell time, and one seventh the time for Ada).
>> The numbers here are fuzzy, but at least they are numbers and not
>> anecdotes.
>
>Are there pointers to Relational Lisp?
>
have a look at:
"http://www.isi.edu/software-sciences/relab/ap5/ap5.html"
--
------------------------------------------------------------------------------
email: marc dot hoffmann at users dot whh dot wau dot nl
------------------------------------------------------------------------------
Hello!
In article <·················@removeme.gst.com>,
Bob Bane <····@removeme.gst.com> wrote:
>[...]
>Haskell was the winner in program length (the C++ version was a factor
>of 7 bigger), but something called Relational Lisp won on development
>time (about half the Haskell time, and one seventh the time for Ada).
>The numbers here are fuzzy, but at least they are numbers and not
>anecdotes.
Note this quote from the paper:
(9) The notable aspect of the Relational Lisp solution is the very
low development time. The documentation size is also quite low
[esp. compared to the Haskell documentation size -- H.S.], which may
partially account for this. The developer also spent 4 hours in the
kickoff meeting at NSWC.
So finally, both Haskell and Relational Lisp fared well there.
Regards, Hannah.
>(if they don't,
> they may well win on all sorts of counts, but we all know that it's very,
> very hard work to make C and C++ programs fail gracefully.)
This is at least true for C. Every now and then (regularly) the
problematic of gets comes into discussion. So it's quite amazing that
somthing which is recognised as very problematic still remains in a
library ...
I hope you don't have such a stuff in Common Lisp too ;-)
Regards
Friedrich
Friedrich Dominicus <···················@inka.de> writes:
> >(if they don't,
> > they may well win on all sorts of counts, but we all know that it's very,
> > very hard work to make C and C++ programs fail gracefully.)
>
> This is at least true for C. Every now and then (regularly) the
> problematic of gets comes into discussion. So it's quite amazing that
> somthing which is recognised as very problematic still remains in a
> library ...
Only for backwards compatibility. If you try to compile a program
calling "gets" using the GNU C compiler with default options it will
refuse to compile with a message like:
/home/cbarry/c/gets.c:13: the `gets' function is dangerous and should not be used.
You're never supposed to use "scanf" in C either, even though many C
classes (like one I took quite some semesters ago) almost always use
it. (Use fgets with sscanf instead.) Clueless instructors (like the
one I had) also still teach "void main()".
> I hope you don't have such a stuff in Common Lisp too ;-)
Not really. Nothing comparably evil or stupid, anyways.
Christopher
* the jungle scout wrote:
> Linux is not an option. All of our clients use Windows.
> Also, in my group of programmers, only 2 of us knows how
> to program under unix, and then only with Motif libraries (which are
> EXPENSIVE).
They are? Do *any* commercial Unix systems not bundle them now?
Solaris certainly does, HPUX I'm almost sure does, dunno about the
rest really. For Linux there is lesstif which is free and I think is
pretty close to motif by now.
--tim
On Fri, 03 Sep 1999 12:40:52 GMT, Bagheera, the jungle scout
<········@my-deja.com> wrote:
> If it wouldn't violate my NDA, I would happily explain it to you.
If C++ shops consider multiple dispatch such a competitive advantage that
employees are required to sign NDAs, why are you surprised that Common Lisp
systems, which provide multiple dispatch and many other standard features,
cost so much? :-)
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
Marco Antoniotti wrote:
> Bagheera, the jungle scout <········@my-deja.com> writes:
>
> > In article <··············@copernico.parades.rm.cnr.it>,
> > Marco Antoniotti <·······@copernico.parades.rm.cnr.it> wrote:
> > >
> > >
> > > Bagheera, the jungle scout <········@my-deja.com> writes:
> > >
> > > > Prove to me lisp is worth it.
> > <snip trvial C++ problem>
>
> I would be really interested to see how you managed to do this in a
> general and systematic way in C++. Really interested. Then I would
For a `general and systematic' (i.e., double dispatch that works only for
classes defined in a certain way,
not for any primitive or 3rd party datatypes you might want to dispatch on)
see OpenInventor.
CL GENERAL WARNING: Exposure to the above material has been shown to increase
the risk of hitting a wall with their heads on Lispers.
Hello!
In article <··············@copernico.parades.rm.cnr.it>,
Marco Antoniotti <·······@copernico.parades.rm.cnr.it> wrote:
>[...]
>But not in the only one that would really make you change your habits.
Please don't say "only".
There are quite a lot reasonable languages out there, even if they're
not mainstream. Check out Haskell or ML for examples besides CL.
Regards, Hannah.
Bagheera, the jungle scout wrote:
> I know, someone shoot me in the head, I've gone nuts,
Maybe not ...
> but I'm looking for a FREE lisp compiler for the PC.
> Win95/Win98 or DOS is ok.
You can start here for a list of free implementations:
http://www.elwoodcorp.com/alu/table/systems.htm#free
Also, there were some pointers on the use of Lisp / CLOS in
games on Franz's web site: http://www.franz.com
Marc
In article <············@nnrp1.deja.com>,
Bagheera, the jungle scout <········@my-deja.com> wrote:
> I know, someone shoot me in the head, I've gone nuts,
> but I'm looking for a FREE lisp compiler for the PC.
> Win95/Win98 or DOS is ok.
>
> Must be able to compile to native code, and create C/C++ linkable
> object files.
You can try the old Scheme->C translator. the original kit is still
available at ftp://gatekeeper.dec.com/pub/DEC/Scheme-to-C/ and someone
already uploaded windoze binaries (see
http://www.cygnus.com/ml/gnu-win32/1997-Jun/0547.html)
The only documentation (execpt those in the kit) I know is available at
http://www.research.digital.com/wrl/techreports/abstracts/89.1.html
> Prove to me lisp is worth it.
> --
> Bagherra <jaebear @ frenzy.com>
> http://www.frenzy.com/~jaebear
> "There's a snake in my boot!"
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.
>
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.