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
Barry Margolin
Reini Urban <rur...@sbox.tu-graz.ac.at> wrote:
>i always feared that they will come up with an interpreted c for
>application customization :)
It's been done. Over a decade ago I used an Emacs-like editor for DOS
called Epsilon. It was pretty nice (about as good a text editor as you
could get for a PC/XT, which was the state of the art at the time) and
extensible. The extension language was patterned after C, but it was
interpreted. I expect it was actually translated into byte codes during
loading, since it was reasonably performant.
Richard MacDonald
strictly as a tool for identifying retardation. There was *no* significance
to a number any higher than 50. Some stupid (and racist) sociologist took
the idea and ran with it. Society has paid dearly ever since. See Steven Jay
Gould's book "The Mismeasure of Man".
Erik Naggum
| I have to disagree with you on one point. Linux is a better end-user
| environment than NT.
uh, I'm not sure we disagree, because your statement is not qualitatively
comparable to the statements "Linux is a programming environment" and "NT
is an end-user environment". I was _not_ comparing the two, I was only
pointing out what they are best at, almost, but not explicitly, to the
exclusion of (focus on) the other. I don't know any actual end-users for
whom NT is the best choice, myself, and all the people I know who say
they think NT is best for end-users don't know any particular person for
which this even _might_ be true, either, but it _has_ been optimized for
_some_ concept of "end-user", and Linux continues to be optimal for
programmers or at least end-users-who-aren't-afraid-of-programmers.
| 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.
I honestly think you should forget making money on free software, and
regard it as luck if it happens. the very concept is basically flawed:
masses of people will never pay for support, but they _will_ pay more for
upgrades than for the original product, which might as well come for
free. quality software does not sell in volumes, and free software is
generally high quality software.
instead, aim for making the software you write for commercial clients
free after a certain period. my clients have accepted that general-
purpose components that I build half on their time and half on my own
time to get the desired functionality for their use, may be re-used and
publicly released as I see fit, but no sooner than six months after the
system has stabilized.
#:Erik
Raymond Toy
Klaus> All lies. Guile is the singlemost best designed lisp-like language. It compiles
Klaus> from C source on all decent operating systems and can be easily extended with
But many other schemes can also be compiled from C source on all
"decent" platforms. I think RScheme, STk, Elk are all compiled from C
source. I think they all have wrappers for system libraries too.
I'm sure there are others.
Klaus> wrappers over system libraries. GNU people only produce the best possible
Klaus> software, unlike non-GNU people.
Is that why CMUCL (non-GNU, from CMU folks) is the best open source
Lisp around? Certainly beats gcl.
Ray
Barry Margolin
> 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.
On this point I strongly agree with Erik. People often get tunnel vision
or are biased by misconceptions and preconceptions. When you want a fair
comparison between languages, go to people who have serious experience with
them in realistic settings.
I've done reasonable amounts of programming (i.e. more than one or two toy
programs) in BASIC, COBOL, PL/I, C, Lisp, Perl, and assemblers for PDP-8
and Z80, I've dabbled a little in Fortran, CLU, Pascal, Tcl, and perhaps
some I've forgotten, and I'm familiar with Ada and APL. I have likes and
dislikes, but I can see the merits of the ones I don't particularly care
for (just as I wouldn't care to drive a tractor trailer, but I can
recognize that it's good for what it's designed for). I've also seen the
insides of a number of language implementations, so I understand what it
takes to make them work well.
For instance, occasionally people assert "Lisp isn't a good language for
programming OS kernels", which is then countered with "Tell that to the
people who designed Lisp Machines." Yes, Lisp Machines are Lisp all the
way down, but it's not portable Common Lisp. Lisp Machine kernels have
some of the same low-level programming needs as other kernels, so they have
objects that are like pointers in traditional system programming languages;
you start playing around with these and you can get yourself into some of
the same kinds of problems you run into in C. And for performance reasons,
there are parts of the system that do manual memory management; there's a
library of functions for maintaining a "pool" of similar objects (it's used
heavily by the networking routines, to allocate and deallocate packet
buffers), and if you forget to return an object to the pool when you're
done with it you can get memory leaks, or you can get duplicates if you
return it prematurely. Of course, the fact that these non-Lispy things are
embedded in a Lisp System does give them an advantage; for instance, if
you're using a pool object in such a way that it should be freed when you
return from the function, there's a WITH-xxx macro that allocates an object
from the pool and guarantees to return it when done (this prevents the
leak, but duplication is still possible if you were wrong about the object
not needing to live beyond that dynamic extent). What this indicates is
that low-level programming often requires certain mental disciplines, which
happen to be similar to the requirements for facility in languages like C
and PL/I; that's one reason why those languages are popular for such tasks.
Hrvoje Niksic
> In article <361e1169.14866807@judy>,
> Reini Urban <rur...@sbox.tu-graz.ac.at> wrote:
> >i always feared that they will come up with an interpreted c for
> >application customization :)
>
> It's been done. Over a decade ago I used an Emacs-like editor for DOS
> called Epsilon. It was pretty nice (about as good a text editor as you
> could get for a PC/XT, which was the state of the art at the time) and
> extensible. The extension language was patterned after C, but it was
> interpreted.
How close is "patterned after C" to the actual C? Because there are
plenty of editors with C-like syntax, a very popular one being Jed
with S-Lang for extension language.
--
Hrvoje Niksic <hni...@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Then... his face does a complete change of expression. It goes from
a "Vengeance is mine" expression, to a "What the fuck" blank look.
Reini Urban
>This is why I like reading your posts. You force me to be more
>precise. I need more of that.
i you want to go the precise way use assembler. if you want to do lisp
use generalisation and abstraction.
forcing people to express themselves more precisely may loose one
important aspect of communication: associations on ambiguities. which
has to something do with learning.
-- Reini Urban
http://xarch.tu-graz.ac.at/autocad/news/faq/autolisp.html
(defun member (item l)
(cond ((null l) nil)
((equal item (car l)) l)
(t (member item (cdr l)))))
Barry Margolin
Hrvoje Niksic <hni...@srce.hr> wrote:
>Barry Margolin <bar...@bbnplanet.com> writes:
>
>> In article <361e1169.14866807@judy>,
>> Reini Urban <rur...@sbox.tu-graz.ac.at> wrote:
>> >i always feared that they will come up with an interpreted c for
>> >application customization :)
>>
>> It's been done. Over a decade ago I used an Emacs-like editor for DOS
>> called Epsilon. It was pretty nice (about as good a text editor as you
>> could get for a PC/XT, which was the state of the art at the time) and
>> extensible. The extension language was patterned after C, but it was
>> interpreted.
>
>How close is "patterned after C" to the actual C? Because there are
>plenty of editors with C-like syntax, a very popular one being Jed
>with S-Lang for extension language.
It's been a dozen years, so I don't remember many details, but it was
pretty close to C. It has all of C's data types, including pointers, plus
some extensions designed for editor programming (e.g. per-buffer
variables).
It was called EEL -- Epsilon Extension Language. In fact, I just searched
for this at Altavista, and found that the product still exists, now for
Windows of course. See <http://www.lugaru.com/extensible.html> for their
marketing blurb on EEL. There's also a page there describing the
history/evolution of Epsilon -- it's eerily similar to the evolution of GNU
Emacs, although different features appeared at different times (e.g. the
Epsilon equivalent of ange-FTP just appeared in the latest release).
Kent M Pitman
>
> "The Interloper" about Pitman:
> >This is why I like reading your posts. You force me to be more
> >precise. I need more of that.
>
> i you want to go the precise way use assembler. if you want to do lisp
> use generalisation and abstraction.
> forcing people to express themselves more precisely may loose one
> important aspect of communication: associations on ambiguities. which
> has to something do with learning.
there's no ambiguity lost here. you have to stretch a lot to
see how i'm "forcing" him. :-)
i agree ambiguity is an immesnely important aspect of language, to the
point where i think scheme in its zeal to be minimalist loses some
important "opportunities" for ambiguity by defining them to be bad.
[e.g., the whole designator concept costs very little to implement and
execute, and it saves a great deal of explicit coercion. it can be
trivially optimized if the performance impact turns out to matter by
just doing either type inferencing or declaration processing. it
causes a modest implementor burden and consolidates certain coercion
all in one place (perhaps even shrinking code size because of the lack
of explicit coercion) rather than distributing it.]
so don't count me in the anti-ambiguity camp, regardless of how the
ambiguity of my "forcing" anyone to be unambiguous makes it look.
on the other hand, i don't think ambiguity for no good reason is a
good thing. ambiguity is your friend when what you want to exprss
is in fact ambiguous--that is, when you are mirroring a real-world
ambiguity. ambiguity is not your friend when you are saying
something that is intended to have specific meaning but your
ambiguity arises not out of a desire to be vague but out of a lack
of command of language, or out of a lack of willingness to spend
time being precise about what you DO know. so there is soemtimes
a case against ambiguity.
Klaus Schilling
> >>>>> "Klaus" == Klaus Schilling <Klaus.S...@home.ivm.de> writes:
> Klaus> All lies. Guile is the singlemost best designed lisp-like language. It compiles
> Klaus> from C source on all decent operating systems and can be easily extended with
>
> But many other schemes can also be compiled from C source on all
> "decent" platforms. I think RScheme, STk, Elk are all compiled from C
> source. I think they all have wrappers for system libraries too.
> I'm sure there are others.
STk is too much GUI oriented (if it's a complete scheme compiler/interpreter
at all and not just an extension/library of an earlier scheme interp/comp, as
Tk is for Tcl).
The way in which elk lets extenders define new elk object types is not flexible
enough to provide customizable garbage collection for new types, at least it is
not as straightforward as in the case of guile.
Klaus Schilling
Steve Gonedes
m...@wildcard.butterfly.demon.co.uk (Martin Rodgers) writes:
< In article <36218368....@news.newsguy.com>, trashcan@david-
< 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.
I think it's a combination of tools that help most in reducing the
silly bugs I make. For me it's auto-indentation, completion,
deliminator matching, and an interpreter that can evaluate the code
while I'm typing it. Dunno about an app-wizard. It sounds like it
would be nice if it were merged into the emacs customize facility
though (have it write elisp code rather than custom stuff that way you
_don't_ have to edit it).
David Steuber The Interloper
asked:
% I honestly think you should forget making money on free software, and
% regard it as luck if it happens. the very concept is basically flawed:
% masses of people will never pay for support, but they _will_ pay more for
% upgrades than for the original product, which might as well come for
% free. quality software does not sell in volumes, and free software is
% generally high quality software.
Well, I have no expectation of making any money. Just a weak hope.
For the project I am working on, I am my own client, so there are no
issues there :-).
I would get a great deal of satisfaction if I am successful at
releasing a product that people like to use. Whether I make a dime
off of it is entirely secondary. I certainly wouldn't expect
students, teachers, or other non-commercial users to want to pay
anything, so I won't even ask. Commercial users may be another story.
However, I am putting the cart before the horse here. I should
actually publish something before I worry about such hypothetical
details.
David Steuber The Interloper
asked:
% 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++.)
Life is too long? I've never heard that one before :-)
C++ has lost a lot of its appeal to me as well. The language has
become exceedingly complicated.
Common Lisp looks a bit scary too. I am hoping that is because it is
a new language to me. In all my life of speaking one language,
English, I haven't mastered it to the point where I could write for a
living. For some reason, programming is more forgiving and I can do
that for a living.
Will I ever master Lisp? I doubt it. I may be able to write useful
programs in it though.
David Steuber The Interloper
<rur...@sbox.tu-graz.ac.at> claimed or asked:
% i you want to go the precise way use assembler. if you want to do lisp
% use generalisation and abstraction.
% forcing people to express themselves more precisely may loose one
% important aspect of communication: associations on ambiguities. which
% has to something do with learning.
But what happens when I ask a question in plain English, and the
question it self is nonsense to everyone else? It is my
responsibility to get the other person to hear what I thought I said,
and not what I said.
How many legitimate interpretations are there for the following
phrase?
"The answer, my friend, is blowing in the wind."
Then of course there is the old saw about the English to Russian and
Russian to English machine translator. It took the phrase
"The spirit is strong, but the flesh is weak."
and translated it to Russian. Then it was translated back and came
out like so
"The vodka is good, but the meat is rotten."
So when I as if Lisp is more concise, what does that really mean? I
thought I was clear with the question. Obviously I wasn't.
Christopher Browne
>i agree ambiguity is an immesnely important aspect of language, to the
>point where i think scheme in its zeal to be minimalist loses some
>important "opportunities" for ambiguity by defining them to be bad.
>
>[e.g., the whole designator concept costs very little to implement and
>execute, and it saves a great deal of explicit coercion. it can be
>trivially optimized if the performance impact turns out to matter by
>just doing either type inferencing or declaration processing. it
>causes a modest implementor burden and consolidates certain coercion
>all in one place (perhaps even shrinking code size because of the lack
>of explicit coercion) rather than distributing it.]
>
>so don't count me in the anti-ambiguity camp, regardless of how the
>ambiguity of my "forcing" anyone to be unambiguous makes it look.
That sounds ambiguous to me :-).
>on the other hand, i don't think ambiguity for no good reason is a
>good thing. ambiguity is your friend when what you want to exprss
>is in fact ambiguous--that is, when you are mirroring a real-world
>ambiguity. ambiguity is not your friend when you are saying
>something that is intended to have specific meaning but your
>ambiguity arises not out of a desire to be vague but out of a lack
>of command of language, or out of a lack of willingness to spend
>time being precise about what you DO know. so there is soemtimes
>a case against ambiguity.
That latter bit seems to me to be a problem.
Ambiguity is *not* your friend when you're not sure which parts are
necessarily ambiguous, and which parts are unknowns that are going to
bite you later.
Scheme tries to do the "going back to first principles" thing so as to
explictly shake out ambiguities, and I suppose that it's fair to suggest
that the attempt to *eradicate* ambiguity may go too far.
I'd suggest that it's ambiguous whether it is preferable to:
a) Attempt to eradicate ambiguity, and thereby risk dilemna when
ambiguity is inherent to a system, or
b) Try to explicitly cope with ambiguity, thus risking that there are
things that you only *think* are ambiguous.
And then there's the Lone Ranger...
--
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"
cbbr...@hex.net- <http//www.hex.net/~cbbrowne/lsf.html>
Kent M Pitman
> I'd suggest that it's ambiguous whether it is preferable to:
> a) Attempt to eradicate ambiguity, and thereby risk dilemna when
> ambiguity is inherent to a system, or
>
> b) Try to explicitly cope with ambiguity, thus risking that there are
> things that you only *think* are ambiguous.
I have no problem with this "tension". The thing that bugs me about
Scheme is that it's never a fight between "their way" and "our way".
It's always a fight between "their right to assert theirs is the only
way" and "our right to assert our way has a place, even if not a
uniquely determined place".
"Obviously", ambiguity is sometimes bad. I had tried to pick a middle
of the road presentation that said it is at least sometimes good,
sometimes bad, and sometimes in a gray middle area.
I just tire of people in the Scheme community--not all Schemers, but
enough to wear me down--using "Common Lisp" as synonymous with "the
obvious work of the devil", and "CL-like" as synonymous with
"hedonistic depravity of the most sinful and immoral kind". I probably
come across as anti-Scheme, but really I'm not. Sometimes I just have to
speak strongly on matters related to it not to put it down, but to
prop up the things I see in my camp that they've given such a bad name.
I've been lately in the "everything is an analogy to the Clinton situation"
mode, and this is no exception. The right-wingers are enjoying a certain
smugness because they think they're "right" (pardon the pun) on this matter.
But really the problem is more that the right-wingers have a certain simple
model that is easy to articulate, and it's easy to confuse the ability to
articulate and chant a certain simplistic (and perhaps even useful) view
with the fact of being uniquely right. What the right-wingers have failed
to recognize, because the left-wingers have failed to articulate it, is
that there IS a morality which drives people to say that Clinton has done
nothing wrong. It is not as simple as an abandonment of all that is good
to say one is behind Clinton. What the left-wingers are doing, I think,
is rejecting simple platitudes like "lies are always wrong" because,
among other things, they think "lies are always wrong" is a useful lie,
but is itself a lie, and therefore is itself a proof that the maxim is
not universal.
Back to Scheme and ambiguity--it is easy to develop a theory of
simplicity and elegance that tells you Scheme is right and everything
else is wrong. What's hard to do is to prove that theory of
simplicity and elegance is uniquely righteous. I personally happen to
value simplicity of programmatic expression over simplicity of
language, and I believe the two are in natural tension. To me, it's
not important that the language is complex if it leads to simpler
programs. To a Schemer, that's horrifying--and I think the price they
pay for it is more complex programs than CL has.
But what's really sad is that one thing the Scheme community HAS done
is invest in articulating its viewpoint, and the CL community has not
really done that to the same extent. More often, we just grin and
bear it when they take potshots at our language for what they say are
inelegances. Lazy declarations is one. Multiple syntaxes for the
same thing is another. Ambiguity (in the form of many pre-defined
argument type coercions) is another. All of these things are
"features" in my book. Not in the sense of being always the best
thing--but in the sense of having been put ther out of an engineering
belief that they'll be good enough of the time to make it worthwhile.
So if you see me push back at what may appear to be no specific
criticism, it's usually that vague etherial sense that through faiulre
to be just as militant as the Scheme people about these issues that
are indeed part of our design methodology, people forget that there
are reasons and start to believe the oft-chanted tommyrot about how CL
is not a language designed by people who thought hard about issues and
who valued elegance and all of that.
The CL designers value elegance as much as anyone. But they are
somewhat pluralistic about the nature of elegance, and so there are
conflicting theories. They also value other things that are not just
elegance, like practicality. And so the elegance is sometimes mixed
in with other aspects, and something you don't always see.
Since I was little, I've been a collector. Stamps, coins, and various
odd idiosyncratic things. Sometimes I notice I collect things and
don't even use them because my sense of "elegance" requires me not to
use something lest I ruin its collector's value. Other times, I
actively fight this and insist there is no purpose in owning and
appreciating something if you don't actually use it. There's probably
some truth in both of those. But CL and Scheme seem to me to fit by
analogy into the same framework. Scheme seems to me like a language
that has never really made its way out there to real things because
it's so concerned with being pretty that it avoids adding useful stuff
it really needs. CL was willing to add the useful things, even if it
ment getting nicks, scratches, etc. from the use.
I have no idea if anyone but me thinks these are even related topics
that I'm hopping between. Sorry--it's just how my mind works.
Ambiguity is a tool upon which important structure is built. Like
puns. Though sometimes considered low humor intellectually, puns are
structurally pretty interesting. And a great deal of clever
programming uses punning. (Whether "clever" programming is to be
sought or merely tolerated or actively shunned I'll leave for another
day. But I think the world would be sadder if there were no
such cleverness in programming or in humor or whatever....)
Maybe that helps link it all up for you, or maybe it just makes it
muddier. But eithe way, I'll stop here before I appear to drift
further afield.
Rob Warnock
| 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."
+---------------
Also see Robert Heinlein's short story "The Lazy, Lazy Man"...
-Rob
-----
Rob Warnock, 8L-855 rp...@sgi.com
Applied Networking http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
2011 N. Shoreline Blvd. FAX: 650-964-0811
Mountain View, CA 94043 PP-ASEL-IA
Charles Hixson
>
...
> All lies. Guile is the singlemost best designed lisp-like language. It compiles
>
> Klaus Schilling
Did I see a smiley on that?
Charles Hixson
> 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
What are the differences between Harlequin and Franz on a Win95 platform
(including approximate price)? (They don't seem to mention prices on
their web site, curious eh?).
Charles Hixson
>
> Pardon me for using this newsgroup as a sounding board for some
> questions / doubts in my mind about Lisp.
>
> alias Common Lisp Lisp
...
> 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
That is the standard attitude on lisp, and it was formed when the
professors who taught the current generation of programmers last looked
at it. Say, around Lisp 1.5.
At that time it was basically correct to say "Lisp was a general purpose
language only in the sense that a Turing machine is." Lisp was a purely
interpretive language in a day when every cpu cycle cost $$ and lisp
programs took lots of RAM in a day when 32K was a HUGE computer (of
course that was 36-bit words, not bytes).
Today, perhaps, things are a bit different. C++ programs use Megabytes
of space on the hard disk. For that matter, so do full-color pixel
images. Lisp comes with a built-in garbage collector, while C programs
regularly die for lack of proper memory management.
I'm a pre-novice in Lisp, so I can't really tell you all that you want.
I am an expert in C, intermediate in Java, intermediate in C++,
post-intermediate in VisualBasic, novice in Ada, expert in Fortran 60,
intermediate in Snobol (expired), etc. Most languages can do most
things. All have certain things that they are best at. If you want
direct control over the hardware, use C, and drop into assembler for
small pieces when you need to. If you need to create object bindings
dynamically, use a dynamic language (currently, this seems to be limited
to Lisp and Smalltalk [that's why I'm studing lisp]). etc.
I see no reason that Lisp shouldn't work fine as a language for
implementing a browser, just be sure that you can call foreign functions
in case there's something lisp can't handle (What? [As I said, I'm
pre-novice]).
Erik Naggum
| (They [Franz Inc] don't seem to mention prices on their web site, curious
| eh?).
not really -- it has legal repercussions to quote prices in publicly
available material, _and_ several companies that advertise on the Net and
elsewhere would rather you call them based on product interest rather
than price.
e.g., I still (occasionally) order pizza at special offer prices because
they forgot to include important legal phrases like "prices subject to
change without notice" and "offer valid through ..." on flyers that they
left _millions_ of at the University of Oslo campus in the fall of 1988.
#:Erik
Erik Naggum
| That is the standard attitude on lisp, and it was formed when the
| professors who taught the current generation of programmers last looked
| at it. Say, around Lisp 1.5.
|
| At that time it was basically correct to say "Lisp was a general purpose
| language only in the sense that a Turing machine is." Lisp was a purely
| interpretive language in a day when every cpu cycle cost $$ and lisp
| programs took lots of RAM in a day when 32K was a HUGE computer (of
| course that was 36-bit words, not bytes).
LISP 1.5 Programmer's Manual, ISBN 0-262-13011-4.
Table of Contents:
...
APPENDIX B The LISP Interpreter
APPENDIX C The LISP Assembly Program (LAP)
APPENDIX D The LSIP Compiler
...
date of publication: 1962-08-17.
it cost USD 8.95 when I bought my copy at the MIT Book Store a few years
ago. you're advised to read it before you make claims about LISP 1.5.
#:Erik
Steve Furlong
Rob Warnock <rp...@rigden.engr.sgi.com> wrote:
>Also see Robert Heinlein's short story "The Lazy, Lazy Man"...
Eh? I thought I'd read everything of RAH's, but this doesn't strike
a bell. Are you referrring to "The Tale of the Man Who Was too Lazy
to Fail" in _Time_Enough_for_Love_?
TIA,
Steve Furlong
Lieven Marchand
>
> Also see Robert Heinlein's short story "The Lazy, Lazy Man"...
>
I don't know that one. Do you mean "The tale of the man who was too
lazy to fail"? To expand a bit on my signature:
I don't think Dave thought of himself as an "efficiency expert" but
every job he ever held he simplified. His successor always had less
work to do then his predecessor. That his successor usually
reorganized his job again to make three times as much work -- and
require three times as many subordinates -- says little about Dave's
oddity other than by contrast. Some people are ants by nature; they
have to work even when it's useless. Few people have a talent for
constructive laziness.
--
Lieven Marchand <m...@bewoner.dma.be>
------------------------------------------------------------------------------
Few people have a talent for constructive laziness. -- Lazarus Long
David Steuber The Interloper
<charle...@earthlink.net> claimed or asked:
% images. Lisp comes with a built-in garbage collector, while C programs
% regularly die for lack of proper memory management.
Isn't Linux a C program? Well, about 10% is assembler...
I am looking at Lisp for two reasons. One is that the language offers
an entirely different way of thinking about programs over C and its
legacy. The other is that it seems like it may actually be the most
suitable language for a project I want to do.
The project, as I've said before, is an extensible 3D animation
modeler program that uses Lisp (or a subset) as a file format.
Normally, C++ would have been my first choice in implementation
languages. A year ago, I couldn't have imagined that there would be
an alternative to C++.
The only two books I've read on AI had examples in Lisp. Every book
I've looked at on Lisp starts out by saying that Lisp is the most
powerful computer language ever devised by mankind.
People I've asked at work who have used Lisp and C++ generally
preferred Lisp.
There must be something to this language. Ok, it isn't a mainstream
language. In fact, it seems to be one of the obscure languages that
if you asked a VB programmer about it, he would say, "never heard of
it." But since when is a language a popularity contest? Most people
are idiots. So popularity can't be used to judge the technical merits
of something.
It comes down to individual choice, I imagine. I am not a language
bigot. I will use what ever will get the job done with the least
amount of effort on my part. I typically don't lump learning a new
language into the effort equation. That would cause me to stick with
only one language. I'm sure I can do everything in C++, but that
doesn't make it the "One True Language."
The other major consideration is this. What is a computer programming
language for? It is a way to allow the human to express a program in
a way that is closer to human style thinking than machine style
thinking. Based on this, what makes a good programming language is
something that makes it as easy as possible to express a program in
some form that can be translated into what the machine can process.
Because of that human thinking portion of the equation, computer
languages will probably always be the subject of religious wars.
Well, at least until the computers don't need us anymore.
--
David Steuber (ver 1.31.2a)
http://www.david-steuber.com
To reply by e-mail, replace trashcan with david.
So I have this chicken, see? And it hatched from this egg, see? But
the egg wasn't laid by a chicken. It was cross-laid by a turkey.
Erik Naggum
| There must be something to this language. Ok, it isn't a mainstream
| language. In fact, it seems to be one of the obscure languages that if
| you asked a VB programmer about it, he would say, "never heard of it."
I would argue that there _are_ no mainstream programming languages, only
mainstream applications, with their attendant languages. in other words,
you don't choose VB, you choose some Microsoft product that has VB in it.
you don't choose C, you choose Unix. you don't choose C++, you choose
Windows. you didn't choose Pascal, you chose a Macintosh. all of these
inferior languages are chosen as _adjuncts_ to something else. Common
Lisp is the first programming language I have chosen in its own right.
| The other major consideration is this. What is a computer programming
| language for? It is a way to allow the human to express a program in a
| way that is closer to human style thinking than machine style thinking.
| Based on this, what makes a good programming language is something that
| makes it as easy as possible to express a program in some form that can
| be translated into what the machine can process.
|
| Because of that human thinking portion of the equation, computer
| languages will probably always be the subject of religious wars.
as long as you keep thinking in religious terms, your understanding of
rationally founded emotive responses will be seriously restricted. act
as if religion and organized irrationality does not exist, and try to see
the reasoning behind what you previously labeled "religious". _lots_ of
interesting properties of human thinking will reveal themselves.
#:Erik
Rob Warnock
+---------------
| Rob Warnock <rp...@rigden.engr.sgi.com> wrote:
| >Also see Robert Heinlein's short story "The Lazy, Lazy Man"...
|
| a bell. Are you referrring to "The Tale of the Man Who Was too Lazy
| to Fail" in _Time_Enough_for_Love_?
Could be, and if so, I apologize for the mangled reference. (I can't
easily check right now since my copy of "Time Enough For Love" is in
a box in the garage -- I know, I know, for shame!)
In any case [to bring this back to Lisp], the potential for a significant
tradeoff between "thinking" and "working" is one of the things I like about
Lisp (and Scheme). It sometimes seems to me that design in the presence of
a decent macro system involves a kind of search for a minimum of effort:
if you don't think enough, you "work stupid", and if you think *too* much
up front, you never finish. But somewhere in between...
-Rob
[p.s. Apologies in advance: Email'd replies may get
a "vacation" bounce message while I'm on sabbatical...]
Tim Bradshaw
> 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?
As fast as perl +/- a bit. Certainly faster than, say, scsh is (this
is a property of scheme 48 not scsh itself I think). It also needs to
start very very fast if it is to be accepted.
--tim
Raymond Toy
Charles> What are the differences between Harlequin and Franz on a Win95 platform
Charles> (including approximate price)? (They don't seem to mention prices on
I don't know since I only have the Harlequin personal version. At one
point the Harlequin site did have prices and I seem to recall that
all versions seemed to be about $500.
Ray
Martin Rodgers
says...
> As fast as perl +/- a bit. Certainly faster than, say, scsh is (this
> is a property of scheme 48 not scsh itself I think). It also needs to
> start very very fast if it is to be accepted.
As a standalone script engine, I'd agree. I can't comment on Gimp.
--
Remove insect from address to email me | You can never browse enough
will write code that writes code that writes code for food
Mike McDonald
Erik Naggum <er...@naggum.no> writes:
> LISP 1.5 Programmer's Manual, ISBN 0-262-13011-4.
> date of publication: 1962-08-17.
>
> it cost USD 8.95 when I bought my copy at the MIT Book Store a few years
> ago. you're advised to read it before you make claims about LISP 1.5.
>
> #:Erik
Amazon.com claims you can still get it for $11(US)!!!! I'm ordering mine!
Mike McDonald
mik...@mikemac.com
David Steuber The Interloper
asked:
% as long as you keep thinking in religious terms, your understanding of
% rationally founded emotive responses will be seriously restricted. act
% as if religion and organized irrationality does not exist, and try to see
% the reasoning behind what you previously labeled "religious". _lots_ of
% interesting properties of human thinking will reveal themselves.
If you have the time, peruse some of the advocacy groups.
comp.lang.java.advocacy is a good one. You will find lots of
fanaticism and flame wars.
It gets repetitive after a while.
Erik Naggum
| comp.lang.java.advocacy is a good one. You will find lots of
| fanaticism and flame wars.
I don't need any more _examples_ of apparent or obvious irrationality.
it is because of what I have seen already that I wonder why some people
engage in it and still think they are rational and want others to believe
that they are. as long as you brand it as "religious" or "fanaticism" or
other such labels that communicate "there is nothing that can or should
be understood here", you will obviously never understand them, either.
the other issue that I'm interested in, in this regard, is why certain
cultural "pockets" forbid emotive responses in what they want to label
"rational behavior". such must be the most repressive and destructive
cultures around: given that people _are_ emotional beings, too, there's
no wonder so many feel free to _become_ irrational if they feel strongly
about something, even if they arrived at it rationally.
my point is simply that there is something to be understood from people
who engage in "advocacy" and the like. I'm not quite sure what, but I
have long since dismissed the arrogant idea that there is _nothing_ to
learn from them. ironically, all the evidence suggests that those who
refuse to listen are the _least_ rational, because they don't even know
or recognize their _own_ emotive responses, and least of all do they
realize that the conclusion that somebody is "rational" is fundamentally
an emotive response, decided long before you actually hear what they say.
(of course, I'm not talking about the mentally ill -- they might even
appear rational from an adaptation and survival instinct perspective.)
#:Erik
rusty craine
I have access to a snobol program (my wife is an english professor) that
analysis written material. The analysis returns statistics regarding 1).
the intellect [my word choice not theirs] of the author 2). the education
[my word choice not theirs] level of the intended reader 3). several notes
on pattern complexity 4). if all submitted works were written by the same
author 5) on and on and on......The point - my wife run nine postings by
#:Erik through the program -
Summary: [in my words not program output]
all nine were written by a post graduate author for an intended readership
of -off the high end of the scale-. The notes on pattern complexity were
all pegged out. [range was from 1 to 10, with 10 high]
The question I must ask is not do have I the intellect or poor work ethic,
which every the Philosophy thread decided it took, to be a good lisp
programmer, but do I have the IQ to read #:Erik's postings :)
Rainer Joswig
<rccr...@flash.net> wrote:
> but do I have the IQ to read #:Erik's postings :)
do we have the *time* ?
Martin Rodgers
steuber.com (David Steuber "The Interloper") says...
> If you have the time, peruse some of the advocacy groups.
> comp.lang.java.advocacy is a good one. You will find lots of
> fanaticism and flame wars.
I've often wondered why there isn't a comp.lang.c++.advocacy ng.
> It gets repetitive after a while.
And then some.
Gareth McCaughan
> I don't know any actual end-users for
> whom NT is the best choice, myself, and all the people I know who say
> they think NT is best for end-users don't know any particular person for
> which this even _might_ be true, either,
There are cases in which it's best for sociological reasons.
I know some people who do (among other things) FPGA design,
and the best tools for this only work under NT. (Or it might
be "under Win32 generally"; I forget.)
Presumably this has nothing to do with the technical merits
and failings of NT, and everything to do with the fact that
most of their intended market was already running NT.
There are probably other domains in which the best software
available is only available for Gatesware platforms. (Obvious
but perhaps trivial example: games; not just the boring
3-d shoot-em-ups, but also various pieces of software that
are extremely useful to professional players of chess and
backgammon.)
--
Gareth McCaughan Dept. of Pure Mathematics & Mathematical Statistics,
gj...@dpmms.cam.ac.uk Cambridge University, England.
Bill Newman
: On Wed, 7 Oct 1998 12:07:31 -0500, "rusty craine" <rccr...@flash.net>
: claimed or asked:
: As far as I can tell, I've been cursed with mediocrity. The
: imagination exceeds the intellectual capacity to realize it. Very
: frustrating.
I don't think that's a very reliable test for mediocrity. In one
famous example, Einstein after 1915 probably wasn't all that mediocre,
but his imagination seems to have exceeded his intellectual capacity
to realize it. And if that isn't convincing (perhaps you suspect that
Einstein really was mediocre after 1915?) consider that he spent a
whole lot of time thrashing between 1905 and 1915 imagining the
General Theory of Relativity but not being able to get it to work.
There must surely have been some times in there when he and others
wondered whether his reach exceeded his grasp, and I submit that if
they'd used your test, they might have been led astray.
(In 1905 Einstein published 5 papers, including Special Relativity and
the photoelectric effect -- amazing work by any standard. Roughly
speaking, SR is relativity in uniform reference frames, without the
complexities introduced by gravitation causing local acceleration. In
or around 1915 he got General Relativity to work, dealing with gravity
in a self-consistent way. It's my -- admittedly vague --
understanding that he worked primarily on GR for the entire decade
1905-1915, with little to show for it until rather late.)
I'm not arguing that there aren't lots of mediocre people who satisfy
your test; but it seems to me that a test which tends to give
spectacular false positives is not one you should rely on.
ObLisp: The history of AI is full of projects whose creators'
imagination exceeded their intellectual capacity to realize it. Were
they *all* mediocre?
Bill Newman
David Steuber The Interloper
claimed or asked:
% ObLisp: The history of AI is full of projects whose creators'
% imagination exceeded their intellectual capacity to realize it. Were
% they *all* mediocre?
How about this then. It seems all the things I imagine doing have
been implemented by others. Probably better than I could.
Being in, say, the top 5% (I don't know where I fall) of human
intelligence (what ever that is) doesn't get me out of the idiot
class.
All that work Einstein did, and his Nobel prize was for the
photoelectric effect. I guess that was easier to verify in those
days.
David Steuber The Interloper
asked:
% I don't need any more _examples_ of apparent or obvious irrationality.
% it is because of what I have seen already that I wonder why some people
% engage in it and still think they are rational and want others to believe
% that they are. as long as you brand it as "religious" or "fanaticism" or
% other such labels that communicate "there is nothing that can or should
% be understood here", you will obviously never understand them, either.
I seem to have struck a nerve in you. Meanwhile, I am trying to
figure out if what you said in your entire post is a reflection on me
or you.
I can't escape my irrationality any more than anyone else can.
Nevertheless, I really would like to. While I have occasionally
benefited from tangential streams of thought, I have in recent years
been far more harmed by some of the oddities that the human brain can
throw at me.
Anyway, I wasn't criticizing anyone for having a preference of one
language over another. My criticism was aimed at the people who think
that their preference should also be everyone else's preference. I
think you have probably read more into my words than I was trying to
say.
Tim Bradshaw
> David Steuber "The
> (In 1905 Einstein published 5 papers, including Special Relativity and
> the photoelectric effect -- amazing work by any standard. Roughly
> speaking, SR is relativity in uniform reference frames, without the
> complexities introduced by gravitation causing local acceleration. In
> or around 1915 he got General Relativity to work, dealing with gravity
> in a self-consistent way. It's my -- admittedly vague --
> understanding that he worked primarily on GR for the entire decade
> 1905-1915, with little to show for it until rather late.)
This is pretty much right I think. A lot of the trouble was the fact
that the maths needed for GR was pretty unknown by physicists (and
possibly even by mathematicians) then. In particular they were
clobbered by awful notation which made it very hard to think about
things. Note that he won the Nobel prize for the photoelectric effect
paper, not the SR one!
--tim (not a physicist any more)
Tim Bradshaw
> All that work Einstein did, and his Nobel prize was for the
> photoelectric effect. I guess that was easier to verify in those
> days.
It was also an *extremely* important paper as it pointed the way very
clearly to quantum mechanics, which is a pretty important theory!
I should stop posting about physics in a Lisp group...
--tim
my-las...@ma.ultranet.com
particularly qualified to pontificate on any of this stuff.
My company wanted to write a fairly complex 3-tier application. We did a pilot
project, using ObjecStore, C++, and Java.
The middle tier logic was complex, and the dataflow issues from both
an application logic standpoint and from a client<->server/Java<->C++
standpoint was also complex.
After doing the pilot project, we handed the company a bill for what it would
take to complete the project using conventionat tools and, for that matter,
conventional people (I'll let you decide what that means).
The resulting bill cost more time and dollars than my small company would be
able to accomodate, so we canned the project.
In my heart, I felt that the problem wasn't so complex that it should be out of
our reach. But using "conventional people and tools" was never going to get it
done.
A little history: I've worked for two lisp vendors. For various reasons, I
didn't do much lisp while working for these vendors, usually working on
bootstrap internals and later, in Symbolics dying day, trying to so something
completely outside the lisp realm targeting C++ solutions.
The result is that ironically, after working for two lisp vendors, I'd never
been paid to professionally program in lisp.
After the project cancellation, I decided to spend a quarter hiding in my
basement to code the essence of the failed project in Lisp. I did this because
I knew that I was most productive in lisp, and that it would save me numerous
headaches in the architecture of the project. For instance, having Lisp's macro
capability meant I didn't need separate DDL compilers and code generators which
were necessary under the C++/Java architecture of the application. CLOS classes
are the modeling language, and macros can wrapper any abstractions I need to
hide from the domain modelers (in my case, a whole persistent version-management
substrate).
After my quarter of programming, I gave a demo of the result and some proposals
on how to fund it to completion for a variety of vertical solutions. My company
has finally bought into the proposals. It wouldn't have been possible without
lisp. The key reason lisp is a win is because of it's productivity enhancing
capabilities and it's appropriateness for the task at hand. Even using Java, I
wouldn't have had sufficient technology to demonstrate after one quarter of
work.
The major points which to me describe good, bad, and cautionary uses for lisp
are:
A) GUIs: no lisp for me.
I'd never use lisp for a GUI. I wouldn't try to write a browser in lisp.
BUT.... using it to *drive* a GUI is another matter. In my case, I use
lisp to dynamically generate HTML and also to drive Java applets running in
browsers. Lisp is good for this.
B) Servers: where it's at for lisp applications.
Lisp is, to me, ideally suited for the middle (logic server) tier of 3-tier
architectures.
You need powerful modeling tools to solve complex problems, and serve up the
results. I serve them up over sockets. (Yes, sockets. I went retro. Forget
CORBA and COM and all that crap. Remove those 5 layers from your architecture
and just use socket-based client-server interaction. Saves a ton of work).
Lisp CORBA support is also somewhat in its infancy, so beware if you go that
way.
Yes, lisp is good for all that classical academic stuff. But what I care about
is modeling a problem, using the tools which help me provide a solution. That
may involve inference engines, but it often just involves lots and lots of
... deeply intertwingled ... logic. And the lisp code savings and expressive
power is unmatched for solving these types of problems in a rapid, robust, and
maintainable fashion.
C) Database (persistence): Crucial piece, lisp stumbles, but it's surmountable.
Caution: the database support of lisp is minimal. I'm using Allegrostore from
Franz. The LISPs are great (I'll put lisp compilers up against java compilers
any day). The database support is not. This includes ODBC and Object database
support. This was my biggest potential technical failing point for my project.
Allegrostore (Franz' OODB support) is almost a toy, and I'll have to pay for
lots of extra work on it from Franz. Harlequin's OODB support is almost
nonexistent, though they have an ObjectStore interface for an obsolete verion of
the product on Solaris. There are other alternatives, like PLOB, but there are
problems there too. (I'm wide open to suggestions here, I don't have all the
answers, so for now I'm using Allegrostore). [Statice is not an option for me,
reasons below].
Ironically, I couldn't have done my demo-project (quickly enough) without the
OODB support, even though the OODB support from lisp is awful. I think the lisp
community has a real opportunity in this era for enabling lisp "application
server" solutions. But the vendors aren't really chasing this. And the window
of opportunity is rapidly closing, being driven by primarily by the Java
community (and of course, the evil Microsoft empire).
D) Threads: caution
Caution: the threaded aspects of lisp based solutions are non-portable,
and in the case of the tools I've been using, present another potential
technical failing point. Just about every time I use lisp threads, I crash or
hang my lisp, and I'm usually pretty good at threaded programming. But I've
been using beta tools, and hopefully my thread problems will go away with the
production kits. For now, I'm using a primarily process-parallel solution, but
that has major performance implications. Still, better a slow solution than no
solution at all, as was the case with C++ and Java.
E) Tools: unsupported, out of date, or entirely absent.
Unlike Java, there isn't a great deal of up-to-date and
works-out-of-the-box-in-your-lisp-dialect tool sets. Yes, the CMU repository is
nice. But I still find that I spend way too much time getting things work work
with my lisp dialects. Furthermore, I still have to write SMTP, POP3, IMAP, and
other protocols myself, there don't seem to be any of these things in the
archives.
I'm sure people who use Genera have more lattitude here, since more of the tools
are present with the environment. In my case, my solution MUST run on
mainstream Windows and Unix boxes. Genera is only on Alpha and proprietary
hardware.
Also, some of the tools are broken, like the source-compare tool and some regexp
tools. I've noticed that my fixes sent to authors don't make it back to the CMU
site, so I've given up. Beware, it's a real pain to find that things like
source comparison don't work the hard way. (Like when you assume your
regression tests passed because source-compare said they matched...)
And DEFSYSTEM. There's the CMU version, and the Franz version, and they don't
work well together. Sigh.
F) Politics: The solution is your edge.
Technical hurdles aside, there were plenty of people who pissed all over my
technology because I chose lisp. But they're getting with the program. Some of
the people who were very put off by lisp soon forget their objections once you
start talking about what the solution is that they'll have, and when and how
they'll be able to sell it. Focus on the solution, and you may be able to sell
the underlying technology. Proof by way of showing how much you can do in a
couple of months (with lisp) is a good way to get the ball rolling. Most of the
lisp vendors are happy to give you a trial license so you can do this at no
material cost (so it costs your company only your salary). If you win, they
win, since you'll then be buying lisp licenses. Franz is very good in this
regard, and I'd guess Harlequin is too, but I haven't tried them.
There was also concern about where to find lisp programmers.
But plenty of the premier schools still teach lisp, or it's cousin scheme.
Also, in our case, we have a proprietary scripting language in one of our
products, and it's certainly easier to find programmers for lisp than for our
proprietary languages. Finally, we don't need too many lisp programmers, or
programmers period, because the resource requirements for the project are much
reduced because of lisp.
G) Lisp as a shell environment and development (QA, document generation) aid.
Given a choice, I always prefer to implement my test harnesses and general
environmental tools in lisp than in the various shells like Perl, CSH, or (ugh)
dos batch files. I come out ahead on time when I use lisp, as well as getting a
portable environment for sustaining development operations besides actual code
development.
Hope that helps.
=========================
Hey, you lisp vendors, two requests!
Without this support, my head is on the chopping block because my project may
fail for having used lisp. If that happens, my next post of this length to the
group will be "why lisp isn't any good for commercial software development"
I'm sure we'd all like to avoid that :-)
1) Give me some decent persistence solutions! That includes performance for
large volumes of data, large numbers of objects, and good concurrent transaction
support (which requires less obvious things like data clustering controls).
2) Give me tools for enabling webcentric solutions, like the Java application
servers. CL-HTTP might be fine for some people, but the license restrictions
put it out of my reach. I'll happily pay for stuff which let's me roll web
solutions more quickly. I'm not happy about the prospect of writing my own HTTP
servers, session support, SSL implementation, etc.. Fortunately, minimal
support of most RFCs is a 2-coffee job in lisp, but it still delays my ship
date. There are an awful lot of RFCs and W3C protocols I need to support.
Dave Tenny
my-las...@ma.ultranet.com
Dave Tenny
my-las...@ma.ultranet.com - no spam please
Marco Antoniotti
> Here's one commercial software developer's viewpoint on lisp, not that I'm
> particularly qualified to pontificate on any of this stuff.
>
> The major points which to me describe good, bad, and cautionary uses for lisp
> are:
>
> And DEFSYSTEM. There's the CMU version, and the Franz version, and they don't
> work well together. Sigh.
I suppose you are referring to MK:DEFSYSTEM from CMU. It works on any
CL with minimal changes, including ACL. Its portability is one of the
major wins. Why do you need to use Franz's?
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - (0)6 - 68 10 03 16, fax. +39 - (0)6 - 68 80 79 26
http://www.parades.rm.cnr.it
David Steuber The Interloper
or asked:
% B) Servers: where it's at for lisp applications.
%
% Lisp is, to me, ideally suited for the middle (logic server) tier of 3-tier
% architectures.
% You need powerful modeling tools to solve complex problems, and serve up the
% results. I serve them up over sockets. (Yes, sockets. I went retro. Forget
% CORBA and COM and all that crap. Remove those 5 layers from your architecture
% and just use socket-based client-server interaction. Saves a ton of work).
% Lisp CORBA support is also somewhat in its infancy, so beware if you go that
% way.
% D) Threads: caution
%
% Caution: the threaded aspects of lisp based solutions are non-portable,
% and in the case of the tools I've been using, present another potential
% technical failing point. Just about every time I use lisp threads, I crash or
% hang my lisp, and I'm usually pretty good at threaded programming. But I've
% been using beta tools, and hopefully my thread problems will go away with the
% production kits. For now, I'm using a primarily process-parallel solution, but
% that has major performance implications. Still, better a slow solution than no
% solution at all, as was the case with C++ and Java.
The only realistic way I would have of getting a Lisp based proposal
to be accepted at my day job would be if Lisp supported CORBA and
Threads. Native CORBA support is necessary to use the back end
services. Threads is essential for serving up HTML. It would not be
remotely practical to run a separate process for each connection. The
only viable solution is a proper mult-threading library that can hide
implementation dependant details.
So for those who are actively working on CMUCL, I would ask that
thread support (POSIX or Java style) and CORBA support (including
being able to compile IDL into CLOS stubs) be considered for
inclusion.
Once I understand the Lisp philosophy, maybe I'll be able to add those
features myself. Or maybe I'll discover that it is too difficult. It
would be a terrible shame to find that Lisp just isn't into threads.
Pierre Mai
> The only realistic way I would have of getting a Lisp based proposal
> to be accepted at my day job would be if Lisp supported CORBA and
> Threads. Native CORBA support is necessary to use the back end
> services. Threads is essential for serving up HTML. It would not be
> remotely practical to run a separate process for each connection. The
> only viable solution is a proper mult-threading library that can hide
> implementation dependant details.
- CORBA: I don't know what kind of support Franz or Harlequin are
offering for CORBA currently, but Harlequin might be offering some
on the Windows plattform, at least their next Dylan Enterprise
offering will support CORBA, so maybe their Lispworks offering does
already or will in the future ;) And I also heard of CORBA support
from Franz being either in the works are already finished.
And then there is ILU[1], which has support for Franz ACL 4.*. It
also offers a compatibility layer for threading, and one could think
of porting the CL-support of ILU to CMU CL, but I can't currently
comment on the amount of work needed for this.
- HTTP: Threading-support is now in the experimental-releases of CMU
CL (from CVS 2.4.5 onward), and should probably also be in the 18b
release. In fact, CL-HTTP is being/has been ported to CMU CL, and
CL-HTTP uses threading.
ILU also supports HTTP in some form, though I can't comment on what
functionality is available: "ILU also includes a self-contained
implementation of the World Wide Web's Hypertext Transfer Protocol
(HTTP), and can thus be used to implement object-oriented web
browsers and servers."
> So for those who are actively working on CMUCL, I would ask that
> thread support (POSIX or Java style) and CORBA support (including
> being able to compile IDL into CLOS stubs) be considered for
> inclusion.
Thread support is already available. CORBA support is something that
should be persued in an implementation-independend fashion, IMHO, and
porting ILU should be the best short-term solution[2].
Regs, Pierre.
Footnotes:
[1] ftp://ftp.parc.xerox.com/pub/ilu/ilu.html
[2] Note that there are some quibles about the copyright of ILU,
which allows:
Unlimited use, reproduction, and distribution of this software is
permitted. Any copy of this software must include both the above
copyright notice of Xerox Corporation and this paragraph. Any
distribution of this software must comply with all applicable United
States export control laws. This software is made available AS IS, and
Xerox Corporation DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING WITHOUT LIMITATION THE IMPLIED WARRANTIES OF MERCHANTABILITY
AND FITNESS FOR A PARTICULAR PURPOSE, AND NOTWITHSTANDING ANY OTHER
PROVISION CONTAINED HEREIN, ANY LIABILITY FOR DAMAGES RESULTING FROM
THE SOFTWARE OR ITS USE IS EXPRESSLY DISCLAIMED, WHETHER ARISING IN
CONTRACT, TORT (INCLUDING NEGLIGENCE) OR STRICT LIABILITY, EVEN IF
Xerox Corporation IS ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
This omits production of derivate works, which is thereby not
allowed, although this was not the intention of ILUs authors (which
aren't the copyright-holders, though, which is Xerox.). Do a DejaNews
search in comp.lang.lisp to get the whole discussion of this. IANAL,
but this could have implications for porting ILU to CMU CL. OTOH
others have contributed patches to include support for other
language-bindings to ILU, so there is precedent, which doesn't
directly imply that this is legal behaviour, though...
--
Pierre Mai <pm...@acm.org> http://home.pages.de/~trillian/
"Such is life." -- Fiona in "Four Weddings and a Funeral" (UK/1994)
Rainer Joswig
<pm...@acm.org> wrote:
> - CORBA: I don't know what kind of support Franz or Harlequin are
> offering for CORBA currently, but Harlequin might be offering some
> on the Windows plattform, at least their next Dylan Enterprise
> offering will support CORBA, so maybe their Lispworks offering does
> already or will in the future ;) And I also heard of CORBA support
> from Franz being either in the works are already finished.
LispWorks Enterpise Edition will. ACL does already.
I haven't used it yet.
> - HTTP: Threading-support is now in the experimental-releases of CMU
> CL (from CVS 2.4.5 onward), and should probably also be in the 18b
> release. In fact, CL-HTTP is being/has been ported to CMU CL, and
> CL-HTTP uses threading.
CL-HTTP can be used primitively also without threading.
AFAIK only the x86 port of CMU CL does threads?
Peter Van Eynde
>[2] Note that there are some quibles about the copyright of ILU,
>which allows:
AFAIK there is a new release of ILU with a more open copyright-notice.
(see http://slashdot.org/articles/98/10/18/1444231.shtml)
--
Groetjes, Peter
--
It's logic Jim, but not as we know it. pvan...@debian.org, pvan...@inthan.be
Look in keyservers for PGP key.
jon....@totient.demon.co.uk
Pierre Mai <pm...@acm.org> wrote:
> [2] Note that there are some quibles about the copyright of ILU,
> which allows:
>
> Unlimited use, reproduction, and distribution of this software is
> permitted. Any copy of this software must include both the above
> copyright notice of Xerox Corporation and this paragraph. Any
> distribution of this software must comply with all applicable United
> States export control laws. This software is made available AS IS, and
> Xerox Corporation DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
> INCLUDING WITHOUT LIMITATION THE IMPLIED WARRANTIES OF MERCHANTABILITY
> AND FITNESS FOR A PARTICULAR PURPOSE, AND NOTWITHSTANDING ANY OTHER
> PROVISION CONTAINED HEREIN, ANY LIABILITY FOR DAMAGES RESULTING FROM
> THE SOFTWARE OR ITS USE IS EXPRESSLY DISCLAIMED, WHETHER ARISING IN
> CONTRACT, TORT (INCLUDING NEGLIGENCE) OR STRICT LIABILITY, EVEN IF
> Xerox Corporation IS ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
>
> This omits production of derivate works, which is thereby not
> allowed, although this was not the intention of ILUs authors (which
> aren't the copyright-holders, though, which is Xerox.). Do a DejaNews
> search in comp.lang.lisp to get the whole discussion of this. IANAL,
> but this could have implications for porting ILU to CMU CL. OTOH
> others have contributed patches to include support for other
> language-bindings to ILU, so there is precedent, which doesn't
> directly imply that this is legal behaviour, though...
>
> --
> Pierre Mai <pm...@acm.org> http://home.pages.de/~trillian/
> "Such is life." -- Fiona in "Four Weddings and a Funeral" (UK/1994)
>
The license is being changed for the next release of ILU, such that it will
provide for derivative works. For further info check the ILU mailing list.
I have incidently managed to get Java talking to a objects in a lisp server,
using ILU. This was using acl4.3 on linux and acl5.0 on linux.
Jon
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Rainer Joswig
my-las...@ma.ultranet.com wrote:
> A) GUIs: no lisp for me.
>
> I'd never use lisp for a GUI. I wouldn't try to write a browser in lisp.
Why that? I have seen a lot great GUI applications in Lisp. Apple Dylan
had *the* cool IDE. Some are even writing very demanding UI software
that competes with the usual C/C++ packages. But the "screen shot
of the week" surely is
http://nd1.neodesic.com/aercam-pics/screenshot-1.jpg . ;-)
> C) Database (persistence): Crucial piece, lisp stumbles, but it's
surmountable.
Itasca? Traditional ODBC to Oracle, etc.?
This surely could be improved.
> D) Threads: caution
>
> Caution: the threaded aspects of lisp based solutions are non-portable,
> and in the case of the tools I've been using, present another potential
> technical failing point. Just about every time I use lisp threads, I crash or
> hang my lisp,
This is unusual. Threads are usually working.
> E) Tools: unsupported, out of date, or entirely absent.
>
> Unlike Java, there isn't a great deal of up-to-date and
> works-out-of-the-box-in-your-lisp-dialect tool sets. Yes, the CMU
repository is
> nice. But I still find that I spend way too much time getting things
work work
> with my lisp dialects. Furthermore, I still have to write SMTP, POP3,
IMAP, and
> other protocols myself, there don't seem to be any of these things in the
> archives.
CL-HTTP can send mails via SMTP. Somewhere there should be POP3. IMAP is
not available, AFAIK. Usually under Unix I'd just use what is there.
> Also, some of the tools are broken, like the source-compare tool and
some regexp
> tools. I've noticed that my fixes sent to authors don't make it back to
the CMU
> site,
The CMU site is mostly dead. The Lisp FAQ, too. There hasn't somebody
promising to fix that, yet.
> And DEFSYSTEM. There's the CMU version, and the Franz version, and they don't
> work well together. Sigh.
A thing that should be fixed by a standard. Better sooner than later.
> lisp vendors are happy to give you a trial license so you can do this at no
> material cost (so it costs your company only your salary). If you win, they
> win, since you'll then be buying lisp licenses. Franz is very good in this
> regard, and I'd guess Harlequin is too, but I haven't tried them.
Personally I think commercial Lisp environments for Unix
are too expensive. Delivery with them is expensive. too.
> 2) Give me tools for enabling webcentric solutions, like the Java application
> servers. CL-HTTP might be fine for some people, but the license restrictions
> put it out of my reach.
Which license restriction in particular? Naming CL-HTTP in the product?
Reporting bugs? Giving back fixes? Separating your code
from CL-HTTP? Something else?
> date. There are an awful lot of RFCs and W3C protocols I need to support.
Some of these are quite big and complicated. :-(
Mike McDonald
jos...@lavielle.com (Rainer Joswig) writes:
> In article <362f3c1d...@news.ma.ultranet.com>,
> my-las...@ma.ultranet.com wrote:
>
>>
>> I'd never use lisp for a GUI. I wouldn't try to write a browser in lisp.
>
> had *the* cool IDE. Some are even writing very demanding UI software
> that competes with the usual C/C++ packages. But the "screen shot
> of the week" surely is
> http://nd1.neodesic.com/aercam-pics/screenshot-1.jpg . ;-)
If you have enough money, the commercial implementations do offer a GUI
solution. But if you're limited to PD, you're pretty much limited to orphaned,
incomplete, or non portable solutions. In my case, and I suspect others, I
have to demo the project before I can get my management to buy in.
Unfortunately, I need them to buy in before I can do the demo. :-(
>> D) Threads: caution
>>
>> Caution: the threaded aspects of lisp based solutions are non-portable,
>> and in the case of the tools I've been using, present another potential
>> technical failing point. Just about every time I use lisp threads, I crash or
>> hang my lisp,
>
> This is unusual. Threads are usually working.
Threads are implemented in the CL's I use on most of my Unix boxes.
>> E) Tools: unsupported, out of date, or entirely absent.
> CL-HTTP can send mails via SMTP. Somewhere there should be POP3. IMAP is
> not available, AFAIK. Usually under Unix I'd just use what is there.
Where do you get CL-HTTP these days? The site I went to
(http://www.ai.mit.edu/projects/iiip/doc/) only has two year old code.
> The CMU site is mostly dead. The Lisp FAQ, too. There hasn't somebody
> promising to fix that, yet.
>
>> And DEFSYSTEM. There's the CMU version, and the Franz version, and they don't
>> work well together. Sigh.
>
> A thing that should be fixed by a standard. Better sooner than later.
AMEN!!!
>> lisp vendors are happy to give you a trial license so you can do this at no
>> material cost (so it costs your company only your salary). If you win, they
>> win, since you'll then be buying lisp licenses. Franz is very good in this
>> regard, and I'd guess Harlequin is too, but I haven't tried them.
>
> Personally I think commercial Lisp environments for Unix
> are too expensive. Delivery with them is expensive. too.
I wholeheartedly agree wih this. When I'm trying to convince my boss that CL
would make solving his problems easy, I first run into the misconceptions
about the language. (He didn't know lisp had arrays!) Then I run into the
$4000 price tag to get a commercial CL with CLIM just to start. That's a big
barrier to entry. When the boss is already dubious about the whole idea,
laying out that kind of expense just to try usually is the final straw. If you
get past that, mentioning the royalties for the runtime kills it everytime. I
do understand the economics from the vendors point of view. It cost them so
much to produce an implementation, divided by the small number of customers
gives a fairly high price. Unfortunately, this results in a chicken and egg
problem.
>> date. There are an awful lot of RFCs and W3C protocols I need to support.
>
> Some of these are quite big and complicated. :-(
But a lot are small and simple too.
Mike McDonald
mik...@mikemac.com
David Steuber The Interloper
claimed or asked:
% I wholeheartedly agree wih this. When I'm trying to convince my boss that CL
% would make solving his problems easy, I first run into the misconceptions
% about the language. (He didn't know lisp had arrays!) Then I run into the
% $4000 price tag to get a commercial CL with CLIM just to start. That's a big
% barrier to entry. When the boss is already dubious about the whole idea,
% laying out that kind of expense just to try usually is the final straw. If you
% get past that, mentioning the royalties for the runtime kills it everytime. I
% do understand the economics from the vendors point of view. It cost them so
% much to produce an implementation, divided by the small number of customers
% gives a fairly high price. Unfortunately, this results in a chicken and egg
% problem.
Suppose the product is delivering an HTML based application? How does
licensing work then? You haven't deployed anything per-se, but there
are a lot of users.
One problem with licensing Sybase was counting the number of users.
The HTML generation code accesses Sybase. That is just one tier. Oh,
but you have 50,000 page views per day?
Don't panic, Linux is just taking over the world By Robert McMillan
(www.linuxworld.com).
Free software is very appealing from a cost point of view :-)
Who provides the support?
Forget support. Hire a consultant if you need help.
--
David Steuber (ver 1.31.2a)
http://www.david-steuber.com
To reply by e-mail, replace trashcan with david.
"Ignore reality there's nothing you can do about it..."
-- Natalie Imbruglia "Don't you think?"
David Steuber The Interloper
asked:
(elide 'good-info)
% Thread support is already available. CORBA support is something that
% should be persued in an implementation-independend fashion, IMHO, and
% porting ILU should be the best short-term solution[2].
I'm glad to hear this. As you can probably tell, I am still seeing
lots of trees instead of a forrest, if that is the appropriate
metaphor.
Implementation-independant CORBA support would be rather difficult I
would think. Currently, Visigenic and Orbix (for example) can't talk
to each other, even though they both use IIOP. (I'm not knowledgable
on the details of CORBA yet). The Lisp part can almost certainly be
made implementation independent, but I think it may have to ride on a
shared object that can link with the appropriate vendor's shared
object.
So much for standards.
I've also been invited to look at ACL. They provide an ORB. I would
need to use the Orbix daemon, I think. I can't remember which one of
the above mentioned two we ended up going with. Small cog in big
watch, you know?
my-las...@ma.ultranet.com
>In article <362f3c1d...@news.ma.ultranet.com>,
>my-las...@ma.ultranet.com wrote:
>
>> A) GUIs: no lisp for me.
>>
>> I'd never use lisp for a GUI. I wouldn't try to write a browser in lisp.
>
>Why that? I have seen a lot great GUI applications in Lisp. Apple Dylan
>had *the* cool IDE. Some are even writing very demanding UI software
>that competes with the usual C/C++ packages. But the "screen shot
>of the week" surely is
>http://nd1.neodesic.com/aercam-pics/screenshot-1.jpg . ;-)
>
I don't doubt there are good GUI capabilities in some lisps on some platforms.
It's just an uphill battle to do cross-platform GUI support in lisp, and take
advantage of and/or provide native look and feel for the platform.
But if I knew anything about GUIs, I supposed I'd do it for a living. My
particular project relies heavily on browsers for most user interface, graphical
or not. And lisp does well here driving the browser interface.
>> C) Database (persistence): Crucial piece, lisp stumbles, but it's
>surmountable.
>
>Itasca? Traditional ODBC to Oracle, etc.?
There's ODBC support in the Franz product. My particular solution requires an
OODB. A performant OODB. I need to cram lots of stuff into it, both number of
objects and volume of data. I'm sure it could all ultimately be modeled on an
RDB, but the performance would stink for my particular application.
Someone else sent me mail on Itasca. I'll check it out.
>> D) Threads: caution
>>
>> Caution: the threaded aspects of lisp based solutions are non-portable,
>> and in the case of the tools I've been using, present another potential
>> technical failing point. Just about every time I use lisp threads, I crash or
>> hang my lisp,
>
>This is unusual. Threads are usually working.
I'm counting on it. My architecture relies on process-level parallelism for
3-tier aspects of concurrency (and because of current but to-be-removed
limitations in the ObjectStore product with respect to concurrent threaded
transactions in the same process).
But I know I'll need lisp threads to get even satisfactory departmental level
performance from my application. It's only my preliminary forays into threads
on beta and pre-beta lisp products which have met with disaster, and so I've
avoided them
for now since I have other fish to fry.
Apropos my original post: I don't think I'd use lisp for a high volume
transaction environment. I can use it for my project because I have a very
"departmentally oriented" and distributed application, and so my biggest risk is
the OODB performance. But (at least in Franz' Product), all threads block on
the lisp heap (except for appropriately declared FFI calls), and so I could
never make adequate use of SMP hardware for high-volume throughput with it.
I'm sure the lisp faithful could argue that some lisps might adequately use SMP
platforms for high volume throughput. I can only base my opinion on my limited
experience with lisp, and where I see the whole lisp solution going in terms of
performance (considering threads and OODB performance, mostly).
>> E) Tools: unsupported, out of date, or entirely absent.
>>
>> Unlike Java, there isn't a great deal of up-to-date and
>> works-out-of-the-box-in-your-lisp-dialect tool sets. Yes, the CMU
>repository is
>> nice. But I still find that I spend way too much time getting things
>work work
>> with my lisp dialects. Furthermore, I still have to write SMTP, POP3,
>IMAP, and
>> other protocols myself, there don't seem to be any of these things in the
>> archives.
>
>CL-HTTP can send mails via SMTP. Somewhere there should be POP3. IMAP is
>not available, AFAIK. Usually under Unix I'd just use what is there.
I already have SMTP and POP client code. Lisp makes those easy jobs.
I'd rather have "in-process" code than spawn calls to "sendmail" or other things
on a variety of platforms (NT and several flavors of Unix are requirements for
me). It's slower to invoke the shell processes to do that,
and the interfaces (depending on the protocol, platform, and tools avaialble)
are going to vary more widely if I call out. Easier to have code "to spec" with
one API written in lisp.
[...]
>> lisp vendors are happy to give you a trial license so you can do this at no
>> material cost (so it costs your company only your salary). If you win, they
>> win, since you'll then be buying lisp licenses. Franz is very good in this
>> regard, and I'd guess Harlequin is too, but I haven't tried them.
>
>Personally I think commercial Lisp environments for Unix
>are too expensive. Delivery with them is expensive. too.
Supply and demand, aggravated by the fact that the market has pretty much done
in the lisp vendors. (One of my biggest fears is that my chosen vendor will go
out of business, since there are so few alternatives, and so many
incompatabilities between real-world use of lisps (platform availability,
database interfaces, sockets, threads, etc.)).
If the lisp vendors need to charge a premium to stay in business, or simply do
it because they can, because we've killed the competition, how is that any
different from what life will be like when Microsoft owns the world?
I agree that royalty-based runtimes for systems which don't rely on the lisp
compiler and development environment is not very desirable, and so the
introduction of runtime royalties for ALL deployed systems with ACL5 (which was
not a requirement in ACLPC 3.0.2) really rubs me the wrong way.
I'd feel better if I could compile and ship my applications in lisp just like in
any other language.
The price issue is one of those unpleasant issues I had to face for my project.
Short term, no lisp, no project, so we pay them. Long term, if we feel like
we're being price gouged on royalties, we can always recode the server in
another language if the solution is really worth it. The other point of view is
this: if you want to distributed a free (academic) application, you don't have
to pay royalties anyway (with Franz). If you want to distribute a commercial
applicaiton, you work with the lisp vendor to reach price points (on your
product and their royalties) which make it a good business prospect for both
parties.
On the bright side, given that I'll be paying royalties, perhaps I'll use the
dynamic environment capabilities of lisp to allow my server solutions to be
patched on the fly, etc. If the lisp vendors are too greedy in the royalty
negotiations, well, so long lisp. It's always a case of ROI.
For the basic development tools license from a commercial software development
standpoint I don't have a problem. It isn't like Visual DevStudio and various
conventional tool vendor's "enterprise" products are exactly cheap.
Lisp is a productivity environment. So's PowerBuilder. I'm sure the Microsoft
camp would argue that DevStudio is too. I'll take lisp any day. If it costs
twice as much, that isn't so bad, since I need half the programmers, and half
the time to deploy a solution (and that's being conservative!).
One thing I like from a commercial development standpoint is that while I pay
top dollar for my license, Franz is very good about fixing bugs quickly.
Compare that to life with Java, Swing components, etc..
There are more pros and cons to the whole thing, but I think I'll stop while
it's still morning here...
>
>> 2) Give me tools for enabling webcentric solutions, like the Java application
>> servers. CL-HTTP might be fine for some people, but the license restrictions
>> put it out of my reach.
>
>Which license restriction in particular? Naming CL-HTTP in the product?
>Reporting bugs? Giving back fixes? Separating your code
>from CL-HTTP? Something else?
>
Several things:
1) Displaying the CL-HTTP logo is not acceptable in my UI. While I've sold a
project based on lisp, our company does not want customers to be clued into the
fact that they're talking to a lisp server. (Long story, but not unusual in my
experience).
2) The following paragraphs from the license make me nervous:
"Additionally, all rights are reserved to any derivative works based on the
Lisp source code in the CL-HTTP distribution, in particular but not limited to
any automatic or manual translation of the source code into other computer
languages or executables."
"Any rights not explicitly waived are retained."
"In the meantime, the right to change this license for CL-HTTP in anyway at
anytime is hereby reserved, any prior clauses notwithstanding."
"If any of elements of this agreement are found to be unenforceable, the others
will remain in effect."
I might still use CL-HTTP, but for now I'm not, and it's the above clauses of
the license which deter me from doing so. I suppose strict source code
separation of CL-HTTP from my product avoids some liability, but the fact is
that CL-HTTP has many tools I'd like to use and incorporate. For now, no
CL-HTTP source is permitted in my source tree. It's my product, I want to keep
it that way.
I admit to being overly paranoid here. I really should get a lawyer to advise
me on this if I decide I can save lots of time by usingCL-HTTP. I'm always
cautious about commercial use of academic product, however.
John Mallery said he was in the process of spinning off a commercial form of
CL-HTTP, but I haven't heard any more on this recently.
(A note to the David Steuber: CL-HTTP is FREE, it wasn't the cost of a license
that deterred me, it was the terms of the license).
>> date. There are an awful lot of RFCs and W3C protocols I need to support.
>
>Some of these are quite big and complicated. :-(
That's where Java is nice, the huge momentum of the java movement makes more and
more standard capabilities available in nice componentized fashion.
I've considered, but haven't explored in depth the possibility of invoking the
JVM from lisp to take advantage of some components on the server side.
Not a serious consideration at this time.
Rainer Joswig
my-las...@ma.ultranet.com wrote:
> I'm sure the lisp faithful could argue that some lisps might adequately
use SMP
> platforms for high volume throughput. I can only base my opinion on my
limited
> experience with lisp, and where I see the whole lisp solution going in
terms of
> performance (considering threads and OODB performance, mostly).
I don't know of any currently supported Common Lisp that has
SMP capable threads.
> One thing I like from a commercial development standpoint is that while I pay
> top dollar for my license, Franz is very good about fixing bugs quickly.
> Compare that to life with Java, Swing components, etc..
Same is true in my experience with Harlequin and Digitool.
Rainer Joswig
> >Which license restriction in particular? Naming CL-HTTP in the product?
> >Reporting bugs? Giving back fixes? Separating your code
> >from CL-HTTP? Something else?
> >
>
> Several things:
>
> 1) Displaying the CL-HTTP logo is not acceptable in my UI. While I've sold a
> project based on lisp, our company does not want customers to be clued
into the
> fact that they're talking to a lisp server. (Long story, but not
unusual in my
> experience).
Most software has an about page. Mentioning CL-HTTP there would be enough.
You don't need to put CL-HTTP in 96 point bold letters upfront.
Btw., you can get info about web servers just by looking at the headers:
? (http:show-url-headers "http://www.hotmail.com/")
Date: Sun, 25 Oct 1998 14:23:28 GMT
Server: Apache/1.2.1
Last-modified: Tue, 20 Oct 1998 18:19:27 GMT
ETag: "97f8-170e-362cc61f"
Content-length: 5902
Accept-Ranges: bytes
Connection: CLOSE
Content-type: text/html
Here we learn the Hotmail, a Microsoft company, is still using Apache
after hey have been bought months ago.
> 2) The following paragraphs from the license make me nervous:
>
> "Additionally, all rights are reserved to any derivative works based on the
> Lisp source code in the CL-HTTP distribution, in particular but not limited to
> any automatic or manual translation of the source code into other computer
> languages or executables."
The idea is that somebody might translate CL-HTTP source automagically
into another programming language (like Dylan) and it still is CL-HTTP.
> "Any rights not explicitly waived are retained."
>
> "In the meantime, the right to change this license for CL-HTTP in anyway at
> anytime is hereby reserved, any prior clauses notwithstanding."
"Subsequent versions of CL-HTTP may have different copyright statements and
license requirements once it becomes clear precisely what arrangements best
serve the Lisp community."
> "If any of elements of this agreement are found to be unenforceable, the
others
> will remain in effect."
Nothing unusual.
The spirit of this license is to let as much people as possible use this
software (which was written in academic environment, where research
is more important than supporting external users of published code),
have a steady stream of contributions/bug fixes where all are getting
a benefit and ensure a unified library.
In case there would be a commercial company providing support and
development for CL-HTTP (polished packaging, polished code, security,
more standards supported, more documentation, ...) there
is the intend to always have a unified source code version of CL-HTTP
available (as today).
> I might still use CL-HTTP, but for now I'm not, and it's the above clauses of
> the license which deter me from doing so. I suppose strict source code
> separation of CL-HTTP from my product avoids some liability, but the fact is
> that CL-HTTP has many tools I'd like to use and incorporate. For now, no
> CL-HTTP source is permitted in my source tree. It's my product, I want
to keep
> it that way.
I usually use DEFSYSTEMS for larger projects. CL-HTTP is indeed in a
separate system. This also helps me recovering from using new CL-HTTP
versions. I'd always thought this is a good software development
principle. You want to make very clear what is your software and
what is CL-HTTP to make upgrades less pain. Otherwise since
CL-HTTP is written using CLOS extensively, you get the
the usual mechanisms to change/extend/modify the way CL-HTTP works.
I think it is enough to have a separate directory for CL-HTTP.
> I admit to being overly paranoid here. I really should get a lawyer to advise
> me on this if I decide I can save lots of time by usingCL-HTTP. I'm always
> cautious about commercial use of academic product, however.
I guess it is always wise to have a lawyer when using external libraries
and developing a commercial product.
Rainer Joswig
Paolo Amoroso
> about the language. (He didn't know lisp had arrays!) Then I run into the
> $4000 price tag to get a commercial CL with CLIM just to start. That's a big
> barrier to entry. When the boss is already dubious about the whole idea,
> laying out that kind of expense just to try usually is the final straw. If you
> get past that, mentioning the royalties for the runtime kills it everytime. I
Besides NASA, who else can afford a commercial Lisp system :) Sorry if I
look so surprised, but I am accustomed to the average prices of Windows
development tools from Microsoft, Imprise, etc. And yes, I know that this
is not a fair comparison. I am aware of the different market penetration
and the costs and difficulties of producing good Lisp environments. But
such prices look expensive anyway. I guess I need a larger moeny-box :)
A quick look at the Web sites of major Lisp vendors seems to suggest that
they mainly target their products to medium or large companies. Are they
also interested in selling Lisp systems to independent consultants or
programmers?
Paolo
--
Paolo Amoroso <amo...@mclink.it>
Charles Hixson
>
>
...
>
> One problem with licensing Sybase was counting the number of users.
> The HTML generation code accesses Sybase. That is just one tier. Oh,
> but you have 50,000 page views per day?
>
> Don't panic, Linux is just taking over the world By Robert McMillan
> (www.linuxworld.com).
>
> Free software is very appealing from a cost point of view :-)
>
> Who provides the support?
>
> Forget support. Hire a consultant if you need help.
>
> David Steuber (ver 1.31.2a)
> http://www.david-steuber.com
> To reply by e-mail, replace trashcan with david.
>
> "Ignore reality there's nothing you can do about it..."
> -- Natalie Imbruglia "Don't you think?"
1) you get to choose who is going to support you, and how much support
you need
2) you often end up paying for the support at a higher per hour rate.
Rainer Joswig
Amoroso) wrote:
> On 23 Oct 1998 18:02:59 GMT, mik...@engr.sgi.com (Mike McDonald) wrote:
>
> > about the language. (He didn't know lisp had arrays!) Then I run into the
> > $4000 price tag to get a commercial CL with CLIM just to start. That's a big
> > barrier to entry. When the boss is already dubious about the whole idea,
> > laying out that kind of expense just to try usually is the final
straw. If you
> > get past that, mentioning the royalties for the runtime kills it
everytime. I
>
> Besides NASA, who else can afford a commercial Lisp system :) Sorry if I
> look so surprised, but I am accustomed to the average prices of Windows
> development tools from Microsoft, Imprise, etc.
Lispworks for Windows and Macintosh Common Lisp are fortunately
affordable.
Pierre Mai
> A quick look at the Web sites of major Lisp vendors seems to suggest that
> they mainly target their products to medium or large companies. Are they
> also interested in selling Lisp systems to independent consultants or
> programmers?
Both Harlequin and Elwood offer Lisp systems for ~ $500, Digitool is
in this range, too, IIRC. The last time I looked, most _serious_
development tools for Windows were in a similar pricing range.
Being an independent developer/consultant, I don't consider $500 as a
serious impediment. Indeed you are hard-pressed to get a decent
computer for this amount of money (which is pretty essential for an
independant), so this _can't_ be a problem.
BTW: I'm currently using CMU CL, which is public-domain, in a
commercial setting (on top of Linux), so you can get by with even less
initial investment. Of course with CMU CL you don't get commercial
support from a vendor. But there is a very active and responsive
group of people developing CMU CL, and they have been very helpful in
solving any problems I've encountered, and have tolerated my
occasional stupidity: Thanks folks... ;)
Regs, Pierre.