Thanks very much to everyone who replied.  Hopefully I can fit a bunch
of reading into my frighteningly busy schedule for the next month...

And -- did you want to reinforce the above statement of Kaz Kylheku?

--
Janis Dzerins

Looking at that impressive list, and given your Google experiences,
which of the old projects would you done differently today? Where
would the extensive libraries of modern languages (if they had been
available at the time) been a great benefit?

  While this is obviously true, the very existence and proliferation of
  exceedingly slow languages like Perl, Python, and Java, means that people
  are beginning to understand that performance does not matter for _every_
  task and are more than willing to do the logic in a more convenient
  language.  I think Common Lisp may have tried to compete on performance
  when it should have competed on convenience.  On the other hand, I would
  so love to have all of Common Lisp available to me in a form that would
  compile to "C-compatible" code, that followed the calling conventions of
  more widely used languages upon request, so that Common Lisp could be
  used without having to let it be the master of the whole application.

Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."

Lisp is too slow, C is fast enough, right?

So Lisp should not be used for some kinds of projects, yes?

I hear a numbers from time to time saying Lisp is sometimes as fast as
C, sometimes 20% slower. Exact numbers don't matter for this problem.

So we should not work 20% slower on "some interesting things", no matter
the advantages of the more elegant language.

OK, not sure on the dates, but six months ago I picked up a 1.4 GHZ
Dell, today I hear Pentiums are spinning at 2.2GHZ.

This means that a cutting edge C project today would have been a third
slower six months ago, hence too slow and should not have been
undertaken.

And systems certainly will be 20% faster before any cutting edge project
starting today can be completed, so no interesting project at all should
be started. Today's systems are too slow.

That result doe snot look right. Anyone see where I went wrong?

thx

Could you elaborate about how the OCaml module system helps you and
to what lengths you have to go to achieve the same effects in Common
Lisp.

Cheers

PS. 3 + 3.14 should yield 6.14!

Wade

For a nice (and very practical) application of phantom types, see e.g.
"No-Longer-Foreign: Teaching an ML compiler to speak C natively." by
Matthias Blume, available there:

  http://cm.bell-labs.com/who/blume/papers/nlffi-entcs.pdf

Or an interesing message of the OCaml list, with several examples:

  http://caml.inria.fr/archives/200109/msg00097.html

When I realized that every OCaml program I (and other people) wrote
started with hundreds of lines defining union types and trivial
operations on those, whose only purpose is to reintroduce dynamic
typing once again, I began to understand that dynamic typing
is actually a /feature/ itself, not a lack of a feature.  And all
those days I spent fighting and outsmarting the type checker,
particularly the module type checker (grrrr), were nothing but
totally wasted time.

Sure, being able to prove that languages like ML won't have any
run-time type errors is an impressive theoretical result.  I
like reading books about the typed lambda calculus myself, just
for fun.  But the fact that we have this nice theory does /not/
automatically imply that we all have to immediately switch to ML
like languages now.  It wasn't so long ago when everybody said
that we all had to switch to Haskell, because it was so
mathematically pleasing at the time.  Now it apparently suffices
to use impure languages like SML or OCaml, heaven knows, why.

And maybe when the static typing hype is over, it'll all of a
sudden be politically correct again to use dynamically typed
languages.  I'll be waiting there until then :-)

Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."

Or if you have some reason to be avoiding mixed-language programming.

The program is written with some release date in mind, and is planned
around the projected hardware available at that time, rather than today's
hardware.

Other LISPs with concurrency (threads) are kind of nice,
but not really built for massively concurrent systems:
the global garbage-collected shared-memory model of LISP
strongly limits the scalability such systems, and
their robustness when faced with fault-containment problems.
Also, no concurrent LISP extension correctly handles
problems of synchronization of interrupted threads with
application-defined invariants - see for instance the problems
that Joe Marshall had with interrupted transactions.
(LISP here is not worse than Java,
but JOCaml and Erlang can do much better).

Of course, it is possible to build distributed systems
atop of LISP (just like you can atop any language), but
then (just like you would have in any such setting), it means
that you have a fight a multi-level programming system
that imposes arbitrary constraints on your programming style
and forces you to make arbitrary early low-level implementation
choice as to which problem will be treated at which level.
LISP's metaprogramming abilities can help you factor a lot,
so you will be better with LISP than with anything else,
but if you take this approach seriously, you will but end up
reimplementing Erlang or JOCaml in LISP, and the idiosynchrasies
of LISP systems (designed around a global namespace) will end up
getting in the way, whether you try to emulate them (expensive
runtime distributed coherence enforcement) or avoid them
(difficult to trace inconsistent behaviour when they are mistakenly used).

Erlang, on the other hand, is a generic tool for building robustp
concurrent systems. It does not depend on the idiosynchrasies of
any particular hardware architecture. Its model of internally pure
communicating processes easily scales to building large distributed systems,
while allowing for real-time behaviour (soft-real-time in practice;
but nothing in theory prevents a hard-real-time implementation if needed).
and provides a framework for fault-containment as well
as for asynchronous interruption handling, and more.
It is actually used in mission-critical telecom switch systems,
in services using internet-standard protocols, etc.

I don't mean that it would be impossible to design a LISP so as to be
as good for concurrent programming as Erlang is. But it would require
deep changes to the language and its implementations, and the end-result
wouldn't quite be like Common Lisp. For instance, instead of global
namespaces and am implicit global object heap, it might have something
like first-class name-spaces and first-class object-spaces;
the behaviour of primitives of the language in face of concurrency
would have to be clarified -- maybe by introducing a linear type system.

Yours freely,

I remember working on an embedded system, I wrote code and tested for almost
two years (there were 9 of us).  I remember sitting down, burning a EPROM
(386 K), looking at it and thinking, "This is it?!!".  It was a little
deflating, what I thought was so important in the big scheme of things
wasn't.

Wade

Functors allow to build generic code taking types and other functors
as parameters; the resulting code can be quite elaborate, and in ML,
static typing is very useful in assessing that module combinations
are done right. Functors could theoretically be implemented as a very
sophisticated set of macros. Indeed, MzScheme has a first-class
module system that can do the equivalent of ML's functors, and also solves
the global namespace problem of Scheme (that has no packages).
In CL, the choice of namespace management technique for functors in CL
would be "interesting": Would you rather dynamically generate new packages?
Generate new symbols? Generate some first-class namespace objects holding
new meanings for existing symbols? Generate code that calls higher-order
functions with additional explicit parameters? Would you use the CL class
system and generate new classes? Or generate new generic functions?
Or generate new objects of a same class, that contain the type and functor
parameters as additional runtime data? It isn't all quite clear to me what
is the Right Thing(TM) to do that in CL. It seems to me that CL programmers
have just learnt to live without the equivalent of higher-order modules
and cope up in a case-by-case basis. The fact that CL won't statically
enforce much any invariant restricts the pressure to define clean module
interfaces, anyway.

<opinion>
BTW, I would much rather see Lisp change to meet modern challenges than
see Lisp programmers convert to Python.  Lisp is still better than Python
from purely language-based considerations.  But the extent to which Lisp
is better than Python is much smaller than the extent to which Lisp is
better than C, to the point where non-language considerations (like not
having to fight with management) give Python the edge in some cases.
</opinion>

Andreas