From: Keith Wilke
Subject: Lisp better than C?
Date:
Message-ID: <0850.AA0850@we>
Help! I need some "hard" evidence that Lisp makes you more
productive than C or C++. Does any one know of any studies that
might show this?
I am developing applications for IC CAD and have used both
C and Lisp. My experience is that I can do 3 times as much
in the programming phase in Lisp than in C. However, no one
belives me where I work. So I need some evidence.
Thanks,
--
Keith Wilke - ·········@nosc.mil or ...!ucsd!nosc!we!keithw
7687-F Rancho Fanita
Santee CA, 92071
In article <···········@we> ······@we.UUCP (Keith Wilke) writes:
>
>
> Help! I need some "hard" evidence that Lisp makes you more
>productive than C or C++. Does any one know of any studies that
>might show this?
>
> I am developing applications for IC CAD and have used both
>C and Lisp. My experience is that I can do 3 times as much
>in the programming phase in Lisp than in C. However, no one
>belives me where I work. So I need some evidence.
>
Although I believe thats the case for my own personal productivity
there are other factors that makes a language "production" language. For a
business to rely on a language to deliver applications there are several
factors:
1) robustness of environment
is the environment reliable during runtime? this is less of a problem with
compiled languages. Is the environment commercially supported? Is it widely
used (which means there are alternate sources for support)?
2) language support
are there good debuggers available? Are there many of them? [For example
if you used smalltalk and you could not debug your code; you would have
a problem] Are there third party libraries -- for example one of the
reasons C++ is attractive is because of the robust libraries available.
Does the language have support for all aspects of general programming;
i.e. database interfaces, good math libraries (this is important - one of
most important reasons fortran is still in use is IMSL!!!)?
3) code validation & pre-run checks
Lint helps find many errors in C programs before you even run the code;
C++ is strongly typed and it helps people deal with some of the errors
before they run the code. [I cannot deny this fact although I also
believe "strong-typing == weak-mind" :-)] This is all in spite of the
fact that this, for good programmers, actually *lowers* productivity quite
a bit...
4) readability, maintenance
Unfortunately, programmers in a typical company spend 80% of the time
maintaining old code and sometimes other people code. The language must
be readable ((((())))) :-) Again, for the weak mind.. :-)
5) performance
Performance is often key in making the language usable. Thats also one of
the reasons fortran is still used to solve math problems; and C++, which
I think is a terrible hack, wins over pure object-oriented languages.
This may be less relevant in the future but for now, it seems to matter.
Having said all this (whew!), your task may be prototyping than production
(in which case ignore all of the above) or you might have a specific domain
which makes some of the above less important (e.g. if all you did was matrix
manipulation, you could get 100x productivity by choosing APL).
I would *love* to hear if the above is not true. For one thing, C & C-based
hacks (C++) are tedious languages to work with which makes things like
good garbage collection impossible [I spend most of my debugging time running
after core-dumps due to explicit allocating errors]. Yeccch. If the above
problems are solved, I would *love* to use LISP.
Reha Elci
Email: ····@bugs.gs.com
To Reha Elci, about all I can say is a heart-felt "Amen". After over 8 years of programming in LISP on the Symbolics, being forced to go to C and C++ under UNIX (all three of which are in my opinion hacks) on Apollo/HP workstations is not only painful, disgusting, and frustrating, but I am amazed at how many people think that this is a "state-of-the-art" environment! Either these people are naive or stupid; I prefer to think that they are just naive. And what about this "new" area called object-oriented
programming? I'm sure glad we have the C++ weenies to explain how to do it properly now (geez! Anybody ever heard of Flavors?).
To the original poster, I realize this is not "hard" evidence, but it's an opinion that I'm sure is shared by many former LISP programmers who have been thrown to the C/C++/UNIX wolves (and let's not forget X-Windows !).
Well, better go now so I can run my script which uses grep and find to search a directory tree for occurrences of a string. I was getting so bored just using Find String !
-Craig Harpel (make sure you get the spelling right in the flames)
My opinions are my own and I have no affiliation with Symbolics.
Ah yes, the old religious debate of which computer language is better. Well
actually neither is. LISP or C. It simply a matter of what you need done.
However you demonsrate major oversight since you say "when I have to move to
C...." this is presumably on your Symbolics machine. Well most people don't
have Symbolics machines so it is certainly not applicable to them is it.
While an avid fan of LISP myself, we have to look at the realities. LISPc
compilers are not necessarily a dime a dozen, nor there prices approach a
"dime" in relative terms. LISP compilers have always been expensive, in fact
prohibitively so for LISP ever to become vogue. One of the reasons for C's
popularity is the abundance of C compilers. People have a choice. They can
buy a high quality C compiler for $100. Now compare some LISP environment
some vendor might sell. Costing maybe a $1000 and looking like it came from
medieval times with EMACS as an editor and totally command line driven in
other respects.
Sure there are exceptions. But those exceptions do not compare in overall
quality (unless you pay for it) AND nice code generation. Somehow I doubt
that a native code LISP compiler will put out nice SMALL code. That is if
you can afford one. I remember wanting to buya commercial LISP product
after I outgrew XLISP. What I found back then is that either it was a full
implementation of Common LISP (didn't agree with "1/2 way there") or if
the price was reasonable it produced native code. Too often it was an
interpreter only or pseudo machine code. Thus requiring a run time (which
did not always come with the package) which was not necessarily petite.
Perhaps things would have been different if "Turbo LISP" had come out but
some things just don't happen. People often make faces when I say I know
LISP and like it. The sad fact is it does not have much commercial value
and this is an overwhelming reason to go with something else. This is also
why FORTRAN and COBOL survive, establishment. LISP never established itself
as a popular commercial language and despite its ease of programming for
various implementations I doubt it ever will.
Pride is not worth two cents when you have to make a living and this is
why most people learn and program in C......
In article <··················@uicvm.uic.edu>, ······@uicvm.uic.edu writes:
|> Ah yes, the old religious debate of which computer language is better. Well
|> actually neither is. LISP or C. It simply a matter of what you need done.
|> However you demonsrate major oversight since you say "when I have to move to
|> C...." this is presumably on your Symbolics machine. Well most people don't
|> have Symbolics machines so it is certainly not applicable to them is it.
|>
Unfortunately, YOU demonstrate lack of ability to read an entire article before making criticisms. I specifically stated that I have moved to HP/Apollo workstations, and MANY people have them!
|> While an avid fan of LISP myself, we have to look at the realities. LISPc
|> compilers are not necessarily a dime a dozen, nor there prices approach a
|> "dime" in relative terms. LISP compilers have always been expensive, in fact
|> prohibitively so for LISP ever to become vogue. One of the reasons for C's
|> popularity is the abundance of C compilers. People have a choice. They can
|> buy a high quality C compiler for $100. Now compare some LISP environment
|> some vendor might sell. Costing maybe a $1000 and looking like it came from
|> medieval times with EMACS as an editor and totally command line driven in
|> other respects.
|>
Since you obviously come from a university environment, I will allow for your total lack of understanding of what "affordable" is in the business world. You also demonstrate a real lack of understanding of the quality of workstation- calibre LISP. While you may be correct for people hacking on PCs at home or school, the majority of people using LISP are now on workstations. Your problem is that you're judging all LISPs by what you've seen on PCs! Wake up!
|> Sure there are exceptions. But those exceptions do not compare in overall
|> quality (unless you pay for it) AND nice code generation. Somehow I doubt
|> that a native code LISP compiler will put out nice SMALL code. That is if
|> you can afford one. I remember wanting to buya commercial LISP product
|> after I outgrew XLISP. What I found back then is that either it was a full
|> implementation of Common LISP (didn't agree with "1/2 way there") or if
|> the price was reasonable it produced native code. Too often it was an
|> interpreter only or pseudo machine code. Thus requiring a run time (which
|> did not always come with the package) which was not necessarily petite.
|>
More obvious Golden Common LISP memories creeping in.
|> Perhaps things would have been different if "Turbo LISP" had come out but
|> some things just don't happen. People often make faces when I say I know
|> LISP and like it. The sad fact is it does not have much commercial value
|> and this is an overwhelming reason to go with something else. This is also
|> why FORTRAN and COBOL survive, establishment. LISP never established itself
|> as a popular commercial language and despite its ease of programming for
|> various implementations I doubt it ever will.
|>
So now we crawl back to the dark ages of FORTRAN and COBOL and now C because they are "established", even though they are pathetic languages when it comes to productivity and, especially in the case of C, unreadable. Ever hear of "The Emperor's New Clothes"?
|> Pride is not worth two cents when you have to make a living and this is
|> why most people learn and program in C......
Hence the new generation of hackers as opposed to computer scientists. It is reasoning like yours (or lack thereof) that is prevalent today. The new hackers can't see the backward evolution in computer languages that C is dragging us toward, and unfortunately, many of them are in management holding the purse-strings. Hack away if you want to, but don't say that LISP has no value simply because you don't have experience with a "real" LISP on a workstation.
I now relinquish the soapbox. Doesn't anyone else want to join in?
As I considered my last posting, I began to feel slightly ashamed of myself for spoiling the professionalism of this newsgroup. Since I have been reading this newsgroup, I have never seen any flames. As one participant in the current ridiculous "LISP vs C" flame war, I suggest to the person who prefers to remain nameless that it be taken to alt.flame. Of course, he/she will be there arguing with no one since I refuse to offer any more comments on the subject. I apologize to the rest of the group for th
e bickering and waste of bandwidth.
Craig Harpel
My opinions are my own.
In article <······················@linus.mitre.org>, ······@mitre.org (Craig Harpel) writes:
>...
>
> I now relinquish the soapbox. Doesn't anyone else want to join in?
>
Ok. How about some input from a C developer?
I'm currently developing in C. I occassionally read this group because I've
been a LISP programmer for 5 years before this job and still have strong
interest in LISP. How (why?) the hack did I get this job and how am I
performing? Well, firstly, I'd like to think of these (their respective
environments, not the languages themselves) as tools to help me do my job
rather than to confine me in their idiosyncrasies. Personally, I don't have
personal attachments to most of the programming languages (ML is an
exception -- I used to love that language). As such, I *utilize* what tools
are available to me and concentrate on solving the problem at hand,
whatever that may be.
Well, you could argue that using LISP could be more productive than, say a
C, due to its richer environment, high-level abstraction, automatic memory
management, etc., etc. Then, somebody may tell you that LISP is slow, big,
"typeless" (ok, I'm pushing it here), and so on. BTW, IMO, LISP being slow
is not a myth like they teach you in class. Yes, I've seen the benchmarks
(although some time ago) for LISPs on the workstations and they were
impressive; however, they don't mean much when you have to explain to your
users that they can't type their input just yet becuase your LISP
application is garbage collecting. Also, with the migration of the LISP
environments to the workstations, the richness of these environments, as
compared to Xerox 1186 and Symbolics, have been severely degraded. On the
other hand, the C environments have matured significantly, especially with
the availiability of interpretive C environments.
As for the original question that was raised, I don't know of any study
that has been done to compare the productiveness of the two languages/
environments. I think such study would be prohibitively expensive. Even if
one was to conduct such a study, how would s/he generalize the result to
all classes of problems? For example, even if you had 10 years of
experience in LISP and 0 years of experience in C, could you convince
your customer that you want to write a real-time application in LISP?
As another example, suppose you (with the same experience as before) had to
quickly prototype a language interpreter. Then, LISP may be your perfect
match.
So in conclusion, I think the choice of language/environment should be
based on many variables, especially the application constraints and
customer needs.
Ok, let the flames rip.
o--------------------------------------o-------------------------------------o
| Ik Su Yoo | Office: (908) 699-5764 |
| Bell Communications Research | Fax: (908) 336-2969 |
| RRC 1H-229, 444 Hoes Lane | E-mail: ··@ctt.bellcore.com |
| Piscataway, NJ 08854 | ...!bellcore!ctt!ik |
o--------------------------------------o-------------------------------------o
From: Bill Andersen
Subject: Re: Lisp better than C?
Date:
Message-ID: <45607@mimsy.umd.edu>
God, I hate this argument, but here goes. I feel qualified to enter
the ring since I have written a lot of both C and lisp code; about
60/40% lisp to C.
Simply put: If it doesn't need to run *fast*, use lisp!
Rationale:
* Most C programmers home-brew data structure manipulation code,
generally eschewing use of abstract data types and toolkits
providing the latter with proven correctness. This is based
on 4 years of experience dealing with C programmers in
government (where C dominates) and private industry. In all
fairness this is not always the case with good programmers, of
which I have only encountered a handful.
* Given the latter, all hell breaks loose when complex data
structures must be manipulated in C programs in the form
of *HUGE* memory management problems, the usual result of
which is something like:
Segmentation fault: core dumped
Unless you are a dbx ace, this sort of thing is not too
helpful.
* Such data structures come virtually for free in Common Lisp,
and modern garbage collectors provide unobtrusive memory
management with minimum performance loss. As a result, Lisp
programs tend to be easier to debug since you aren't blasted
out of your debugging environment when something goes awry.
* Lisp is definitly easier to learn for novice programmers than C
is. Having seen people learn both (and doing a bit of teaching),
people who have never been exposed to a real programming language
have an easier time with lisp, and are able to do more sophisticated
tasks earlier. Witness the use of Scheme as the first-year
teaching language at MIT, Indiana, and Rochester, to name a few.
These students are not writing checkbook balancing programs; they
are building compilers, interpreters, new languages and exploring
other advanced issues as freshmen, SIMPLY BECAUSE THEY DO NOT HAVE
TO BATTLE C's CRYPTIC SYNTAX!.
* Back to my first point. I claim that if something does not have
to run *fast*, you should use lisp. This is not to say that lisp
implementations cannot produce fast code; they can. There is no
inherent reason that the code emitted from a lisp compiler would
be any slower than the code emitted by a C compiler for the same
function. However, most lisp implementations (at least those I
know of) do not allow you to chuck all of the runtime baggage lisp
brings with it, even if you know for user you won't need it. For,
this reason, lisp is not appropriate for programs which need to
run more or less in real time. In my experience, such programs
comprise only a small proportion of the total programming to be
done.
I could go on, but I'll let people comment on what I have already
written. Have a good new year!
...Bill
--
Bill Andersen (·······@cs.umd.edu) |
University of Maryland | clever .signature saying
Department of Computer Science | under construction
College Park, Maryland 20742 |
In article <·····@mimsy.umd.edu> ·······@cs.umd.edu (Bill Andersen) writes:
>
> God, I hate this argument, but here goes. I feel qualified to enter
>the ring since I have written a lot of both C and lisp code; about
>60/40% lisp to C.
>
> Simply put: If it doesn't need to run *fast*, use lisp!
I recall reading an article in Apropos to the effect that an
organization
compared LISP and C code on a complicated VLSI application.
The LISP code ran at one half the speed of the C code. Both code
was optimized for speed. E.g. "register" was used in the C code
where appropriate. "type" was used to declare things in the LISP
code.
In article <····················@uxa.ecn.bgu.edu> ·····@uxa.ecn.bgu.edu (Dr. Laurence Leff) wrote:
>
> I recall reading an article in Apropos to the effect that an
> organization compared LISP and C code on a complicated VLSI application.
>
> The LISP code ran at one half the speed of the C code. Both code
> was optimized for speed. E.g. "register" was used in the C code
> where appropriate. "type" was used to declare things in the LISP
> code.
(Here we go again...)
These kinds of statements mean absolutely nothing. Just because declarations
were added to the lisp code doesn't mean they were the right ones; the wrong
declarations do no more good than declaring every variable in your C program
to be "register".
For any given (moderately large) application, a skilled Lisp hacker can
implement as fast a version as a skilled C hacker. The Lisp versus C wars
always come down to:
speed of development
cost of development environment
cost of delivery environment
availability of skilled hackers
Lisp wins hands down on the first one; C wins on the second and third in a
big way; and C wins on the fourth, most likely because of the second and
third, which are in a nice little feedback loop with the fourth.
There's also a school of thought that holds that it's easier to write a bad
lisp program than a bad C program, because lisp gives you so much more rope
to hang yourself with. A mediocre lisp hacker can easily produce a lot of
working but inefficient code. A mediocre C hacker generally doesn't produce
very much working code at all.
(As an aside, any halfway decent C compiler should know much better than
you do which variables should be register-allocated and which shouldn't...)
-- Jamie
···@lucid.com (Jamie Zawinski) writes:
> (As an aside, any halfway decent C compiler should know much better than
> you do which variables should be register-allocated and which shouldn't...)
Careful there... Such decisions are usually made statically. I'd hazard
that there's quite a few folx working on dynamically tuning code, but this
technology is not yet run-of-the-mill.
I've done quite a bit of work in both C and Lisp, and I have come to hate C for
the dog it really is. Much of what I do is not performance intensive. But if
it were, I'd be profiling heavily in late stages with the goal of rewriting in
C (or some other low-level language) that ~10% of the code where ~90% of the
time is being spent.
There's been other comments about teaching Lisp to beginners in lieu of C (or
some other low-level language). In my experience, this is a serious win. I
recall how long it took for me to learn Pascal, and grudgingly compare this
with the afternoon or two it takes to teach somebody the basics of a Lisp.
Regards, [Ag] ······@remus.rutgers.edu
`Gun for Hire'
From: Jeff Dalton
Subject: Re: Lisp better than C?
Date:
Message-ID: <5890@skye.ed.ac.uk>
In article <·························@romulus.rutgers.edu> ······@romulus.rutgers.edu (Silver) writes:
>There's been other comments about teaching Lisp to beginners in lieu of C (or
>some other low-level language). In my experience, this is a serious win. I
>recall how long it took for me to learn Pascal, and grudgingly compare this
>with the afternoon or two it takes to teach somebody the basics of a Lisp.
Lisp has several big advantages for teaching:
- It's interactive.
- Most datatypes have printed representations so that they
can be read or at least printed.
- The syntax is simple, without complex operator precedence
and punctuation rules.
- The presence of symbols and lists makes it easy to develop
programs that do something more interesting than low-level
manipulations of numbers and strings.
- There's no need for declarations. (Indeed, I think it's
more natural to think of objects as being typed, rather than
variables. Variable typing should be considered an aspect
of the types of functions (which are a kind of object), as
in functional languages.)
- There's automatic storage management, which also makes it
easier to regard data as objects. (It's easy to treat an
array, for example, as something you construct rather than
as something built into the program.)
Lisp's reputation for being unreadable is partly deserved, because
it doesn't support the mathematical notation that is already familiar
to many people who want to write programs and because many people
are unused to the idea that every parenthesis is significant.
On the other hand, well-written Lisp programs are not nearly as
unreadable as many people suppose. Indeed, many Lisp programmers
find Lisp more readable than other languages. "Well, they would,
wouldn't they? That's why they decided to become Lisp programmers."
seems an obvious counterargument, but I don't think that's really
all there is to it.
Lisp code is hard to read if you try to write it as if it were
C or Pascal, with lots of close parens on lines of their own
along with comments that indicate which construct they're closing.
Lisp as imitation Pascal is less readable than real Pascal.
However, the key to writing readable Lisp is to use indentation
that makes it unnecessary to pay attention to individual parens
when reading the code. (Use of a good editor makes parens
manageable when writing it.)
(For examples of well-indented code, look at the better textbooks,
such as Abelson and Sussman's.)
-- jd
In article <·····@mimsy.umd.edu> ·······@cs.umd.edu (Bill Andersen) writes:
* Back to my first point. I claim that if something does not have
to run *fast*, you should use lisp. This is not to say that lisp
implementations cannot produce fast code; they can. There is no
inherent reason that the code emitted from a lisp compiler would
be any slower than the code emitted by a C compiler for the same
function. However, most lisp implementations (at least those I
know of) do not allow you to chuck all of the runtime baggage lisp
brings with it, even if you know for user you won't need it. For,
this reason, lisp is not appropriate for programs which need to
run more or less in real time. In my experience, such programs
comprise only a small proportion of the total programming to be
done.
A couple elaborations:
- "Real-time" is not the same thing as "blindingly fast." Real-time
refers to the ability of a system to respond to each input within a
fixed time limit. Depending on the specific application, this limit
may leave ample time for high-level information processing, an
increment of garbage collection, etc. Similarly, some real-time
constraints may be probabilistic rather than absolute, thereby
permitting longer delays as long as they are extremely rare.
- The speed of a complex system is determined more than anything by
its hardware and software architecture. If a more powerful
programming language makes possible the successful deployment of a
better architecture, the resulting system may be faster than those
built by more primitive means.
Lawrence G. Mayka
AT&T Bell Laboratories
···@iexist.att.com
Standard disclaimer.
What's more or less killed LISP in the commercial market is very
simple to understand:
If I write a program in C (other languages could be used as examples)
I can take the output and ship it, done. It will run on target
systems that it was compiled for.
If I write a program in LISP I have to ship an entire LISP interpreter
or equivalent run-time environment with my package.
In most cases this is separately licensed and controlled (e.g.
copying, royalties etc.) Just negotiating some arrangement to be able
to ship this with a product is more than most start-up developers want
to get into. In the first place, it will take business leverage and
lawyers etc.
I love LISP dearly, don't get me wrong. But I believe that this one
thing has essentially killed it (commercially.)
Add to that the fact that even if you could ship the environment it
will usually be huge relative to the application you're shipping
("hello world"? Oh, about 12MB of disk space to install.) I suppose
in its favor once you have it it doesn't grow much, but that first
step is a killer.
--
-Barry Shein
Software Tool & Die | ···@world.std.com | uunet!world!bzs
Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD
In article <··················@uicvm.uic.edu> ······@uicvm.uic.edu writes:
>
>While an avid fan of LISP myself, we have to look at the realities. LISP
>compilers have always been expensive, in fact prohibitively so for LISP ever
>to become vogue. People [...] can buy a high quality C compiler for $100. Now
>compare some LISP environment some vendor might sell. Costing maybe a $1000
I agree that Common Lisp's high cost and poor availability on PCs has made it
a much less popular language than it might have been. Many people who are
using Scheme are doing so not mainly because of its elegance, but because of
its simplicity. This simplicity allows Scheme to run on PCs with little
memory, and also makes implementation cheap enough so that there are several
low-cost (or free) implementations.
If Common Lisp could have fit this niche as well, then it probably would have
increased the total Lisp user community (including Scheme) since CL seems to
have been more successful than Scheme in selling itself as a practical
programming tool.
Although we have not ported to the PC, I hope that the CMU Common Lisp
project's high-quality public domain Common Lisp will allow CL to move into
the PC market. Typical PC hardware and software probably won't support a
workstation-quality CL for two years (need 8meg of memory + VM).
>and looking like it came from medieval times with EMACS as an editor and
>totally command line driven in other respects.
Allegro has long offered a reasonable development environment, but
unfortunately it adds a great deal to the already high cost, so most academic
users don't buy it. Now that Lucid is no longer barred from marketing a CL
environment by the Sun agreement, look forward to an interesting product from
them.
A full programming environment is essential to gain the full productivity
advantages of Lisp. I believe that CL vendors are shooting themselves in the
foot by trying to squeeze out some extra profit by selling the environment as
an extra-cost option.
Rob MacLachlan (···@cs.cmu.edu)
>A full programming environment is essential to gain the full productivity
>advantages of Lisp. I believe that CL vendors are shooting themselves in the
>foot by trying to squeeze out some extra profit by selling the environment as
>an extra-cost option.
Hear hear! At least 2 CL vendors (Venue and Harlequin) include the full
environment. I know for sure in Venue's case (and most likely in
Harlequin's case too) that the Lisp can't be seperated from the
environment. Back when Medley only ran on proprietary hardware, there
was an occasional request for a telnet server. The standard response
was "Sure, we'd be happy to, if you'll just tell us what you'd like it
to do." Person would sit and think for a minute, then respond "You're
right, never mind." As close as one could come would be something like
the Interlisp-10 interface, which no one wanted.
>I agree that Common Lisp's high cost and poor availability on PCs has made it
>a much less popular language than it might have been. Many people who are
>using Scheme are doing so not mainly because of its elegance, but because of
>its simplicity.
Somehow I don't see people switching to CL for simplicity...:-)
...arun
----------------------------------------------------------------------------
Arun Welch
Lisp Systems Programmer, Lab for AI Research, Ohio State University
·····@cis.ohio-state.edu
In article <···················@sacral.cis.ohio-state.edu> ·····@sacral.cis.ohio-state.edu (Arun Welch) writes:
Hear hear! At least 2 CL vendors (Venue and Harlequin) include the full
environment. I know for sure in Venue's case (and most likely in
Harlequin's case too) that the Lisp can't be seperated from the
environment. Back when Medley only ran on proprietary hardware, there
I think Harlequin now offers an application delivery system, which
does not include the environment. But I agree that developer systems
should (and do, for Harlequin) include it.
Lawrence G. Mayka
AT&T Bell Laboratories
···@iexist.att.com
Standard disclaimer.
From: Jeff Dalton
Subject: Re: Cost of Lisp (was Re: Lisp better than C?)
Date:
Message-ID: <5888@skye.ed.ac.uk>
In article <·······················@cs.cmu.edu> ····@cs.cmu.edu (Rob MacLachlan) writes:
>A full programming environment is essential to gain the full productivity
>advantages of Lisp. I believe that CL vendors are shooting themselves in the
>foot by trying to squeeze out some extra profit by selling the environment as
>an extra-cost option.
Hear, hear!
Another problem with Lisp is that environments are often inferior
in many ways to the environments available for C. How many Lisps
have something like dbxtool, for example? Most Lisp debugging
seems to predate the invention of screen editors. This is
extremely annoying, because a better environment is supposed to
be one of the advanatges of Lisp.
In article <······················@linus.mitre.org>, ······@mitre.org
(Craig Harpel) writes:
|> To Reha Elci, about all I can say is a heart-felt "Amen". After over 8
|> years of programming in LISP on the Symbolics, being forced to go to C and
|> C++ under UNIX (all three of which are in my opinion hacks) on Apollo/HP
|> workstations is not only painful, d|> isgusting, and frustrating, but I am
|> amazed at how many people think that this is a "state-of-the-art" environment!
|> Either these people are naive or stupid; I prefer to think that they are just
|> naive. And what about this "new" area called object-oriented programming?
|> I'm sure glad we have the C++ weenies to explain how to do it properly now
|> (geez! Anybody ever heard of Flavors?).
(...additional ravings deleted...)
Nobody forced you, Craig.
Incidentally, direct his flames to: ······@woodstock.mitre.org.
--
| Randy Crawford ········@mitre.org
|
| N=1 -> P=NP 703 883-7940
In article <······················@linus.mitre.org>, ········@fermat.mitre.org (Randolph Crawford) writes:
>
> Nobody forced you, Craig.
Spoken like a true SINK (SIngle, No Kids), Randolph.
>
> Incidentally, direct his flames to: ······@woodstock.mitre.org.
Don't bother. I can't receive E-mail yet.