I believe that many of the questions asked in the "mainstream"
thread are actually irrelevant. The problems are small IMHO. Lisp
is here, has been for years, and will continue to be.
The problem of linking is not a problem in Lisp at all, as you
can solve it easily by using shared libraries. If your OS doesn't
have this feature, get one that does. This sounds glib, and maybe
it is. I just happen to Microsoft Windows, which has had such
libraries since 1984. However, I first read of this feature a
few years earlier, in connection with PL/I. If there's a Unix
that still doesn't have this feature, or a language that doesn't
exploit it, that's the fault of the users who don't *demand* it.
Some Mac users have also made this point.
I agree with Scott McKay about optimising CL. It can be done if
a determined effort is made, and there is a willingness to make
a few compromises where necessary. *Why* should EVAL and COMPILE
be available in a stand alone program? What about the debugger?
Very few C programs I use have debugging code left in, and those
that do are actually beta versions. Users don't like odd dialogs
poping up and unknown files created. Let's be reasonable, please.
Lisp is *not* too big to optimise. It's not impossible for the
source too be purchased from different vendors who can specialise
in a particular area, like streams or numbers, and let a delivery
system be chosen. Of course you'll still need a complete CL to
run the DS compiler on, but this should be workable once the
standard is complete. One system for development, and another
forthe production code.
It's not unusual to aquire the source for a package or library,
esp if more than a single platform is to be supported. This
approach just gives the programmer more control, and that's why
it's used by C programmers.
The high price for CL is another thing that should change - until
a few years CL was beyond my humble means, now it's comparable to
a full C++ development system for Windows plus a number of database
and widget libraries. These same libraries can also be used by Lisp,
as they're just DLLs, which can be accessed thru the foreign func
interface in a typical Windows hosted Lisp.
The most popular Smalltalk for Windows that I know of is Digitalk's
Smaltalk/V, and it uses a DLL (Dynamically Linked Library) for
the runtime system. It runs a little slow on my machine but
that's 'cos I use a slow 386. Most new machines now should run
this language fast enough to be useful for writing large apps.
In what way is Lisp worse than Smalltalk/V? There's a GC, the
method searching, compact objects and a large runtime system.
The code is native so there's no reason for it to be slow on
a machine with enough speed and memory for DTP. The same comments
about Lisp can also be made of Smalltalk, and this is what I
find. The hardcore C programmer will resist *anything*.
Don't forget that Smalltalk was misunderstood for many years. Most
people saw the graphics and missed the concepts behind them. After
a long struggle, those ideas have finally become "mainstream"
programming practice, at least in the eye of the media. This *is*
true for Windows programming tho, which is, strangely enough,
not a million miles away from Smalltalk-80, in presentation...
IMHO most of the faults outlined recently are red-herings. The
programmers I know prefer C, C++ or Pascal simply because there's
a measurable speed difference between their chosen language and
another compiler choice. They completely ignore any language
that may cut development time regardless of how small the penalty
for using it may be. Looked at like this, neither Smalltalk nor
Lisp have any chance, nor any language that uses a GC, as this
consumes too much memory for people still counting bytes. I gave
up counting bytes some years ago, when I stopped using a Z80!
Yes, I'm rather depressed by all this negativity. I'd like to
counter it by saying that Lisp *is* being used, and I don't care
whether it is a "mainstream" language, whatever that is. If it
never gets wide acceptance, I shall still use it and be content.
Without it, too many of my programs would never get written at
all, never mind debugged and improved. The only problem is finding
the time to finish them, which remains the same regardless of the
language I use.
Best of all, I get to play with a neat language. I'm also a Forth
programmer (but forced to use C++ for most DOS/Windows development),
and know that the kick from discovering some new trick or weird
coding style is what keeps most of us Forthers going. If it happens
that it's the only language suitable for a certain job, then we
have a way to justify it the rest of the world. Forth still sells
as well, and some of the apps are rather prominent, like the SkyCam.
The question of whether it is "mainstream" or not has never been
asked at the FIG meetings I've attended.
So now, which apps might never have been written without Lisp?
ISTR that the Information Lens uses CL, so my favourite language
is still used at the cutting edge, and by the same people who gave
the world Smalltalk. There's hope yet!
-- Cyber Surfing on CIX --