Others have pointed out that even high prices form tools are far
outwaged by payment for programmers. So for learning I guess a free
triela version is quite ok and if you think that suits your needs you
can look further.

  you aren't this stupid, are you?  nobody wants to hire more people than
  necessary, but they have to if they hire C++ programmers, because one guy
  can't cut it.  one guy often can get it done in Common Lisp.  this is
  supposed to be an advantage.  I didn't say anything at all about what the
  programmer wants, but I see that you don't need to base your conclusions
  about what other people say on anything they have actually _said_, so you
  won't understand that I have contradicted you _before_ you concluded what
  you did, and you won't understand that I do now.  end of discussion.

| Interesing enought the crap buils stuff which is used for many and the
| all-so supierour Lispers ...

  only people with serious inferiorioty complexes think others are "all so
  superior" just because they are better than them at something and aren't
  afraid to say so (but neither do they do so without cause).  good people
  enjoy the competence of others.  you obviously don't.

| Grining
| Friedrich

  it's "grinning", you moron, and it fits you very well to misspell it, too.

Erik Naggum schrieb:

So either you calm down and really answer questions or flag your
comments as anecdotal but not as a fact which they aren't.

So I would suggest you read some mails from me than you might get such
things right.

Bagheera, the jungle scout <baghe...@my-deja.com> writes:

Isn't KMP coming up with one? :)

Cheers

All in all this are not "language inherent" problems.  I suppose you
could expect an improvement for CL if many more programmers were
working at it.  I.e. it is a matter of "scale" and invesment.  I would
venture out to say that it is reasonable to think that CL compilers
have fallen behind C/C++ compiler technology in recent years,
w.r.t. the situation of, let's say, 10 years ago.  Of course I have no
real data to support my case.  It is just a hunch.

Cheers

  none such exists.  your willingness to go from "some" to "all" is your
  very own logical flaw.  I suggest you take responsibility for it.

| and my impression is that that is your opinion toward anyone who uses C++.

  your impression is precisely that -- your impression.  it is not my
  responsibility to correct people who aren't even able to _read_ stuff
  they don't agree with.

| But I won't start flaming just because others have other opinions and
| that's what I wrote you just drop in your opinion and it seems to me that
| you have problems with anyone who's not using CL.

  it seems that way to you because you don't think, but rather want to fit
  things into predetermined prejudices.  again, your very own problem.

| Grinning even move brightly

  and you speak about _other_ people's attitude problems?  geez.  but, hey,
  I understand why you think in terms of attitude.  you're the pro, here.

  now, find a mirror and enjoy your grinning, but spare us more of it.

After this side-step towards flaming could we forget the last mails and
you just give me an answer on the question which was asked. I said you
don't have numbers and that you put in you opinion. You opinion might be
right or wrong, I believe you are possibly more on the right side. And
yes I do think that Common Lisp is a better choice as C++ ever will and
can be, just for the record: we don't have comparisons and because we
doN't have we just are guessing. That's quite ok but I personally think
that it would be a good idea having some comparisons.

1) Ease of learning (on different levels)
2) Development Effort
3) Maintenance costs
4) Tool support

...

a lot more. You can fill in you favourites.

Now my wild guesses: I think that Common Lisp is a better choice in
point 2 and three I'm not sure about 1. I do think that 4) is found for
C++ other points can be addes and that really would be helpful to see
for different languages. But I see this does not fit the subject of this
thread.

I tried to learn C++ and CL at the same time. Compared to the various
books I read then as beginner I'd say 80% are very good in the lisp
domain and 20% are very good in C++. (very optimistic)
I actually only found Coplien interesting. Reading Stroustrup was a
mess, compared to Kernigan/Ritchie then.

Guess it would be helpful. And I guess this might be something for the
FAQ

But guys, you don't just need to buy them - you need to read them
and work your way through them with one hand to the keyboard
of your favorite Lisp system - and, yes, you don't have
to type the source code - but if you want - go ahead.
Get the Lisp experience of an interactive software
design environment - try out your ideas - don't let
the system constrain you.

If your books are looking worn out, the pages are starting
to fade away, you have traces of chinese food on the pages,
your disk is full of edited versions of the code
and you have rewritten your graphical interfaces
to "blocks world" and "Othello" ten times - than you are on the
right track.

AT&T/Lucent is/was doing ATM switch projects. They
have systems with software written in C and C++. Usually
these products have a staff of, say, 1000 people.
At any one time only a part of the source code
is understood (people moving in and out).
As a a research project they were developing
a system in Lisp and a production version in
C++. The Lisp project had all in all around, say,
(can't remember the exact numbers) hundred people.

The claim was that after years of development the Lisp-based
project was more functional (on-the-fly updating of software
with zero-downtime was a goal), had comparable performance
and needed much less resources (time, developers, money, ...).
Still it was hard to convince management to make products
based on it (which finally happened). I hear
numbers like *seven* times productivity increase in such
large projects. If you get these results - would you
tell your competition?

Humor me for a second with my rough distinction between programming
and coding.  I see programming as the act of abstracting, designing,
pondering, trying things, and "writing" things.  I see coding as the
work of putting this into machine understandable form, syntax checks,
remembering variable and function names, typing the stuff in, editing
source code.  The split is an inuitive one, not a strong, factual
one.  I hate coding, it's mind-numbing and is the number one force of
friction for me when developing.  Lisp systems, with real interfaces
like emacs and ILISP (and the others that vendors provide) make coding
a much easier task, and greatly reduce the amount of friction I need
to overcome in order to encode an idea into a system.

I see several things contributing to the Lisp systems ability to
reduce coding friction.  Interactive development is the biggest one,
and it really pays off if you take a functional approach to your
design.  At any point you can test a fragment code, no recompile, no
big testing harness needed, no test proggies.  This alone prolly gives
me a two-fold performance increase, and that's a modest estimate.

The simple syntax and editor support for it is another one.  Fewer
syntax errors and less complex editing (once you learn sexpr-based
movement and editing in emacs) result in more productivity for me.

Symbol completion, integrated documentation and help mean that I don't
have to switch to another application to read the help, and don't have
to navigate some hypertext document with the accursed mouse.  Looking
up a functions documentation or arglist is trivial and almost a
reflex.  Less errors from guessing and less time wasted hunting for
docs.  The result is even more increased productivity.

There are a dozen other advatnages to Lisp itself, but I wanted to
just focus on the advatanges of the developm3ent environments that
come with it.  We can talk about the power of macros, the fullness of
the language and other things later, a newcomer is not going to be
able to experience those too deeply at first.

But in reality learning Lisp can (and should) be very easy
to learn (powerful interactive environments, good documentation, elegant
concepts, designed by people who really understood their
field, ...). Everybody who then wants to move on from
simple Lisp introductions should read a book like
PAIP from Peter Norvig.

To give an example from CL-HTTP's
web walker: What the author did was to create
a language to declare ACTIONS, ACTIVITIES and
CONSTRAINTS in the domain of walking over
graphs of web pages.

Here is an example for an action that
generates a sorted list of inferior pages
from an URL:

 W4:DEFINE-ACTION-TYPE name
                       (type &key (class 'action-type) documentation)
                       lambda-list
                       &body body
 [macro]

 Defines a new type of action named NAME whose type
 is TYPE. TYPE can be any of: STANDARD,
 OPEN-HTTP-STREAM, ENCAPSULATING, GENERATOR
 LAMBDA-LIST is the set of arguments passed to the
 action function. The lexical variables ACTION
 ACTIVITY URL are available within BODY. When CLASS
 is a subtype of encapsulating-action-type, the
 continuation that executes the encapsulated actions
 is invoked within the action function with
 (call-next-action &optional action url activity).
 Additionally, the first argument after the standard
 action arguments must be the inferior actions
 during the allocation process.

(define-action-type
  generate-sorted-inferiors
  (:generator
   :documentation "Primary action for walking the inferiors of a URL."
   :class generator-type)
  (action activity url predicate)
  (declare (ignore action))
  (values (stable-sort (url-inferiors-satisfying-activity url activity)
                       predicate)
     t))

Having just come off a 6 month project in a non-lisp language, the
things that is most immediate in my mind is the grunt work required to
code in this other language because I could not do the neccesarry
programming to reduce the code required in a significant manner.
Because there was not a real macro system (and for other reasons
inherent in the language we were using) I had to do things like
maintain 3 seperate files describing the same componnent.  Had this
been done in Lisp, a domain language for describing these components
would have made me only have to describe them once, in one location,
and that would have saved me many many hours synchronizing and
tracking down inconsistencies between the different views of the
component.  This was in a language and environment which is quite
possibly the best that "conventional" environments have to offer for
that task, WebObjects.

The last few days of work with CL-HTTP have been refreshing indeed.

Of course.  For these comparisons to make sense, I always assume we're
talking about various implementations of various languages.

    David> remember of CL beating Fortran was CMUCL.  I really, really
    David> doubt Macintosh Common Lisp will; it doesn't handle floats
    David> quite as well.

I thought it was Maclisp (not MCL) that beat Fortran on a PDP-11(?)

Sounds about right to me.  I also guess that CL compilers haven't
stressed numerical efficiency as other languages, so these
deficiencies show up in these types of tests.