A Philosophical Diversion
David Steuber The Interloper
questions / doubts in my mind about Lisp.
alias Common Lisp Lisp
First a doubt. I was told at work today that Lisp is not a real
general purpose language. Instead, it was a domain language only
useful in AI circles. The person who told me this is a very good
programmer, so I can't just dismiss what he says. On the other hand,
he admits to only knowing some Emacs Lisp just well enough to
configure Emacs to his liking.
The types of applications I am used to working with are for the most
part GUI based and event driven. A web browser such as Netscape would
be a good example of one. Could someone write a web browser like
Netscape using Lisp? Would that be a good language choice? Isn't C++
better for performance reasons? Don't most GUI's assume C style
linkage?
I am asking this because I have an application I would like to write.
It will use a GUI. It will need to communicate over TCP sockets,
maybe use UDP. It will be intensely graphical. I originally thought
that Java 1.2 would be a good language to implement the program in.
Indeed, Java 1.2 provides many useful features that would make my work
easier.
But I also want a scripting / extension language for my program. I
took a look at ECMAScript, since it is a standard, and I could only
think of one thing. How the heck would I implement it? It would be a
lot of work. So I looked around for an easier language to parse. Two
came to mind: Lisp and Scheme. Based on postings here, I decided to
choose Lisp.
Lisp is most naturally defined in Lisp. Further more, I thought that
Lisp would make an excellent file format for my application. To
complete the symmetry, I thought, "why not implement the program in
Lisp?" I started to get enthusiastic about this idea. Lisp as the
implementation language, extension language, and file format. I fell
in love with the idea.
I then came to this group to start annoying everyone with dumb
questions about what Lisp I should use and where I could get a free
one. The suggestion that Linux had a number of choices that weren't
even available to windows finally pushed me to get Linux on my
machine. That is an upgrade I had been debating with myself for over
a year.
So now I am looking at cmucl or clisp as my implementation language.
Then my coworker bursts my bubble with the statement that Lisp is just
not a mainstream language for the simple reason it is not general. So
now I am questioning the group that is obviously biased in favor of
Lisp if I should continue along this line. To Lisp or not to Lisp?
The other question. Is Lisp a lazy man's programming language? I
have seen claims that Lisp source is typically much smaller than C++
source. In theory, less source code means fewer opportunities for
bugs. I like that idea. Is it true? Is Lisp a more concise way of
stating a program? Is Lisp less prone to buggy code?
If Lisp is so great, why hasn't the programming world latched on to it
as the silver bullet to save everyone from growing complexity? Is it
just politics? I know that seems to be the reason people are still
moving to Microsoft's inferior server solutions.
So here I am with FUD on the one hand and Lisp, the savior, on the
other. Can someone please relieve me of my Fear, Uncertainty, and
Doubt? I want to write the modeling program to end all modeling
programs. I want it to run under Linux first. If I can, I'll port it
to the JVM. So it's Lisp or Java. Lisp is new to me. It is a
different way of thinking. The new part entices me. The different
part scares me. The Lisp trinity idea strikes me as beautiful
elegance.
To Lisp, or not to Lisp. That is the question. Be there a programmer
so lazy as me who wishes the program to write it self, or perhaps a
fool. Language and thought intertwine. Each controls the other. It
is by language that you express yourself. Without the language, you
can not think it.
When it comes down to it, programming is the synthesis of math and
poetry. Thought gives birth to form and electrons learn to think.
--
David Steuber (ver 1.31.1b)
http://www.david-steuber.com
To reply by e-mail, replace trashcan with david.
When the long night comes, return to the end of the beginning.
--- Kosh (???? - 2261 AD) Babylon-5
"Where do you want to go tomorrow?" --- KDE tool tip
Pierre Mai
> First a doubt. I was told at work today that Lisp is not a real
> general purpose language. Instead, it was a domain language only
> useful in AI circles. The person who told me this is a very good
> programmer, so I can't just dismiss what he says. On the other hand,
> he admits to only knowing some Emacs Lisp just well enough to
> configure Emacs to his liking.
QED: How can Lisp be a language (family) only useful in AI circles,
if >90% of Emacs is written in Emacs Lisp, a member of the lisp family
of languages, which is not too different[1] from CL if one uses the CL
macro package? Ok, from the viewpoint of most users of other
editors/IDEs, it would indeed seem that Emacs is really an artificial
intelligence specialized on supporting developers/text editors ;) And
we even have a Eliza and Zippy on board... ;)
But seriously: If you have read the list of applications at ALU, then
your doubts should be dispelled already. And again, I'm currently
working on an event-driven factory-floor and logistics simulation
package, whose predecessor was implemented in C++, and which is now
being implemented in CL. No AI here[2], and it's running very well
indeed... ;)
> The types of applications I am used to working with are for the most
> part GUI based and event driven. A web browser such as Netscape would
> be a good example of one. Could someone write a web browser like
> Netscape using Lisp? Would that be a good language choice? Isn't
> C++
Not only could one, but it's already been done: W3, which runs in
(X)Emacs, and no doubt one of the commercial CLs has something
similiar built-in for documentation reading (IMHO Lispworks does at
least)). And I'm using W3 for displaying the HyperSpec while working
on CL code (thanks to Erik Naggum's hyperspec.el ;).
> better for performance reasons? Don't most GUI's assume C style
> linkage?
Well, as far as performance goes, Netscape or MSIE are not really
stars, are they? Ok, W3 is somewhat slower, but it's running
byte-interpreted on top of a not very fast interpreter!
> I am asking this because I have an application I would like to write.
> It will use a GUI. It will need to communicate over TCP sockets,
> maybe use UDP. It will be intensely graphical. I originally thought
> that Java 1.2 would be a good language to implement the program in.
> Indeed, Java 1.2 provides many useful features that would make my work
> easier.
Well, one who considers Java as a language shouldn't worry about
performance: On this computer, XEmacs, CMUCL and Netscape run quite
fast enough for me, and I'm an impatient man (all three of them are
memory-hogs, and neither XEmacs nor Netscape is famous for it's speed,
but OTOH the first two provide masses of functionality, whereas
Netscape provides lots of mis-features (like HTML-mail/news)... ;).
But the moment a Java-application touches my computer, things start
getting sloooow, and _any_ Java-application using Swing is so slow as
to be unusable (I mean it! Watching how a menu is slowly redrawn is
not my favourite hobby, especially if it takes > 10s ;).
And I frankly don't see the point of getting a snazzy Xeon >400 MHz
just for an ugly, badly designed GUI-package.
> But I also want a scripting / extension language for my program. I
> took a look at ECMAScript, since it is a standard, and I could only
> think of one thing. How the heck would I implement it? It would be a
> lot of work. So I looked around for an easier language to parse. Two
> came to mind: Lisp and Scheme. Based on postings here, I decided to
> choose Lisp.
>
> Lisp is most naturally defined in Lisp. Further more, I thought that
> Lisp would make an excellent file format for my application. To
> complete the symmetry, I thought, "why not implement the program in
> Lisp?" I started to get enthusiastic about this idea. Lisp as the
> implementation language, extension language, and file format. I fell
> in love with the idea.
It is a great/natural idea, and we are following along these lines in
our simulation.
OTOH I often decouple the GUI from the main application, for a number
of reasons:
a) GUIs just aren't cross-plattform portable (Java not withstanding,
or we wouldn't have Swing!, and btw Tk is probably still more
portable than Java!).
b) The GUI-look of the month is currently often more important than
usability, stability, and reliability taken together, as can be
witnessed by observing Microsofts GUI-looks (3.0,3.1,3.11(3d),95,
97, 98, etc.).
c) Todays GUIs are dumb, and you often have to conform, or your client
will kill you ;)
d) Todays GUI-Toolkits are very invasive: They change your whole
program structure, ripping apart the cohesion of your application
logic, and instead emphasize display logic. This is a completely
wrong approach, and just leads to unreflected throw-away coding,
which concentrates on screens, menus, etc. and not on the
application domain.
e) Often, GUI's are best built with the GUI-builder of your choice,
which will give you a mess of code, which is best isolated from
your implementation code, or it will infect it.
...
> So now I am looking at cmucl or clisp as my implementation language.
> Then my coworker bursts my bubble with the statement that Lisp is just
> not a mainstream language for the simple reason it is not general. So
> now I am questioning the group that is obviously biased in favor of
> Lisp if I should continue along this line. To Lisp or not to Lisp?
Well, I still don't know what exactly your application will be
(i.e. mostly GUI and nearly no domain knowledge, or vice-versa),
but in general I'd recommend staying with lisp. But beware that
free GUI solutions currently are a bit scarce, and idiosyncratic.
BTW you could take a look at lisptk, which couples Lisp and Tcl's
Tk (this coupling is not very lispy, but Tk is one of the easiest
GUI Toolkits to use, and it gives reasonable results in short time,
and is not that evil, if one doesn't have to use Tcl!).
Or you go the way of seperating Interface and Implementation, (if that
makes sense in your application)...
> The other question. Is Lisp a lazy man's programming language? I
> have seen claims that Lisp source is typically much smaller than C++
> source. In theory, less source code means fewer opportunities for
> bugs. I like that idea. Is it true? Is Lisp a more concise way of
> stating a program? Is Lisp less prone to buggy code?
Is Lisp a lazy man's language? I think it accommodates both, being
lazy and being eager, and when you combine both strengths in you, and
know the time for being lazy (prototyping, re-use, avoiding
pre-optimization) from the time for being eager (framework building,
building reusable components/constructs, optimiztation/profiling,
"productizing" your application), then CL will let you focus your
limited energy in ways that will maximize your return of investment.
Is Lisp more concise? Well it can be, if you use it right, and start
building abstractions of your problem domain, before, during and after
design and implementation (i.e. iteratively). For this, CL is one of
the best languages I know of, because of it's source represantation
and macro-language (CL again ;), and it's functional, procedural and
OO components.
Is Lisp-code less buggy? Less buggy than what? Whose Lisp-code? If
done well, Lisp-code will probably have fewer low-level defects than
C++ code. And it will probably have fewer application logic defects
than if implemented in less adaptable languages, and the defects will
be easier to locate and fix, since they will most often be found in
the supporting macrology/functions, and not widely dispersed in the
application code. Compare:
(with-open-file (stream name)
(with-lock (*ordered-lock1*)
(blabla)
...))
(defun blabla ()
(with-lock (*ordered-lock2*)
...))
to any C++ equivalent, which will have a number of bugs waiting to
happen, which the CL equivalent not only avoids (there are not many
things you can do wrong, short of leaving out one of the constructs,
which is easily detectable by grepping, or getting the locking order
of locks intermixed, which the macros will catch), but actively
inhibits.
> If Lisp is so great, why hasn't the programming world latched on to it
> as the silver bullet to save everyone from growing complexity? Is it
> just politics? I know that seems to be the reason people are still
> moving to Microsoft's inferior server solutions.
Yes, it mostly is politics, statistics, economics, game-playing
theory, psychology, sociology and history... ;) BTW if you haven't
already done so, get
- Frederick P. Brooks, Jr.: The Mythical Man-Month (20th anniversary
edition), Addison-Wesley Longman, 1995, ISBN 0-201-83595-9
- Richard P. Gabriel: Patterns of Software, Oxford University Press,
1996, ISBN 0-19-5100269-X
or at least read his article "Worse is Better", IMHO reachable via
ALU's site...
> Doubt? I want to write the modeling program to end all modeling
> programs. I want it to run under Linux first. If I can, I'll port it
> to the JVM. So it's Lisp or Java. Lisp is new to me. It is a
> different way of thinking. The new part entices me. The different
> part scares me. The Lisp trinity idea strikes me as beautiful
> elegance.
Well, what kind of modeling? 3D modeling, like in Blender, et al.?
IIRC a (japanese?) graphics-firm has a product range, which includes
high-level (and high-cost, ;) modelers and so, which are based on
Lisp-technology inherited from Symbolics, so this can be done, and is
done. And I'd imagine that most of the advanced things you want from
a modeler (skeleton-based movement/kinematics, live-like motion of
swarms of artificial animals, etc., etc.) will require a very strong
scripting/implementation language, and will bring AI topics into your
application.
And since there seem to be bindings for OpenGL, and CLX, I'd imagine
this to work quite well. But it's your call, you know your
requirements and expertise level's best, your time-frame, goals, etc.
Regs, Pierre.
Footnotes:
[1] Yes I know of the differences in scoping, case-preserving reader
by default, etc. And I too would prefer a version of Emacs based on
CL, with compatibility to existing Emacs Lisp code... ;) But wrt to
this "proof", this detail doesn't matter... IMHO...
[2] It's not that one couldn't use some AI techniques for
optimization purposes in the simulation: The problem is, that reality
is still using very boring techniques -- thanks to "standards" like
SAP R/3 -- and we have to simulate reality ;(
--
Pierre Mai <de...@cs.tu-berlin.de> http://home.pages.de/~trillian/
"Such is life." -- Fiona in "Four Weddings and a Funeral" (UK/1994)
Rainer Joswig
tras...@david-steuber.com wrote:
> alias Common Lisp Lisp
>
> First a doubt. I was told at work today that Lisp is not a real
> general purpose language. Instead, it was a domain language only
> useful in AI circles. The person who told me this is a very good
> programmer, so I can't just dismiss what he says. On the other hand,
> he admits to only knowing some Emacs Lisp just well enough to
> configure Emacs to his liking.
From my experience Lisp can be a general purpose language.
On my Lisp machine networking software on the all the levels of the OSI
model ;-)
is implemented with help of Lisp. Receiving packets from
network interfaces then looks like this (Flavors not CLOS):
(defmethod (:receive-packet ip-protocol) (pkt source-interface ignore)
(incf pkts-received)
(if enabled
(let ((ip (neti:get-sub-packet pkt 'sys:art-8b 0 neti:sub-packet-size
'ip-header)))
(neti:with-network-packet (ip)
(let ((header-length (* 4 (ip-header-ihl ip))))
(cond ((not (= (ip-header-version ip) internet-header-version-number))
(ip-error ip t 'bad-version))
((null routing-initialized))
((< (ip-header-ihl ip) 5) (ip-error ip t 'bad-field 0))
((ip-check-checksum ip 0 10 header-length) (ip-error ip t
'checksum))
(t (ip-retransmit-packet ip header-length (ip-header-length ip)
(ip-header-source ip)
(ip-header-destination ip) nil
source-interface t))))))
(neti:deallocate-packet-buffer pkt)))
I mean, how much more general purpose can you go? Who else has implemented
a real-world object-oriented version of networking (especially TCP/IP)
down to the lowest levels?
It is not on all platforms the case, though. But there
is no reason why you shouldn't be able to write
the next Adobe Illustrator or Quark XPress in Lisp.
You might have problems writing drivers for Ethernet
cards for the PC-Platform - the infrastructure may not
be there (I'm not a particular fan of this hardware).
> The types of applications I am used to working with are for the most
> part GUI based and event driven. A web browser such as Netscape would
> be a good example of one. Could someone write a web browser like
> Netscape using Lisp? Would that be a good language choice? Isn't C++
> better for performance reasons? Don't most GUI's assume C style
> linkage?
Sure you can write a web browser like Netscape in Lisp.
The performance is not a big problem. Lisp machines
had complicated UI-based software years ago
with a tenth of the current bang. MCL for example
has some very graphical applications (Apple Dylan is a very
cool development enviroment, a company is developing a new
software for music notation in MCL, ...) and this is where
it has some strengths. Nichimen is doing 3D graphics for games in Lisp on
Unix and NT.
> So now I am looking at cmucl or clisp as my implementation language.
> Then my coworker bursts my bubble with the statement that Lisp is just
> not a mainstream language for the simple reason it is not general. So
> now I am questioning the group that is obviously biased in favor of
> Lisp if I should continue along this line. To Lisp or not to Lisp?
Commercial grade Lisps are really more advanced than what
you get as free versions. CMU CL is not nearly as robust
and performant as ACL for example. You can always
find examples where CMUCL has a good performance,
but last time I looked the overall performance (GC, scheduling,
CLOS, ...) was much less.
So most people who want to write demanding *applications*
will choose a commercial implementation and might
even contract the Lisp vendor to provide certain
capabilities (like near-real-time GC).
> The other question. Is Lisp a lazy man's programming language? I
> have seen claims that Lisp source is typically much smaller than C++
> source. In theory, less source code means fewer opportunities for
> bugs. I like that idea. Is it true? Is Lisp a more concise way of
> stating a program? Is Lisp less prone to buggy code?
Drawback: Some people prefer dynamic typing.
In general you can handle very complex applications from
within Lisp. If you reach a complexity boundary (too many parts
to be handled manually for example), then you need to
introduce an infrastructure that handles these things
for you automatically and makes them visible.
> If Lisp is so great, why hasn't the programming world latched on to it
> as the silver bullet to save everyone from growing complexity? Is it
> just politics? I know that seems to be the reason people are still
> moving to Microsoft's inferior server solutions.
Lisp would in its **final** consequence introduce a new computing
infrastructure. One that is not compatible with the
current. Another problem is education? - how long
do you need to be a capable Lisp programmer? - given that
you have a lot of concepts available and already laid
out. How do you choose between the different alternatives
within Lisp and its libraries? How do you teach to get
the focus *not* to use every available feature because
it is there? How do you teach the overview to identify
the parts you can reuse and where your application fits
into the larger system and really leverage the infrastructure?
Everybody would like to have the mythical "Lisp wizard"
- but this is a limited resource.
I share the view of one prominent Lisp programmer: "no apologies".
> I want to write the modeling program to end all modeling
> programs.
There is a lot already done in Lisp. Modelling (knowledge representation,
etc.) is an integral part of AI (-> large systems like KEE
(Knowledge Engineering Environment) were very early attempts
in this direction).
> I want it to run under Linux first.
ACL runs under Linux. CMU CL would need some hacking. There
are some dedicated people working on CMU CL and it has made
some good progress in the last year. CMU CL is definitely,
from the technology, the best free system available. CLISP
is another choice for a wide range of applications.
Another dream (so more distant) is to use that abstractions
provided by CLIM on all platforms, getting
good looking UIs. But CLIM in its current state has
some problems and the best it could get is more users
and a freely available implementation.
> If I can, I'll port it to the JVM.
The JVM has some limitations and I doubt if you really get
good performance with the JVM for Lisp. **I** for my part want to
be able to handle large amounts of data, do number
crunching, etc.
> To Lisp, or not to Lisp.
Do a smaller evaluation project. Some questions to explore:
- design of large(?) Lisp applications (frameworks)
- Documentation of Lisp programs
- interface to the platform (graphics, video, networking, ...)
- data storage
- ways to deliver your application
- performance
- stability and usability
- productivity
- development environment and tools
- maintenance over a longer time with changing and
extending requirements
- community (who can use your software?, who can extend your
software?, who can understand the implementation?,
acceptance of the implementation?, ...)
Rainer Joswig
<pm...@acm.org> wrote:
> OTOH I often decouple the GUI from the main application, for a number
> of reasons:
>
> a) GUIs just aren't cross-plattform portable (Java not withstanding,
> or we wouldn't have Swing!, and btw Tk is probably still more
> portable than Java!).
> b) The GUI-look of the month is currently often more important than
> usability, stability, and reliability taken together, as can be
> witnessed by observing Microsofts GUI-looks (3.0,3.1,3.11(3d),95,
> 97, 98, etc.).
> c) Todays GUIs are dumb, and you often have to conform, or your client
> will kill you ;)
> d) Todays GUI-Toolkits are very invasive: They change your whole
> program structure, ripping apart the cohesion of your application
> logic, and instead emphasize display logic. This is a completely
> wrong approach, and just leads to unreflected throw-away coding,
> which concentrates on screens, menus, etc. and not on the
> application domain.
> e) Often, GUI's are best built with the GUI-builder of your choice,
> which will give you a mess of code, which is best isolated from
> your implementation code, or it will infect it.
This is where CLIM (and Dynamic Windows) comes into play.
These toolkits are allowing
you to work directly on your domain objects. The UI
part itself is expressed in high-level terms where
the realization can be changed (especially in CLIM). That means
you specify commands - how these commands are possibly
invoked on your domain objects (by keypress, by command interpreters,
by mouse click, by dragging, by menu, ...) can be changed.
An example. I have written a small UI for an application
which examines logs of our telephone system. So a telephone call
in the UI is an object to be drawn in a table. CLIM remembers
the real domain object behind the display:
(defun draw-call (stream highlight call x y scale)
(let ((duration (call-duration call)))
(when duration
(let ((ink (call-color call highlight)))
(clim:with-output-as-presentation (stream call 'call)
(clim:draw-rectangle* stream x y
(max (+ x (/ (* 4 (/ duration 100)) scale))
(+ x 1))
(+ y (- *phone-y-delta* ))
:ink ink))))))
So you want to have a command to further describe a call:
(define-tellog-command (com-describe-call :menu t)
((call 'call :Default nil))
...
(format stream "~%Call type ~a from " type)
...
Then when you have a call you might want to further describe the
phones (inside and outside) associated with this call, just my using a context
sensitive menu:
(clim:define-presentation-to-command-translator describe-call-2
(call com-describe-phone tellog
:gesture nil)
(object)
(let* ((frame clim:*application-frame*)
(log (tellog-log frame)))
(list (with-slots (inside-number) object
(find inside-number (inside-phones log) :key #'phone-number
:test #'equal)))))
(clim:define-presentation-to-command-translator describe-call-3
(call com-describe-phone tellog
:gesture nil)
(object)
(let* ((frame clim:*application-frame*)
(log (tellog-log frame)))
(list (with-slots (outside-number) object
(find outside-number (outside-phones log) :key #'phone-number
:test #'equal)))))
The interface one does develop, works on the domain level ***and***
does not infect in any way the implementation of the non-GUI code.
This is what I like.
rusty craine
David Steuber "The Interloper" wrote in message
<361fc98b....@news.newsguy.com>...
>Pardon me for using this newsgroup as a sounding board for some
>questions / doubts in my mind about Lisp.
>
>alias Common Lisp Lisp
>
>The other question. Is Lisp a lazy man's programming language? I
>have seen claims that Lisp source is typically much smaller than C++
>source. In theory, less source code means fewer opportunities for
>bugs. I like that idea. Is it true? Is Lisp a more concise way of
>stating a program? Is Lisp less prone to buggy code?
>
>If Lisp is so great, why hasn't the programming world latched on to it
>as the silver bullet to save everyone from growing complexity? Is it
>just politics? I know that seems to be the reason people are still
>moving to Microsoft's inferior server solutions.
My views of lisp are indeed very different from most recipients in this news
group. I read the news group because a number of respondents have a "lisp"
IQ in the genius range and I have learned alot (even after using lisp since
the mid 80's). That being said, might give you a clue to the nature of
lisp (imo). since most people even rather bright ones are concrete
sequential thinkers; they make good cobol, fortran, et all procedural
programmers. To this group of thinkers lisp is a lazy man's lanuage. There
is another smaller group of programs that are "ABSTRACT", random thinkers,
with rather high IQ's that turn lisp into amazing things (let me assure you
i'm not unfortunately not one of those). Lisp is like a checker board. ya
can play checkers with your 9 year old or chess with "big blue"...same
board, different level of thinkers. lisp is as good as you can think
abstractly (symbolically).
as for my professional opinion of lisp (having been an application manager
for 10 yrs). God help the application manager that hires one of those
"ABSTRACT", random thinkers, with a rather high IQ..... they are few and far
between. not that they don't write good, documented code, it is that can
abstract several layers deeper than we "scudders" can. So if you do decided
to do your project in lisp and you do have one of those 180+ IQ's please
write your program as if I was going to have to maintain it. that is a:
55yr old, experinced programmer with a 120 IQ. Your boss will love ya, your
fellow programmers (the scudders like me) will appreciated it. and you will
know that you have left a maintainable legacy of yourself, with pride....no
showing off now :)
scudderingly
rusty
Rainer Joswig
jos...@lavielle.com (Rainer Joswig) wrote:
> > I want it to run under Linux first.
>
> ACL runs under Linux. CMU CL would need some hacking. There
> are some dedicated people working on CMU CL and it has made
> some good progress in the last year. CMU CL is definitely,
> from the technology, the best free system available.
Sorry, this was not very well written. Sure, CMU CL
runs under Linux and quite good.
Still, ACL in principle is in another league (also due
to its hefty price tag)..
Erik Naggum
| First a doubt. I was told at work today that Lisp is not a real general
| purpose language. Instead, it was a domain language only useful in AI
| circles. The person who told me this is a very good programmer, so I
| can't just dismiss what he says. On the other hand, he admits to only
| knowing some Emacs Lisp just well enough to configure Emacs to his
| liking.
ignorance of Lisp is very widespread. for your enjoyment, something that
floated my way via a friend from a MUD mailing list. (the name of the
ignorant fuck is withheld so he can't find himself using Dejanews.)
> > If lisp is the answer, it was a stupid question, or else you asked an
> > aging CS prof.
> Could you please provide some support for this opinion?
1. Functional languages are dead outside academia. Even IN academia,
they're fading away quickly.
2. (1) is a goodly part of the salvation of mankind.
3. Lisp causes the early retirement of the parentheses on a keyboard.
4. Dynamic scoping is for chumps writing their first interpreters by
hand, and if the chumps have any talent, even THEY won't use it.
5. Perl, Python, and a dozen other interpreted languages are far more
expressive, have far more development done for/with them, and are
far more widely known, and are likely to exist in 20 years.
6. Aging CS profs love Lisp because they were a part of the doomed
minority who swore up and down that functional programming was
the wave of the future.
7. Recursion is good for quicksort. This does not mean that recursion
should be an integral part of every algorithm used on a computer.
I'm reminded of Larry Wall's response to a major Lisp freak who was
bitching about how Perl had stolen what he regarded as Lisp's rightful
glory. He said something to the effect of: 'You've wasted a 25 year
head start. Whose fault is that?' What he didn't say, but should
have appended to his comment, is: 'on a language nobody wants.'
note that he is wrong on _every_ count, yet _nothing_ will ever make him
change his mind, least of all understanding what he's talking about.
people like that abound. fortunately, they are so easy to spot that they
are no danger to anything. they're just like those alternative medicine
bigots who know zilch about medicine.
| Isn't C++ better for performance reasons?
there may be reasons for choosing C++, but performance is not among them.
C has performance when well written. C++ has not really borrowed much
from C when you look carefully and ignore the hype, and certainly not the
simplicity that _allowed_ the perceived performance of C. note also that
C++ requires a _huge_ run-time system, which you have stated that you
don't want. so by your own criteria, C++ is inadmissable. incidentally,
C is not that much of a performer, either, it's just that every statement
causes few instructions in the compiled code, and so you breeze through
the statements, but you don't get the return value any faster just
because of this.
Common Lisp generally runs faster than C++ code doing the same thing,
although it is hard to write Common Lisp code that does as little as C++
code generally does. for instance, you have to work real hard and write
a lot of code to crash a Lisp program, leak memory, return bogus values,
ignore errors, etc, but if you want all that, Common Lisp probably runs a
little slower than C++. can't imagine why you'd want it, though. oh,
unless you're a C++ programmer afraid of unemployment. C and C++ are
really great languages only if your biggest goal is just being safely
employed, not solving anybody's problems.
| So now I am looking at cmucl or clisp as my implementation language.
| Then my coworker bursts my bubble with the statement that Lisp is just
| not a mainstream language for the simple reason it is not general.
Lisp ignorants will produce an amazing array of bullshit to defend their
ignorance. they're like racists that way.
| The other question. Is Lisp a lazy man's programming language?
the intelligent work less than the stupid to get the same job done. the
lazy just don't get the job done. big difference.
| I have seen claims that Lisp source is typically much smaller than C++
| source. In theory, less source code means fewer opportunities for bugs.
| I like that idea. Is it true? Is Lisp a more concise way of stating a
| program? Is Lisp less prone to buggy code?
errors in Lisp are of a fundamentally different type than errors in most
other languages. for instance, explicit static typing is supposed to
catch a lot of errors, but generally is just gets in the way of doing
what you want, and doesn't catch any errors professionals make, anyway.
| If Lisp is so great, why hasn't the programming world latched on to it as
| the silver bullet to save everyone from growing complexity?
because Lisp requires more intelligent programmers than C and C++ do.
| Can someone please relieve me of my Fear, Uncertainty, and Doubt?
you have nothing to fear but fear itself. just stop fearing.
| Without the language, you can not think it.
this is also why C/C++ programmers hate Lisp: what they generally want to
do is a harder and much more verbose in Lisp, but what they don't know
that they _should_ have done instead is a lot easier, but they will never
think about it and won't have the conceptual framework to understand what
you're talking about if you tell them. at some level, I think they do
understand that what they're so proud of doing in C/C++ is really quite
silly to begin with, and nobody likes feeling stupid, so blaming the
agent of their understanding is better than just quitting the stupidity.
| When it comes down to it, programming is the synthesis of math and
| poetry. Thought gives birth to form and electrons learn to think.
nice, but I think you need to find your way back to earth, now. :)
#:Erik
Howard R. Stearns
helpful in thinking about how Lisp relates to other langues
(http://www.elwood.com/alu/table/lisp.htm). In particular the
"performance" and "compare" pages address a lot of what you ask about.
As Pierre points out, the applications section of the same site lists
many non-AI applications.
II. Don't confuse language, implementation, and integration strategy.
clisp, cmucl, allegro & lispworks, and eclipse all use very
different implementation styles
tight-integration, foreign-function + sockets, interface-style
(ILU,CORBA,COM) and engines/native-methods (clisp/java) all provide
different language integration strategies that, except for "tigh
integration", are independent both the languages involved and the
language implementations.
These are three different axes to think about. Pick the best for
your application along each axis separately. Note that Lisp and,
arguably, C, allow you to do this! Of course, Lisp makes it easier to
make the integration strategy independent of the application source
code.
III. I really like Erik's examples of ignorance. Even at my company (a
maker of a Lisp implementation!) the IT guy thought that Lisp ran until
it used all memory, and then stopped, and that all Lisps worked by
producing stand-alone C code to be compiled. Go figure.
Ralf Muschall
> lisp (imo). since most people even rather bright ones are concrete
> sequential thinkers; they make good cobol, fortran, et all procedural
> programmers. To this group of thinkers lisp is a lazy man's lanuage. There
Agreed - I'm a lazy man anyway.
The point that lisp influenced me is e.g. to leave algorithms in the
recursive
form in which they arise naturally instead of converting them manually
into loops as most (non-lazy) programmers do.
If I had e.g. to evaluate a polynomial in C, I'd write (barring stack
overflow
and timing problems and ignoring the fact that it is already in math.h
and libm)
double poly(double x, double * coeffs, int degree)
{
return (degree<0) ? 0 : coeffs[0]+x*poly(x,coeffs+1,degree-1);
}
for the simple reason that it is easier to come up with, easier to
write,
and less error prone than the iterative way (not strictly, because
polynomial evaluation is a common idiom that everybody can type in,
but it is valid for less trivial problems).
In addition, the C function above looks like the Horner scheme that
everybody knows, so that it would need less documentation than the loop
(again this is not true for just *this* example, but you get the point:
Type just the mathematical definition and rely on the optimizing
compiler instead of trying to do some optimizations manually and
thereby hiding the idea from the human reader (or a *very* smart
compiler,
who might look at the above code and replace it with something
completely different and much better, which would be impossible
if the algorithm were messed up by hand)).
IMHO this method requires *less* IQ (which I never measured) and
thinking
than the iterative way (I consider converting the former to the the
latter
an optimization hack, and I do such things only when needed).
To formulate the opposition to your statement: Lisp (as well as similar
languages) is very suitable for stupid, lazy people -- just like myself.
It is a completely different question what geniusses <sp?> can do with
it.
Ralf
Kent M Pitman
[addressing only a subset of the issues you raised]
> Is Lisp a lazy man's programming language?
I'm curious if you mean lazy as a pejorative term here?
I remember some Ziggy cartoon, I think it was, that said something to
the effect of "never underestimate the power of being lazy. you can
bet power steering wasn't invented by an exercise freak."
> I have seen claims that Lisp source is typically much smaller than C++
> source.
I've seen such claims, too. My guess is that it pretty much has to be
true, even though I doubt it can be proven. The Lisp macro system is
sufficiently powerful (without loss of intelligibility needed to
reliably maintian it) that macros for doing interesting things must be
shorter in Lisp than some equivalent things in C or C++. If you look
at some of the things you can do in CLIM code with a few simple macros,
I'd say you're up against a lot to match it in C or C++.
I suppose the same could be done with function calls, but in my
experience it never quite works out that way. Basic language syntax
always ends up getting in your way in languages that don't allow you
to bend it with macros.
Then again, not everyone uses such techniques, so we're talking
ideal code length using someone who knows how to generate such,
which may not be meaningful either.
> In theory, less source code means fewer opportunities for
> bugs.
I agree with this.
> I like that idea.
I agree with people liking things about Lisp, too.
> Is it true?
To paraphrase Clinton, "it depends on what you mean by true".
> Is Lisp a more concise way of stating a program?
When you put the question this way, I become less sure.
I've been trained that (and I do believe that) there is no single
uniquely best way of stating something. There are a finite number
of strings of a given length that are valid programs in the language.
(I suppose you could also remove those valid program that are not useful,
but since we're not making a precise count, that doesn't matter here.)
The result is that whatever "concise" means, there are only a finite
number of things that can be concise in any given language. And if you
believe there are an infinite number of things that can be said,
then some things are always sacrificed by any notation.
Nevertheless, I think in practice Lisp is optimizd to make the
things people typically want to say to be not very painful. That's
not a theoretical claim, just a practical engineering task. I think
Lisp is well-engineered for conciseness in practical situations.
But if you state it in a very general way like your question above,
I start to worry you're making a theoretical assertion, and I'm not
so sure.
> Is Lisp less prone to buggy code?
Well, plainly there are some bugs in programs that are due to type
mismatches. And plainly languages that are statically typed are
better at that. Lisp is a grand experiment in the belief that there
is more to programming than type errors. There are design errors, for
example. And rapid prototyping (prototype -> users -> feedback ->
new-prototype -> users -> feedback -> ...)detects them better than the
clasical "waterfall" model. (requirements -> design spec ->
implementation -> users) .
Also,though they do static hcecking, most other languages DON'T do
various kind of runtime checking that Lisp does. And that creates a
very apples and oranges comparison.
So I guess I should say it may depend on what you see as "buggy".
I think there's a lot of data to suggest that the worst bugs in programs
in the world today are not those that send you into the debugger--they
are just bad design. And so I personally think anything that improves
that improves the world.
> If Lisp is so great, why hasn't the programming world latched on to it
> as the silver bullet to save everyone from growing complexity?
there is a lot of evidence that suggests that the "build a better
mousetrap and the world will beat a path to your door" philosophy
of the world didn't work.
moreover, things often succeed or fail for reasons not related to
their technical merit. i could say more but am going to decline to.
> Is it just politics?
the word "just" is probably never correctly used before the word
politics.
David Steuber The Interloper
claimed or asked:
% as for my professional opinion of lisp (having been an application manager
% for 10 yrs). God help the application manager that hires one of those
% "ABSTRACT", random thinkers, with a rather high IQ..... they are few and far
% between. not that they don't write good, documented code, it is that can
% abstract several layers deeper than we "scudders" can. So if you do decided
% to do your project in lisp and you do have one of those 180+ IQ's please
% write your program as if I was going to have to maintain it. that is a:
% 55yr old, experinced programmer with a 120 IQ. Your boss will love ya, your
% fellow programmers (the scudders like me) will appreciated it. and you will
% know that you have left a maintainable legacy of yourself, with pride....no
% showing off now :)
As far as I can tell, I've been cursed with mediocrity. The
imagination exceeds the intellectual capacity to realize it. Very
frustrating.
David Steuber The Interloper
asked:
% | When it comes down to it, programming is the synthesis of math and
% | poetry. Thought gives birth to form and electrons learn to think.
%
% nice, but I think you need to find your way back to earth, now. :)
Thank you, but I like it out here :-)
Well, I guess it is time to get back on course. The vote for which
lisp (of the free variety) seems to be in favor of cmucl. If my Linux
doesn't have it, I will get it.
The other practical matter is to actually learn lisp! I've got
Graham's Ansi Common Lisp book. I figure that should be a good start.
I'll get me XEmacs set up. I need to put together a .emacs file that
will pretty print and syntax highlight, etc for me.
I am a lazy programmer. I like a language to do things for me. I
like to express an algorithm in a natural way (what ever that means)
and have the tools generate the optimum code. Whatever.
This really is a new world for me. Not only am I moving to the land
of Linux, but I am choosing to speak with a lisp instead of C. Go
figure.
In case anyone is curious, my one man project is to produce a 3D
modeling program for animation. Done to death, I know. I want the
objects that are modeled to posses some rudimentary intelligence so
that they can help animate themselves. The objects, scenes, and
sequences will be expressed in lisp. The GUI environment I have in
mind is the typical view you get with Truespace. I want to take
advantage of OpenGL (Mesa) for the UI so that, hopefully, a user can
choose between shaded and wire frame representations on a per object
basis. Emacs is sort of my role model in terms of extension
capability. Where Emacs is used to edit text, my editor, if realized,
will edit a synthetic universe.
Normally, I would have gone with VC++ and NT for a project like this.
The scripting language would have been ECMAScript. Various eddies and
convergences in my streams of thought have lead me to a Lisp
implementation and X as a target. One of these was the requirement of
a distributed rendering engine that can use all the machines on a
network as process servers.
I'm sure its nothing new. The day I come up with a completely
original idea and I find out about it, I will be truly surprised.
I want to create just one application that other people will like and
use.
Anyway, thanks for all the replies. I'm sure you can't all be deluded
into thinking Lisp is a good language :-) With any luck, my future
posts will be dull questions about how to do x in lisp.
Steve Gonedes
tras...@david-steuber.com (David Steuber "The Interloper") writes:
< First a doubt. I was told at work today that Lisp is not a real
< general purpose language. Instead, it was a domain language only
< useful in AI circles. The person who told me this is a very good
< programmer, so I can't just dismiss what he says. On the other hand,
< he admits to only knowing some Emacs Lisp just well enough to
< configure Emacs to his liking.
I'm surprised that no one mentioned
http://www.norvig.com/paip-preface.html, which I think sums the
`general programming language myth' up fairly well. He wrote a really
great book on writing programs in CL - even if you don't take a liking
to title it maybe worth looking at.
< The types of applications I am used to working with are for the most
< part GUI based and event driven. A web browser such as Netscape would
< be a good example of one. Could someone write a web browser like
< Netscape using Lisp? Would that be a good language choice? Isn't C++
< better for performance reasons? Don't most GUI's assume C style
< linkage?
I think that the new HTML based operating-systems (netscape, IE, etc.)
just recently had some nasty buffer overflow problems.
Sigh, (... && i < MAX_BUFFER).
My favorite browser Lynx had a worse bug - you could run programs on a
person's machine by embedding some cruft in a url (very frightening -
consider `mail -s 'captured account' $(echo $LOGNAME)` ...), you'd get
an email from yourself!)
Maybe your focus would be better spent on what languages are _not_
right for the job - this will at least narrow the selection down a
bit.
< The other question. Is Lisp a lazy man's programming language? I
< have seen claims that Lisp source is typically much smaller than C++
< source. In theory, less source code means fewer opportunities for
< bugs. I like that idea. Is it true? Is Lisp a more concise way of
< stating a program? Is Lisp less prone to buggy code?
I think that Lisp may just make solutions accessible; I'm convinced
that only hard work will allow a `solution' manifest into a program
though. I could be wrong (and I frequently am so...).
You could just use lisp because it's a pretty language.
rusty craine
>As far as I can tell, I've been cursed with mediocrity. The
>imagination exceeds the intellectual capacity to realize it. Very
>frustrating.
>
Ah well you are indeed the type programmer that can make a difference. I
have been using lisp as the programming language of choice since 1985. Most
of the recipents of this news group would gasp at the unlisp like code i
have written in lisp. The fact that matters is that my code is
maintainable, it works without fail, and most important to me is I made a
good living...turning out mediore code that was rock solid and worked. That
does not mean that I don't try to learn from these guys and improve, I do.
There is some kind of standard "out there" called "lisp like" that some of
the recipients are very very good at. I try to learn from that......but on
the other hand every single day of the year at the hopital I work at, lisp
is driving micro-pumps to build life saving IV's for patients. Any one of
these folks who are regular respondents could have done a much better "lisp"
job of it...but the point is lisp is doing the job even with my
unlisp-likeness. So which do you think, I think most about...the good job
my lisp programs are doing or the fact that a number of these guys could
have written better lisp programs than i did?
Not to worry my friend mediocrity at our level puts us most likely in the
top 10 or 15 percent of humans and give us an opportunity to put to work
(altough maybe not as they would like it) the output of the top 5 percent
or so who actually make up this stuff. I guess (with tongue in cheek???) I
wish they had more real work to do. The point here is that the lisp i
started with had something like 200 native symbols, the current lisp i use
has around 300 native symbols, common lisp (i think) has 900+ native
symbols...hell that is more words then I use in my every day english
vocabulary...oh you could tell that? :) I only smybols that are not in
common lisp that would make a great deal of sense is the functions...
...
(or
(do-what-i-am-thinking-not-what-i-typed 'rusty)
(do-what-i-should-be-thinking-not what-i-thought 'rusty)
...
Reini Urban
>| If Lisp is so great, why hasn't the programming world latched on to it as
>| the silver bullet to save everyone from growing complexity?
>
> because Lisp requires more intelligent programmers than C and C++ do.
that's about the same argument rusty craine used. cannot really admit.
rather quite the opposite.
my general opinion (having only IQ 130) is that c++ would require a much
higher iq, so i'm doing just lisp which satisfies me and which is a
simple language i am able to understand.
i'll better stay stupid as i am using a "more intelligent" development
system than trying to raise my IQ (impossible!) or learn it the silly
way and do c++ or c instead. loosing one year trying to understand such
systems? naa.
inferior development system certainly requires more manpower and
iq-power, just to express and understand your intentions, which are
certainly much easier to express in lisp or other clearly functional
and/or object-orientated languages.
i still haven't got the point with c++ and perl object extensions, but i
got the point with all lisp and scheme objects systems around (if class
or prototype based: kr, clos, meroon, flavours, xlisp, tinyclos, los,
..) plus pascal or python (the language not the compiler).
it must be the language not the iq! it's both, semantics and syntax
which either makes me feel desperate (c++) or bright (lisp).
maybe that's the point why guile and not perl will be used as general
purpose scripting language for desktop environments in unix (gnome).
perl is nice but who can read and maintain this mess?
---
Reini Urban
http://xarch.tu-graz.ac.at/autocad/news/faq/autolisp.html
Paul Rudin
> system than trying to raise my IQ (impossible!)
Depends how you define IQ. Most people can improve their scores in IQ
tests simply by practicing similar puzzles...
If you define your IQ as something like "the score you get on taking
an IQ test" then it is possible to dramatically raise your IQ.
Howard R. Stearns
> > Is Lisp a more concise way of stating a program?
>
> I've been trained that (and I do believe that) there is no single
> uniquely best way of stating something. There are a finite number
> of strings of a given length that are valid programs in the language.
> (I suppose you could also remove those valid program that are not useful,
> but since we're not making a precise count, that doesn't matter here.)
> The result is that whatever "concise" means, there are only a finite
> number of things that can be concise in any given language. And if you
> believe there are an infinite number of things that can be said,
> then some things are always sacrificed by any notation.
See http://www.cs.auckland.ac.nz/CDMTCS/chaitin/lm.html
As I understand it (that is to say, not at all), Gregory Chaitin uses
Scheme to exercise theories about expressibility by doing computations
on lambda-calculus expressed in a language implemented in Scheme. (I use
the word excercise rather than prove because I believe that some of
Chaitin's work has to do with proving that some things can't be proved.)
His book, "The Limits of Mathemetics", even has a chapter called
"Elegant LISP programs", which, if I recall, defines elegence and states
theorems about it.
(You can read it on-line.)
David Thornley
David Steuber "The Interloper" <tras...@david-steuber.com> wrote:
>Pardon me for using this newsgroup as a sounding board for some
>questions / doubts in my mind about Lisp.
>
>alias Common Lisp Lisp
>
>general purpose language. Instead, it was a domain language only
>useful in AI circles. The person who told me this is a very good
>programmer, so I can't just dismiss what he says. On the other hand,
>
programming do the AI types do? In my experience, an AI program is
likely to contain approximately anything, and any language that is
useful for AI in general (I think we can agree Common Lisp is) is
general-purpose and suitable for many different sorts of programming.
It's arguable that CL is too general-purpose for some applications,
which are best written in something more special-purpose like C++.
I'm not impressed with that argument myself.
>The types of applications I am used to working with are for the most
>part GUI based and event driven. A web browser such as Netscape would
>be a good example of one. Could someone write a web browser like
>Netscape using Lisp? Would that be a good language choice? Isn't C++
>better for performance reasons? Don't most GUI's assume C style
>linkage?
>
Somebody wrote a HTTP server, so I assume somebody could write a
browser. It seems to me that CL would be a good language choice,
because I think CL is an excellent general-purpose language. In
my experience, C++ is not necessarily faster than CL where it matters.
A browser will be limited heavily by its ability to receive the HTML
code and the human input, so blazing speed is not all that necessary.
(I except the idiots who put a 150K page into one table, or some other
formatting thing that requires a large amount of data to be gotten
and *then* processed.) The other thing is that, in my experience,
CL is wonderful for playing around with algorithmic changes, so if
a bottleneck is discovered, it will be easier to fix in CL than in
most languages.
Most GUIs are indeed expecting C or Pascal programs to call them,
but this is not generally a problem. There is no fixed way to call
GUIs from CL, but then there are few fixed GUIs. How many will run on
X/Unix, Microsoft Windows, and the Macintosh? I see no reason to
ask for the implementation of GUIs to be more standard than the design.
>Lisp is most naturally defined in Lisp. Further more, I thought that
>Lisp would make an excellent file format for my application. To
>complete the symmetry, I thought, "why not implement the program in
>Lisp?" I started to get enthusiastic about this idea. Lisp as the
>implementation language, extension language, and file format. I fell
>in love with the idea.
>
Wonderful, isn't it?
>So now I am looking at cmucl or clisp as my implementation language.
>Then my coworker bursts my bubble with the statement that Lisp is just
>not a mainstream language for the simple reason it is not general. So
>now I am questioning the group that is obviously biased in favor of
>Lisp if I should continue along this line. To Lisp or not to Lisp?
>
Lisp. There will be high-quality Lisps available for Unix, MS Windows,
and the Mac for the foreseeable future. Lisp will do what you want
it to. You're obviously not committed to a mainstram language, or you'd
be asking these questions in comp.lang.c/c++/java.*. If you're
concerned about large run-time systems, then you don't want Java;
if the application itself is large, the size of the CL run-time
becomes less important.
>The other question. Is Lisp a lazy man's programming language? I
>have seen claims that Lisp source is typically much smaller than C++
>source. In theory, less source code means fewer opportunities for
>bugs. I like that idea. Is it true? Is Lisp a more concise way of
>stating a program? Is Lisp less prone to buggy code?
>
I'm a lazy man, and I like CL. CL does seem to be a more concise
way of stating things, particularly with CLOS. CL avoids a large
number of C/C++ bugs by the way it does things. Maybe a third of
C/C++ bugs relate to memory allocation, and quite a few more relate
to mismatched types. I don't know how many bugs are attributable
to arithmetic overflow and, frankly, neither does anybody else.
All of these are simply non-issues in Lisp.
>If Lisp is so great, why hasn't the programming world latched on to it
>as the silver bullet to save everyone from growing complexity? Is it
>just politics? I know that seems to be the reason people are still
>moving to Microsoft's inferior server solutions.
>
I used to use C as my language of choice. I changed my mind when I
had to do a ten-week class project in Common Lisp. I found that
I was getting it done with surprisingly little fuss, and that I was
swapping algorithms around with what in C I would have considered
reckless abandon.
I think there's an educational problem here. Most people start
programming with some sort of procedural language: Basic, Pascal,
C, C++. They then think this is _the_ way to program. Learning
other procedural languages isn't going to shake their belief.
They then see CL as an unattractive language. While CL can be
used procedurally, it's not obviously superior than C at that,
and if you're thinking procedurally you aren't going to see why you
might want to use other styles of programming. Once you start
using it on a project of significant size, you may well drift
into other styles which you couldn't use effectively with C.
IMNSHO, once you begin using CLOS and macros effectively, you'll
be converted.
In the meantime, I keep seeing features pioneered by Lisp showing up
in other languages. CL was actually the first ANSI-standard
object-oriented language, and so people use C++. CL is what
popularized garbage collection, and so people use Java. While
all of this is good for users of other languages, IMNSHO they'd
generally be better off using CL rather than swiping features
now and then.
>To Lisp, or not to Lisp. That is the question. Be there a programmer
>so lazy as me who wishes the program to write it self, or perhaps a
>fool. Language and thought intertwine. Each controls the other. It
>is by language that you express yourself. Without the language, you
>can not think it.
>
>When it comes down to it, programming is the synthesis of math and
>poetry. Thought gives birth to form and electrons learn to think.
>
Lisp isn't bad for math, but I think there's no programming language
superior for poetry.
--
David H. Thornley | These opinions are mine. I
da...@thornley.net | do give them freely to those
http://www.thornley.net/~thornley/david/ | who run too slowly. O-
Barry Margolin
Reini Urban <rur...@sbox.tu-graz.ac.at> wrote:
>Erik Naggum <er...@naggum.no> wrote:
>>| If Lisp is so great, why hasn't the programming world latched on to it as
>>| the silver bullet to save everyone from growing complexity?
>>
>> because Lisp requires more intelligent programmers than C and C++ do.
>
>rather quite the opposite.
I agree that "more intelligent" is probably not the right way to express
it. Lisp programming involves a different way of thinking than C/C++
programming. Programming in mid-level languages like C requires you to
keep track of lots of details like memory management. Programming in
high-level languages like Lisp generally involves designing abstractions.
It seems almost like it might be a left-brain/right-brain type of
difference, rather than a quantitative difference.
Also, the freedom that Lisp provides requires that the programmer exercise
certain amounts of discipline, to avoid hanging themselves with the rope.
In my post yesterday I mentioned the "software factories" -- they aren't
willing to trust the workers to exercise discipline on their own, which is
why they use languages that enforce it with strong, compile-time type
checking.
On the other hand, these factory workers are also generally less
experienced, and that would argue for using languages that don't require
lots of manual control. While few would argue that BASIC was a good
language, it was certainly successful at shortening the learning curve to
prorgamming. And many people who are otherwise non-programmers have easily
picked up the minimal amount of Lisp necessary to write Emacs init files.
I can't imagine trying to teach someone with no CS background how to deal
with pointers!
--
Barry Margolin, bar...@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Erik Naggum
| my general opinion (having only IQ 130) is that c++ would require a much
| higher iq, so i'm doing just lisp which satisfies me and which is a
| simple language i am able to understand.
your problem is not your IQ (as if it could have been), but that you are
conscientious and want to understand what you're doing. this is bad for
you if you want to deal with C++ and Perl and the like. the less you
actually care, the better these languages become. if all you need is for
something to "work", and you don't give a damn when and how it fails, C++
and Perl is for you. if you care deeply about not having your software
fail, you would naturally feel a correspondingly deep sense of betrayal
from the authors of both languages -- because they make it so damn hard
to express the fact that you do care about the failure modes.
if you read the ludicrously complicated document they call the language
specification for C++, you will probably arrive at the same conclusion I
did: "these guys must be _real_ slow". I'm reminded of the saying that
"complexity is the hallmark of stupidity"น. the elegant, simple solution
is the result of smart people thinking a lot and solving something that
might not even have looked like a very complex problem to begin with.
(incidentally, "smart" in this context refers more to one's attention to
detail and a desire for elegance than high IQ scores. intelligence is
only a labor-saving device. less intelligent people can in principle
create just as elegant solutions, but it would normally take them more
effort to get there. achieving elegance is never painless, however, and
you actually need to _want_ that quality in your code to get it.)
| inferior development system certainly requires more manpower and
| iq-power, just to express and understand your intentions, which are
| certainly much easier to express in lisp or other clearly functional
| and/or object-orientated languages.
intelligent people would rather develop a new development environment
than continue to prove the inferiority of a bad environment. (that's
about the only redeeming quality of C++ and Perl.)
| it must be the language not the iq! it's both, semantics and syntax which
| either makes me feel desperate (c++) or bright (lisp).
I share this impression. C++ left me feeling that I was never in control
of anything, in particular because the dimwits who wrote the soi-disant
"specification" left so much to the implementation and were so inept at
expressing their intentions. Common Lisp gave me a feeling that the
vendor would (or should) be sufficiently competent and trustworthy that I
could trust the specification and go from there.
| maybe that's the point why guile and not perl will be used as general
| purpose scripting language for desktop environments in unix (gnome).
incidentally, I think GUILE is _really_ stupidly designed, too, and Emacs
Lisp started losing its charm quickly in 1995, and by the time MULE had
been "integrated", had become just another god-awful "design-free" mess.
#:Erik
-------
น if it isn't a saying, it should be
Paolo Amoroso
> tras...@david-steuber.com (David Steuber "The Interloper") writes:
> > be a good example of one. Could someone write a web browser like
> > Netscape using Lisp? Would that be a good language choice? Isn't
> > C++
>
> Not only could one, but it's already been done: W3, which runs in
The latest version of STk, a Scheme system, comes with a Web browser
written in Scheme. For more info check:
Paolo
--
Paolo Amoroso <amo...@mclink.it>
James A. Crippen
>
> In article <joswig-0710...@pbg3.lavielle.com>,
> jos...@lavielle.com (Rainer Joswig) wrote:
>
> >
> > ACL runs under Linux. CMU CL would need some hacking. There
> > are some dedicated people working on CMU CL and it has made
> > some good progress in the last year. CMU CL is definitely,
> > from the technology, the best free system available.
>
> runs under Linux and quite good.
>
> Still, ACL in principle is in another league (also due
> to its hefty price tag)..
Remember though that ACL is free on Linux for non-commercial usage.
That doesn't mean that one could develop software on a free ACL on Linux
and then sell the software, but a person could do the experimentation on
their home machine with a free copy, then convince the corp to purchase
ACL on the appropriate platform once they've produced some decent
demonstrations of its potential. That is, the research into the
development is free, and so is the in-house demo. As long as nobody
sells the demo parts created on the free ACL (yes, there /are/ lots
of potential legal problems here, but most are trivially solvable)
Franz couldn't care less. Once someone makes money from something
involving their software they want a piece of the pie, and justifiably
so.
This is a pedantic point, but Franz deserves many kudoi (is that the
correct greek plural for 'kudos'?) for putting out high quality
software for free to experimenters and educators.
On a side note, a prof at my university was thinking of conniving
Franz into selling him a couple licenses for ACL for WinNT at low cost
so he could use them to teach Lisp classes. This campus is
unfortunately
primarily a Win?? and VMS place (isn't it horrid?) with only the very
occasional unix box, so students aren't used to having to deal with
unix in any functional way (beyond running pine). Having a Win version
of Lisp would help these people continue to avoid unix, and allow them
to learn Lisp alone, thus saving much wasted class time. So does anyone
off
the top of their head know if Franz does educational licensing at cheap,
preferably free prices? (Their free version doesn't compile, so it's
not
nice for larger programs and students get the wrong idea about the
language;
they think it's like BASIC (*shudder*) or something -- not useful for
real
programs.)
cheers,
james
Raymond Toy
James> On a side note, a prof at my university was thinking of
James> conniving Franz into selling him a couple licenses for ACL
James> for WinNT at low cost so he could use them to teach Lisp
James> classes. This campus is unfortunately primarily a Win??
James> and VMS place (isn't it horrid?) with only the very
James> occasional unix box, so students aren't used to having to
James> deal with unix in any functional way (beyond running pine).
James> Having a Win version of Lisp would help these people
James> continue to avoid unix, and allow them to learn Lisp alone,
James> thus saving much wasted class time. So does anyone off the
James> top of their head know if Franz does educational licensing
James> at cheap, preferably free prices? (Their free version
James> doesn't compile, so it's not nice for larger programs and
James> students get the wrong idea about the language; they think
James> it's like BASIC (*shudder*) or something -- not useful for
James> real programs.)
You can always try Harlequin's version for Windows. You can download
the full version. The only functional constraint is that it exits
after 5 or so hours.
Plus, Harlequin seemed to have reasonably cheap licenses---$500 per
license?
Ray
Erik Naggum
| On a side note, a prof at my university was thinking of conniving Franz
| into selling him a couple licenses for ACL for WinNT at low cost so he
| could use them to teach Lisp classes. This campus is unfortunately
| primarily a Win?? and VMS place (isn't it horrid?) with only the very
| occasional unix box, so students aren't used to having to deal with unix
| in any functional way (beyond running pine). Having a Win version of
| Lisp would help these people continue to avoid unix, and allow them to
| learn Lisp alone, thus saving much wasted class time. So does anyone off
| the top of their head know if Franz does educational licensing at cheap,
| preferably free prices?
well, I thought it was a crying shame that the NT version was priced
lower than the Unix versions, but then Franz Inc announced that Linux is
a supported platform at the same price as NT, in addition to making the
environment available to Linux users on a trial basis without charge. to
me, this is a very nice gesture to a community who deserves attention.
if you buy into Bill Gates' propaganda and rhetoric by buying NT, you
should also _pay_ for that choice. _nothing_ comes for free under his
regime. remember, sharing software under Unix is a matter of posting
_source_ to USENET and the Internet in general, while sharing software
under Bill Gates' totalitarian regime is a matter of binary distribution
of crippleware and paying "small" amounts of money to get uncrippled
versions, and you never get the source. the mind-sets are so different
it should be impossible to imagine that a company would want to provide
people with free versions of _anything_ under Windows. that you don't
get a file compiler in the demo version under Windows is just what I'm
talking about, and it's entirely fair.
it should be a major goal of every conscientious being on this planet to
help anybody and everybody avoid Microsoft products. I hope Franz Inc
denies you the opportunity to "help these people continue to avoid Unix",
at least without purchasing an educational site license.
incidentally, all they will need to learn under Linux is the Emacs/Lisp
Interface to Allegro CL. it's trivial for a reasonably competent system
administrator to set up the machines so the users will fire up Emacs and
Emacs will fire up Allegro CL when they log in and just land them in the
listener, all ready to visit Lisp files and enjoy the benefits of working
in a _programming_ environment instead of an end-user environment. a
university that has VMS systems _must_ have reasonably competent system
administrators, but I wouldn't bet any money on a place that used NT.
#:Erik
Georg Bauer
>he admits to only knowing some Emacs Lisp just well enough to
>configure Emacs to his liking.
So he uses Lisp for some completely non-AI stuff and still says such
stupid things? Disregard him.
David Steuber The Interloper
asked:
% it should be a major goal of every conscientious being on this planet to
% help anybody and everybody avoid Microsoft products. I hope Franz Inc
% denies you the opportunity to "help these people continue to avoid Unix",
% at least without purchasing an educational site license.
%
% incidentally, all they will need to learn under Linux is the Emacs/Lisp
% Interface to Allegro CL. it's trivial for a reasonably competent system
% administrator to set up the machines so the users will fire up Emacs and
% Emacs will fire up Allegro CL when they log in and just land them in the
% listener, all ready to visit Lisp files and enjoy the benefits of working
% in a _programming_ environment instead of an end-user environment. a
% university that has VMS systems _must_ have reasonably competent system
% administrators, but I wouldn't bet any money on a place that used NT.
I have to disagree with you on one point. Linux is a better end-user
environment than NT. For people who like pretty pictures, just look
at www.kde.org and take a gander at the screen shots. They don't do
the product justice though.
I hope to go a long way on free software. I even hope to make money
on it! Mostly I hope to have fun with it. Linux is fun. NT isn't.
David Steuber The Interloper
claimed or asked:
% > Is Lisp a lazy man's programming language?
%
% I'm curious if you mean lazy as a pejorative term here?
%
% I remember some Ziggy cartoon, I think it was, that said something to
% the effect of "never underestimate the power of being lazy. you can
% bet power steering wasn't invented by an exercise freak."
The Ziggy example seems to match my usage of the word lazy here. I
have an idea that good engineers are lazy in the sense that they will
go to great lengths to find ways of doing things with as little effort
as possible.
Generating useful programs is probably one of the more difficult tasks
that a human mind may be called upon to perform. I certainly don't
find it easy. It makes solving problems just that much more
satisfying. However, for really complicated problems, my brain is
just too small. I need to break down the problem into small enough
chunks that I can deal with them. Not only that, I must be able to
piece the chunks back together to actually solve the original problem.
This is also a task that I find to be quite difficult.
When a program editor can show me syntax errors as I type them or find
expressions for me, that makes my job easier. I can think more about
the program than the task of code entry. Taken to the next level, if
a programming language supports mechanisms to state expressions in a
consistent way, I don't have to worry about syntax so much. The
closer the language can get to the domain of the problem I want to
solve, the more likely I am to solve that problem. For many years,
C++ was THE language for me. I imagine I have to unlearn some of what
I learned over the years to think in Lisp rather than thinking in C++
and translating into Lisp. If the end goal is that I can be more
productive than I was with C++, then the effort will be worth while.
% > Is Lisp a more concise way of stating a program?
%
% When you put the question this way, I become less sure.
% I've been trained that (and I do believe that) there is no single
% uniquely best way of stating something. There are a finite number
% of strings of a given length that are valid programs in the language.
% (I suppose you could also remove those valid program that are not useful,
% but since we're not making a precise count, that doesn't matter here.)
% The result is that whatever "concise" means, there are only a finite
% number of things that can be concise in any given language. And if you
% believe there are an infinite number of things that can be said,
% then some things are always sacrificed by any notation.
%
% Nevertheless, I think in practice Lisp is optimizd to make the
% things people typically want to say to be not very painful. That's
% not a theoretical claim, just a practical engineering task. I think
% Lisp is well-engineered for conciseness in practical situations.
% But if you state it in a very general way like your question above,
% I start to worry you're making a theoretical assertion, and I'm not
% so sure.
This is why I like reading your posts. You force me to be more
precise. I need more of that.
What I think I mean by concise is (to use a probably worthless metric)
to express a non trivial process with a small enough number of tokens
to make the code small, but not so few as to make the tokens to
complex to understand. Take Perl. It can very concisely describe a
way to digest a large text file. It has the undesirable
characteristic of being a write-only language. I find that I have a
heck of a time reading other peoples Perl. I tend to be more verbose
than necessary.
When Lincoln gave his address at Gettysburg, PA, he followed someone
(I forget who) that gave a speech that went on for some length.
Lincoln's speech was on the order of a couple minutes. When he sat
down afterwards, the previous fellow was reported to say that Lincoln
had said more in his short address than the fellow did in his long
winded speech.
I hope this analogy gets across my meaning in the way I intended.
% > Is Lisp less prone to buggy code?
%
% Well, plainly there are some bugs in programs that are due to type
% mismatches. And plainly languages that are statically typed are
% better at that. Lisp is a grand experiment in the belief that there
% is more to programming than type errors. There are design errors, for
% example. And rapid prototyping (prototype -> users -> feedback ->
% new-prototype -> users -> feedback -> ...)detects them better than the
% clasical "waterfall" model. (requirements -> design spec ->
% implementation -> users) .
By less buggy, I mean code that performs as intended by the
programmer, not necessarily what was asked for by the end user who may
not have stated any clear design requirements. In practice, I don't
have the luxury of working with any sort of functional specification.
If asked for one, I document what my code already does :-).
Sometimes, code really is the best word to describe it too :-).
One example of a bit of code I wrote where the requirement was not
complete was, "write an ISAPI filter for Microsoft's Proxy Server to
force certain URIs to be requested only by https rather than http."
This was actually a trivial filter to write (in C++ using the SDK).
Then along comes another request: "I need some URI to be non-secure
because Java won't work otherwise." So I had to go back and add
functionality. The original code wasn't written to be extended, but I
managed to fit it in. Additional requirements got thrown at the
filter. At that point I was working on something else. Another
programmer undertook the task of changing the code. This other
programmer is a good engineer, but he is used to more abstraction from
the OS. In this case, it worked to his disadvantage and I had to
revisit my code. In the course of doing that, I discovered latent
bugs of my own creation along with additional difficulties that the
other programmer introduced. The worst part of the experience was
working around a badly thought out design of the ISAPI interface for
filters that Microsoft had come up with. It was possible for my
filter to send a 302 down to the client in clear text over a secure
port. The client doesn't like that and immediately complains and
drops the connection.
That particular code I couldn't have written in anything other than C
or C++ no matter how much I wanted too. However, it seems that a
desirable characteristic of a general purpose programming language is
to reduce the likely hood of a programmer error.
My friend at work who dislikes Lisp used to work for AT&T. Emacs was
his editor of choice (and still is). He had it set to a mode that
reformatted the text of a visited file so that the code matched a
convention that someone had decided upon when they added the c-mode to
Emacs. Or perhaps it was part of a canned .emacs file. At any rate,
it blew up a metric that AT&T used to measure bugs in new code. That
metric was bugs per thousand lines of new code. The simple
reformatting fooled the metricing software into thinking there were
many more lines of new code than really existed. Once that problem
was discovered, a new metric was devised. My friend came up with a
metric based on tokens. That made formatting irrelevant.
Anyway, all programming languages are made up of tokens. I might
naively wonder if Lisp code normally has fewer bugs per million tokens
than a C program. But that would be a bad comparison if a Lisp
program and its C equivalent wildly varied in size. I have no idea
how to normalize the numbers in any meaningful way.
Maybe declaring that wild pointers don't happen in Lisp would be a
nice .advocacy answer. It seems quite popular in
comp.lang.java.advocacy.
David Steuber The Interloper
claimed or asked:
% Somebody wrote a HTTP server, so I assume somebody could write a
% browser.
In my experience, this is a case where the server is easier to write
than the client. There is no GUI to worry about. With GUI programs,
it seems like 90% of the code is for the GUI. No GUI should make the
program 10% of the size of a GUI program. I'm sure this
generalization is easy to break.
I think I am pretty well sold on Lisp. The only thing that could
derail me is not being able to do what I want in Lisp. Java failed me
a while back because the AWT was so buggy. I don't forgive easily. I
haven't done anything of consequence in Java since.
Lisp has CLOS, so I can still do OOA/D/P.
David Steuber The Interloper
claimed or asked:
% >he admits to only knowing some Emacs Lisp just well enough to
% >configure Emacs to his liking.
%
% So he uses Lisp for some completely non-AI stuff and still says such
% stupid things? Disregard him.
That isn't easy to do. He knows the internals of C++ and Unix to an
extent I would not have thought humanly possible. He also is very
good at architectural design and analysis. This guy is brilliant.
However, he is not infallible. I have been able to code some
algorithms with slightly better efficiency :-). OTOH, he has written
compilers and implemented portions of Unix. That is far and away more
than I have done. He also knows a lot more about features of Emacs
than everyone else at the company.
It would be like Ptolemy arguing with Feynman. However, he is open
minded. But he is also human. He doesn't like Perl just because it
has such bizarre syntax. I can understand that. I like/hate Perl. I
like its power, I hate the syntax.
Anyway, the issue is decided. Not only have I chosen to give Lisp a
solid try, I have chosen to use cmucl. I just have to get set up for
it. I also want to try GARNET, but I have not been successful in
obtaining it.
F. Heinrichmeyer
Reini Urban <rur...@sbox.tu-graz.ac.at> writes:
> ...
> system than trying to raise my IQ (impossible!) or learn it the silly
> ...
++++++++++++++++++++++++++++++++++++ ^ not true ^ ++++++++++++
IQ can be raised and is partly formed by training! IQ goes down when
there is no challenge for the brain for some time so ..... IS LISP
DANGEROUS FOR OUR BRAIN?
--
Fritz Heinrichmeyer mailto:fritz.hei...@fernuni-hagen.de
FernUniversitaet Hagen, LG Elektronische Schaltungen, 58084 Hagen
(Germany)
tel:+49 2331/987-1166 fax:987-355 http://ES-sun1.fernuni-hagen.de/~jfh
PGP fingerprint (mail for key): 160BDF84 3F2F63C0 5CA20D31 3E42D116
Erik Naggum
| That isn't easy to do. He knows the internals of C++ and Unix to an
| extent I would not have thought humanly possible. He also is very good
| at architectural design and analysis. This guy is brilliant. However,
| he is not infallible. I have been able to code some algorithms with
| slightly better efficiency :-). OTOH, he has written compilers and
| implemented portions of Unix. That is far and away more than I have
| done. He also knows a lot more about features of Emacs than everyone
| else at the company.
just because he has optimized himself for one mind-set doesn't make him
even able to claim anything about any other mind-set for which he has
deliberately _pessimized_ himself. the odd thing about optimization in
one direction is that it costs much more than it could ever gain on the
whole, but that _one_ direction of optimization has been perceived as
valuable enough to absorb the costs. (I'm talking about what humans do,
not machines.) the result is extremely hard to optimize for something
else, which was obviously possible _before_ going to the far end of the
one optimization direction that was chosen.
(I used to be a C/Unix guru, and I still get called upon to give courses
in C and presentations on the history of Unix and Unix internals and
such, but I had gotten bored, and C++ appeared to be the future at the
time, so I _had_ to find something else. I had programmed toys in Lisp
on and off since late seventies, so CMUCL became the savior of my sanity,
and I spent three years studying and working with it before I felt I was
sufficiently competent to write Common Lisp applications for commercial
clients. so I made living writing articles for newspapers and computer
magazines, instead. I don't know anybody who doesn't think this was a
high prize to pay to change course, but life is too long to want to be an
expert in C++.)
#:Erik
Martin Rodgers
steuber.com (David Steuber "The Interloper") says...
> When a program editor can show me syntax errors as I type them or find
> expressions for me, that makes my job easier. I can think more about
> the program than the task of code entry.
I usually find errors by compiling and running the code. No editor can
tell me about errors not caught by the compiler or me checking the
runtime behaviour of the code I've just written.
This is true for every language that I've used, so perhaps it says
something about the kind of code I write! YMMV, but I find that an editor
that does little more than matching of parens is good enough for me.
Curiously, most non-Lisp editors fail to do this.
Note: if you can write less code, then you have less code to check. No
editor will help you do this. No app wizard will, either. The best they
can do is generate some of the code for you. You still need to edit it.
So I prefer to edit the code that writes the code.
--
Remove insect from address to email me | You can never browse enough
will write code that writes code that writes code for food
Reini Urban
>I wrote:
>> than trying to raise my IQ (impossible!)
>
>tests simply by practicing similar puzzles...
>
>If you define your IQ as something like "the score you get on taking
>an IQ test" then it is possible to dramatically raise your IQ.
i originally thought the same but it was not possible over the years!
my tests with 18 gained the same results as with 25 (after a few days
extensive training to get a good job) and now (with 35) again. seemed to
be good-enough tests :) now i'm rather satisfied with being dull.
The easiest way of course would be to try and train other IQ tests. but
this is probably only needed for hiring tests not for improving
programming skills.
--
Reini Urban
Raymond Toy
David> Anyway, the issue is decided. Not only have I chosen to give Lisp a
David> solid try, I have chosen to use cmucl. I just have to get set up for
David> it. I also want to try GARNET, but I have not been successful in
David> obtaining it.
You can get a version of Garnet for CMUCL at www.cons.org in the ports
directory. It includes several patches and fixes not available in the
"stock" version of Garnet.
Ray
Reini Urban
>| maybe that's the point why guile and not perl will be used as general
>| purpose scripting language for desktop environments in unix (gnome).
>
> incidentally, I think GUILE is _really_ stupidly designed, too, and Emacs
> Lisp started losing its charm quickly in 1995, and by the time MULE had
> been "integrated", had become just another god-awful "design-free" mess.
admitted. guile seems to have the worst design of all lisp dialects
around. worse than islisp, and it is the slowest lisp/scheme also. but
what would you have expected from GNU people?
it least it's dramatically better than shell programming, perl or c.
i always feared that they will come up with an interpreted c for
application customization :) or yet another perl-, autoconfig-,
sendmail- or m4-like syntactic mess. at least it's some kind of readable
lisp.
---
http://xarch.tu-graz.ac.at/autocad/news/faq/autolisp.html
"C makes it easy to shoot yourself in the foot. C++ makes it
harder, but when you do, it blows away your whole leg."
-- Bjarne Stroustrup on C++
Reini Urban
>this may be not completely off-topic:
>Reini Urban <rur...@sbox.tu-graz.ac.at> writes:
>> trying to raise my IQ (impossible!)
>IQ can be raised and is partly formed by training! IQ goes down when
>there is no challenge for the brain for some time so ..... IS LISP
>DANGEROUS FOR OUR BRAIN?
hey, tell me how!
should i immediatly stop doing lisp and join the wave riders in hawaii?
this seems to be more challenging for the brain and my whole soul at
once.
or are you refering to the everydays challenges such as porting unix
software to nt or even win95, written in "portable" c?
this will bring more money, a secure job, and even raise my IQ
dramatically!
good point!
getting rich and smart versus staying lazy, poor, self-satisfied,
knowing-it-better and lonely.
--
"The C language is particularly rich with ways of writing a program
that totally hides the original design intent." Stanley Crow
Paul Rudin
>
> The easiest way of course would be to try and train other IQ tests. but
> this is probably only needed for hiring tests not for improving
> programming skills.
Indeed, to improve ones programming skills I guess you want to
practice programming and study relevant theoretical work. Improving
ones ability to get high IQ scores will presumably have little bearing
on this.
The trouble with IQ tests is they try to associated a number with
something that is inhenetly much more complex than can be captured by
such. Some people are very good at certain tasks that require
intelligence and not so great at others. It the context of the currect
discussion it may be that some people are just much better able to
express certain algorithms in, for example, C++; whereas others may
find Lisp provides a closer match with the way they envisage things.
Erik Naggum
| IQ can be raised and is partly formed by training! IQ goes down when
| there is no challenge for the brain for some time so ..... IS LISP
| DANGEROUS FOR OUR BRAIN?
Lisp is both more challenging and more rewarding than doing complex
menial labor, which is what C/C++ is about. aim for supreme elegance
_and_ total efficiency at the same time, and your brain should have
plenty to work on. :)
#:Erik
Klaus Schilling
> Erik Naggum <er...@naggum.no> wrote:
> >| maybe that's the point why guile and not perl will be used as general
> >| purpose scripting language for desktop environments in unix (gnome).
> >
> > incidentally, I think GUILE is _really_ stupidly designed, too, and Emacs
> > Lisp started losing its charm quickly in 1995, and by the time MULE had
> > been "integrated", had become just another god-awful "design-free" mess.
>
> admitted. guile seems to have the worst design of all lisp dialects
> around. worse than islisp, and it is the slowest lisp/scheme also. but
> what would you have expected from GNU people?
All lies. Guile is the singlemost best designed lisp-like language. It compiles
from C source on all decent operating systems and can be easily extended with
wrappers over system libraries. GNU people only produce the best possible
software, unlike non-GNU people.
Klaus Schilling
Martin Rodgers
> admitted. guile seems to have the worst design of all lisp dialects
> around. worse than islisp, and it is the slowest lisp/scheme also. but
> what would you have expected from GNU people?
A tool designed for scripting and small enough to link into apps like
Gimp? (I'll ignore your anti-Scheme bias.)
Performance today is not too meaningful, as it looks like the Guile
people intend to eventually replace the SCM core with a bytecoded design.
Check the archives for the Guile mailing list for details. Meanwhile, how
fast does a script engine need to be?
> it least it's dramatically better than shell programming, perl or c.
That may well be the point of Guile. CTAX already offers a C-like syntax,
and Perl and Tcl might someday be "assimilated". I'm more than a little
sceptical of this, esp after Randal Schwartz's "smoke and mirrors"
comment on Perl syntax in comp.compilers, earlier this year. However, I
love the idea of Guile running Perl code from CPAN.
Nobody can accuse Lisp people of not thinking big. ;-)
--
Please note: my email address is munged; You can never browse enough
"There are no limits." -- ad copy for Hellraiser