Hello!
First of all, I apologize for touching this topic again considering the
fact that there were and are many discussions about this. I have read
almost everything I could find on this topic, yet I could not answer my
question.
I am a novice with LISP (about two month of intensive self-study), but
it is already my favorite language (I also did some C and VB programming).
I am amazed by the flexibility of the language, including the ability
to choose any of the three most popular programming styles (imperative,
functional, and object-oriented if that is not already obvious). The
one problem I am facing is the lack of berable libraries for such things
as GUI or networking. I know that there are several GUI projects under
development. I don't recall any networking libraires at all, though.
Right now I'm working on a simple project -- the game of Yahtzee. I have
the core ready, but stuck on the GUI part (I really don't want to do it
with stream-based interface). I compiled CLX (the LISP implementation I am
using is CMU CL) and have done some very basic things with it (like
subwindows, colors, text, and so on). It seemed pretty easy to use and
relatively nice-looking to be suitable for my game. Unfortunately as soon
as I tried to make some simple widgets (particualary a button widget) I
discovered that it would take a lot of work to make it usable, much longer
than porting the core game to C or VB and using one of the many GUI
toolkits available for them. Oops, I didn't mean to write this, but maybe
it will serve as an example...
My real question is, "Can LISP be used as general purpose programming
language?" By 'general purpose' I mean a language that can be used to
develop small (and perhaps large) GUI programs for everyday tasks such as
mail client, image viewer, or something of that sort. I know LISP is
excellent when it comes to mathematical and logical problems, and of course
the AI, but what about every-day life? Can someone really abandon C and do
something like that using LISP?
And while I'm at asking question, can anyone suggest how I can finish that
game in LISP? That is, are there any GUI toolkits avaialble for LISP that
are free and at least some documentation?
Thank you in advance,
rk
P.S. NOTE: By no means do I try to start yet another holy war, I am merely
trying to decide whether I should spend more time learning this fantastic
language or abandon it and continue with something more mainstream. I also
don't try to say LISP is slower, bigger, or uglier than the mainstream
languages, because I know none of that is true (in most cases anyways).
--
Richard Krushelnitskiy "A mathematician is a blind man in a dark
·········@gmx.net room looking for a black cat which isn't
http://rkrush.cjb.net there." -- Charles Darwin
From: Bulent Murtezaoglu
Subject: Re: LISP for general programming? (sorry)
Date:
Message-ID: <87ae4bjtpg.fsf@nkapi.internal>
[...]
RK> And while I'm at asking question, can anyone suggest how I can
RK> finish that game in LISP? That is, are there any GUI toolkits
RK> avaialble for LISP that are free and at least some
RK> documentation?
Garnet is free, runs under CMUCL can comes with first rate and voluminous
documentation.
see:
http://www.cs.cmu.edu/afs/cs.cmu.edu/project/garnet/www/garnet-home.html
and:
ftp://ftp.csl.sri.com/pub/users/gilham/garnet/
I have used (toyed with) CLUE CLIO and CLIM a longish time ago.
CLIM worked fine for me, but you have to get a commercial Lisp although
there is McCLIM under development. I liked CLUE, but it is meant as
a substrate to build stuff like CLIO (which seemed buggy when I tried
it). Google should know where those are.
hope this helps,
BM
"Richard Krush" <·········@gmx.net> wrote in message
··················@ID-60069.news.dfncis.de...
> My real question is, "Can LISP be used as general purpose programming
> language?" By 'general purpose' I mean a language that can be used to
> develop small (and perhaps large) GUI programs for everyday tasks such as
> mail client, image viewer, or something of that sort. I know LISP is
> excellent when it comes to mathematical and logical problems, and of
course
> the AI, but what about every-day life? Can someone really abandon C and do
> something like that using LISP?
Yes. I have written several apps with Mac-like GUIs on the Mac using MCL. I
also worked on a version of the Newton OS written mostly in Dylan (that
never shipped) whose entire user interface and all its frameworks were in
Dylan (which at the time was called 'Ralph' and close to indistinguishable
from Scheme + CLOS). I am presently writing a game in Corman Common Lisp on
Windows. I have also written commercial and enterprise applications using C,
C++ and Java. All things considered, I'd rather do it in LISP.
> And while I'm at asking question, can anyone suggest how I can finish that
> game in LISP? That is, are there any GUI toolkits avaialble for LISP that
> are free and at least some documentation?
Other people can say more about that. One of my coworkers on Newton worked
on Garnet and thought it was pretty good.
Richard Krush <·········@gmx.net> writes:
> I am a novice with LISP (about two month of intensive self-study), but
> it is already my favorite language (I also did some C and VB programming).
> I am amazed by the flexibility of the language, including the ability
> to choose any of the three most popular programming styles (imperative,
> functional, and object-oriented if that is not already obvious). The
> one problem I am facing is the lack of berable libraries for such things
> as GUI or networking. I know that there are several GUI projects under
> development. I don't recall any networking libraires at all, though.
I don't like to comment on the philosophical question in the subject
header, since I feel that it is an unanswerable as well as pretty
useless question. Instead I'll stick to trying to provide possible
answers to your specific problems.
As to GUI libraries see below. WRT networking libraries, what do you
find missing, or in other words, what _is_ a networking library under
your definition? CMU CL (your implementation of choice) provides
a networking layer based on the socket API, as well as providing
higher-level systems for a direct CMU CL <-> CMU CL RPC layer. Most
other lisp implementations do provide at least access to the socket
API, and a number of them provide other higher-level mechanisms, like
CORBA, Java RMI, etc.
There are third-party libraries for a number of layered protocols,
like HTTP, SNMP, etc.
> Right now I'm working on a simple project -- the game of Yahtzee. I have
> the core ready, but stuck on the GUI part (I really don't want to do it
> with stream-based interface). I compiled CLX (the LISP implementation I am
> using is CMU CL) and have done some very basic things with it (like
> subwindows, colors, text, and so on). It seemed pretty easy to use and
> relatively nice-looking to be suitable for my game. Unfortunately as soon
> as I tried to make some simple widgets (particualary a button widget) I
> discovered that it would take a lot of work to make it usable, much longer
> than porting the core game to C or VB and using one of the many GUI
> toolkits available for them. Oops, I didn't mean to write this, but maybe
> it will serve as an example...
CLX is the equivalent of Xlib for C, i.e. it provides only access to
the basic substrate protocol of X (which pretty much only knows about
windows, events, primitive drawing-ops and resources). What you
probably want is a toolkit that sits on top of this basic mechanism,
and provides such things as widgets, etc.
Depending on your needs, there are several possible candidates that
work with CMU CL. Among them is e.g. CLM (the CMUCL version thereof),
which gives you access to most of the Motif toolkit and widget-set,
including its button, list, slider, etc. widgets, etc.
CLM comes with CMU CL (in the extras package, together with a
precompiled version of CLX), and works out of the box with both 1.x
Motif and Lesstif libraries. It is used in conjunction with CLX.
While there are certainly nicer (even more high-level) GUI toolkits
for Lisp, you will find that CLM is pretty easy to use.
> And while I'm at asking question, can anyone suggest how I can finish that
> game in LISP? That is, are there any GUI toolkits avaialble for LISP that
> are free and at least some documentation?
CLM is documented to a certain degree, and since it just provides
access to the Motif API, you can use the documentation of Motif 1.x
for the details (last time I looked, SCO had versions of the Motif
doc-set available online).
See the ALU site at http://www.lisp.org/ and/or CLiki at
http://ww.telent.net/cliki/ for other GUI toolkits.
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
Richard Krush <·········@gmx.net> writes:
> My real question is, "Can LISP be used as general purpose programming
> language?" By 'general purpose' I mean a language that can be used to
> develop small (and perhaps large) GUI programs for everyday tasks such as
> mail client, image viewer, or something of that sort. I know LISP is
> excellent when it comes to mathematical and logical problems, and of course
> the AI, but what about every-day life? Can someone really abandon C and do
> something like that using LISP?
There appears to be an unstated requirement here that you want to do
it all using free tools (otherwise, talk to your vendor about their
GUI tools; most respectable commercial implementations have such
things).
Short answer: most of the bits are available, lots of them are alpha
or beta quality, all needs some massaging to get it to work well
together. Liken it to the state of 1993-era Linux systems.
> And while I'm at asking question, can anyone suggest how I can finish that
> game in LISP? That is, are there any GUI toolkits avaialble for LISP that
> are free and at least some documentation?
Other people have pointed out CLM and Garnet. There's also (two sets
of) bindings to the GTK+ toolkit that Gnome uses, and an
under-development CLIM reimplementation effort
clg, see http://ww.telent.net/cliki/clg
cl-gtk, see http://ww.telent.net/cliki/cl-gtk
McCLIM, see http://www.mikemac.com/mikemac/McCLIM/index.html
> P.S. NOTE: By no means do I try to start yet another holy war, I am merely
> trying to decide whether I should spend more time learning this fantastic
> language or abandon it and continue with something more mainstream. I also
Average daily page requests on CLiki have increased six-fold[*] since it
was first installed a year ago. Learn CL now and you could be in on
the next wave before it's fashionable ;-)
-dan
[*] yes, up from a poxy 100 pages/day to an almost-as-poxy 600. It's
a start ...
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
On 18 May 2001 01:57:45 GMT, Richard Krush <·········@gmx.net> wrote:
> And while I'm at asking question, can anyone suggest how I can finish that
> game in LISP? That is, are there any GUI toolkits avaialble for LISP that
> are free and at least some documentation?
See the graphics toolkits page at CLiki:
http://ww.telent.net/cliki
Also note that the CLISP distribution includes a game written in CLX that
may provide you with useful ideas:
http://clisp.sf.net/
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
Hello!
Thank you all for replying, I learned some things I didn't know and
received many encouraging facts, which helped me find my true self and
stick with LISP.
About the GUI toolkits.. I knew there are many projects, but all of them
are either in ALPHA/BETA stages or have been dead for quite some time.
The commercial toolkits are very good, but due to my low income (I am
still a high school student) I cannot afford to buy either CLIM or CAPI.
From the information provided from the replies, I decided to give Garnet
and CLM a try (although Garnet is dead and CLM too, I suspect).
I must say that what I posted was very far from what I intended to do
(as can be seen from the subject). I meant for it to be yet another
philosophical discussion (hopefully a short one) that would help me
defeat the "evil part" of my brain which tries to convince me that LISP
is not worth the time and I should go back to C. I also hoped that I
would receive replies from several people who have done "general" work
using LISP. Instead I wrote a chaotic cry for help regarding GUI toolkits
and made myself look like an idiot who haven't heard about web search.
I am very sorry about this.
Regards,
rk
Hey Richard,
I'm a total newbie to Lisp with a fast connection so I downloaded several
tools. The eval version of Franz has a really easy to use window building
tools if that's what your interested in - very much like Microsoft IDEs.
I'm having fun playing with it because I don't feel so lost with a familiar
IDE.
Wayne
"Richard Krush" <·········@gmx.net> wrote in message
·····························@localhost.localnet...
> Hello!
>
> Thank you all for replying, I learned some things I didn't know and
> received many encouraging facts, which helped me find my true self and
> stick with LISP.
>
> About the GUI toolkits.. I knew there are many projects, but all of them
> are either in ALPHA/BETA stages or have been dead for quite some time.
> The commercial toolkits are very good, but due to my low income (I am
> still a high school student) I cannot afford to buy either CLIM or CAPI.
> From the information provided from the replies, I decided to give Garnet
> and CLM a try (although Garnet is dead and CLM too, I suspect).
>
> I must say that what I posted was very far from what I intended to do
> (as can be seen from the subject). I meant for it to be yet another
> philosophical discussion (hopefully a short one) that would help me
> defeat the "evil part" of my brain which tries to convince me that LISP
> is not worth the time and I should go back to C. I also hoped that I
> would receive replies from several people who have done "general" work
> using LISP. Instead I wrote a chaotic cry for help regarding GUI toolkits
> and made myself look like an idiot who haven't heard about web search.
> I am very sorry about this.
>
> Regards,
> rk
"Richard Krush" <·········@gmx.net> wrote
...
> I must say that what I posted was very far from what I intended to do
> (as can be seen from the subject). I meant for it to be yet another
> philosophical discussion (hopefully a short one) that would help me
> defeat the "evil part" of my brain which tries to convince me that LISP
> is not worth the time and I should go back to C. I also hoped that I
> would receive replies from several people who have done "general" work
> using LISP.
What do you mean by "general" work?
We have been writing industrial software in Lisp for some years now with
GUI, 3D, real-time etc...
I will make a web site when I have time but until then I've put some screen
shots here:
http://www.fractalconcept.com/ndt/andt.html
We used to write this in C/C++ before but the productivity was at least 5 to
10 times lower and it was much harder to write an application that can work
for days.
Marc
"Marc Battyani" <·············@fractalconcept.com> wrote in message news:<············@reader1.fr.uu.net>...
> GUI, 3D, real-time etc...
> I will make a web site when I have time but until then I've put some screen
> shots here:
> http://www.fractalconcept.com/ndt/andt.html
> We used to write this in C/C++ before but the productivity was at least 5 to
> 10 times lower and it was much harder to write an application that can work
> for days.
>
> Marc
Looks very interesting. Which Lisp implementation did you use ?
-Klaus.
"Klaus Momberger" <···············@yahoo.com> wrote > "Marc Battyani"
<·············@fractalconcept.com> wrote
> > GUI, 3D, real-time etc...
> > I will make a web site when I have time but until then I've put some
screen
> > shots here:
> > http://www.fractalconcept.com/ndt/andt.html
> > We used to write this in C/C++ before but the productivity was at least
5 to
> > 10 times lower and it was much harder to write an application that can
work
> > for days.
> >
> Looks very interesting. Which Lisp implementation did you use ?
LispWorks under NT/W2k
I've given more details about it in another post.
Marc
Marc Battyani wrote:
> "Richard Krush" <·········@gmx.net> wrote
> ...
> > I must say that what I posted was very far from what I intended to do
> > (as can be seen from the subject). I meant for it to be yet another
> > philosophical discussion (hopefully a short one) that would help me
> > defeat the "evil part" of my brain which tries to convince me that LISP
> > is not worth the time and I should go back to C. I also hoped that I
> > would receive replies from several people who have done "general" work
> > using LISP.
>
> What do you mean by "general" work?
> We have been writing industrial software in Lisp for some years now with
> GUI, 3D, real-time etc...
> I will make a web site when I have time but until then I've put some screen
> shots here:
> http://www.fractalconcept.com/ndt/andt.html
> We used to write this in C/C++ before but the productivity was at least 5 to
> 10 times lower and it was much harder to write an application that can work
> for days.
>
> Marc
Hi,
I often read that programming in Lisp is much more productive compared to C/C++.
I'm not very experienced in Lisp programming but I can imagine that it is indeed
more
productive. But I can hardly imagine the factor of 5 to 10. At the moment I
switched
to OCaml for some of my work but I'm still considering using CL. So it would by
quite
helpful for me to know more of your experience. I would be very appreciative if
you
could tell me what are the reasons are for that great improvement in
productivity?
Rolf
From: Kent M Pitman
Subject: Lisp productivity [Re: LISP for general programming? (sorry)]
Date:
Message-ID: <sfwvgmx462f.fsf_-_@world.std.com>
Rolf Wester <···········@t-online.de> writes:
> I often read that programming in Lisp is much more productive
> compared to C/C++.
>
> I'm not very experienced in Lisp programming but I can imagine that
> it is indeed more productive. But I can hardly imagine the factor of
> 5 to 10. At the moment I switched to OCaml for some of my work but
> I'm still considering using CL. So it would by quite helpful for me
> to know more of your experience. I would be very appreciative if you
> could tell me what are the reasons are for that great improvement in
> productivity?
It's an observation a lot of people have made, it's not a thing that's
easy to debate. It might not even be a true point, though I suspect
there are individual cases where what you say is an understatement,
and I also suspect that on average there's some truth to a
productivity multiplier, even if 5 is not it.
One point that's certainly true though is that the s-expression style,
paren-wrapped forms, means that Emacs editing commands, including
keyboard macros, can easily pick up whole, well-formed expressions and
move them as a unit when re-shaping code. It's one of the reasons
that Lisp users are so grudging about giving up this feature of the
language which they know irritates outsiders so much. Most other
programming languages require reaching with the mouse and using a
careful wipe to designate both ends of an expression before it can be
manipulated, and even then it's both not reliable (easy to make a
typo) and hard to automate.
Infix languages have the problem that if your cursor is:
a+b*c
^
and you say "delete the previous expression", you might mean
"delete c" or "delete b*c" or "delete a+b*c". But in Lisp there is never
an ambiguity, because every expression has its own paren boundary, so
the cursor is at any of the three indicated positions, each unambiguously
designating a particular "prior expression". Hence keyboard commands that
pick up or exchange expressions, that raise and lower expressions, etc.
are very easy to write.
(+ a (* b c))
^^^
This one point is not responsible for the entire speed gain, but is
illustrative of the idea that a language's structure can make a
productivity effect.
I'm sure other issues could be listed. I started a new thread so others might
feel encouraged to contribute ideas.
From: mikel evins
Subject: Re: Lisp productivity [Re: LISP for general programming? (sorry)]
Date:
Message-ID: <9e6fu6$8hu@dispatch.concentric.net>
"Kent M Pitman" <······@world.std.com> wrote in message
·······················@world.std.com...
> Rolf Wester <···········@t-online.de> writes:
>
> > I often read that programming in Lisp is much more productive
> > compared to C/C++.
> >
> > I'm not very experienced in Lisp programming but I can imagine that
> > it is indeed more productive. But I can hardly imagine the factor of
> > 5 to 10. At the moment I switched to OCaml for some of my work but
> > I'm still considering using CL. So it would by quite helpful for me
> > to know more of your experience. I would be very appreciative if you
> > could tell me what are the reasons are for that great improvement in
> > productivity?
>
> It's an observation a lot of people have made, it's not a thing that's
> easy to debate. It might not even be a true point, though I suspect
> there are individual cases where what you say is an understatement,
> and I also suspect that on average there's some truth to a
> productivity multiplier, even if 5 is not it.
My unscientific estimate of the productivity gain in the Dylan version of
Newton versus the competing C++ version is a factor of 4. (The experienced
lispers working on the Dylan version produced roughly 40% of the feature set
of the C++ version writtien by experienced C++ programmers; there were ten
times as many C++ folks.) I'm ignoring common low-level code between the two
projects, but also very-high-level features that the C++ version didn't
have.
Speed was essentially indistinguishable; the Dylan version was maybe 50%-60%
bigger in RAM, unoptimized.
I am of course biased; take my estimate with a grain of salt. Also, not all
the C++ coders were equally experienced (but they did have some really good
ones).
[...]
> This one point is not responsible for the entire speed gain, but is
> illustrative of the idea that a language's structure can make a
> productivity effect.
I agree with the point about Lisp's editor friendliness. When Dylan's syntax
changed it lost something more significant than I expected.
> I'm sure other issues could be listed. I started a new thread so others
might
> feel encouraged to contribute ideas.
Typical memory management errors in C and C++ mean you spend three days
crawling around in a debugger to figure out why the program crashes hard in
some plave apparently totally unrelated to the error. Typical memory
management errors in Lisp mean you notice when you run your memory profiling
tools that you are wasting too much time in GC and spend an hour or two
reorganizing your representations.
You don't have to make a decision about representation up front as you do in
C and C++, because it's so easy to make anything out of lists. After you
figure out how the program is supposed to work you can build a data
structure that facilitates fast execution. While you're figuring out what
it's supposed to do it doesn't matter that it's slow. Lisp's semantics make
it very easy to change representation without changing interface.
User functions are indistinguishable from Lisp functions, and macros enable
you to creat your own 'primitives', so when you find a cliche that helps
your productiviy it's easy to make it part of the language itself.
Pointers bugs are bad and hard (i.e. time-consuming) to debug. You don't
make many pointer errors in Lisp.
In Lisp the program's runtime is sitting there on the operating table in
front of you and everything is accessible as elements of the language. It's
easy to find out exactly what's going on in your program. If a variable has
an unexpected value you can halt the program and change it to what you
thought it should be and then continue to see if the program does what you
think it should with the right data.
I'm sure there are lots more reasons.
On 19 May 2001 19:01:26 GMT, "mikel evins" <·······@mikelevins.com>
wrote:
>My unscientific estimate of the productivity gain in the Dylan version of
>Newton versus the competing C++ version is a factor of 4. (The experienced
>lispers working on the Dylan version produced roughly 40% of the feature set
>of the C++ version writtien by experienced C++ programmers; there were ten
>times as many C++ folks.) I'm ignoring common low-level code between the two
>projects, but also very-high-level features that the C++ version didn't
>have.
>
>I am of course biased; take my estimate with a grain of salt. Also, not all
>the C++ coders were equally experienced (but they did have some really good
>ones).
The problem with such comaprisons is this:
even if you had equally experienced C++ as Lisp programmers they
would still not be as good ( in general quality terms ). The reason
is that all the crappy programmers will tend to accumulate in
the more popular language. There are a lot of reasons for this (eg):
crappy programmers tend not to care about programming
just what will make them money ( ie the more popular languages ),
crappy programmers find it easier to hide their ineptness in a bigger
crowd ( the low the quality of programmers exacerbates itself ),
and lower quality programmers tend to want to learn as easily as
possible--often times by buying a book like "Popular Language
for Morons", since the books are poorer in quality the programmer
tends to be poorer in quality ( and you are not likely to find a
book "Unpopular Language for Morons", it just won't sell ).
So it's likely you will find several crappy "Popular Language"
programmers in a group, while you won't find any crappy
"Unpopular Langauge" programmers in a same sized group.
From: mikel evins
Subject: Re: Lisp productivity [Re: LISP for general programming? (sorry)]
Date:
Message-ID: <9e9pb1$cfn@dispatch.concentric.net>
"Thaddeus L Olczyk" <······@interaccess.com> wrote in message
·······················@nntp.interaccess.com...
> On 19 May 2001 19:01:26 GMT, "mikel evins" <·······@mikelevins.com>
> wrote:
>
> >My unscientific estimate of the productivity gain in the Dylan version of
> >Newton versus the competing C++ version is a factor of 4. (The
experienced
> >lispers working on the Dylan version produced roughly 40% of the feature
set
> >of the C++ version writtien by experienced C++ programmers; there were
ten
> >times as many C++ folks.) I'm ignoring common low-level code between the
two
> >projects, but also very-high-level features that the C++ version didn't
> >have.
> >
> >I am of course biased; take my estimate with a grain of salt. Also, not
all
> >the C++ coders were equally experienced (but they did have some really
good
> >ones).
> The problem with such comaprisons is this:
> even if you had equally experienced C++ as Lisp programmers they
> would still not be as good ( in general quality terms ). The reason
> is that all the crappy programmers will tend to accumulate in
> the more popular language. There are a lot of reasons for this (eg):
> crappy programmers tend not to care about programming
> just what will make them money ( ie the more popular languages ),
> crappy programmers find it easier to hide their ineptness in a bigger
> crowd ( the low the quality of programmers exacerbates itself ),
> and lower quality programmers tend to want to learn as easily as
> possible--often times by buying a book like "Popular Language
> for Morons", since the books are poorer in quality the programmer
> tends to be poorer in quality ( and you are not likely to find a
> book "Unpopular Language for Morons", it just won't sell ).
>
> So it's likely you will find several crappy "Popular Language"
> programmers in a group, while you won't find any crappy
> "Unpopular Langauge" programmers in a same sized group.
Your argument is sound, but I don't think it applies to the project in
question, which not only was not riddled with crappy programmers, but had
some of the best. But these are totally unquantifiable assessments, so my
opinion, no matter how confident I might be of it, can be written off to
bias.
So be it.
From: David Thornley
Subject: Re: Lisp productivity [Re: LISP for general programming? (sorry)]
Date:
Message-ID: <NMgO6.3157$Dd5.1210168@ruti.visi.com>
In article <··················@world.std.com>,
Kent M Pitman <······@world.std.com> wrote:
>Rolf Wester <···········@t-online.de> writes:
>
>> I often read that programming in Lisp is much more productive
>> compared to C/C++.
>>
>> I'm not very experienced in Lisp programming but I can imagine that
>> it is indeed more productive. But I can hardly imagine the factor of
>
>It's an observation a lot of people have made, it's not a thing that's
>easy to debate. It might not even be a true point, though I suspect
>there are individual cases where what you say is an understatement,
>and I also suspect that on average there's some truth to a
>productivity multiplier, even if 5 is not it.
>
My experience is that programming is easier and more fun in CL
than in C++, although I've never done any study of how long
it takes. Richard Gabriel ("Patterns of Software Development")
at one point says that moving his people form CL to C++ seemed
to be a 30% productivity hit.
I think there are other factors involved. I think people who
program in CL for a while become better programmers in general.
They think in different ways, and see more different ways to
do things. (It is possible that, if the world programmed in CL,
that those who went out and learned C++ came back with new
insights.) I know that I've had a good deal of success while
thinking Lispy and writing C++. This suggests that Gabriel's
30% is a considerable underestimate for people who haven't worked
in Lisp before.
--
David H. Thornley | If you want my opinion, ask.
·····@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
From: Hartmann Schaffer
Subject: Re: Lisp productivity [Re: LISP for general programming? (sorry)]
Date:
Message-ID: <slrn9gja54.1i2.hs@paradise.nirvananet>
In article <······················@ruti.visi.com>, David Thornley wrote:
> ...
>>It's an observation a lot of people have made, it's not a thing that's
>>easy to debate. It might not even be a true point, though I suspect
>>there are individual cases where what you say is an understatement,
>>and I also suspect that on average there's some truth to a
>>productivity multiplier, even if 5 is not it.
>>
>My experience is that programming is easier and more fun in CL
>than in C++, although I've never done any study of how long
>it takes. Richard Gabriel ("Patterns of Software Development")
>at one point says that moving his people form CL to C++ seemed
>to be a 30% productivity hit.
>
>I think there are other factors involved. I think people who
>program in CL for a while become better programmers in general.
>They think in different ways, and see more different ways to
>do things. (It is possible that, if the world programmed in CL,
>that those who went out and learned C++ came back with new
>insights.) I know that I've had a good deal of success while
>thinking Lispy and writing C++. This suggests that Gabriel's
>30% is a considerable underestimate for people who haven't worked
>in Lisp before.
not necessarily: his observation goes in the other direction. this could
indicate that sufficient previous exposure to lisp would make them also
more productive in the languages they are (forced to be) moving to
--
hs
----------------------------------------------------------------
"The cheapest pride is national pride. I demonstrates the lack of
characteristics and achievements you can be proud of. The worst loser
can have national pride" - Schopenhauer
From: David Thornley
Subject: Re: Lisp productivity [Re: LISP for general programming? (sorry)]
Date:
Message-ID: <jGbP6.3761$Dd5.1443623@ruti.visi.com>
In article <·················@paradise.nirvananet>,
Hartmann Schaffer <··@paradise.nirvananet> wrote:
>In article <······················@ruti.visi.com>, David Thornley wrote:
>>>
>>My experience is that programming is easier and more fun in CL
>>than in C++, although I've never done any study of how long
>>it takes. Richard Gabriel ("Patterns of Software Development")
>>at one point says that moving his people form CL to C++ seemed
>>to be a 30% productivity hit.
>>
>>I think there are other factors involved. I think people who
>>program in CL for a while become better programmers in general.
....
>>thinking Lispy and writing C++. This suggests that Gabriel's
>>30% is a considerable underestimate for people who haven't worked
>>in Lisp before.
>
>not necessarily: his observation goes in the other direction. this could
>indicate that sufficient previous exposure to lisp would make them also
>more productive in the languages they are (forced to be) moving to
>
That's what I meant, anyway. Gabriel's people were Lisp programmers,
and so I would expect them to be more effective C++ programmers
than usual, once familiar with C++. This means that moving a C++
programmer to Common Lisp and giving that person enough time to
start thinking Lispy would probably show much more than a 30%
improvement.
Others more knowledgeable or less cautious than I can speculate
how much.
--
David H. Thornley | If you want my opinion, ask.
·····@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
········@visi.com (David Thornley) wrote:
>Kent M Pitman <······@world.std.com> wrote:
>>It's an observation a lot of people have made, it's not a thing that's
>>easy to debate. It might not even be a true point, though I suspect
>>there are individual cases where what you say is an understatement,
>>and I also suspect that on average there's some truth to a
>>productivity multiplier, even if 5 is not it.
>>
>My experience is that programming is easier and more fun in CL
>than in C++, although I've never done any study of how long
>it takes. Richard Gabriel ("Patterns of Software Development")
>at one point says that moving his people form CL to C++ seemed
>to be a 30% productivity hit.
>
In his book, Software Development (Fashioning the Baroque), Darrel Ince already
wrote in 1988 that it was not uncommon that a program in a very high level
language like Lisp is 5 to 10 times shorter than the same program in a
conventional language like C or Fortran. I don't think that C++ has been an
improvement, maybe Java is better, I don't know. This program length factor and
the 5 productivity multiplier correspond more to my experience, including for
GUI development and especially for maintenance.
--
www.algo.be
Logo programming : www.algo.be/logo.html
From: Hannah Schroeter
Subject: Re: Lisp productivity [Re: LISP for general programming? (sorry)]
Date:
Message-ID: <9edug0$3o1$1@c3po.schlund.de>
Hello!
In article <··································@4ax.com>,
Francis Leboutte <··········@algo.be> wrote:
>[...]
>In his book, Software Development (Fashioning the Baroque), Darrel Ince already
>wrote in 1988 that it was not uncommon that a program in a very high level
>language like Lisp is 5 to 10 times shorter than the same program in a
>conventional language like C or Fortran. I don't think that C++ has been an
>improvement,
I beg to differ. C++ is definitely an improvement over C for me. Of
course it's still by much not as good as really good languages (be they
CL, Haskell, some ML derivative, or Smalltalk, just for some examples),
but still by much better than plain C.
>[...]
Kind regards,
Hannah.
From: David Thornley
Subject: Re: Lisp productivity [Re: LISP for general programming? (sorry)]
Date:
Message-ID: <krSO6.3388$Dd5.1362519@ruti.visi.com>
In article <············@c3po.schlund.de>,
Hannah Schroeter <······@schlund.de> wrote:
>Hello!
>
>In article <··································@4ax.com>,
>Francis Leboutte <··········@algo.be> wrote:
>
>>In his book, Software Development (Fashioning the Baroque), Darrel Ince already
>>wrote in 1988 that it was not uncommon that a program in a very high level
>>language like Lisp is 5 to 10 times shorter than the same program in a
>>conventional language like C or Fortran. I don't think that C++ has been an
>>improvement,
>
At least at one time, Capers Jones had a listing of languages in
terms of how many lines per function point (Jones is the guy behind
function points). If I remember correctly, he listed C as having
six times the number of lines for the same functionality as CL
(CLOS is what he called it, presumably to differentiate it from
earlier Lisps.)
The only language that looked general-purpose that was on the same
level as CL was Smalltalk.
>I beg to differ. C++ is definitely an improvement over C for me. Of
>course it's still by much not as good as really good languages (be they
>CL, Haskell, some ML derivative, or Smalltalk, just for some examples),
>but still by much better than plain C.
>
Remember how C++ spread at first: as an improved C. It's no wonder
then that C++ programs tended to be enhanced C programs, and therefore
not much of an advance. If you were to study C++ from a book such
as Lippman's "C++ Primer, 3rd Ed." and learn appropriately, you
would be using C++ far better than you could use C.
It's still less fun than Common Lisp, for my money.
--
David H. Thornley | If you want my opinion, ask.
·····@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
"David Thornley" <········@visi.com> wrote in message
···························@ruti.visi.com...
> It's still less fun than Common Lisp, for my money.
As I put it, "The worst day programming in a dynamic language is better than
the best day programming in a static language."
faa
From: Marc Battyani
Subject: Re: Lisp productivity [Re: LISP for general programming? (sorry)]
Date:
Message-ID: <9e99r5$b3v$1@reader1.fr.uu.net>
[I changed the subject to the same thread subject set by Kent M Pitman]
"Rolf Wester" <···········@t-online.de> wrote
> Marc Battyani wrote:
>
> > We have been writing industrial software in Lisp for some years now with
> > GUI, 3D, real-time etc...
> > I will make a web site when I have time but until then I've put some
screen
> > shots here:
> > http://www.fractalconcept.com/ndt/andt.html
> > We used to write this in C/C++ before but the productivity was at least
5 to
> > 10 times lower and it was much harder to write an application that can
work
> > for days.
> I often read that programming in Lisp is much more productive compared to
C/C++.
>
> I'm not very experienced in Lisp programming but I can imagine that it is
indeed
> more
> productive. But I can hardly imagine the factor of 5 to 10. At the moment
I
> switched
> to OCaml for some of my work but I'm still considering using CL. So it
would by
> quite
> helpful for me to know more of your experience. I would be very
appreciative if
> you
> could tell me what are the reasons are for that great improvement in
> productivity?
The productivity increase factor I mentioned is on a software that I wrote
in C++ (250k lines of code (without the comments)). There have been several
versions of it written in C++. When Harlequin (now Xanalys) ported their LW
to Win32 I rushed to get it (from the beta test stage). The version I
rewrote in Lisp is only 22k lines of code.
Those lines of code metrics are rather crude in general (and totally useless
in absolute) but they can give a relative indication as there is the same
kind of presentation/comments etc. in both versions.
The Lisp version has much more functionalities than the C++ one.
In both version I don't use any existing GUI toolkit (no MFC and no
CLIM/CAPI) as they are not standard and not easily available from multiple
sources (at that time at least). So the code size includes the GUI framework
code.
Here are the factors that increase productivity of (a non exhaustive list in
no particular order):
It takes less time to write/test/debug 22k lines than 250k.
In lisp you work in or along the application within the Lisp system. So you
can change/modify/inspect Lisp code and variables without stopping the
application. In real-time industrial code it's a very very big time saver.
When an error occurs at some stage you can correct it and continue even if
you make very big changes, like changing class slots, or even changing the
class hierarchy. This was quite impressive for the people making the
automated test equipment to see that I could modify the system in one
listener while it was working and driving their motors. No
"Edit/Compile/Link/Execute/Run up to where you've seen the problem that does
not exists anymore because you restarted the CNC so now you can't test your
correction" cycle. It's during this part that the productivity gain was
incredible. The system was debugged (and clean) in 5 days instead of several
months (and still some crash) for the C++ one.
The after, around and after methods + multiple dispatch saves a lot of code
comparing to other languages.
The MOP makes life easier.
Lisp has macros of unmatched power + lexical closures + an error processing
system that makes it much easier to deal with errors than in C++.
Lisp manage the memory quite well. In C++ if you use the standard heap you
end up with a bloated and fragmented memory space. If you make specialized
memory allocators it's better but you had to make them and it's still not as
good as a good GC. This is important in software working 24x7.
You can send patches as fsl files that are loaded when they restart the
software.
Globally I was impressed by the "resilience" of the Lisp software to
changes. I can completely change some parts of the design and the system
still works. This enables us to accept software changes from our clients
that we would have declined in C++.
The end result is that the Lisp software is more powerful, much more
reliable than the C++ one, and took much less time to write and debug.
Marc