I have actual reasons for not being able to use Lisp and you're saying
those reasons are not important because the average programmer (who's
ignorance of what compilers can do is apparently greater than mine)
gives different reasons.  

So I'd think a better question than why people who don't know anything
about modern Lisp systems don't use them would be, what do Lisp
systems need in order to be useful to everyone who does know about
them.

There is nothing wrong with a Lisp being unsuited for many companies
except that the language could change so that it covers all needs.

  I love it when people think theirs is the only corner of the world that
  is worthy of the trademark Real World.  one usually doesn't need any more
  evidence to discard people than that.

  I have had the opportunity to do everything I have wanted to do for my
  client, and have been able to spend all the time I have wanted on what I
  think is important to the end goal: that I shall be able to leave the
  project and it shall continue to be operational for a long time to come.
  only when my management has decided on some particular deadline for some
  particular feature has this idyllic image been disturbed.  this is not a
  government project -- it's a financial news agency's distribution system,
  where we care more about accuracy and fault tolerance than anything else.

I think you meant to say, "Lisp has PREFIX syntax".

(At least, I *hope* that's what you meant to say...)

-Rob

Uh... That's what Lisp *can* do, if *you* choose to write a reader macro
function that implements an infix parser and bind it to a dispatch character
(in this case, "I", which is undefined by default in standard CL) for the
non-terminating dispatching macro character "#" in *your* application program.
But it's not built into Lisp. Lisp's native syntax (in the absence of macro
characters) is prefix:

        (+ 2 (* foo pi))

-Rob

    Rob> Uh... That's what Lisp *can* do, if *you* choose to write a reader macro
    Rob> function that implements an infix parser and bind it to a dispatch character

There is the infix package in the CMU Lisp archives....

One of the major problems with C++ is that it requires static
typechecking, which means that building generic functions requires the
contortions of templates, which have taken years to settle down enough
that compilers could coherently implement them.  (And it is not at all
clear that template-based code is portable between different
template-implementation approaches.)  

The fact that CL doesn't *force* you to restrict the manipulable types
at the time that you write the code means that you don't need
templates; you just need to go write CL code, and use it on whatever
datatypes you need to use it on.

You're not likely to get agreement that the problem *that you
perceive* represents a problem *in fact.*

By the way, if static type checking is, as you say, an order of
magnitude more important than simplicity of appearance, would you then
pay an order of magnitude more for the Lisp implementation?  

Money talks; if the Lisp vendors figure out that they can make ten
times as much (a decimal order of magnitude) in sales as a result of
implementing this functionality, then I don't think they'll sit back
on their haunches with some "religious" attitude about not doing it
because they think it's a silly idea; they'll say:

"Cool!  If we invest $100,000 paying a developer or two to add static
type checking, and when our sales increase by an order of magnitude,
from $10M to $100M, this $100K investment will pay off handsomely!"

[Hint: The fact that they haven't done so means that they obviously
consider this "enhancement" to *not* be of that much economic value.]

That's hardly an "X implementation written in a Lisp;" that's merely a
wrapper for the X protocol written in a Lisp, and is not a
*remarkably* interesting thing.

Cheers

Is this why your CLEmacs (http://sourcery.naggum.no/emacs/clemacs.html)
project is dormant for almost 2 years now? :-)

Apparently it's not important to the end goal...

[No, you do not owe anyone anything, and I am not blaming you for
anything, and I am not whining &c &c &c.]

In general, though, all the jobs I have had have been flaky, with ego
maniacal managers and leads.  I find this kind of atmosphere too
difficult to be productive in.  Chaos begets chaos.

--
Bagherra <jaeb...@frenzy.com>
http://www.frenzy.com/~jaebear
  "What use is it to have a leader who walks on water
       if you don't follow in their footsteps?"

Contrary to what you say, isolating failures is not at all difficult
to achieve in C++ or other mainstream languages. Of course, if you
only look at monolytic systems typically emanating from Redmond, then
you are sure to crash the whole system when something goes wrong. As
an example of where we are heading, consider distributed systems
(using CORBA and other technlogies). More and more systems are built
as collections of components where every component does one thing and
one thing only. And this isn't exactly new either: On certain
mainframe systems of the past it was commonplace to implement every
transaction type as a separate program.

Anyway, this is all besides the point. How did we get distracted into
this discussion? The topic was whether more static type checking in
Common Lisp implementations would be a worthwhile improvement or
not. Nobody, at least not me, was claiming that other languages are
better than Lisp.

Joachim

Note: this last sentence was meant to be a joke! Keep in mind that I
am using Lisp myself.

Joachim

Joachim

  you won't find one, either.  formal grammars are useful for languages
  that are designed to be unreadable and with constructs designed to be
  impossible to represent at run-time.  Lisp is designed to be readable and
  source code to be representable at run-time, and so have a very different
  way of thinking about its grammar.  considering that all you will ever do
  with a grammar is associate the first element of a list (a symbol) with a
  rule for dealing with the rest of the list, you might as well design the
  whole system using a recursive descent "parser".

  Common Lisp's syntax is designed to be LL(1), and objects are read in
  their entirety before any semantics are associated with them, quite
  unlike languages designed to keep the sources unreadable to programs
  written in those languages.

CMUCL alows you to specify types, and I imagine that the commercial
compilers do as well.  Just because it is not specified in ANSI
does not mean that it does not exist in most implementations... but
it would be nice if it were specified.

Regs, Pierre.

Back to Common Lisp:

If Lisp is about anything, it's about doing the right thing, or at
least trying very very hard to do so, and recognizing that to achieve
this, you have to move very carefully, yet move nonetheless.  There
has gone much thought, and philosophical analysis, into nearly all of
the features you'll find in the current ANSI CL spec, and I expect the
same to happen with any other new ingredient that might be added to
that self-same standard in the future.

That high standard of doing the right thing, is the single most
outstanding reason that I'm working with CL.  It is not the dynamism,
the machismo or the nice parenthesis.  It is that I care about doing
the right thing, it is that my customers expect this of me (or else
they will not be my customers), and I trust Common Lisp to help me
achieve this.

So before we added some kind of (mandatory) compile-time type-checking
to Lisp, I'd want to be very sure that we are doing the right thing
here, that we've understood the issues at hand, the limitations,
the user's expectations, and the ability of implementations to
successfully implement this reliably.

Well, and C++/Java-style "type-checking" strikes me as being most
obviously not the right thing.

IMNSHO, IF C++ or Java programmers *really* cared about type-checking
at compile-time, they wouldn't be using those languages in the first
place.  To care about type-checking, you'd want to have a sensible and
expressive type-system to start with.  So you'd want at least something
like Ada, which also has bounds checking and a lot of other stuff you'd
want, or much better yet, you'd want something like the current crop of
typed pure functional languages, like Haskell or OPAL, etc., which not
only have expressive type-systems, and compile-time type-checking but
also type-inference, and at least in the case of OPAL, an algebraic
property language, which allows you to specify further properties of
your defined operations, to be checked at compile-time where possible.

That would be the course of action for C++ programmers that *really*
cared about compile-time type-checking.

Since the above mentioned languages don't have huge amounts of new
recruits either, it seems to me that most C++ programmers care about
compile-time type-checking like they care about OOP, or speed, or
portability, or most other things for that matter: It is a
must-have-it-and-exactly-this-way feature, yet they don't really know
what it is, or care about the underlying semantics or problems.  As
long as the compiler acts like it's doing something, everything's just
fine.  The sayings "Lisp programmers know the value of everything and
the cost of nothing" vs. "C++ programmers know the cost of everything,
yet the value of nothing" come to mind.  And since the time of this
saying, I think CL programmers at least have gotten a long way to
knowing the cost of things, yet I still see no movement in the C++
community of starting to care about the value of things.

Since I've heard in this discussion that C++-style type-checking is
mostly helpful in uncovering simple mistakes in argument order, etc.,
(which strikes me as being as mostly unrelated to type-checking), I'd
suggest using environments that reduce the likelyhood of MAKING those
mistakes.  Although I've not been prone to making those mistakes even
in languages like C++, in my Lisp environment, not only have I got the
arglist and documentation of every Lisp operator -- whether built-in or
user-defined -- at my finger-tips, but also the complete Hyperspec, all
just a keypress away.  So if I'm only a tiny bit in doubt about
argument order, or semantics, I look them up.  And guess what, I'm
quite a bit better at doing that kind of checking, than any compiler
I've yet seen (besides the SSC of course ;).

Of course I'd still be very willing to listen to the ideas and designs
of someone who *REALLY* cares about type-checking at compile-time.  But
I fear that since the type systems of modern pure functional languages
are still a much researched area, meaningfully type checking a language
like CL seems to me to be worthy of a number of PhDs before the design
space is clearly understood.

Of course, a much more "simplistic" kind of type-checking can be
attained with CMU CL today... Not that I see most former C++ users
flocking to CMU CL instead of other CL implementations though...

Regs, Pierre.

Footnotes:
[1]  Note that these ideas are over 2000 years old...

[2]  In reality of course, it's the languages' communities that care,
and not the language itself ;)

  I tend to think of this in terms of young people who learn something that
  older people have known for decades.  the world is getting increasingly
  complex, so the effort needed to get up to speed also increases and young
  people need to work harder to catch up.  and when they do, they have a
  steeper "gradient" than the older people they catch up with, so it is
  only natural that they want to continue with their catch-up speed and go
  on to do new stuff at a higher pace than they think the old people do.
  that's why you find new languages picking up a lot of _experimental_
  stuff that is "new" in some sense of the word, but which older people
  know to be junk, because it's something they discarded long ago, and
  people who catch up don't see where people retracked after going wrong,
  only where they went and decided to proceed.  similarly, new languages
  will do a lot of "research" and get a lot of funding for concepts and
  ideas that have previously been discarded.  however, to make this fly,
  they have to call it something else, the same way people who want to
  "circumvent" patents have to do _something_ clever on their own that lets
  them use somebody else's inventions.  except that regurgitated research
  uses somebody else's money by fooling people who don't know that it
  didn't work the last time around.

  and with all these new languages and regurgitated research, progress is
  _actually_ moving a lot slower than it would have if people could just
  stick to using other people's inventions instead of optimizing for their
  own degrees and for funding fun research and publicity hunters.

| I don't share your believe in the power of the market to lead us to
| paradise.  If the market had this power would Lisp be the fringe language
| it is?  Would Microsoft be the most successful software company?

  this is so mind-bogglingly over-simplified an attitude that I can't begin
  to answer it, but Microsoft has succeeded because it moved technical
  issues into _irrelevant_ positions.  people do _not_ buy Microsoft's
  shitware because they want quality, robustness, investment protection, or
  the like, they buy it out of fear of not being able to keep up with the
  competitors for their manpower and with companies they exchange files
  with.  Microsoft did, however, offer something of relevance a good number
  of years ago: they gave the suits a computer on their own desk that the
  computer people didn't control.  _that_ was the relevant criterion that
  propelled Microsoft into their leading role in the minds of the people
  who decide life or death in business: the suits.  like evolution, any
  irrelevant property can mutate without control, and some day it might
  prove to be relevant once sufficiently advanced.

  I read Kent Pitman's incessant argumentation for the "market" to be a
  strong voice to let the vendors know that certain issues are _relevant_
  to their customers, because the market only decides what's relevant, the
  irrelevant is taken for granted, and can be _anything_ that doesn't get
  relevant one way or another.  Kent's trying to influence that, and lots
  of people are trying to let people know what kind of irrelevant issues
  caused them to purchase virus distribution vehicles and security holes
  from Microsoft along with the relevant ego-stroking abilities for suits.