Future of LISP in NatLang/AI
Timothy Bosley
I think there was some sort of survey about this in the not
too distant past......but I wasn't thinking about this then
and didn't pay attention to it. [To whomever conducted the
survey: could you please send me the results?]
I would like opinions from NL/AI researchers or anyone who
uses lisp on a regular basis....is there a future for lisp?
Does it meet your needs for cutting edge work? Does it need
to be extended? Is there a more suitable language out there
or on the horizon?
Any thoughts at all appreciated.
Staffan Larsson
Timothy Bosley wrote:
...
> I would like opinions from NL/AI researchers or anyone who
> uses lisp on a regular basis....is there a future for lisp?
> Does it meet your needs for cutting edge work? Does it need
> to be extended? Is there a more suitable language out there
> or on the horizon?
>
> Any thoughts at all appreciated.
I study computational lingustics at Goteborg University in Sweden.
I have not studied any Lisp (nor have I had the chance to do so),
as it seems to be considered otdated.
Instead, I have used Prolog. Logic programming is a very natural
choice in NL/AI, since formal logic is the most widely-used
approach to NL/AI.
However, seeing how many researchers still rely on LISP, I might
have to learn it anyway.
Are there any technical advantages with Lisp, compared to Prolog?
--
Staffan Larsson
Howard R. Stearns
Timothy Bosley wrote:
>
> I think there was some sort of survey about this in the not
> too distant past......but I wasn't thinking about this then
> and didn't pay attention to it. [To whomever conducted the
> survey: could you please send me the results?]
>
> uses lisp on a regular basis....is there a future for lisp?
> Does it meet your needs for cutting edge work? Does it need
> to be extended? Is there a more suitable language out there
> or on the horizon?
>
> Any thoughts at all appreciated.
Here's the results of the survey again. The purpose of the survey was
to see what issues people had with the IMPLEMENTATION of their
favorite languages, not the languages themselves.
The "Future of Lisp" angle is that presumably, Lisp vendors should
move their products in a direction to reflect these concerns.
-----------------------------------------------------------------
Some respondents listed more than one language as being their most
prefered (even while evaluating the implementation for a single
langage). Languages described as being favored:
CL was favored 27 times (31%).
C++ was favored 13 times (15%).
C was favored 13 times (15%).
ADA was favored 9 times (10%).
SCHEME was favored 8 times ( 9%).
SMALLTALK was favored 6 times ( 7%).
PROLOG was favored 6 times ( 7%).
PERL was favored 5 times ( 6%).
PYTHON was favored 5 times ( 6%).
DYLAN was favored 3 times ( 3%).
MERCURY was favored 3 times ( 3%).
JAVA was favored 3 times ( 3%).
MODULA-3 was favored 2 times ( 2%).
EIFFEL was favored 2 times ( 2%).
SML was favored 2 times ( 2%).
PASCAL was favored 2 times ( 2%).
SATHER was favored 2 times ( 2%).
OBERON was favored 1 times ( 1%).
MUMPS was favored 1 times ( 1%).
SISAL was favored 1 times ( 1%).
CLP was favored 1 times ( 1%).
BETA was favored 1 times ( 1%).
PL/I was favored 1 times ( 1%).
HELIX-EXPRESS was favored 1 times ( 1%).
APPLESCRIPT was favored 1 times ( 1%).
CLEAN was favored 1 times ( 1%).
HASKELL was favored 1 times ( 1%).
ASM was favored 1 times ( 1%).
CAML was favored 1 times ( 1%).
XLISP-STAT was favored 1 times ( 1%).
ASSEMBLY was favored 1 times ( 1%).
AMIGA-E was favored 1 times ( 1%).
ICON was favored 1 times ( 1%).
AWK was favored 1 times ( 1%).
SH was favored 1 times ( 1%).
QBASIC was favored 1 times ( 1%).
Most preferred language:
CL received 25 responses (29%).
C++ received 9 responses (10%).
ADA received 7 responses ( 8%).
C received 6 responses ( 7%).
PROLOG received 5 responses ( 6%).
SCHEME received 5 responses ( 6%).
SMALLTALK received 5 responses ( 6%).
PERL received 3 responses ( 3%).
PYTHON received 3 responses ( 3%).
MERCURY received 2 responses ( 2%).
MODULA-3 received 2 responses ( 2%).
SATHER received 2 responses ( 2%).
XLISP-STAT received 1 responses ( 1%).
BETA received 1 responses ( 1%).
AMIGA-E received 1 responses ( 1%).
QBASIC received 1 responses ( 1%).
JAVA received 1 responses ( 1%).
HELIX-EXPRESS received 1 responses ( 1%).
PL/I received 1 responses ( 1%).
SISAL received 1 responses ( 1%).
PASCAL received 1 responses ( 1%).
MUMPS received 1 responses ( 1%).
OBERON received 1 responses ( 1%).
EIFFEL received 1 responses ( 1%).
DYLAN received 1 responses ( 1%).
Results for ALL-LANGUAGES:
%programming %delivering
UNIX 68 69
WINDOWS 43 49
MAC 30 36
AMIGA 6 5
SYMBOLICS 3 3
OS2 3 2
DOS 1 2
VMS 1 2
BEBOX 1 1
ATARI 1 1
CMS 1 1
UNKNOWN 0 0
VAX/VMS 0 1
REAL-TIME 0 1
NT 0 1
Room for improvement is seen in:
Standards conformance : 31%
Speed : 45%
Size of development environment : 30%
Application delivery : 33%
Calling other languages : 47%
Being called by other languages : 46%
Developement environment : 45%
GUI : 47%
Responses came from the following comp.lang newsgroups:
UNKNOWN provided 56 of the responses (64%).
LISP provided 13 of the responses (15%).
PYTHON provided 4 of the responses ( 5%).
MISC provided 3 of the responses ( 3%).
ADA provided 2 of the responses ( 2%).
C provided 2 of the responses ( 2%).
DYLAN provided 2 of the responses ( 2%).
SMALLTALK provided 1 of the responses ( 1%).
SCHEME provided 1 of the responses ( 1%).
C++ provided 1 of the responses ( 1%).
PROLOG provided 1 of the responses ( 1%).
SATHER provided 1 of the responses ( 1%).
11% of responses appeared to be from educational domains, while
30% appeared to be from outside the US.
45% currently have a Common Lisp compiler.
Results for CL:
%programming %delivering
UNIX 72 68
WINDOWS 36 44
MAC 40 36
SYMBOLICS 12 12
UNKNOWN 0 0
OS2 4 0
Room for improvement is seen in:
Standards conformance : 48%
Speed : 28%
Size of development environment : 36%
Application delivery : 60%
Calling other languages : 68%
Being called by other languages : 60%
Developement environment : 24%
GUI : 52%
Responses came from the following comp.lang newsgroups:
UNKNOWN provided 11 of the responses (44%).
LISP provided 10 of the responses (40%).
DYLAN provided 2 of the responses ( 8%).
ADA provided 1 of the responses ( 4%).
C++ provided 1 of the responses ( 4%).
24% of responses appeared to be from educational domains, while
36% appeared to be from outside the US.
96% currently have a Common Lisp compiler.
Results for C++:
%programming %delivering
UNIX 67 67
WINDOWS 56 56
MAC 22 33
BEBOX 11 11
ATARI 11 11
REAL-TIME 0 11
DOS 0 11
Room for improvement is seen in:
Standards conformance : 44%
Speed : 33%
Size of development environment : 11%
Application delivery : 22%
Calling other languages : 56%
Being called by other languages : 78%
Developement environment : 67%
GUI : 22%
0% of responses appeared to be from educational domains, while
44% appeared to be from outside the US.
33% currently have a Common Lisp compiler.
Results for ADA:
%programming %delivering
UNIX 71 86
WINDOWS 43 57
MAC 29 43
AMIGA 29 29
DOS 14 14
VMS 14 14
VAX/VMS 0 14
Room for improvement is seen in:
Standards conformance : 14%
Speed : 43%
Size of development environment : 14%
Application delivery : 0%
Calling other languages : 29%
Being called by other languages : 29%
Developement environment : 57%
GUI : 57%
Responses came from the following comp.lang newsgroups:
UNKNOWN provided 6 of the responses (86%).
ADA provided 1 of the responses (14%).
0% of responses appeared to be from educational domains, while
14% appeared to be from outside the US.
14% currently have a Common Lisp compiler.
Results for C:
%programming %delivering
WINDOWS 67 83
UNIX 83 67
AMIGA 17 17
NT 0 17
VMS 0 17
MAC 0 17
Room for improvement is seen in:
Standards conformance : 33%
Speed : 33%
Size of development environment : 50%
Application delivery : 33%
Calling other languages : 17%
Being called by other languages : 17%
Developement environment : 50%
GUI : 33%
Responses came from the following comp.lang newsgroups:
UNKNOWN provided 3 of the responses (50%).
C provided 1 of the responses (17%).
MISC provided 1 of the responses (17%).
PYTHON provided 1 of the responses (17%).
17% of responses appeared to be from educational domains, while
0% appeared to be from outside the US.
17% currently have a Common Lisp compiler.
Results for PROLOG:
%programming %delivering
UNIX 80 80
WINDOWS 20 40
MAC 20 40
Room for improvement is seen in:
Standards conformance : 40%
Speed : 20%
Size of development environment : 0%
Application delivery : 40%
Calling other languages : 60%
Being called by other languages : 40%
Developement environment : 40%
GUI : 60%
Responses came from the following comp.lang newsgroups:
UNKNOWN provided 3 of the responses (60%).
PROLOG provided 1 of the responses (20%).
PYTHON provided 1 of the responses (20%).
0% of responses appeared to be from educational domains, while
20% appeared to be from outside the US.
80% currently have a Common Lisp compiler.
Results for SCHEME:
%programming %delivering
UNIX 100 100
WINDOWS 40 60
MAC 40 40
AMIGA 20 0
Room for improvement is seen in:
Standards conformance : 0%
Speed : 100%
Size of development environment : 40%
Application delivery : 40%
Calling other languages : 60%
Being called by other languages : 40%
Developement environment : 60%
GUI : 60%
Responses came from the following comp.lang newsgroups:
UNKNOWN provided 3 of the responses (60%).
SCHEME provided 1 of the responses (20%).
LISP provided 1 of the responses (20%).
0% of responses appeared to be from educational domains, while
20% appeared to be from outside the US.
40% currently have a Common Lisp compiler.
Results for SMALLTALK:
%programming %delivering
MAC 60 60
WINDOWS 60 60
UNIX 40 60
Room for improvement is seen in:
Standards conformance : 0%
Speed : 40%
Size of development environment : 60%
Application delivery : 40%
Calling other languages : 0%
Being called by other languages : 40%
Developement environment : 20%
GUI : 40%
Responses came from the following comp.lang newsgroups:
UNKNOWN provided 4 of the responses (80%).
SMALLTALK provided 1 of the responses (20%).
0% of responses appeared to be from educational domains, while
0% appeared to be from outside the US.
0% currently have a Common Lisp compiler.
Results for ALL-EXCEPT-LISP:
%programming %delivering
UNIX 64 68
WINDOWS 46 52
MAC 23 34
AMIGA 7 7
OS2 4 4
VMS 2 4
DOS 2 4
CMS 2 2
BEBOX 2 2
ATARI 2 2
NT 0 2
VAX/VMS 0 2
REAL-TIME 0 2
Room for improvement is seen in:
Standards conformance : 25%
Speed : 46%
Size of development environment : 25%
Application delivery : 20%
Calling other languages : 37%
Being called by other languages : 41%
Developement environment : 52%
GUI : 43%
Responses came from the following comp.lang newsgroups:
UNKNOWN provided 42 of the responses (75%).
PYTHON provided 4 of the responses ( 7%).
MISC provided 3 of the responses ( 5%).
C provided 2 of the responses ( 4%).
SMALLTALK provided 1 of the responses ( 2%).
SATHER provided 1 of the responses ( 2%).
PROLOG provided 1 of the responses ( 2%).
ADA provided 1 of the responses ( 2%).
LISP provided 1 of the responses ( 2%).
7% of responses appeared to be from educational domains, while
29% appeared to be from outside the US.
23% currently have a Common Lisp compiler.
Results for all Lisp languages (cl, sheme, xlisp):
%programming %delivering
UNIX 74 71
WINDOWS 35 45
MAC 42 39
SYMBOLICS 10 10
AMIGA 3 0
UNKNOWN 0 0
OS2 3 0
Room for improvement is seen in:
Standards conformance : 42%
Speed : 42%
Size of development environment : 39%
Application delivery : 58%
Calling other languages : 65%
Being called by other languages : 55%
Developement environment : 32%
GUI : 55%
Responses came from the following comp.lang newsgroups:
UNKNOWN provided 14 of the responses (45%).
LISP provided 12 of the responses (39%).
DYLAN provided 2 of the responses ( 6%).
SCHEME provided 1 of the responses ( 3%).
ADA provided 1 of the responses ( 3%).
C++ provided 1 of the responses ( 3%).
19% of responses appeared to be from educational domains, while
32% appeared to be from outside the US.
84% currently have a Common Lisp compiler.
Ingemar Hulthage
For those who don't know LISP really means:
Lots of Incredible Staying Power.
Ingemar
Jim Rankin
Changing the subject somewhat, do any of you see definitive advantages to
using an OO programming language to do AI/NLP research, as compared to
more traditional AI/NLP languages like Lisp/Scheme/Prolog/etc.? I
suppose there's some obvious advantages like strong commercial support
for languages like C++ and Java, but what about the merits of OO
programming languages as research tools?
Jim Rankin, aspiring NLP researcher
Marty Hall
In article <jmrst32-2904...@ehdup-n-5.rmt.net.pitt.edu>
jmr...@pop.pitt.edu (Jim Rankin) writes:
>Changing the subject somewhat, do any of you see definitive advantages to
>using an OO programming language to do AI/NLP research, as compared to
>more traditional AI/NLP languages like Lisp/Scheme/Prolog/etc.?
Also, note that, assuming by "Lisp" you mean "Common Lisp", Lisp *is*
an OO programming language. It is like C++ and Dylan, and unlike
Smalltalk and Java, in the sense that the OO parts are optional to
some extent -- you can write methods/functions that are not part of a
class if you want. It is like C++ and Dylan and unlike Smalltalk and
Java in the sense that multiple inheritance is supported.
Many people would say that the OO capabilities of CLOS (the Common
Lisp Object System) are more advanced than C++ or Java, although the
concept of data protection in CLOS is dramatically different.
See the section on CLOS in my Lisp WWW page for a quick intro:
<http://www.apl.jhu.edu/~hall/lisp.html>
- Marty
(proclaim '(inline skates))
Richard A. O'Keefe
jmr...@pop.pitt.edu (Jim Rankin) writes:
>Changing the subject somewhat, do any of you see definitive advantages to
>using an OO programming language to do AI/NLP research, as compared to
>more traditional AI/NLP languages like Lisp/Scheme/Prolog/etc.? I
>suppose there's some obvious advantages like strong commercial support
>for languages like C++ and Java, but what about the merits of OO
>programming languages as research tools?
Hysterical laughter. We have some very powerful and interesting
grammatical theories, stuff derived from GPSG, stuff derived from
Chomsky-style principles-and-parameters, &c. Naive processing of
these things can be stupendously inefficient. People use all kinds
of `compilation' strategies to take one of these things and get an
efficient parser. High level strategies have *vastly* more effect on
the performance of the resulting system than the bottom level
implementation language.
The conceptual gap between the kinds of things Java helps with and
the technical issues people are trying to deal with in NLP is so vast
that it really isn't funny. (Though Java would presumably be wonderful
for building GUI front ends, I would expect it to be outperformed by
existing Lisp systems. MCL is no slouch.) C++ is at an even lower
level than Java; the *last* thing we need is to worry about storage
leaks, pointer problems, integer overflow, and so on.
This is not to deny that OOP may help in NLP, but CL/CLOS is considerably
more powerful as an OOP language, and it takes care of all the low level
issues for you so that you can worry about the really interesting problems.
NLP programs can benefit from accessing large knowledge bases, if that can
be done efficiently, so an interface between the language you are using and
the PEIRCE data base, for example, would be an excellent thing. PEIRCE is
implemented in C++ (it stores large collections of conceptual graphs), but
there are PEIRCE interfaces for other programming languages (Prolog for one,
and probably Lisp).
The fact that PATR-II was developed in Lisp, Pappi in Prolog, and ProGram
in Pop is not an accident of history.
--
Fifty years of programming language research, and we end up with C++ ???
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.
Travis Porco
In article <3180B3...@cling.gu.se> Staffan Larsson <cl2s...@cling.gu.se> writes:
>From: Staffan Larsson <cl2s...@cling.gu.se>
>Subject: Re: Future of LISP in NatLang/AI
>Date: Fri, 26 Apr 1996 11:27:32 GMT
>I have not studied any Lisp (nor have I had the chance to do so),
>as it seems to be considered outdated.
...
>Are there any technical advantages with Lisp, compared to Prolog?
There is a useful discussion in
_Paradigms of Artificial Intelligence Programming_ by Peter Norvig,
Morgan-Kaufmann, ISBN 1-55860-191-0
>--
>Staffan Larsson
HTH, --Travis Porco
Jeff Shrager
: Lots of Incredible Staying Power.
Funny; I really just wrote this today, and was sitting on it overnight
before posting it, as it's a bit flaming, but since it seems apropos...
-----
I'm sorry to flame all over this list, but I just have to complain
aloud to some understanding souls or I'm going to explode!
(flame 'on)
I've been programming since about 1970, and programming in lisp since
about 1976, meanwhile, I've written APL, Fortran, PL/I, cobol, C, C++,
BASIC (of course), ...blah blah blah..., lots of different assemblers,
even SNOBOL and TECO for (#&|$~'$ sake! I've written code at pretty
much every level from operating systems, through compilers, through
applications, through AI and cognitive models; I've probably have
almost filled out the connectivity matrix of sorts-of-programming-
languages by sorts-of-programs.
Last week I wrote the top-level controller for a large image-
processing pipeline that lives in Unix. I chose lisp because the task
is mostly file handling and string processing, and I call out to C
code when I have to do heavy computing (mostly because the C code
already exists, not because I couldn't rewrite it in lisp, but what's
the point). Also, the application involves a tiny bit of heuristic
analysis of user goals and of which files go with which
others. Finally, the application called for a micro-language
intepreter to allow the user to put together part of the pipeline in
arbitrary ways. This was all trivial in Lisp; It took about three
hours to get the basics going and a couple of days to have it to the
point of usability by naive users, including documentation and an
advisory wizard.
Okay, so I go to show this completely documented, completely working,
fully interactive, partly intelligent, system to the other folks in my
group, who are mostly unix hackers, and get the usual, knee-jerk
response: "Oh, it's in lisp, well we can't let anyone else have it in
*that* state; it won't be supportable and it's too heavy-weight, and
the users won't be able to modify it and etc...."
Okay, if you're so smart, how would you do it?
Their answer....
(I hope you haven't eaten anything you want to keep down!)
....Perl!
Now, I generally try to keep an open mind, and I'm always happy to
learn a new improved way to do things, so I start playing around with
Perl, looking at the Perl archives, reading the perl bboard, etc.,
thinking that perhaps there is reason behind my colleagues' feelings.
Well, I must say that Perl is probably the worst travesty of a
programming language I have *ever* seen in my entire life! It is a
sin against all right-minded programmers everywhere to associate such
a load of random crap with the concept of programming. (I'm told by a
colleague that if I think Perl is bad, I ought to see Tcl. Thanks but
I'll pass!)
Now, you might wonder why I'm flaming on about some idiots in my
particular circle of associates, but of course these idiots aren't
alone in the world, and they aren't complete idiots, and neither
presumably are the hundreds of other Perl users and the thousands of
others who are wasting their lives producing YANPLWTHBAPGOFAFY (Yet
Another New Progrmaming Language When There Has Been A Perfectly Good
One For Almost Forty Years!)
Lisp is the ONLY programming language that has stood the test of time
(aside from, perhaps, Fortran, which is only used by folks who have to
crunch numbers, and probably really ought to be replaced by C at this
point). Can you imagine how wonderful the computing world would be if
all those lusers had put the effort that they put into Java, Perl,
C++, SmallTalk and so forth into improving Lisp instead?! We might
have light-weight lisp processors, lovely optimizing lisp compilers,
solutions to the problems of modules and packages, solutions to the
various complexities of OOP, excellent and brilliant debuggers, a
universal byte-code standard for all platforms, and so on. It just
makes me crazy to think about the amount of brilliance that goes down
a $#|~hole like Perl, not to mention all the other flash-in-the-pan
N.I.H. programming horrors out there!
Can something be done about this? Can *anything* be done about this?
The lisp world made a great stride when they unified behind the
commonlisp standard. Is it time for another movement? What would it
be? It seems to me that the problem that most non-lispers can't get
beyond is the fact that they have to drag around a lisp interpreter.
(People joke about the parentheses, but serious programmers don't seem
to really care that much about syntax. If they did, they wouldn't be
using C++ and Perl!) Perhaps we ought to develop a standard byte-code
level so that there's a minimum of junk that has to be dragged around
when you run (simple) lisp. (To their credit some modern compilers go
into C, or some other low-level language. This is step in the right
direction: putting C in its appropriate place next to assembly
language and binary.)
Then again, I don't know that anything like this is the right
approach; Maybe there are cultural approaches: Mass an attack on the
educational community to ensure lisp is included in the EARLY CS
curriculum; produce "NUMERICAL RECIPES IN LISP" or, better yet write a
companion volume: "RECIPES FOR EVERYTHING ELSE IN LISP!"; lobby
congress to enforce >>Lisp By Law<< (Now *there's* a slogan!); sick
the NRA on anyone who dares create Yet Another....
I'm at a loss. But I feel much better now. Thanks for listening and
may you never have to even see a Perl program much less write one!
(flame 'off)
Cheers,
-- Jeff
Mike McDonald
In article <4m9dv2$s...@usenet.srv.cis.pitt.edu>,
shr...@neurocog.lrdc.pitt.edu (Jeff Shrager) writes:
>: Lots of Incredible Staying Power.
>
>Funny; I really just wrote this today, and was sitting on it overnight
>before posting it, as it's a bit flaming, but since it seems apropos...
>
>-----
>
>I'm sorry to flame all over this list, but I just have to complain
>aloud to some understanding souls or I'm going to explode!
Me too!
>(flame 'on)
>Okay, so I go to show this completely documented, completely working,
>fully interactive, partly intelligent, system to the other folks in my
>group, who are mostly unix hackers, and get the usual, knee-jerk
>response: "Oh, it's in lisp, well we can't let anyone else have it in
>*that* state; it won't be supportable and it's too heavy-weight, and
>the users won't be able to modify it and etc...."
I'm in the same boat. I'm really despising starting this new project
because I know I'll get the same response. I'm writing a kind of
software logic analyzer. Think of having a bunch of event records of
things like begin of SCSI write, end of SCSI write, received ethernet
packet, start/end of syscall, ... I then need to be able to look for
patterns of events in these large traces. Things like
when $X.ID == SCSI and $X.command == Write # Bogus syntax!
and $Y.ID == SCSI and $Y.command == Error
and $X.time < $Y.time < ($X.time + 100ms)
do_something_else($X, $Y);
or better yet
foreach ($X $Y)
when $X.ID == SCSI
and $X.command == Write
and $X.start == True
and $Y.ID == SCSI
and $Y.command == SCSI
and $Y.start == False
and $X.time < $Y.time < ($X.time + 100ms)
collect $Y.time - $X.time
This is trivial to write in lisp and so much more useful! (Where's
my Symbolics??) If you set $A to the result of the foreach loop, then
you can do things like
(histogram $A) or (highlight-regions $A) or ...
And users can defined their own analysis and plotting routines! "Hey,
what a wonderful idea. Let's make it extensible! But we can't use
lisp. Heck EVERYONE knows it's too slow and too big. And besides, only
those AI wierdos use lisp."
> Okay, if you're so smart, how would you do it?
>
> Their answer....
>
> (I hope you haven't eaten anything you want to keep down!)
>
> ....Perl!
The answer here is TCL! :-((( Excuse me a moment while I go barf
... Ahh, felling better now.
>Now, I generally try to keep an open mind, and I'm always happy to
>learn a new improved way to do things, so I start playing around with
>Perl, looking at the Perl archives, reading the perl bboard, etc.,
>thinking that perhaps there is reason behind my colleagues' feelings.
PERL's fine for what it was "designed" for, writing reports from
simple databases. Then the kitchen sink got thrown in and ...
>Well, I must say that Perl is probably the worst travesty of a
>programming language I have *ever* seen in my entire life! It is a
>sin against all right-minded programmers everywhere to associate such
>a load of random crap with the concept of programming. (I'm told by a
>colleague that if I think Perl is bad, I ought to see Tcl. Thanks but
>I'll pass!)
CHICKEN! :-)))
>Now, you might wonder why I'm flaming on about some idiots in my
>particular circle of associates, but of course these idiots aren't
>alone in the world, and they aren't complete idiots, and neither
>presumably are the hundreds of other Perl users and the thousands of
>others who are wasting their lives producing YANPLWTHBAPGOFAFY (Yet
>Another New Progrmaming Language When There Has Been A Perfectly Good
>One For Almost Forty Years!)
I think its related to the "dumbing down" of the industry. Back in
the good ole days, programming and computers were assumed to be hard
things to deal with. As a result, only talented and dedicated people
got involved with them. Now days, the attitude is that anyone can
program. That plus all of the money in the industry, has attracted
lots of unqualified people. (Heck, my former employer had a preference
for hiring foreign language majors over CS/EE majors for programming
positions. After all, they've spent their college years studying
different languages and programming is just using another language!)
Now, an awful lot of the industries time and energies are spent trying
to support and build up the capabilities of these unqualified
people. Don't believe me? Just look at all of that garbage code in
your company's/college's product. Where'd that come from? Why do you
have to spend all of your time fixing some parts of the code while
other parts "just keep on ticking"?
>Lisp is the ONLY programming language that has stood the test of time
>(aside from, perhaps, Fortran, which is only used by folks who have to
>crunch numbers, and probably really ought to be replaced by C at this
>point).
Actually, Fortran still has a big advantage over C in numerical code
due to its built in support of complex numbers. (Yes, you can emulate
complex numbers in C. It's not the same thing.)
> Can you imagine how wonderful the computing world would be if
>all those lusers had put the effort that they put into Java, Perl,
>C++, SmallTalk and so forth into improving Lisp instead?! We might
>have light-weight lisp processors, lovely optimizing lisp compilers,
>solutions to the problems of modules and packages, solutions to the
>various complexities of OOP, excellent and brilliant debuggers, a
>universal byte-code standard for all platforms, and so on. It just
>makes me crazy to think about the amount of brilliance that goes down
>a $#|~hole like Perl, not to mention all the other flash-in-the-pan
>N.I.H. programming horrors out there!
Oh, but it's so much more fun (and profitable!) to invent a new
language! "You too can be Geek of the Week by inventing a new,
improved language!" And around here, an instant billionaire! Of
course, you'll probably be broke again a week later but by then,
everyone will have moved on so no one will notice.
>Can something be done about this?
Sure. Invent a new language, cash in your stock options before the
hype fades, and retire to a beach in Bora Bora where you don't have to
think about the sorry state of anything. :-)
>I'm at a loss. But I feel much better now. Thanks for listening and
>may you never have to even see a Perl program much less write one!
I'm at a loss too. I have no idea on how to get people to come
around. And I'm getting tired of the battle. :-( Unfortunately, I don't
feel better, I now have to go write a TCL interpreter in C++.
>(flame 'off)
>
>Cheers,
>-- Jeff
>
--
Mike McDonald
mik...@engr.sgi.com
Jim Veitch
I'm afraid I couldn't help responding to this thread.
* We have several thousand paying users. Many are doing AI and Natural
Language (including Boeing, Siemens, SRI, Price Waterhouse and lots
and lots of others).
* We have free Web version of our Windows Lisp (Allegro CL) which 2,500
different people have downloaded off our Web page in the last 6 months.
This developer system runs in 16 MB RAM without paging. To do the same
with Visual C++ would take 20 or 24 MB RAM.
* In the last 12 months we have 11 Value Added Resellers sign up with us
or start shipping major quantities of Lisp based products for commercial
sale. These range from Nichimen Graphics (who sell game development
systems to Nintendo and Acclaim), to High Level Design Systems (who
sell ASIC CAD tools - in fact both Mentor Graphics and LSI Logic are
reselling the HLDS software).
* Some Value Added Resellers are big names: AT&T, Siemens, and
Parametric Technology Corp.
So if Lisp is dead, we sure don't know about it. And nor do a lot of other
people out there. Don't let the great unwashed masses fool you.
Jim Veitch
VP Marketing
Franz Inc.
http://www.franz.com/
Cyber Surfer
In article <4m9dv2$s...@usenet.srv.cis.pitt.edu>
shr...@neurocog.lrdc.pitt.edu "Jeff Shrager" writes:
> (flame 'on)
First of all, a minor CaRP (Campaign for Real Pedentry - try it (-; ).
If you're using CL, I think that should be (flame t) or possibly
(prose-style :flame t).
> Well, I must say that Perl is probably the worst travesty of a
> programming language I have *ever* seen in my entire life! It is a
> sin against all right-minded programmers everywhere to associate such
> a load of random crap with the concept of programming. (I'm told by a
> colleague that if I think Perl is bad, I ought to see Tcl. Thanks but
> I'll pass!)
Yes, _do_ avoid Tcl if you can! I only use a very small subset of
Perl, and I find it pretty unpleasant. On the other hand, it does
the job, just like awk, only a little different, and with a larger
bag of tricks. There are pros and cons for everything.
> Now, you might wonder why I'm flaming on about some idiots in my
> particular circle of associates, but of course these idiots aren't
> alone in the world, and they aren't complete idiots, and neither
> presumably are the hundreds of other Perl users and the thousands of
> others who are wasting their lives producing YANPLWTHBAPGOFAFY (Yet
> Another New Progrmaming Language When There Has Been A Perfectly Good
> One For Almost Forty Years!)
The reason I use for anyone using any software is this:
BECAUSE THEY CAN!
Don't try to rationalise it. If I could use an alternative to C/C++,
then I'd be using it. If I write something in Lisp, it's because it
can be done, and I like Lisp (Scheme, Common Lisp, etc). I started
writing my own Lisp to C compiler coz I could, and I was tired of
battling the assumptions made by the designers of other dialects.
By writing my own compiler (or interpreter - I've done that twice
before), I'm free to design it any way I please - because I can.
Perl is also like that. Ask Larry Wall why (or don't!), and he might
give you an answer. I doubt it'll be better than "coz I can". In fact,
it might be longer than that, or just as short but less enlightening.
I can respect Larry as a fellow programmer because he's honest enough
to admit that he's just not concerned about what other programmers
think of him and Perl.
> I'm at a loss. But I feel much better now. Thanks for listening and
> may you never have to even see a Perl program much less write one!
I recently re-wrote a short awk utility of mine in Perl. I use it
several times a day, and it's now a little bit more useful. Perhaps
that makes it worth re-writing, but I dunno. Still, I did it, and
you can guess the reason.
If I could've written it in Lisp, I might have done so. Actually,
I'd rather re-write it in Dylan, but that's coz Dylan is much closer
to what I'd like Lisp to be, i.e., a language that I might be paid
to write code in.
I'm not apologising for Perl programmers, any more than for those
who use any other language - including Lisp programmers. We all
do things that seem dumb to othe people. Take me, first instance.
I write code that fits onto a single floppy disk. If the code won't
fit, then it has to be re-written so that it _does_ fit. That may
be why I'm still using C (yes, _C_, not C++) to do it. I use C
because I can, and I have to. I don't like it, but Lisp can't do
what I need. Dylan probably can't do it, either, and I'm pretty
sure that Perl can't, either. Someday I may get to use a more
civilised (and modern) language, but it could be a long wait.
Do what you can, and see if you can live with it.
<fx: rides off into sunset>
--
<URL:http://www.enrapture.com/cybes/> "You can never browse enough."
Ion Androutsopoulos
In article <jmrst32-2904...@ehdup-n-5.rmt.net.pitt.edu>
jmr...@pop.pitt.edu (Jim Rankin) writes:
Changing the subject somewhat, do any of you see definitive advantages to
using an OO programming language to do AI/NLP research, as compared to
more traditional AI/NLP languages like Lisp/Scheme/Prolog/etc.? I
suppose there's some obvious advantages like strong commercial support
for languages like C++ and Java, but what about the merits of OO
programming languages as research tools?
Inheritance plays an important role in several NLP/CL grammar
formalisms/theories. HPSG, for example, uses a hierarchy of
feature-structure sorts, with the various sorts inheriting features
and restrictions from their super-sorts. Inheritance seems
particularly important in lexicons. For example, the lexical entries
for the various forms of a verb (e.g. "departs", "departing") are
typically very similar. One could have a generic "depart" entry, from
which the entries of the particular "depart" forms would inherit most
of their information. Similarly, there could be a generic verb entry,
from which entries for particular verbs would inherit information. If
I remember correctly, Pollard and Sag sketch an approach of this kind
in their HPSG volume 1.
Maybe the inheritance mechanisms of OO languages would be useful when
implementing ideas of this kind. But on the other hand, in a language
like C++ there is no built-in support for other mechanisms
(e.g. unification) that seem particularly useful for NLP.
---
Ion (Ioannis) Androutsopoulos E-mail: i...@aisb.ed.ac.uk
Dept.of AI, Univ. of Edinburgh, Phone : (+44)(0)131-650 2727
80 South Bridge, room F11 Fax : (+44)(0)131-650 6516
Edinburgh EH1 1HN, Scotland, U.K. http://www.dai.ed.ac.uk/students/ion/
Cyber Surfer
In article <JIM.96Ma...@vapor.Franz.COM> j...@Franz.COM "Jim Veitch" writes:
> So if Lisp is dead, we sure don't know about it. And nor do a lot of other
> people out there. Don't let the great unwashed masses fool you.
It could appear "dead" to many people, just as Fortran does,
simply coz they don't see any apps written in it. Basic, on
the other hand, appears to be very much alive, as there are
many popular apps that are written in it.
I like ACL/Win a _lot_, but few, if any, developers will be
delivering any popular apps with it. If you could write something
as popular as Netscape in Lisp (not necessarily Common Lisp), you
might eventually change the impression most people have that Lisp
is "dead".
Dead languages are usually languages that people don't speak
anymore. Programming languages can also die, and dialects can
certainly fade to the point where it's hard to find anyone still
using them. However, to most people that language or dialect may
be dead, so it seems fair to me that they might refer to it as
"dead". Just remind them that seeming to be dead, and actually
_being_ dead are very different.
Imagine some villages in a remote part of the world, where they
have their own language. There are only a few thousand people in
these villages, so even if their numbers are not diminishing, the
perception of them by the rest of the world will be that their
language is dying.
My argument for claiming that Lisp is still alive is to point
out that Microsoft don't use dead languages, but they _do_ use
Lisp, or some programmers at MS have used it. The Lisp was
ACL/Win, BTW, running on an NT machine. (Perhaps that makes them
atypical developers? Possibly.) They didn't use it to deliver
an app, in Lisp. They used it to write some C++ code for an
animated user interface, as the Lisp code was too slow (or big?
I can't remember) to deliver as part of the UI itself. Check
the ACM website for details.
It's not a strong argument, but it's there. Just don't expect
it to be very effective against the marketing/advertising
propaganda for C++. Put as much money behind ACL/Win 3.0 as MS
have with VC++ 1.x and 4.x, and you _might_ alter the perception
of Lisp, just a little. It's also possible that most programmers
would just think you're crazy.
I recently found an advert for Amzi! Prolog (possibly another
"dead" language) in a magazine for Windows developers, Windows
Tech Journal. It was near the back, and very small. 6cm x 8cm.
Adverts for tools like C++ compilers in the same mag can often
be two whole pages! MS don't advertise in that mag, which might
give you an advantage if you wanted to tell a fair number of
programmers that ACL/Win exists, and that the language it
implements isn't dead. If you're not bothered about selling
ACL/Win to the kind of developers who read this mag, that may
explain why so many people think Lisp is dead. Perhaps it is.
Amzi! Prolog at least lets you integrate your Prolog code with
your C++/VB code, without requiring you to put the C++/VB code
into a DLL. That's a very powerful feature. Some people will
prefer to keep the main part of the app, like the UI, under the
control of their existing tools. Amzi! understand this, but I'm
not sure that any Lisp vendor does, at least for Windows.
How many people use ACL/Win? Several thousand? How many might
use it if you advertised it in a magazine read by mainstream
developers? I don't know, partly coz I'm not sure that ACL/Win
offers them a realistic delivery system. Statically linking
the runtime system (in the .IMG file) is not good enough for
most programmers, which is perhaps why Apple decided to support
class sealing in Dylan. Could Common Lisp support that? I dunno,
but I suggest that you try. If you succeeded, then you might
win a few more developers to your side. If you fail, then C++
will keep those developers.
MS have put some very powerful marketing behind C++, selling
it as one of the two ways to develop code (VB is the other one).
If you don't bother fighting their marketing with some of your
own, on similar ground, then most programmers will just ignore
you, if they even know you exist. Just like a remote village,
whose language is spoken by fewer people than you'll find in
a moderately sized city (of "unwashed" people).
Why would MS use ACL/Win? Because they can. That's why I use it,
too. I love it, but I dispair coz there are so few programs that
it'll let me write. Perhaps that's coz I'm using the "web" version,
but I can't afford $2500 for a full version, as I'd have to pay
for it personally, nor can I justify it professionally, unless it
supports OCX and can produce a very small image (e.g. <300K) for
the entire Lisp specific code.
If you think that I'm an atypical developer, then I might agree.
For example, I'd like to use Lisp! Most programmers _don't_, and
they may have good reasons for not wanting to use it. Simply
saying that they don't understand Lisp isn't an excuse. You have
to understand what it is that they _do_ want, and more importantly
why. I've already given one reason: strong marketing for C++.
This isn't really a language issue, but perhaps cultural one.
Lisp and Smalltalk both suffer from the idea of delivering the
app in the development enviroment. That's not how most people
want their apps to run - they're not programmers. They won't
buy your software if it looks "too big". That's very subjective,
which may explain why Lisp vendors don't understand it. How many
CL system support shared libraries at runtime? I only know of
one, for SPARC machines. ACL/Win produces Win32 programs, which
run on platforms that support shared libraries (DLLs), but ACL/Win
doesn't use this handy OS feature.
Meanwhile, there are Prolog systems that have better support for
what I need to do, and they're a hell of a lot cheaper. Amzi!
Prolog and LPA's WIN-PROLOG, for example. Both of them cost about
1/3 of ACL/Win. Until I know how much DylanWorks for NT will cost,
I'll be happy to use Prolog, which seems to be free from many of
the mistakes made by the Lisp community. For example, the runtime
for Amzi! Prolog is in a 200K DLL. That's smaller than VB!
Marty Hall
In <831108...@wildcard.demon.co.uk> cyber_...@wildcard.demon.co.uk writes:
>In article <JIM.96Ma...@vapor.Franz.COM> j...@Franz.COM "Jim Veitch" writes:
>
>> So if Lisp is dead, we sure don't know about it. And nor do a lot of other
>> people out there. Don't let the great unwashed masses fool you.
>
>It could appear "dead" to many people, just as Fortran does,
I think it depends what circles you travel in. From your previous
postings, I gather you travel in PC circles, doing a particular type
of application. In the circles in which I travel, people tend to work
on large applications, and UNIX is pretty prevalent. Here, apps
written in Lisp are not uncommon. We have several military-related
simulation system in Lisp at my company (the Hopkins Applied Physics
Lab), plus lots of people hear about emacs and ICAD and AI-related
Lisp tools. And isn't AT&T using Lisp for their next generation phone
switching system (Global Broadband 2000)?
Cheers-
- Marty
(proclaim '(inline skates))
Patrick Logan
Jeff Shrager wrote:
> I'm sorry to flame all over this list, but I just have to complain
> aloud to some understanding souls or I'm going to explode!
>
> (flame 'on)[Well written flame elided.]
> (flame 'off)
Sounds to me like we need a lisp-haters-haters mail list!
Jim Veitch
> So if Lisp is dead, we sure don't know about it. And nor do a lot of other
> people out there. Don't let the great unwashed masses fool you.
It could appear "dead" to many people, just as Fortran does,
simply coz they don't see any apps written in it. Basic, on
the other hand, appears to be very much alive, as there are
many popular apps that are written in it.
I like ACL/Win a _lot_, but few, if any, developers will be
delivering any popular apps with it. If you could write something
as popular as Netscape in Lisp (not necessarily Common Lisp), you
might eventually change the impression most people have that Lisp
is "dead".
Lots of people are delivering apps. Maybe a 1000 here or 1000 there
doesn't qualify as "popular." Now let's see: Cadence sells a many
hundreds of millions of $$$ per year with an embedded Lisp (SKIL).
Autodesk does the same. And so does Interleaf (only $100 million or so,
though). Not to speak of Gnu Emacs. Or the other Lisp vendors.
Imagine some villages in a remote part of the world, where they
have their own language. There are only a few thousand people in
these villages, so even if their numbers are not diminishing, the
perception of them by the rest of the world will be that their
language is dying.
Our job is to correct that impression.
My argument for claiming that Lisp is still alive is to point
out that Microsoft don't use dead languages, but they _do_ use
Lisp, or some programmers at MS have used it. The Lisp was
ACL/Win, BTW, running on an NT machine. (Perhaps that makes them
atypical developers? Possibly.) They didn't use it to deliver
an app, in Lisp. They used it to write some C++ code for an
animated user interface, as the Lisp code was too slow (or big?
I can't remember) to deliver as part of the UI itself. Check
the ACM website for details.
Fine. Lisp is very good for writing special purpose embedded compilers.
A very fair and reasonable use for it!
It's not a strong argument, but it's there. Just don't expect
it to be very effective against the marketing/advertising
propaganda for C++. Put as much money behind ACL/Win 3.0 as MS
have with VC++ 1.x and 4.x, and you _might_ alter the perception
of Lisp, just a little. It's also possible that most programmers
would just think you're crazy.
I happen to agree that competing against C/C++ is not the right answer
(see below).
This isn't really a language issue, but perhaps cultural one.
Lisp and Smalltalk both suffer from the idea of delivering the
app in the development enviroment. That's not how most people
want their apps to run - they're not programmers. They won't
buy your software if it looks "too big". That's very subjective,
which may explain why Lisp vendors don't understand it. How many
CL system support shared libraries at runtime? I only know of
one, for SPARC machines. ACL/Win produces Win32 programs, which
run on platforms that support shared libraries (DLLs), but ACL/Win
doesn't use this handy OS feature.
Allegro CL for UNIX supports shared libraries. ACL/Win will also in
the future. As for too big: the right tool for the right job. We don't
want to compete with C/C++, it does too good a job at what it is good
for! But Lisp is good for other things. In particular, it is very
good for dynamic, runtime configuration and adaptation -- things close
to impossible in C/C++ (unless... you build a runtime kernel!).
That's what some customers are doing: they are using it as a secret weapon
to grow multi-million dollar companies or internally save millions of
dollars. Go read our Web page!
Fortunately, things like VB and Java are blazing the way for popularizing
runtime engines, so we don't have to do it all on our own.
Now you are completely right: smaller is better! But in the meantime
we are doing things like figuring out how to integrate with OCX, to support
CORBA, to improve integration with C++, etc.
Meanwhile, there are Prolog systems that have better support for
what I need to do, and they're a hell of a lot cheaper. Amzi!
Prolog and LPA's WIN-PROLOG, for example. Both of them cost about
1/3 of ACL/Win. Until I know how much DylanWorks for NT will cost,
I'll be happy to use Prolog, which seems to be free from many of
the mistakes made by the Lisp community. For example, the runtime
for Amzi! Prolog is in a 200K DLL. That's smaller than VB!
Fine. Prolog is good for inferencing. Use it! Right tool for the
right job.
Thanks for your input,
Jim Veitch
http://www.franz.com
Cyber Surfer
In article <JIM.96Ma...@vapor.Franz.COM> j...@Franz.COM "Jim Veitch" writes:
> I like ACL/Win a _lot_, but few, if any, developers will be
> delivering any popular apps with it. If you could write something
> as popular as Netscape in Lisp (not necessarily Common Lisp), you
> might eventually change the impression most people have that Lisp
> is "dead".
>
> Lots of people are delivering apps. Maybe a 1000 here or 1000 there
> doesn't qualify as "popular." Now let's see: Cadence sells a many
> hundreds of millions of $$$ per year with an embedded Lisp (SKIL).
> Autodesk does the same. And so does Interleaf (only $100 million or so,
> though). Not to speak of Gnu Emacs. Or the other Lisp vendors.
Any _popular_ apps? My point is that the apps developed with
Lisp systems, like ACL/Win, will be irrelevant to most people.
Now, they may be irrelevant to you, also, but that may explain
why so many people see Lisp as dead.
> Imagine some villages in a remote part of the world, where they
> have their own language. There are only a few thousand people in
> these villages, so even if their numbers are not diminishing, the
> perception of them by the rest of the world will be that their
> language is dying.
>
> Our job is to correct that impression.
Agreed. I just don't think you're succeeding. I'm not sure that
you're _likely_ to succeed, with languages like C++ are being
pushed so heavily - and the apps developed in them.
Consider this: the favourite language of Bill Gates is Basic.
While Basic has been around for almost as long as Lisp, as far
as I know, it has adapted rather better to the needs of the
developers who write code for the mass markets. The result is
that Basic (well, VB) is perceived as being relevant to Windows
developers. Apps written in VB can be very easily found.
I know, I'd rather write in CL than in Basic, esp if the Basic
is VB. So far I've managed to avoid VB, but only by using VC++
instead. If MS had a CL system, perhaps called VCL, I might be
able to justify using it, as it would have the marketting support
of MS behind it. VB programmers have no trouble justifying it,
so it gets used by a very large number of them.
This has the effect of creating the impression that Basic is
still alive and well, even amoung people who detest Basic.
> Fine. Lisp is very good for writing special purpose embedded compilers.
> A very fair and reasonable use for it!
Yes, and one that is perceived as irrelevant by most developers.
Sad but true. They won't understand why such a compiler might be
needed, even if we do.
> Allegro CL for UNIX supports shared libraries. ACL/Win will also in
> the future. As for too big: the right tool for the right job. We don't
> want to compete with C/C++, it does too good a job at what it is good
> for! But Lisp is good for other things. In particular, it is very
> good for dynamic, runtime configuration and adaptation -- things close
> to impossible in C/C++ (unless... you build a runtime kernel!).
My point is that if the tool delivers an app that is too big,
then it'll limit the number of developers who'll use it. Size
_is_ relevant, as disk space is still finite. So is RAM size.
You might not be concerned about these issues, but many people
are, and that may be why they don't use Lisp.
> That's what some customers are doing: they are using it as a secret weapon
> to grow multi-million dollar companies or internally save millions of
> dollars. Go read our Web page!
I know. Some customers, yes. Most potential customers, no. You
have a development system that targets developes of vertical
market apps. Fine, but that won't help tell most people that
Lisp is still alive and well. Lisp has a very low profile, while
languages like VB and C++ have an _exceptionally_ high profile.
All I'm saying is that be why most people think that Lisp is dead.
> Fortunately, things like VB and Java are blazing the way for popularizing
> runtime engines, so we don't have to do it all on our own.
Will you be competing with VB and Java? How many VB and Java
developers think of Lisp as a viable alternative to what they're
currently using? Damn few, I bet. I'm one of the exceptions.
> Now you are completely right: smaller is better! But in the meantime
> we are doing things like figuring out how to integrate with OCX, to support
> CORBA, to improve integration with C++, etc.
Excellent. Support for OCX, ODBC, etc will be a great help to
making ACL/Win more attractive to Windows developers. Runtime
support in a DLL, instead of in the app image, will also help.
On the other hand, if you're a Lisp developer and just happen
to be using Windows as the platform on which you write the code,
then all of this may be irrelevant. I don't know many, if any,
developers like that. All the people I work with develop for
Windows, and it's a lot easie to find work developing for Windows.
> Fine. Prolog is good for inferencing. Use it! Right tool for the
> right job.
I'll use it for a lot more than just inferencing. ;-) Just like
I use Lisp for more than creating functional closures or list
processing. If I use Prolog professionally, it'll be because
I've succeeded in convincing my boss that something he wants me
to write can be done better in Prolog than in C++. However, I
don't expect that to be easy, but it might be easier than trying
to convince him that I should use Lisp. <sigh>
Cyber Surfer
In article <DqtzB...@aplcenmp.apl.jhu.edu>
ha...@aplcenmp.apl.jhu.edu "Marty Hall" writes:
> I think it depends what circles you travel in. From your previous
> postings, I gather you travel in PC circles, doing a particular type
> of application. In the circles in which I travel, people tend to work
> on large applications, and UNIX is pretty prevalent. Here, apps
> written in Lisp are not uncommon. We have several military-related
> simulation system in Lisp at my company (the Hopkins Applied Physics
> Lab), plus lots of people hear about emacs and ICAD and AI-related
> Lisp tools. And isn't AT&T using Lisp for their next generation phone
> switching system (Global Broadband 2000)?
I wouldn't know about that, as the only Unix machines I use are
web servers. I don't doubt that there are more Lisp programmers
using Unix than, let's say, NT. So, I can't really comment on what
Unix programmers might think is a dead language. I _can_ comment
on what DOS and Windows programmers think, and if it isn't C, Basic
or Pascal, most of them will not have used it.
It's great that AT&T and Microsoft are using Lisp, but who knows about
it? I'll bet it's just people like us, and mainly because we have an
interest in Lisp. If I'd have to work for AT&T or at Microsoft Research
in order to use Lisp professionally, then perhaps Lisp is no longer
relevant to me, and I should consider an alternative, like Dylan. That's
the message I'm getting.
Vijayaraghavan Raman
The problem - LISP has never been presented
as a mainstream development tool for conventional applications.
If you want Expert Systems, then maybe(then maybe not- you should use
Prolog or an Expert System VBX)
When the explanation goes "Well, LISP is for this, not that zzz" one
does wonder if we are not better off without it.
The cost has been high and few individuals (as remarked by
Cyber_surfer) can afford the system. It is not amenable to
becoming the grassroots phenomenon that nowadays guarantees both
trained professionals,thousands of third party addons and
great energy(look at Visual Basic).
Then there is this vision amongst LISP vendors that
the great technical merit of a language will have
everyone running to purchase it from them. This often
shows in the way they communicate with prospective clients.
Since AT&T has been mentioned...
Several months ago..
I was in a position to present to certain Executives and
Technology groups within AT&T LISP (possibly ACL/Win) for several of
their large applications and their Enterprise Foundation Architecture.
Knowledge of LISP was almost nonexistent. Amongst the issues of
concern was technical support, longevity of the vendor etc. etc.Zzzz.
My email enquiry to a LISP vendor drew no response for months.
Needless to say, I very quickly began to see how beautiful and full
featured Visual Basic was for everything.
Go to the AT&T home page, search their documents with "LISP, ACL "
etc and you will find the "presence" claimed for LISP.
Cyber Surfer
In article <4mh807$d...@dfw-ixnews1.ix.netcom.com>
vjr...@ix.netcom.com(Vijayaraghavan "Vijayaraghavan Raman " writes:
> The problem - LISP has never been presented
> as a mainstream development tool for conventional applications.
> If you want Expert Systems, then maybe(then maybe not- you should use
> Prolog or an Expert System VBX)
I wouldn't call Lisp a mainstream language. It's a elitist's language.
That's another reason for simplay saying, 'I use it coz I can'. How
can you justify something that so few people can use? Well, you can
justify _your_ use of it if you _can_ use it. I know it's obvious to
us, but it ain't so obvious to the masses.
Someone like Gates can say, 'Let developers eat VB/VC++', but I doubt
he's an elistist. If he were, well, we might see a system called VCL,
Visual Common Lisp. It would probably cost something like $299 and
work very differently to most CL systems. Perhaps more like...Dylan.
> When the explanation goes "Well, LISP is for this, not that zzz" one
> does wonder if we are not better off without it.
How true. Why does everyone want their Lisp enviroment to be like a
Lisp Machine? That's great if you _could_ use such a machine, and
expect your users to use one, too. Most of us can't be that arrogant.
Clients tell us what _they_ want.
> The cost has been high and few individuals (as remarked by
> Cyber_surfer) can afford the system. It is not amenable to
> becoming the grassroots phenomenon that nowadays guarantees both
> trained professionals,thousands of third party addons and
> great energy(look at Visual Basic).
And look at Perl. It's been heavily pushed until it has become a
popular tool. Just like VB, but without the money behind it. All Perl
needed was a few fanitical users and UseNet. Perl is also _small_.
It doesn't need to be "good". It only needs to be there.
> Then there is this vision amongst LISP vendors that
> the great technical merit of a language will have
> everyone running to purchase it from them. This often
> shows in the way they communicate with prospective clients.
Um, can I say Perl again? <slap> Oh, ok. I'll not mention it again,
at least for a while...
ozan s. yigit
Jeff Shrager:
[leading flame elided]
Well, I must say that Perl is probably the worst travesty of a
programming language I have *ever* seen in my entire life!
[trailing flame elided]
ok, so that is your reaction. now, if you can just make that into
a well reasoned argument [in the style of, say "why pascal is not
my favorite language" by kernighan] and distribute it and publish
it, we can all learn what you appear to already know in your guts.
"aaaaghhh! bogghgh... (cough)" is not good enough. :]
oz
---
the unaided eye does not see very far | electric: o...@nexus.yorku.ca
or deep. -- Ian Hacking
Francis Leboutte
ha...@aplcenmp.apl.jhu.edu (Marty Hall) wrote:
>I think it depends what circles you travel in. From your previous
>postings, I gather you travel in PC circles, doing a particular type
>of application. In the circles in which I travel, people tend to work
>on large applications, and UNIX is pretty prevalent. Here, apps
>written in Lisp are not uncommon. We have several military-related
>simulation system in Lisp at my company (the Hopkins Applied Physics
>Lab), plus lots of people hear about emacs and ICAD and AI-related
>Lisp tools. And isn't AT&T using Lisp for their next generation phone
>switching system (Global Broadband 2000)?
>
>Cheers-
> - Marty
>(proclaim '(inline skates))
><http://www.apl.jhu.edu/~hall/lisp.html>
Gensym with its Lisp based tool named G2 has recently reported a quarterly
revenue growth of $7 million. G2 is a real-time KBS tool and the leader in
this market since many years. Not so bad for a supposed dead language.
About my PC circles: I have participated in the development of 2 products
written in Lisp (ACL4W). The first one is an application for planning
refueling operations in nuclear plants. The second one is a tool for the
design and planning of electrical networks.
Francis
--
Francis Leboutte Algorithme, Rue de la Charrette 141
lebo...@mail.interpac.be 4130 Tilff, Belgium
T&FAX: 32-(0)41-883528
Richard A. O'Keefe
Cyber Surfer <cyber_...@wildcard.demon.co.uk> writes:
>And look at Perl. It's been heavily pushed until it has become a
>popular tool. Just like VB, but without the money behind it. All Perl
>needed was a few fanitical users and UseNet. Perl is also _small_.
>It doesn't need to be "good". It only needs to be there.
You can impute many virtues to Perl, but by no stretch of the imagination
can it be called "small". I've studied the Perl5 docs, and they are
bigger than _any_ Lisp manual I've ever used before CLtL2.
I too think that Perl is a lousy _language_, but nobody ever switched
to Perl because of its virtues as a _language_. The virtues of Perl
are virtues as a _tool_; simple access to UNIX data and operations,
simple support for sockets and external hash tables and ...
There's nothing in Perl that Lisp couldn't have if we wanted it to.
The 'scsh' people have been adding that kind of stuff to their Scheme.
Cyber Surfer
In article <318d6073...@news.interpac.be>
lebo...@mail.interpac.be "Francis Leboutte" writes:
> Gensym with its Lisp based tool named G2 has recently reported a quarterly
> revenue growth of $7 million. G2 is a real-time KBS tool and the leader in
> this market since many years. Not so bad for a supposed dead language.
How many people know about this? It sounds like a vertical market app,
which would mean that very few people will know about it, never mind
care. It's not going to convince many people that Lisp is 'alive'.
Remember my example of a language spoken by a few remote villages?
The language may be alive, but so what? Most people will consider it
irrelevant. A bit like Latin. So what if it still has some remote
relevance today? I doubt that many people will even recognise a word
derived from Latin, and not worry about it. Lisp seems to have a
similar status amoung programming languages.
> About my PC circles: I have participated in the development of 2 products
> written in Lisp (ACL4W). The first one is an application for planning
> refueling operations in nuclear plants. The second one is a tool for the
> design and planning of electrical networks.
More vertical apps. I'm not claiming that Lisp is dead. What I'm saying
is that Common Lisp systems are not relevant to the developers of mass
software. You're simply saying, "I write vertical apps, and ACL is
perfect". So it is. That won't change the way that Lisp is seen by
developers who've never touched Lisp, and who _can't afford to_. By
selling Lisp as an elitist develop tool, you're excluding it from the
options available to most developers. Why be suprised if they think
that Lisp is dead? As far as they're concerned it, perhaps it is.
If you want to sell the idea that Lisp is still alive, you have to
show developers why _they_ need it, not why you need it. Nobody cares
what you think, in this tough competitive world. That's why C++ is
where it is today, and Lisp is...well. Perhaps a modern Lisp isn't
called Lisp, but Dylan. Take a good long look at what Dylan offers,
as a language.
When DylanWorks becomes available, if the price is cheaper than ACL,
then I'll be far more likely to buy it than ACL, and I doubt I'll be
the only one. That has nothing to do with my own preferences, which
might be for a very different syntax. However, the semantics of Dylan
are far closer to what I can use than Common Lisp's. Most developers
don't need to define classes at run time, and many of them won't even
won't to. They won't want functions like EVAL or COMPILE, either.
Good luck with your apps for vertical markets. You've probably got
the perfect tool for developing them. Meanwhile, back in the grubby
world of mass markets, developers like myself struggle with C++,
even when we wouldn't choose that language. The choice is made for
us, by the people who design languages and develop and then sell
the implementations of them. People like Microsoft and Franz.
Mainly MS, coz of their agressive marketting, but companies like
Franz also play a (smaller) part, by concentrating on devlopers
like yourself and ignoring the mass market dominated by...MS.
That's wonderful, unless you happen to want to use a better tool
than C++ to develop mass market apps. BTW, if you're developing
for vertical markets, you might be saying, "I'm out of touch with
the needs of most developers". I'm no expert, but I've not noticed
MS worrying too much about vertical markets. I guess that such
markets take care of themselves without any help from MS.
Cyber Surfer
In article <4mkq7n$o...@goanna.cs.rmit.edu.au>
o...@goanna.cs.rmit.edu.au "Richard A. O'Keefe" writes:
> You can impute many virtues to Perl, but by no stretch of the imagination
> can it be called "small". I've studied the Perl5 docs, and they are
> bigger than _any_ Lisp manual I've ever used before CLtL2.
I was refering to the runtime. The docs for the Win32 API are now
only available on CD-ROM. MSDN subscribers get, amoung other things,
the Development Library, which is another CD-ROM of docs, articles,
source code etc.
> I too think that Perl is a lousy _language_, but nobody ever switched
> to Perl because of its virtues as a _language_. The virtues of Perl
> are virtues as a _tool_; simple access to UNIX data and operations,
> simple support for sockets and external hash tables and ...
I agree. It's not just useful for Unix users, either. I'm using it for
NT, and I'm told that there's a web server for Netware that includes a
Perl interpreter.
> There's nothing in Perl that Lisp couldn't have if we wanted it to.
> The 'scsh' people have been adding that kind of stuff to their Scheme.
Err, scsh requires 20 MB of RAM. Nobody who doesn't use Unix is
going to accept overheads like that. It's fine if you have 128 MB
of RAM, but most Windows developers will have 32 MB - or less.
Just enough memory for ACL/Win 3.0 or VC++ 4.x.
I'm _not_ claiming that Lisp is inferior to Perl/VB/C++ etc. I'm
simply _observing_ that most Windows developers won't even know
ACL/Win exists, never mind choose it instead of one of the more
mainstream languages. If you're really suggesting that Lisp can
be used to develop popular Windows apps, then please tell me which
Lisp you're talking about so I buy it. If I can use it, then I can
tell other Windows developers that they can, too. I'd love to be
able to do that, instead of getting those blank looks that mean
someone thinks I'm crazy to use Lisp.
If you're only concerned with Unix development, then it's simple.
You only have to convince Unix developers that Lisp is a viable option.
That might be a lot easier than convincing Windows developers, since
Bill Gates has very little interest in Unix, other than replacing it
with NT.
Martin Cracauer
vjr...@ix.netcom.com(Vijayaraghavan Raman ) writes:
>My email enquiry to a LISP vendor drew no response for months.
All I can say is that Harlequin and Franz answer my emails with no
problems, no matter whether I am already a customer (Harlequin) or
just an interested person (Franz).
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <crac...@wavehh.hanse.de> - BSD User Group Hamburg
BSD, Lisp and other programming info http://www.bik-gmbh.de/~cracauer
ozan s. yigit
Jim Veitch [amongst other things]:
...
Fortunately, things like VB and Java are blazing the way for popularizing
runtime engines, so we don't have to do it all on our own.
but also developing a whole generation of programmers who are familiar
and confortable with languages which are nothing like lisp. this is a
significant disadvantage for the future utility of the language.
oz
Will Ware
I've been watching this thread progress for a couple of weeks now. My
background is that I studied Lisp for a short time in college, then
started working as a hardware engineer so I didn't see it again for about
15 years. In the last ten years, I've been doing increasing amounts of C
programming. Now I'm rediscovering Lisp thanks to CLISP running on my
Linux box. I'm delighted with the progress that Lisp has made in that
time, and I'd love to see Lisp gain popularity. There's probably a lot of
great software that isn't being written because people don't know Lisp,
and think they should avoid it for one reason or another.
It would certainly help if Lisp was getting the kind of financial backing
that Java and C++ are enjoying, but that doesn't seem to be in the cards.
Looking at the gradual ascension of Linux, I wonder if there isn't
something that could be done at a grassroots level. One place to start is
to look at what are widely (but not accurately) perceived as shortcomings
of Lisp.
(1) The idea that Lisp is hard or obscure or confusing. These days I write
C for work and Lisp for fun, and the Lisp is easier to read and write. I
haven't invested lots of hours, and there was no traumatic learning curve.
I had to learn some new stuff about Common Lisp, but no big deal. If Lisp
is obscure, it's only because it isn't widely known.
(2) The idea that Lisp is memory-greedy and slow. I've used CLISP on a DOS
machine with 4 megs of RAM, and I didn't have any memory or performance
problems. I didn't try to consciously benchmark it against an equivalent C
program, but I wasn't bothered by slowness. I've read that if one does
invest a lot of time, one eventually learns to write Lisp code that runs
about as fast as C, and some day I'd like to do that.
(3) The idea that Lisp is incomplete as a language, and lacks features
required to get real work done. This might have been a valid complaint
once, but not with all the stuff that's new in Common Lisp, e.g. access to
the file system.
Something that might help would be if there were more tutorial material
around for Lisp. Web pages would be particularly good for this. The web
pages I've seen on Lisp are mostly resource lists (some very good ones,
but not tutorials). I've found Paul Graham's books really useful myself,
and if there were web pages like that, it would be great. I also found
that CLISP came with a useful file called LISP-tutorial.txt.
Big splashy apps like Emacs and Autocad definitely have their place in
keeping Lisp alive, but to somebody new to Lisp, huge things like that are
probably intimidating. A large number of smaller, simpler apps might do
more to win peoples' affection. One simple project I did when I was
getting started with CLISP was to replace the spreadsheet I used to
compute my monthly finances with a Lisp program.
--
-------------------------------------------------------------
Will Ware <ww...@world.std.com> web <http://world.std.com/~wware/>
PGP fingerprint 45A8 722C D149 10CC F0CF 48FB 93BF 7289
Erik Naggum
[Cyber Surfer]
| How many people know about this? It sounds like a vertical market app,
| which would mean that very few people will know about it, never mind
| care. It's not going to convince many people that Lisp is 'alive'.
there appears to be an interminable stream of excuses for not seeing that
Lisp is alive, so I assume that _nothing_ will convince people to the
contrary if they think Lisp is dead. why bother with people who are
impervious to facts and absord hype with a passion?
--
natural born Lisper
Crispin Miller
Ion Androutsopoulos (i...@aisb.ed.ac.uk) wrote:
: In article <jmrst32-2904...@ehdup-n-5.rmt.net.pitt.edu>
: jmr...@pop.pitt.edu (Jim Rankin) writes:
I have just spent the last year doing work on the relationship between
Categorial Grammars and Conceptual Graphs, using an OO language for
implementation. Both CatGrams, and ConGraphs are
compositional - you can see them as sticking objects together - and
seem particularly suited to an OO representation.
I have been using a new functional, OO programming language - UFO
(United Functions and Objects), which has been developed in my
department, and have found it particularly well suited to the task.
The functional bias towards values means that no time is wasted
messing around with low level stuff like pointers, whilst the OO
stuff allows Conceptual Graphs and Categorial Grammars to be
implemented really quite nicely.
My own experience is that the OO ideas are great - especially for
researchy type stuff - as long as the low-level implementational
crud doesn't get in the way. THis is a fair criticism of C++ or Java
as a development language, but not of OO techniques in general.
Finally, encapsulation lets you develop 'quick and dirty' bits of code
to test ideas, which can be ripped out and thrown away when they don't
work. This used to be called hacking, but I think the correct term now
is 'incremental development'.
That's the good side, on the bad side:
Inheritance is a central theme to AI, and a language with its own
internal constructs to support it would appear to be useful, but:
i) It seems to me that most serious AI stuff needs multiple
inheritance. IF the language doesn't support this, then you end up
implementing it yourself.
ii) If new objects need to be created dynamically at run time you're
pretty much stuck - since the inheritance stuff is sorted out at
compile time.
Crispin
Vijayaraghavan Raman
XX
>** ha...@aplcenmp.apl.jhu.edu (Marty Hall) wrote:
>
>I think it depends what circles you travel in. From your previous
>postings, I gather you travel in PC circles, doing a particular type
>of application. In the circles in which I travel, people tend to work
>on large applications, and UNIX is pretty prevalent. Here, apps
>written in Lisp are not uncommon. We have several military-related
>simulation system in Lisp at my company (the Hopkins Applied Physics
>Lab), plus lots of people hear about emacs and ICAD and AI-related
>Lisp tools. And isn't AT&T using Lisp for their next generation phone
>switching system (Global Broadband 2000)?
?Can we then safely conclude that one is either running in
small circles building large applications or large circles
building small ones.
Perhaps in the large circles one has to deliver good and usable
systems to numerous users using the rearside of technology.
?What is the cost and value of of technology outside of a
"wide" social context.
XX
>** vjr...@ix.netcom.com(Vijayaraghavan Raman ) writes:
>
>My email enquiry to a LISP vendor drew no response for months.
>
>** Martin Cracauer <crac...@wavehh.hanse.de> - BSD User Group
Hamburg replies
>
>All I can say is that Harlequin and Franz answer my emails with no
>problems, no matter whether I am already a customer (Harlequin) or
>just an interested person (Franz).
Well, yours had all the right number of consonants,vowels and keywords.
The circle of my experience has shaped my impression
of accessibility, support, resources and tools, setting
my anticipation level rather high.
The theme is simply - often it is strenuous promoting a wonderfool
tool which has few users, high cost and questionable support
/longevity.
XX
>**Jim Veitch [amongst other things]:
> ...
> Fortunately, things like VB and Java are blazing the way for
> popularizing runtime engines, so we don't have to do it all on
> our own.
>
>** oz
>but also developing a whole generation of programmers who are familiar
>and confortable with languages which are nothing like lisp. this is a
>significant disadvantage for the future utility of the language.
>
>
Words of wisdom.
The truth is that both Java and VB have been developed and promoted
by people with a broader understanding and better social skills.
!There are signs that these are emerging in the LISP community.
ACL4*Windows* is such an encouraging sign that would benefit by
being more "inclusive."
Peter Ludemann
In article <JIM.96Ma...@vapor.Franz.COM> j...@Franz.COM (Jim Veitch) writes:
[snip]
> Fine. Lisp is very good for writing special purpose embedded compilers.
> A very fair and reasonable use for it!
[snip]
> Fine. Prolog is good for inferencing. Use it! Right tool for the
> right job.
If you're in the business of correcting mistaken impressions, please
don't create others. Prolog is great for writing special purpose
compilers (using DCGs et al) ... and that has very little to do with
inferencing, unless you think that writing compilers is an AI-ish
thing. [Prolog is good for lots of other things which don't have much
to do with inferencing either.]
Prolog's built-in inferencing is fast but stupid. If you want to do
AI-style inferencing, there are systems implemented in Prolog to do
that (just as there are systems implemented in Lisp; although the
Lisp-ers need to write a bit of code to provide what Prolog already
has, namely logical variables).
--
Peter Ludemann lude...@expernet.com, plud...@gigasd.com
ExperNet phone: +1.408.327.4339
Systems Architect fax: +1.408.492.1920
KNS Project Leader 3945 Freedom Circle,
http://www.expernet.com Suite 240, Santa Clara CA 95054
William Barnett-Lewis
In article <831197...@wildcard.demon.co.uk>, Cyber Surfer <cyber_...@wildcard.demon.co.uk> says:
>
>In article <JIM.96Ma...@vapor.Franz.COM> j...@Franz.COM "Jim Veitch" writes:
>
>> I like ACL/Win a _lot_, but few, if any, developers will be
>> delivering any popular apps with it. If you could write something
>> as popular as Netscape in Lisp (not necessarily Common Lisp), you
>> might eventually change the impression most people have that Lisp
>> is "dead".
>>
>> Lots of people are delivering apps. Maybe a 1000 here or 1000 there
>> doesn't qualify as "popular." Now let's see: Cadence sells a many
>> hundreds of millions of $$$ per year with an embedded Lisp (SKIL).
>> Autodesk does the same. And so does Interleaf (only $100 million or so,
>> though). Not to speak of Gnu Emacs. Or the other Lisp vendors.
I've been doing the programming thing for about 16 years now. Lisp is my
favorite language because, more than anything else, it's fun. OTOH, I do
all my "real" programming in VB. Many of us PC types live in a Messysoft
world and if it don't have 'Visual' in front of it, our managers won't
pop the $$$ for it. Franz has a nice start on a package in ACL/Win 3,
but from this perspective, only a start.
>Any _popular_ apps? My point is that the apps developed with
>Lisp systems, like ACL/Win, will be irrelevant to most people.
>Now, they may be irrelevant to you, also, but that may explain
>why so many people see Lisp as dead.
>
>Consider this: the favourite language of Bill Gates is Basic.
>While Basic has been around for almost as long as Lisp, as far
>as I know, it has adapted rather better to the needs of the
^^^^^^^
>developers who write code for the mass markets. The result is
>that Basic (well, VB) is perceived as being relevant to Windows
>developers. Apps written in VB can be very easily found.
>
>I know, I'd rather write in CL than in Basic, esp if the Basic
>is VB.
Like too many people, I got started on those hideous little ROM basics
that all the 8 bitters came with. Compared to those, VB is like
another language. This is the _perception_. Likewise is the
idea many folks have that Lisp hasn't changed since the eary '80s
and the LispM's. Until these perceptions are changed, Lisp will
remain what it is today - a niche product that survives where it should
be flourishing.
>> Allegro CL for UNIX supports shared libraries. ACL/Win will also in
>> the future. As for too big: the right tool for the right job. We don't
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> want to compete with C/C++, it does too good a job at what it is good
>> for! But Lisp is good for other things. In particular, it is very
>> good for dynamic, runtime configuration and adaptation -- things close
>> to impossible in C/C++ (unless... you build a runtime kernel!).
(big snip)
>> Now you are completely right: smaller is better! But in the meantime
>> we are doing things like figuring out how to integrate with OCX, to support
>> CORBA, to improve integration with C++, etc.
These are all things that _have_ to be done if you want any real
penitration of the PC market. For my bosses to even begin to consider
Lisp as a possible developement tool, it Must support OCX controls,
ODBC, talk to the network, and not (effectivly) require a CDROM to
distribute the finished product. As the IS manager for a small state
government agency, I live in a world where my bosses in the Department
of Administration see all problems as nails, hence I can only buy a
hammer. Right now, because ACL/Win doesn't do what _they percieve_
Visual Basic as being able to do, that hammer is VB. I don't much like
it, but I really like the $$$ that goes into my bank every two weeks
for tolerating it. "Right tool for the right job" - Well, it'd really be
nice if it worked that way, but Uncle Bill has taken that option away
from many of us.
In the '80s the partisans of the Lisp Machines had to come to grips
with that nasty little kludge called Unix. In the end, the machines
were gone and workstation based versions of their products could run rings
around the specialized hardware. In the '90s you're facing the same
challenge with Cutler's VMSjr and if products that reflect that don't
start coming out Real Soon Now, it'll make the AI winter look like the
AI spring. All that'll be left is a few of us children and our favorite
toys. And that will be just too bad. Couple of years ago, I bought a
student copy of Medley. Makes a PC into a real nice clone of an 1186.
Faster even! Doesn't do much else though. Now I can;t even get the phone
answered to find out if they ever fixed a bug I reported back when
I got it. I'll probably not risk the $$$ for a full version of ACL/Win
anytime soon as a result of that. Franz may well be around, but the way
things are going, I can't be sure. Please prove me wrong....
William A. Barnett-Lewis
Information Systems Manager
Wisconsin State Board of Elections
wle...@mailbag.com
Paul Fuqua
In article <831306...@wildcard.demon.co.uk> Cyber Surfer <cyber_...@wildcard.demon.co.uk> writes:
> How true. Why does everyone want their Lisp enviroment to be like a
> Lisp Machine?
Let's see: bitmapped screen, window system, integrated editor and
compiler and debugger and interpreter, transparent networking. Can't
imagine why that would be popular.
To be honest, it's a terrible delivery environment, because it's hard to
strip out the parts you don't need, but it's one hell of a development
environment. The concepts survive not only in commercial Lisps like
Allegro and Harlequin, but in emacs' compile-mode.
(I'm not just a lispm user, I'm a former lispm developer, so my biases
are showing.)
> Perl is also _small_.
> It doesn't need to be "good". It only needs to be there.
It's a good tool, but a terrible language. It puts a bunch of useful
sysadmin features in a form that's a lot easier than the combination of
tools that were used before, and thereby fills a need.
Tools for jobs. Lisp is a perfectly good tool for lots of things, but
suffers more than any other language from preconceptions and prejudice.
From my quotes file:
"Would you go over to Computer City and ask what language Microsoft
Word is written in? If they said ALGOL 60, would you buy something
else instead?" - Clint Hyde
Paul Fuqua
Texas Instruments, Dallas, Texas p...@hc.ti.com
Mark Pedersen
>My own experience is that the OO ideas are great - especially for
>researchy type stuff - as long as the low-level implementational
>crud doesn't get in the way. THis is a fair criticism of C++ or Java
>as a development language, but not of OO techniques in general.
>Finally, encapsulation lets you develop 'quick and dirty' bits of code
>to test ideas, which can be ripped out and thrown away when they don't
>work. This used to be called hacking, but I think the correct term now
>is 'incremental development'.
;-)
I spent a couple of years programming C++, and I found that using OO did
remarkable things to the integrity of the algorithms I wrote. When it
came to testing some fairly complex tree manipulations, all cases were
covered by the basic algorithm - no exceptions had to be made, because
each object covered its own "exceptions". I feel this elegance leaves
you to concentrate on the "research" more than the programming - the
grunginess of C++ notwithstanding.
>That's the good side, on the bad side:
>ii) If new objects need to be created dynamically at run time you're
>pretty much stuck - since the inheritance stuff is sorted out at
>compile time.
I believe Smalltalk gives dynamic creation, but I don't know if it's
suitable to NLP in any other respect.
I'm actually considering what implementation language I'll use for an
NLP research project I'm working on now. As always, unification is
essential, and support for feature structures, but I'd like to have OO
support as well, since it suits my mindset, and as I said, done right it
seems to produce good results.
There seem to be several unification-based languages that offer
inheritance/type-sorts etc., such as CUF and TFS, but they don't seem
to offer much in the way of encapsulation. Maybe encapsulation is
antithetical to declarative programming anyway, but not necessarily.
Someone has suggested that Lisp's CLOS might offer me what I'm looking
for, but they also suggested that Scheme might be nicer to use if it
supports CLOS. Any comments on using CLOS for NLP, or Scheme for that matter?
Does anyone know of any other unification-based langs that offer OO (not
*just* inheritance)??
Cheers,
Mark
--
------------------------------------------------------------------------
Mark Pedersen | email : ma...@cs.uq.oz.au,
Dept. Computer Science | http://www.cs.uq.edu.au/personal/markp/index.html
Richard A. O'Keefe
ma...@cs.uq.edu.au (Mark Pedersen) writes:
>I'm actually considering what implementation language I'll use for an
>NLP research project I'm working on now. As always, unification is
>essential, and support for feature structures, but I'd like to have OO
>support as well, since it suits my mindset, and as I said, done right it
>seems to produce good results.
LIFE.
Ask about LIFE in comp.lang.prolog.
Unification, feature structures, inheritance.
And much more besides.
>Does anyone know of any other unification-based langs that offer OO (not
>*just* inheritance)??
What _precisely_ do _you_ mean by OO here?
Unification based languages are concerned with a possibly typed,
possibly inheritance based, possibly subject to interesting
programmer-extensible equality theories, universe of timeless VALUES.
Object orientation is primarily about dividing up a mutable world
into liitle capsules each of which has its own state, history, and
behaviour. Inheritance is an entirely separate issue.
What are you doing in your NLP project that wants lots and lots of
mutating state? I don't see how that is relevant to, say, principles
and parameters parsing, or any of the work I've seen lately on lexicons.
For what it's worth, SIL are producing their fancy-dandy system for
linguists in Smalltalk.
Richard A. O'Keefe
I wrote:
You can impute many virtues to Perl, but by no stretch of the imagination
can it be called "small". I've studied the Perl5 docs, and they are
bigger than _any_ Lisp manual I've ever used before CLtL2.
Cyber Surfer <cyber_...@wildcard.demon.co.uk> writes:
>I was refering to the runtime. The docs for the Win32 API are now
>only available on CD-ROM. MSDN subscribers get, amoung other things,
>the Development Library, which is another CD-ROM of docs, articles,
>source code etc.
Ok, how big _is_ the perl runtime?
ls -lL `which perl` => 650 000 bytes (rounded). SPARC
Now, how big are some Schemes?
scm 236k SPARC
elk ~400k [*1] SPARC
stalin 1736k Highly optimising compiler SPARC
nawk 188k [*2] SPARC
tclsh 192k [*6] SPARC
MacScheme 84k Mac
Gambit 1.7.1 472k ...
Gambit 2.2.2 668k (includes debugger, window interface)
Xlisp-Stat 2.1 440k [*3] (lots of extra code for number crunching)
MatLab 350k [*4] (C-like language, lots of number crunching)
Alpha 6.12(68k) 472k [*5]
I can't find out the size of the PC Schemes (TI PC Scheme and the newer
Geneva version) because I've forgotten my PC file server password, but
TI PC Scheme ran comfortably on a 640k PC, and that included Edwin.
[*1] I have an old version of Elk configured for another machine, so
it doesn't finish building. This is an estimate.
[*2] Nawk is the UNIX tool that most resembles Perl.
[*3] XlispStat is a statistics package built on top of Xlisp; this is
an old release, but the language is roughly comparable to Scheme
and the extra goodies make a fair comparison with Perl.
[*4] MatLab is nothing like Lisp (and it's the worse for it), but it
is a language of about the same complexity as Perl, with lots of
support for a particular area (Perl: text; MatLab: numbers).
[*5] Alpha is a "programmer's editor" for the Macintosh having TCL
as its extension language.
[*6] This is the "TCL shell"; I included this to get some feel for
how much of Alpha is TCL and how much of Alpha is editing.
Programs [*3], [*4], and [*5] are also to Perl in having a large
library which is hidden from such calculations by being loaded on
need at run time.
In comparison with an optimising compiler whose end product is native code,
yes, Perl is small.
That's not because it's Perl. That's because it's not an optimising
compiler whose end product is native code.
Compare Perl with other systems processing languages of comparable
complexity, and it stops looking small. It's more than three times the
size of Nawk or TCL.
Here are some lessons for looking good in the size stakes:
(1) Split off as much as you can into autoloaded packages.
People _will_ count them when they argue "features.
They _won't_ count them when they argue "size".
(2) Don't include a good native code compiler.
This _will_ be counted as a size penalty.
This _won't_ be counted as a feature.
(3) Don't admit to your real competition in the size stakes.
>I agree. It's not just useful for Unix users, either. I'm using it for
>NT, and I'm told that there's a web server for Netware that includes a
>Perl interpreter.
There are web servers including all sorts of things, including ML.
>> There's nothing in Perl that Lisp couldn't have if we wanted it to.
>> The 'scsh' people have been adding that kind of stuff to their Scheme.
>
>Err, scsh requires 20 MB of RAM.
So what? That's irrelevant to my point.
There is nothing in Perl that Lisp couldn't have IF WE WANTED IT TO.
Interlisp-D, a much richer language than Perl, with a compiler
included, plus a ton of networking software, two Lisp editors,
a drawing editor, and a programmable WYSIWIG editor not altogether
unlike Alpha, ran *happily* on a machine with 32Mb _max_ virtual
memory, and 4Mb _max_ of physical memory. You were able to do
Perlish stuff in that without a lot of paging.
>Nobody who doesn't use Unix is going to accept overheads like that.
Blame the Scheme48 implementation technology, where memory footprint
has not been a priority. The point is that the _language_ can absorb
this stuff easily.
>It's fine if you have 128 MB
>of RAM, but most Windows developers will have 32 MB - or less.
Interlisp-D could do _awesome_ things in 32Mb of *virtual* memory,
4Mb of *real* memory. I have yet to see a windowing system approach
it for power, ease of use, or performance.
>If you're really suggesting that Lisp can
>be used to develop popular Windows apps, then please tell me which
>Lisp you're talking about so I buy it.
Naughty naughty. You snuck in that word "popular".
If big memory footprints made programs unpopular, Microsoft Word
would no longer exist, indeed Windows itself would be a rapidly
fading memory. I'm using Macintosh "apps" written in Scheme, TCL,
and Clean, with no memory footprint problems.
I am not writing "apps" for the mass market on _any_ machine.
Next semester, I hope to join a project working on software worth
millions. (Fingers crossed...) GUI interfaces will not be a
priority; rock solid right answers will be.
>That might be a lot easier than convincing Windows developers, since
>Bill Gates has very little interest in Unix, other than replacing it
>with NT.
If I understand you correctly, you seem to be saying that Windows
developers only use tools blessed by Bill Gates, or possibly that
Bill Gates is the only Windows developer, I can't figure out which.
What on earth has Bill Gates' interest in Unix (which Windows NT
closely resembles AND CLAIMS TO IMPLEMENT) or fish or frogs or
anything got to do with the utility of Lisp?
There is nothing about Windows NT (except the performance problems I
keep hearing about) which makes it unsuitable for Lisp or anything
else. If I can run CLISP on a small machine, and I can, I can run
CLISP on a Windows NT machine.
The only real problem with Lisp size that has been mentioned so far
is that
- Lisp systems tend to include a lot of stuff instead of autoloading
- some of this stuff is optimising compiler
- some of this stuff is development system
- stripping it out requires a really good treeshaker.
This is admittedly a flaw, but there is no law that says Lisp systems
_have_ to be built that way, and Stalin for one isn't. Programs compiled
using Stalin (a compiler for Scheme) do not include compiler or development
system. Stalin is a one-man show, and it is intended to produce speedy
object code, not fast compilation time.
Application memory footprint is something Dylan was supposed to address.
Shame on you, Apple!
Mike McDonald
In article <4mpak6$l...@grandcanyon.binc.net>,
<Unknown> (William Barnett-Lewis) writes:
>I got it. I'll probably not risk the $$$ for a full version of ACL/Win
>anytime soon as a result of that. Franz may well be around, but the way
>things are going, I can't be sure. Please prove me wrong....
>
>
>William A. Barnett-Lewis
Well, if everyone takes that attitude, then I can guarantee that
Franz won't be around for long. This is the exact same attitude I ran
into when I worked at Harris and we were trying to get people to use
Symbolics. "Oh, but we don't know if they'll survive so we can't risk
it." Well, eight years later, they finally went under. (I know there's
some form of the company left.) That eight years was a lot longer than
any of our apps lasted. How come this attitude always comes up in
relation to lisp? When we bought Sun 3's, nobody was concerned about
Sun surviving. (Symbolics actually had larger revenues than Sun did at
the time.) Lisp has been around for more than 35 years in one form or
another. Oh well,
Mike McDonald
mik...@engr.sgi.com
William Barnett-Lewis
The point is that my _management_ says I must have that attitude
towards any "non-standard" product. It literally doen't matter what's
best, only what's on the list. I hope Franz will get ACL available in
a form they can say fits thier "standards". Until they do, they may as
well be gone as far as the PC world is concerned.
William A. Barnett-Lewis
wle...@mailbag.com
Gary Houston
Erik Naggum <er...@naggum.no> writes:
| there appears to be an interminable stream of excuses for not seeing that
| Lisp is alive, so I assume that _nothing_ will convince people to the
| contrary if they think Lisp is dead. why bother with people who are
| impervious to facts and absord hype with a passion?
Such people are not necessarily irrational. They may be reasoning
consistently using probability theory as an extended logic.
Given a proposition C ("C++ is the language to use") in which
according to your existing knowledge (I) is very likely to be true
(say P(C | I) > 0.999) then some very convincing evidence would be
needed to make you revise your opinion to the point where you would be
in doubt (via Bayes' Theorem).
However when you see new evidence such as E ("Erik Naggum said on
comp.text.lisp that C++ is for losers"), you are more likely to favour
an alternative proposition ("Erik Naggum has a vested interest", "Erik
Naggum is lying", "Erik Naggum is out of touch with the real world")
than accept "C++ is for losers", which has a very low probability
given I. Although you may consider the alternative propositions
unlikely, they are still more probable than "C++ is for losers".
Reference: E.T. Jaynes, Probability theory: the logic of science,
draft from http://omega.math.albany.edu:8008/JaynesBook.html.
ozan s. yigit
...
Here are some lessons for looking good in the size stakes:
(0) assume things are of equal complexity or have more or less the
same feature set.
:-]
There is nothing in Perl that Lisp couldn't have IF WE WANTED IT TO.
there is nothing in ada that lisp couldn't have if someone wanted it to.
oz
ozan s. yigit
i wrote:
there is nothing in ada that lisp couldn't have if someone wanted it to.
oh dear, i dropped the smiley again. uh, huh i think i had one somewhere
here, ah, no that is just nil, ah here. :-}
Jeffrey Mark Siskind
In article <31914B7F...@math.utexas.edu> Benjamin Shults <bsh...@math.utexas.edu> writes:
I thought that the advantage of Prolog in inferencing was for rule-based,
backtracking inferencing systems. These systems really scream in Prolog.
Lispers do have to code up a backtracking rule application system and
Prologers, I think, do not. Inferencing systems not needing backtracking
should be approximately as easy to code in Lisp, and sometimes easier.
Take a look at Screamer (available from my home page) for a portable
implementation of nondeterministic extensions to Common Lisp
(i.e. backtracking).
Jeff (home page http://tochna.technion.ac.il/~qobi)
--
Jeff (home page http://tochna.technion.ac.il/~qobi)
Christopher Oliver
Vijayaraghavan Raman (vjr...@ix.netcom.com) wrote:
: Words of wisdom.
: The truth is that both Java and VB have been developed and promoted
: by people with a broader understanding and better social skills.
Hmmm. Justice Stanley Sporkin wasn't too impressed with the borg's social
skills.
--
Christopher Oliver Traverse Communications
Systems Coordinator 223 Grandview Pkwy, Suite 108
oli...@traverse.com Traverse City, Michigan, 49684
(define magic (lambda (f) (lambda (x) x)))
(define (more-magic n) (lambda (f) (lambda (x) (f ((n f) x)))))
Erik Naggum
[Erik Naggum]
| there appears to be an interminable stream of excuses for not seeing
| that Lisp is alive, so I assume that _nothing_ will convince people to
| the contrary if they think Lisp is dead. why bother with people who
| are impervious to facts and absorb hype with a passion?
[Gary Houston]
| Such people are not necessarily irrational. They may be reasoning
| consistently using probability theory as an extended logic.
|
| [arguments about C++ elided]
my argument was about those who (1) think Lisp is dead (which cannot
possibly imply that any other language is for losers), and (2) appear to
have an interminable stream of excuses for not seeing that Lisp is alive.
I think people who have interminable streams of excuses _are_ irrational,
i.e., people who will conjure up a new excuse as soon as their previous one
was shown to be irrelevant. if they are reasoning consistently according
to any form of logic, they will, sooner or later, terminate their stream of
excuses and provide actual arguments consistent with such reasoning (or
have such done for them).
as far as it applies to your imputing opinions to me, I don't care what
people do with C++. my only interest in C++ is the ability to write Lisp
that can either talk to C++ code or write C++ code for me, if such needs
should surface. I also don't care what the kind of people write in C++.
I'm just glad I don't have to be one of them, because I don't like the
language. I have no reason to dislike its users. (maybe its creators, but
that's another story.)
--
natural born Lisper
Cyber Surfer
In article <30404756...@arcana.naggum.no>
er...@naggum.no "Erik Naggum" writes:
> [Cyber Surfer]
>
> | How many people know about this? It sounds like a vertical market app,
> | which would mean that very few people will know about it, never mind
> | care. It's not going to convince many people that Lisp is 'alive'.
>
> there appears to be an interminable stream of excuses for not seeing that
> Lisp is alive, so I assume that _nothing_ will convince people to the
> contrary if they think Lisp is dead. why bother with people who are
> impervious to facts and absord hype with a passion?
Coz some of us are unlucky enough to work for people who demand that
code be developed in C or C++, when we'd prefer to code in a more
civilised language. I'd love to be able to recommend such an alternative,
but I don't know if it exists. I'm currently coding in C instead of
Lisp coz I yet know of a Lisp compiler for Win16 and/or Win32 that
can work with the tools needed by the company I work for.
Are you sure that it's simply a matter of some people being "impervious
to facts and absord hype with a passion"? That phrase might also describe
some Lisp programmers, for all I know. Try delivering code for an app
that'll fit onto a single floppy disk, and see if you can do it in Lisp.
If you succeed, how much free space is there on the disk? If you don't
know why code size is significant, then you're probably not interested
in the mass sofware market.
However, many other programmers _are_ interested, and that _may_ be why
they've chosen...C++. It may well be an ugly mess of a language, but so
what? Programmers use it _coz they can_. I'd love to be able to say that
I use Common Lisp or Scheme (or Dylan, or...) for the same reason, but
until the day comes when somebody tells me they're prepared to pay me to
code in such a language, I'll have to use something else.
I'm realistic enough to know that I'm unlikely to find another company
where I'll be as happy working, regardless of the language I have to code
in, so I don't have the option of leaving. Of course, I'll welcome any
offers...
--
<URL:http://www.enrapture.com/cybes/> "You can never browse enough."
Now back from hospital and recovering...
Cyber Surfer
In article <4mqnnm$h...@fido.asd.sgi.com>
mik...@titian.engr.sgi.com "Mike McDonald" writes:
> Well, if everyone takes that attitude, then I can guarantee that
> Franz won't be around for long. This is the exact same attitude I ran
> into when I worked at Harris and we were trying to get people to use
> Symbolics. "Oh, but we don't know if they'll survive so we can't risk
> it." Well, eight years later, they finally went under. (I know there's
> some form of the company left.) That eight years was a lot longer than
> any of our apps lasted. How come this attitude always comes up in
> relation to lisp? When we bought Sun 3's, nobody was concerned about
> Sun surviving. (Symbolics actually had larger revenues than Sun did at
> the time.) Lisp has been around for more than 35 years in one form or
> another. Oh well,
I'd buy ACL/Win if I had the money! However, I'm not sure that I do.
As for, let's say, Open Genera, well. I wish I had _that_ kind of money,
but if I did, I'd still have to buy an Alpha to run it on. How would
I deliver the app? I dunno, as I've never used Genera.
On the other hand, I'm guaranteed a copy of VC++ (Win16 & Win32) as
part of my job. Go figure.
Cyber Surfer
In article <4mpak6$l...@grandcanyon.binc.net>
wle...@mailbag.com "William Barnett-Lewis" writes:
> I've been doing the programming thing for about 16 years now. Lisp is my
> favorite language because, more than anything else, it's fun. OTOH, I do
> all my "real" programming in VB. Many of us PC types live in a Messysoft
> world and if it don't have 'Visual' in front of it, our managers won't
> pop the $$$ for it. Franz has a nice start on a package in ACL/Win 3,
> but from this perspective, only a start.
That sounds painfully familiar! Very few of us can find an ivory tower
in which to work. I find myself hanging around the ground outside ivory
towers trying to catch anything that falls out, but by the time it gets
down to my level, there's not much that's usable. Alas.
> Like too many people, I got started on those hideous little ROM basics
> that all the 8 bitters came with. Compared to those, VB is like
> another language. This is the _perception_. Likewise is the
> idea many folks have that Lisp hasn't changed since the eary '80s
> and the LispM's. Until these perceptions are changed, Lisp will
> remain what it is today - a niche product that survives where it should
> be flourishing.
Spot on! I was totally disgusted by a dialect called Fast Basic, coz it
was still just old-tech token-interpreting Basic, but for a 68K machine
instead of a 6502 (it was an "extended BBC Basic"). Most people I know
havn't even heard of Lisp machines. VB for them is "state of the art".
Meditate on _that_, and you'll see why they think "Lisp is dead". If they
can think it, then it's _true_! Who's gonna tell 'em different? Not Bill
Gates! MS are _promoting_ the idea that VB is state of the art...
> These are all things that _have_ to be done if you want any real
> penitration of the PC market. For my bosses to even begin to consider
> Lisp as a possible developement tool, it Must support OCX controls,
> ODBC, talk to the network, and not (effectivly) require a CDROM to
> distribute the finished product. As the IS manager for a small state
> government agency, I live in a world where my bosses in the Department
> of Administration see all problems as nails, hence I can only buy a
> hammer. Right now, because ACL/Win doesn't do what _they percieve_
> Visual Basic as being able to do, that hammer is VB. I don't much like
> it, but I really like the $$$ that goes into my bank every two weeks
> for tolerating it. "Right tool for the right job" - Well, it'd really be
> nice if it worked that way, but Uncle Bill has taken that option away
> from many of us.
If your only tool is a hammer, everything looks like a nail. It won't
matter if Lisp can do stuff that VB can't - nobody will know it! MS
won't tell 'em. In fact, they say the opposite.
And then there's multimedia...MS are saying we need C++ for that,
so it's C++ that I'll be using. I'm not paid to write compilers.
> In the '80s the partisans of the Lisp Machines had to come to grips
> with that nasty little kludge called Unix. In the end, the machines
> were gone and workstation based versions of their products could run rings
> around the specialized hardware. In the '90s you're facing the same
> challenge with Cutler's VMSjr and if products that reflect that don't
> start coming out Real Soon Now, it'll make the AI winter look like the
> AI spring. All that'll be left is a few of us children and our favorite
> toys. And that will be just too bad. Couple of years ago, I bought a
> student copy of Medley. Makes a PC into a real nice clone of an 1186.
> Faster even! Doesn't do much else though. Now I can;t even get the phone
> answered to find out if they ever fixed a bug I reported back when
> I got it. I'll probably not risk the $$$ for a full version of ACL/Win
> anytime soon as a result of that. Franz may well be around, but the way
> things are going, I can't be sure. Please prove me wrong....
I'm not using Unix or VMS. I can't even install Linux on this machine,
coz the disk controller (on the motherboard) has a hardware bug, and
it stops Linux from installing. However, NT copes just fine. Now, I'm
not even paid to use NT, I just get a copy with MSDN III, which is
supplied to me by my employer.
Alternately, there's DOS and Windows 3.11. Yuk. If I'm lucky enough
to get another drive, I could perhaps install Win95, or NT 4.0, but
will that help me use Lisp? Alas, no.
The message here is think in terms of a larger market, a _much_ smaller
delivery image, and the platform with the largest number of programmers
and users. If you're lucky, you might find that even MS use your software.
Franz will know what I mean, coz MS have used ACL/Win to create an
animated UI. Sadly, the Lisp code was only used to generate the C++
code to do the real work, but that was closer than most people will
get to using delivered Lisp code. Now, if only the MS marketing people
could get the message!
Cyber Surfer
In article <wiu3xpr...@quagmire.ghouston.actrix.gen.nz>
ghou...@actrix.gen.nz "Gary Houston" writes:
> Erik Naggum <er...@naggum.no> writes:
>
> | there appears to be an interminable stream of excuses for not seeing that
> | Lisp is alive, so I assume that _nothing_ will convince people to the
> | contrary if they think Lisp is dead. why bother with people who are
> | impervious to facts and absord hype with a passion?
>
> Such people are not necessarily irrational. They may be reasoning
> consistently using probability theory as an extended logic.
MS are telling them that they can't go wrong with C++. When have MS
been hurt by chosing C++? People can use that as a way of justifying
C++ as their chosen language, even if they don't have other ways.
> Given a proposition C ("C++ is the language to use") in which
> according to your existing knowledge (I) is very likely to be true
> (say P(C | I) > 0.999) then some very convincing evidence would be
> needed to make you revise your opinion to the point where you would be
> in doubt (via Bayes' Theorem).
Yep. Read the marketing stuff coming out of MS, and then wonder how
you would market Lisp in order to get people to see it as not dead.
I can't recall the last time I saw an advert for a Lisp system in
a magazine, but it was probably Byte. If Franz could get ads for
ACL/Win into magazines like MSJ and Windows Tech Journal (a mag that
MS no longer advertises in, coz of the editorial freedon that the mag
insists on), then at least a few programmers might see that Lisp is
not dead, so long as there's still at least one Lisp vendor. Keep
quiet and they can think what they like, which might be what ever
MS put into their adverts, i.e. "C++ is the answer".
Cyber Surfer
In article <PF.96Ma...@elissa.hc.ti.com>
p...@elissa.hc.ti.com "Paul Fuqua" writes:
> In article <831306...@wildcard.demon.co.uk> Cyber Surfer
> <cyber_...@wildcard.demon.co.uk> writes:
> > How true. Why does everyone want their Lisp enviroment to be like a
> > Lisp Machine?
>
> Let's see: bitmapped screen, window system, integrated editor and
> compiler and debugger and interpreter, transparent networking. Can't
> imagine why that would be popular.
Don't forget: won't run Windows apps. That's a big disadvantage for
many people. Then there's the cost...
> To be honest, it's a terrible delivery environment, because it's hard to
> strip out the parts you don't need, but it's one hell of a development
> environment. The concepts survive not only in commercial Lisps like
> Allegro and Harlequin, but in emacs' compile-mode.
I can't comment on Emacs, as my only experience with it was brief,
and slow. It was on an 8 MB 386/33 that could only just run Linux-FT,
and I had no idea what I was doing. In the time available, I didn't
get to see any features that could've come from Lisp.
Delivery is one of the few things that C/C++ excells at.
> (I'm not just a lispm user, I'm a former lispm developer, so my biases
> are showing.)
Fair enough. ;-) BTW, I've written a couple of Lisp interpreters, and,
more recently, a crude Lisp compiler. I love Lisp, but I've yet to find
one that has a delivery footprint small enough for me to use it in a
commercial app. That may tell you something about the kind of apps that
I write. The complete code tends to be less than 1 MB.
> > Perl is also _small_.
> > It doesn't need to be "good". It only needs to be there.
>
> It's a good tool, but a terrible language. It puts a bunch of useful
> sysadmin features in a form that's a lot easier than the combination of
> tools that were used before, and thereby fills a need.
I agree. I use it very carefully - and as little as possible. However,
it has been heavily promoted - unlike Lisp. Sorry, but I see the lack
of "success" of Lisp as partly due to the complacency of vendors and
users. If you fail to see why Lisp is seen as "dead" by so many people,
then this is the reason. You forgot to promote it, and keep at least
_some_ of the Lisp implementations competitive with more "vital" (in
marketing terms, anyway) languages like VB.
> Tools for jobs. Lisp is a perfectly good tool for lots of things, but
> suffers more than any other language from preconceptions and prejudice.
> From my quotes file:
>
> "Would you go over to Computer City and ask what language Microsoft
> Word is written in? If they said ALGOL 60, would you buy something
> else instead?" - Clint Hyde
That's a good point. I just hope that most people don't see Dylan as
a new name for Lisp, coz it's more than that. Removing introspection
from a language is significant. Not every programmer needs to be able
to create new classes at runtime, so why should they have to pay for
such a feature? A CL implementation may well demand such a price,
while Dylan simply says, "No, you can't have that - try CL instead".
I'll choose Dylan, if Harlequin don't set the price for DylanWorks
to high. They've at least got the platform right. Now all they need
is a healthy market...
--
<URL:http://www.enrapture.com/cybes/> "You can never browse enough."
Cyber Surfer
In article <4mpq3c$1...@goanna.cs.rmit.EDU.AU>
o...@goanna.cs.rmit.EDU.AU "Richard A. O'Keefe" writes:
> Ok, how big _is_ the perl runtime?
> ls -lL `which perl` => 650 000 bytes (rounded). SPARC
>
> Now, how big are some Schemes?
> scm 236k SPARC
> elk ~400k [*1] SPARC
> stalin 1736k Highly optimising compiler SPARC
> nawk 188k [*2] SPARC
> tclsh 192k [*6] SPARC
>
> MacScheme 84k Mac
SPARC? Are you kidding me? I can't use a SPARC, nor can the people
I work with, nor do any of their users. They use machines with Intel
(compatible) CPUs in them.
How many of those Lisp systems can deliver code that can be linked
with C/C++ for Windows? This isn't a hypothetical question, it's
about the demands made by real clients.
> In comparison with an optimising compiler whose end product is native code,
> yes, Perl is small.
I wouldn't use Perl to write code and then deliver it to a client,
but it does get used on web servers. You'd only need one copy of the
interpreter, of course. MS want you to use VC++.
> (3) Don't admit to your real competition in the size stakes.
Err, but what about the client? ;-)
> >I agree. It's not just useful for Unix users, either. I'm using it for
> >NT, and I'm told that there's a web server for Netware that includes a
> >Perl interpreter.
>
> There are web servers including all sorts of things, including ML.
Does it run under NT? After reading about ISAPI, I suddenly have
visions of someone lashing up ML with IIS.
> >> There's nothing in Perl that Lisp couldn't have if we wanted it to.
> >> The 'scsh' people have been adding that kind of stuff to their Scheme.
> >
> >Err, scsh requires 20 MB of RAM.
>
> So what? That's irrelevant to my point.
It's not irrelevant to _my_ point, which is that I can't justify
something that uses more memory than C++, simply coz I'd have to
show why using, let's say, Lisp is better for the _client_, not
why it's better for me.
> There is nothing in Perl that Lisp couldn't have IF WE WANTED IT TO.
I agree. Let's add it!
> Interlisp-D, a much richer language than Perl, with a compiler
> included, plus a ton of networking software, two Lisp editors,
> a drawing editor, and a programmable WYSIWIG editor not altogether
> unlike Alpha, ran *happily* on a machine with 32Mb _max_ virtual
> memory, and 4Mb _max_ of physical memory. You were able to do
> Perlish stuff in that without a lot of paging.
Would that be a system that you'd have to boot, or could it be run
under an OS like NT? That's vital to me, as I _must_ use either NT
or some other form of Windows. I don't have that choice.
> >Nobody who doesn't use Unix is going to accept overheads like that.
>
> Blame the Scheme48 implementation technology, where memory footprint
> has not been a priority. The point is that the _language_ can absorb
> this stuff easily.
Sure, but not for NT. Not yet, anyway. While I'm waiting, I'll just
have to use C++ instead. I'd also need to seperate the runtime from
the development time support, so that the user doesn't get burdened
with any unnecessary overheads. I don't know if Scheme 48 can do that,
but if it can, and it can be done for NT, produce native code, fully
support the Win32 API (perhaps via a FFI), then I _might_ be able to
convince my boss. I doubt that most other Windows developers have
find it so easy, as my boss is also one of my best friends.
> Interlisp-D could do _awesome_ things in 32Mb of *virtual* memory,
> 4Mb of *real* memory. I have yet to see a windowing system approach
> it for power, ease of use, or performance.
Too bad, then, that my boss and none of his clients know about it.
Who marketed it?
> >If you're really suggesting that Lisp can
> >be used to develop popular Windows apps, then please tell me which
> >Lisp you're talking about so I buy it.
>
> Naughty naughty. You snuck in that word "popular".
> If big memory footprints made programs unpopular, Microsoft Word
> would no longer exist, indeed Windows itself would be a rapidly
> fading memory. I'm using Macintosh "apps" written in Scheme, TCL,
> and Clean, with no memory footprint problems.
Word isn't so bad on a machine with 32MB of RAM, but I think that the
real reason why Word "succeeds" even when its so big is that it has MS
pushing it. You can buy it as part of a bundle called Office. Some
people need Word simply coz so many other things depend on it. Who can
afford to be without it? In spite of all the obvious failings, it
survives coz MS want it to.
> I am not writing "apps" for the mass market on _any_ machine.
> Next semester, I hope to join a project working on software worth
> millions. (Fingers crossed...) GUI interfaces will not be a
> priority; rock solid right answers will be.
Good luck to you, then. Few of us are so fortunate.
> >That might be a lot easier than convincing Windows developers, since
> >Bill Gates has very little interest in Unix, other than replacing it
> >with NT.
>
> If I understand you correctly, you seem to be saying that Windows
> developers only use tools blessed by Bill Gates, or possibly that
> Bill Gates is the only Windows developer, I can't figure out which.
The "blessing" of Bill Gates, yes. That's it exactly. One of the things
that a Windows developer can be sure of is that buying VB/VC++ won't hurt,
and anything else blessed by MS (like Word) might also help. I dunno
how true this is, but you can easily find people who behave as if they
believe it.
> What on earth has Bill Gates' interest in Unix (which Windows NT
> closely resembles AND CLAIMS TO IMPLEMENT) or fish or frogs or
> anything got to do with the utility of Lisp?
It has a great deal to do with the perception of things created by
the marketing people at MS.
> There is nothing about Windows NT (except the performance problems I
> keep hearing about) which makes it unsuitable for Lisp or anything
> else. If I can run CLISP on a small machine, and I can, I can run
> CLISP on a Windows NT machine.
I know. I've used Lisp on an NT machine (I have one right here),
so I know I can use a Lisp, like ACL/Win. I'm not sure about CLISP,
but only coz the when I tried it, I got an error message. It looked
like there was a memory problem, so perhaps I'll have to tweak the
setup a bit, when I have the time.
Sadly, I'm unlikely to be paid to use CLISP to develop apps. I'm not
even sure it _could_ be used to write these apps, unless there's now
a Win32 version of CLISP, producing native code?
> The only real problem with Lisp size that has been mentioned so far
> is that
> - Lisp systems tend to include a lot of stuff instead of autoloading
> - some of this stuff is optimising compiler
> - some of this stuff is development system
> - stripping it out requires a really good treeshaker.
> This is admittedly a flaw, but there is no law that says Lisp systems
> _have_ to be built that way, and Stalin for one isn't. Programs compiled
> using Stalin (a compiler for Scheme) do not include compiler or development
> system. Stalin is a one-man show, and it is intended to produce speedy
> object code, not fast compilation time.
I agree about these things being possible. It's the fact that they
appear not to have yet been done that worries me. I can't use something
that's not available for a platform that I use, like NT. However, I'm
actually developing for Win16, so I I'd need Win32s support, which
would increase the size of the delivered code (Win32s itself would
have to be included).
Is Stalin available for NT?
> Application memory footprint is something Dylan was supposed to address.
> Shame on you, Apple!
Yep, shame on Apple. Still, I'm lucky that I'm not a Mac developer!
Thanks for cheering me up. ;-)
Cyber Surfer
In article <30408111...@arcana.naggum.no>
er...@naggum.no "Erik Naggum" writes:
> I think people who have interminable streams of excuses _are_ irrational,
> i.e., people who will conjure up a new excuse as soon as their previous one
> was shown to be irrelevant. if they are reasoning consistently according
> to any form of logic, they will, sooner or later, terminate their stream of
> excuses and provide actual arguments consistent with such reasoning (or
> have such done for them).
I think that most people are simply ignorant of modern Lisps. Whose
fault is that? Well, I blame marketing people.
> as far as it applies to your imputing opinions to me, I don't care what
> people do with C++. my only interest in C++ is the ability to write Lisp
> that can either talk to C++ code or write C++ code for me, if such needs
> should surface. I also don't care what the kind of people write in C++.
> I'm just glad I don't have to be one of them, because I don't like the
> language. I have no reason to dislike its users. (maybe its creators, but
> that's another story.)
When I find someone who'll pay me to program in Lisp, I might feel
some sympathy. Until then, I'm unfortunate enough to be stuck with
C++, wondering how I can get Lisp code to work with it. I don't like
C++ either, but that's the only programming work I can find. The
alternative appears to be unemployed...which leaves me even fewer
options, all running under Linux.
I'm practical enough to accept that the people I work for don't want
what systems like ACL/Win offer. Put another, the things they _do_ want
are not offered by ACL/Win. (For example, where's the OCX support?)
I've been reading threads in comp.lang.lisp asking 'Why isn't Lisp
more mainstream?' for the last 4 years, and very few people here seem
o realise how simple the answer is. I suspect that the designers of
Dylan understood it, and if you look at the differences between Dylan
and Common Lisp, you might see what it is that CL is doing wrong.
Of course, until DylanWorks is released, we won't know for sure
how close Dylan really is to what most Windows developers are
looking for. Until developers begin to write apps using such a
development system and deliver them to clients, we can only
speculate about whether Dylan will be better at satisfying the
requirements of clients than C++/Lisp/VB/etc.
--
<URL:http://www.enrapture.com/cybes/> "You can never browse enough."
Richard A. O'Keefe
Cyber Surfer <cyber_...@wildcard.demon.co.uk> writes:
>In article <4mpq3c$1...@goanna.cs.rmit.EDU.AU>
> o...@goanna.cs.rmit.EDU.AU "Richard A. O'Keefe" writes:
>> Ok, how big _is_ the perl runtime?
>> ls -lL `which perl` => 650 000 bytes (rounded). SPARC
>>
>> Now, how big are some Schemes?
>> scm 236k SPARC
>> elk ~400k [*1] SPARC
>> stalin 1736k Highly optimising compiler SPARC
>> nawk 188k [*2] SPARC
>> tclsh 192k [*6] SPARC
>>
>> MacScheme 84k Mac
>SPARC? Are you kidding me? I can't use a SPARC, nor can the people
>I work with, nor do any of their users. They use machines with Intel
>(compatible) CPUs in them.
I have access to a SPARC, so that's what I measured things on.
Are _you_ kidding me that you see that as a problem?
Do you know of any reason why the size ratio for scm/perl should be
more in Perl's favour on a 386 than on a SPARC?
>How many of those Lisp systems can deliver code that can be linked
>with C/C++ for Windows? This isn't a hypothetical question, it's
>about the demands made by real clients.
Of the Scheme systems I listed, the answer is "all of them".
>> In comparison with an optimising compiler whose end product is native code,
>> yes, Perl is small.
>I wouldn't use Perl to write code and then deliver it to a client,
>but it does get used on web servers.
So does ML. So what?
>You'd only need one copy of the
>interpreter, of course. MS want you to use VC++.
And Sun want you to use Java.
>> (3) Don't admit to your real competition in the size stakes.
>Err, but what about the client? ;-)
I don't understand what point you are making here, if any.
I did not write "don't admit XXX to your competition",
I wrote "don't admit to [the existence of] your competition".
"What about the client?" Well, it's precisely the potential
client who is being deceived by this failure to admit to the
existence of the _real_ competition.
>> There are web servers including all sorts of things, including ML.
>Does it run under NT?
No idea. Since NT is supposed to have a "POSIX personality",
why wouldn't it?
>After reading about ISAPI, I suddenly have
>visions of someone lashing up ML with IIS.
I can't keep up with the acronyms in the Wintel world.
Please tell me what IIS and ISAPI are.
>It's not irrelevant to _my_ point, which is that I can't justify
>something that uses more memory than C++, simply coz I'd have to
>show why using, let's say, Lisp is better for the _client_, not
>why it's better for me.
Yes, but "scsh" and "Lisp" are no coextensive.
I just went to the trouble of pointing out that there are _other_ Schemes,
with the exception of a separate compiler delivering small extremely fast
standalone executables, they were all smaller than Perl.
>> Interlisp-D, a much richer language than Perl, with a compiler
>> included, plus a ton of networking software, two Lisp editors,
>> a drawing editor, and a programmable WYSIWIG editor not altogether
>> unlike Alpha, ran *happily* on a machine with 32Mb _max_ virtual
>> memory, and 4Mb _max_ of physical memory. You were able to do
>> Perlish stuff in that without a lot of paging.
>Would that be a system that you'd have to boot, or could it be run
>under an OS like NT?
It's the same "Medley" that has recently been mentioned in this newsgroup.
I know that Medley runs as an ordinary process on UNIX boxes.
I don't know what the PC version does, but apparently there is one.
>> Interlisp-D could do _awesome_ things in 32Mb of *virtual* memory,
>> 4Mb of *real* memory. I have yet to see a windowing system approach
>> it for power, ease of use, or performance.
>Too bad, then, that my boss and none of his clients know about it.
>Who marketed it?
"not sure if we want to be in the computer business" Xerox, that's who.
The inventors of the WIMP paradigm epitomised by Mac and Windows today.
The inventors of Smalltalk.
Xerox technical work was *brilliant*.
Xerox marketing was *abysmal*.
>Word isn't so bad on a machine with 32MB of RAM,
I haven't _got_ a machine with 32Mb of RAM.
>but I think that the
>real reason why Word "succeeds" even when its so big is that it has MS
>pushing it.
Exactly.
The success of Wintel and Perl, and the lack of Lisp growth,
can be attributed to the same three factors:
Marketing,
Marketing, and
Marketing.
>> I am not writing "apps" for the mass market on _any_ machine.
>> Next semester, I hope to join a project working on software worth
>> millions. (Fingers crossed...) GUI interfaces will not be a
>> priority; rock solid right answers will be.
>Good luck to you, then. Few of us are so fortunate.
How many *popular* "apps" have you written, and what tools were used
to write them?
>The "blessing" of Bill Gates, yes. That's it exactly. One of the things
>that a Windows developer can be sure of is that buying VB/VC++ won't hurt,
>and anything else blessed by MS (like Word) might also help. I dunno
>how true this is, but you can easily find people who behave as if they
>believe it.
Once upon a time there was a slogan "nobody was ever sacked for buying IBM."
>Is Stalin available for NT?
Stalin itself is compiled by the free "Scheme to C" compiler.
As I said, it's a one man project. I don't know any reason why it
_couldn't_ be made to run on NT. If I had an NT box, I'd try it.
>> Application memory footprint is something Dylan was supposed to address.
>> Shame on you, Apple!
>Yep, shame on Apple. Still, I'm lucky that I'm not a Mac developer!
>Thanks for cheering me up. ;-)
--
Peter Norvig
The "Why Lisp" and "Lisp vs Prolog" discussion is available online.
Follow the "why Lisp?" link from
http://www.cs.berkeley.edu/~russell/paip.html
In article <porco.55...@emf.net> po...@emf.net (Travis Porco) writes:
> >Are there any technical advantages with Lisp, compared to Prolog?
>
> There is a useful discussion in
> _Paradigms of Artificial Intelligence Programming_ by Peter Norvig,
> Morgan-Kaufmann, ISBN 1-55860-191-0
--
Peter Norvig | Phone: 415-833-4022 FAX: 415-833-4111
Harlequin Inc. | Email: nor...@harlequin.com
1010 El Camino Real, #310 | http://www.harlequin.com
Menlo Park CA 94025 | http://www.cs.berkeley.edu/~russell/norvig.html
Mark Pedersen
[This is a repost - I think my news poster stuffed up - sorry if you've
seen this before. ]
In <4mnms4$s...@m1.cs.man.ac.uk> mil...@cs.man.ac.uk (Crispin Miller) writes:
>My own experience is that the OO ideas are great - especially for
>researchy type stuff - as long as the low-level implementational
>crud doesn't get in the way. THis is a fair criticism of C++ or Java
>as a development language, but not of OO techniques in general.
>Finally, encapsulation lets you develop 'quick and dirty' bits of code
>to test ideas, which can be ripped out and thrown away when they don't
>work. This used to be called hacking, but I think the correct term now
>is 'incremental development'.
;-)
I spent a couple of years programming C++, and I found that using OO did
remarkable things to the integrity of the algorithms I wrote. When it
came to testing some fairly complex tree manipulations, all cases were
covered by the basic algorithm - no exceptions had to be made, because
each object covered its own "exceptions". I feel this elegance leaves
you to concentrate on the "research" more than the programming - the
grunginess of C++ notwithstanding.
>That's the good side, on the bad side:
>ii) If new objects need to be created dynamically at run time you're
>pretty much stuck - since the inheritance stuff is sorted out at
>compile time.
I believe Smalltalk gives dynamic creation, but I don't know if it's
suitable to NLP in any other respect.
I'm actually considering what implementation language I'll use for an
NLP research project I'm working on now. As always, unification is
essential, and support for feature structures, but I'd like to have OO
support as well, since it suits my mindset, and as I said, done right it
seems to produce good results.
There seem to be several unification-based languages that offer
inheritance/type-sorts etc., such as CUF and TFS, but they don't seem
to offer much in the way of encapsulation. Maybe encapsulation is
antithetical to declarative programming anyway, but not necessarily.
Someone has suggested that Lisp's CLOS might offer me what I'm looking
for, but they also suggested that Scheme might be nicer to use if it
supports CLOS. Any comments on using CLOS for NLP, or Scheme for that matter?
Does anyone know of any other unification-based langs that offer OO (not
*just* inheritance)??
Cheers,
Mark
--
-----------------------------------------------------------------------------
Mark Pedersen | email : ma...@cs.uq.oz.au | http://student.uq.edu.au/~s303080
"When freedom destroys order, the yearning for order will destroy freedom."
Heiko Wengler
p...@elissa.hc.ti.com (Paul Fuqua) writes:
>In article <831306...@wildcard.demon.co.uk> Cyber Surfer <cyber_...@wildcard.demon.co.uk> writes:
>> How true. Why does everyone want their Lisp enviroment to be like a
>> Lisp Machine?
>Let's see: bitmapped screen, window system, integrated editor and
>compiler and debugger and interpreter, transparent networking. Can't
I have a question...
Again and again someone posts about the great features those old lisp machines
had.
Is there sourcecode of the OS/system of such a machine out there?
(So that someone could begin and port it to PC (sucks but
it is the defacto standard now) hardware.
Like Native Oberon etc...)
I would like to have an integrated lisp(PC) machine to work on...
Heiko Wengler
Christian Lynbech
>>>>> "Cyber" == Cyber Surfer <cyber_...@wildcard.demon.co.uk> writes:
Cyber> I can't comment on Emacs, as my only experience with it was brief,
Cyber> and slow. It was on an 8 MB 386/33 that could only just run Linux-FT,
Cyber> and I had no idea what I was doing. In the time available, I didn't
Cyber> get to see any features that could've come from Lisp.
You do not need linux to run emacs on PC's. Emacs 19.30 already has
support for at least Windows NT, though I do not really know the
status of it. At least some exiciting is suppose to happen when 19.31
comes out, but of hwat nature I can't really tell.
As to features, almost any darn feature you see in emacs is IMHO
precisely because of lisp. If adding something like parsing errors in
compilation buffers and jumping to the right line of source was a
matter of pulling the C source and hacking it into that, emacs would
not be much more today that something like xedit. That emacs has an
omnipotent extension language has been the overall foundation for the
amount of features (and yes, I do seriously consider the amount of
features in emacs a feature!).
And digressing to general lisp alternatives in the windows world, I
think things are rapidly improving. Check something like STk, the
Scheme Tk system, which combins scheme and Tk and I believe also runs
on Windows NT (but don't hang me up on that). It supports dynamic
loading of object files, but I do not think that that constitutes a
real FFI yet.
Check out anonymous ftp at
/kaolin.unice.fr:/pub
---------------------------+--------------------------------------------------
Christian Lynbech | Computer Science Department, University of Aarhus
Office: R0.32 | Ny Munkegade, Building 540, DK-8000 Aarhus C
Phone: +45 8942 3218 | lyn...@daimi.aau.dk -- www.daimi.aau.dk/~lynbech
---------------------------+--------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- pet...@hal.com (Michael A. Petonic)
Arun Welch
>>>>> "Heiko" == Heiko Wengler <wengler@s_isst2.do.isst.fhg.de> writes:
Heiko> Again and again someone posts about the great features
Heiko> those old lisp machines had.
Heiko> Is there sourcecode of the OS/system of such a machine out
Heiko> there? (So that someone could begin and port it to PC
Been there, done that. See the FAQ entry for Medley.
...arun
---------------------------------------------------------------------------
Arun Welch 5000 Arlington Centre Blvd
Lead Software Engineer Columbus, OH 43220
CompuServe awe...@csi.compuserve.com
--
---------------------------------------------------------------------------
Arun Welch 5000 Arlington Centre Blvd
Lead Software Engineer Columbus, OH 43220
CompuServe awe...@csi.compuserve.com
Cyber Surfer
In article <4n6dv0$d...@goanna.cs.rmit.EDU.AU>
o...@goanna.cs.rmit.EDU.AU "Richard A. O'Keefe" writes:
> I have access to a SPARC, so that's what I measured things on.
> Are _you_ kidding me that you see that as a problem?
No, I'm simply pointing out that not everyone has a SPARC, or even
has access to one. I thought we were discussing why so many people
see Lisp as a dead language?
> Do you know of any reason why the size ratio for scm/perl should be
> more in Perl's favour on a 386 than on a SPARC?
Perl is an interpreter, so comparing it with VB might make more sense
than with native code generated from a Lisp compiler. I'm thinking of
the size of the object code delivered with an app, since that's what
so many people (like clients, users, etc) seem to be concerned with.
> >How many of those Lisp systems can deliver code that can be linked
> >with C/C++ for Windows? This isn't a hypothetical question, it's
> >about the demands made by real clients.
>
> Of the Scheme systems I listed, the answer is "all of them"
Excellent. How many of them can produce stand-alone apps and provide
even a tenth of the Windows support that you can find in VB?
I'm actually agreeing with you, but if I want to use these tools to
develop with, then I have to be able to prove that these tools can
do the same job as C++ or VB. Lisp itself suffers from a credibility
problem, so even if it were technically possible, we still have to
prove it. While I'd _prefer_ to use Lisp to write Windows apps, not
everyone has the time available to me for experiementing, and a fair
number of developers won't have the willingness, either.
> >I wouldn't use Perl to write code and then deliver it to a client,
> >but it does get used on web servers.
>
> So does ML. So what?
So, Perl has been very heavily promoted by Larry Wall and friends.
Would Lisp have that kind of popularity, if it had been promoted
as much? I dunno.
Part of the problem is that it's much easier to know what Perl is,
while Lisp comes in many different flavours, sizes, etc. I've lost
count of the number of times that I've seen someone on UseNet, even
when they're a Lisp programmer, claiming that Lisp requires 20 MB
of RAM! The first Lisp that I remember reading about only needed
16K, but that was something like than 15 years ago.
> >You'd only need one copy of the
> >interpreter, of course. MS want you to use VC++.
>
> And Sun want you to use Java.
I know. Java is getting a _lot_ of promotion. Is that all a language
needs, for it to succeed?
> >> (3) Don't admit to your real competition in the size stakes.
>
> >Err, but what about the client? ;-)
>
> I don't understand what point you are making here, if any.
> I did not write "don't admit XXX to your competition",
> I wrote "don't admit to [the existence of] your competition".
> "What about the client?" Well, it's precisely the potential
> client who is being deceived by this failure to admit to the
> existence of the _real_ competition.
What I mean is that the client will see the size of the code.
That's pretty hard to hide, when the code is delivered to them.
Some people are still counting bytes - even if tends to be
floppy disks, these days.
> >> There are web servers including all sorts of things, including ML.
>
> >Does it run under NT?
>
> No idea. Since NT is supposed to have a "POSIX personality",
> why wouldn't it?
I dunno. I'm mainly developing for Win16, but when it's possible,
then I try to write an app for Win32 - which, BTW, is being heavily
promoted by MS and a number of other big software companies. I've
no idea whether POSIX will be enough, coz the demand that I'm aware
of is for Win32.
> >After reading about ISAPI, I suddenly have
> >visions of someone lashing up ML with IIS.
>
> I can't keep up with the acronyms in the Wintel world.
> Please tell me what IIS and ISAPI are.
IIS is the MS web server, while ISAPI is the interface for "CGI"
code. It's not actually CGI, of course, coz it used dynamic linking
instead of starting a new process.
> I just went to the trouble of pointing out that there are _other_ Schemes,
> with the exception of a separate compiler delivering small extremely fast
> standalone executables, they were all smaller than Perl.
I'm trying to point out that neither Lisp nor Perl are competing
with VB, which is interpreted, or VC++, which is native code. Both
VB and C++ are seen as _the_ Windows development tools, leaving
very little room for any other languages, altho there are some.
In such a competitive market, I'm impressed that Smalltalk is still
there, at the high end of the market, but not everyone may feel
that way. A Windows developer might find it very much harder to
justify using ST, never mind Lisp, when VB or C++ is available.
I'm certainly _not_ saying that I like this situation, but I am
wondering what might be done to improve it.
> >Would that be a system that you'd have to boot, or could it be run
> >under an OS like NT?
>
> It's the same "Medley" that has recently been mentioned in this newsgroup.
> I know that Medley runs as an ordinary process on UNIX boxes.
> I don't know what the PC version does, but apparently there is one.
Well, that doesn't answer my question. Never mind. If you don't
know, then I'd not be suprised if very few Windows developers
know about it, either. I've never seen an advert for it, but I
wouldn't expect to - there are ST systems that I don't recall
ever seeing an advert for, either, so it may mean very little.
> >Too bad, then, that my boss and none of his clients know about it.
> >Who marketed it?
>
> "not sure if we want to be in the computer business" Xerox, that's who.
> The inventors of the WIMP paradigm epitomised by Mac and Windows today.
> The inventors of Smalltalk.
> Xerox technical work was *brilliant*.
> Xerox marketing was *abysmal*.
I totally agree! I watched them lose it all in the early 80s, and
a recently 3-part TV series, here the UK, dedicated an entire show
to the sad story. That's why I asked, "Who marketed it?" I knew
the answer, and my point was that successful marketing is vital
these days, when the market is so competitive. Having a good idea
is not enough to succeed.
> >Word isn't so bad on a machine with 32MB of RAM,
>
> I haven't _got_ a machine with 32Mb of RAM.
Neither did I, until 5 months ago. ;-) I don't do word processing,
if I can avoid it, and I usually can. Actually, my dad uses Word
on a 16 MB machine, and seems happy, but he's using Win95, while
I'm using NT and VC++.
> >but I think that the
> >real reason why Word "succeeds" even when its so big is that it has MS
> >pushing it.
>
> Exactly.
We probably don't have anything to argue about. ;-)
> The success of Wintel and Perl, and the lack of Lisp growth,
> can be attributed to the same three factors:
> Marketing,
> Marketing, and
> Marketing.
That's just what I've been saying.
> How many *popular* "apps" have you written, and what tools were used
> to write them?
Last year, I wrote a multimedia app that was, I'm told,
distributed with about 1/4 million magazines. I've wondered
how that app might have been written in Lisp, but if I find
a way of doing it, then I'll have to use it to write the
Win32 version, as I'm no longer working on the Win16 version.
What I could really use is a Lisp system with the Windows
support that VB has, with OCX support, very low runtime
overhead, and some decent marketing behind it. I'm not even
sure if DylanWorks will have that!
> Once upon a time there was a slogan "nobody was ever sacked for buying IBM."
True. So what? I'm not buying C++. I've asked for ACL/Win,
but I dunno if or when I'll get it. I'm just a programmer.
> >Is Stalin available for NT?
>
> Stalin itself is compiled by the free "Scheme to C" compiler.
> As I said, it's a one man project. I don't know any reason why it
> _couldn't_ be made to run on NT. If I had an NT box, I'd try it.
So it's unlikely that it'll have any of the Win32 support that
I need. Thanks.
Probal Shome
Vijayaraghavan Raman wrote:
>
> Words of wisdom.
>
> The truth is that both Java and VB have been developed and promoted
> by people with a broader understanding and better social skills.
>
> !There are signs that these are emerging in the LISP community.
>
> ACL4*Windows* is such an encouraging sign that would benefit by
> being more "inclusive."
I'm not sure why we can't leverage all the push
behind Java, and write a LISP
compiler/interpreter/environment in Java? Microsoft
has plans to let Java applets interact with
OCXs/ActiveXs, so that may satisfy some other
people's requirements as well...
Regards,
Probal
Patrick Logan
Heiko Wengler wrote:
>
> Again and again someone posts about the great features those old lisp machines
> had.
> ...
> I would like to have an integrated lisp(PC) machine to work on...
Medley?
--
Patrick...@ccm.hf.intel.com
"Moore's Law has come to refer to almost anything
related to the semiconductor industry that when
plotted on semilog paper approximates a straight line."
-Gordon Moore
Cyber Surfer
In article <gt689zk...@cobalt.daimi.aau.dk>
lyn...@cobalt.daimi.aau.dk "Christian Lynbech" writes:
> You do not need linux to run emacs on PC's. Emacs 19.30 already has
> support for at least Windows NT, though I do not really know the
> status of it. At least some exiciting is suppose to happen when 19.31
> comes out, but of hwat nature I can't really tell.
So much software, so little time. ;-)
> And digressing to general lisp alternatives in the windows world, I
> think things are rapidly improving. Check something like STk, the
> Scheme Tk system, which combins scheme and Tk and I believe also runs
> on Windows NT (but don't hang me up on that). It supports dynamic
> loading of object files, but I do not think that that constitutes a
> real FFI yet.
>
> Check out anonymous ftp at
>
> /kaolin.unice.fr:/pub
I'll take a look, thanks. Can it produce native code and stand-alone
.EXE files? What I'm looking for is a Lisp that I can use as an
alternative to VC++, so it really has to be able to most of the things
that VC++ can do. Otherwise, I'll still be using C++ most of the time.
The only native code Scheme that I've used so far is MIT Scheme, and
that appears to be totally unsuitable, dispite being available for NT.
Howard R. Stearns
Indeed, CLOS combines the dynamic language features you are used to from
Lisp and a very powerful OO language. It's SO dynamic, that not only
can you define a new class at run time, but you can actually CHANGE the
class of an object instance without effecting its identity. In
addition, there is a very powerful reflective toolkit (the Meta Object
Protocol). Check out:
"Object-Oriented Programming: The CLOS Perspective", edited by Andreas
Paepcke. MIT Press, 1993. There's some good articals on what the
features of CLOS are, why they are useful, and how they compare with
other OO languages.
> Does anyone know of any other unification-based langs that offer OO (not
> *just* inheritance)??
>
> Cheers,
>
> Mark
>
> --
>
> ------------------------------------------------------------------------
> Mark Pedersen | email : ma...@cs.uq.oz.au,
> Dept. Computer Science | http://www.cs.uq.edu.au/personal/markp/index.html
ozan s. yigit
Cyber Surfer:
> And Sun want you to use Java.
I know. Java is getting a _lot_ of promotion. Is that all a language
needs, for it to succeed?
no. they also need large (and long-lasting) government research grants
for artifical person construction, nuclear submarine guidence software
and www-expert systems.
:-\
oz
Michael Wein
Jeffrey Mark Siskind wrote:
>
> In article <31914B7F...@math.utexas.edu> Benjamin Shults <bsh...@math.utexas.edu> writes:
>
> I thought that the advantage of Prolog in inferencing was for rule-based,
> backtracking inferencing systems. These systems really scream in Prolog.
> Lispers do have to code up a backtracking rule application system and
> Prologers, I think, do not. Inferencing systems not needing backtracking
> should be approximately as easy to code in Lisp, and sometimes easier.
I don't fully aggree with you: although you can use Prolog's built-in
backtracking mechanism to do nice things, it still has one big disadvantage
because it only supports one backtracking strategy, chronological backtracking.
As we all know, this can become very inefficient. To implement alternative,
intelligent strategies, you have to do the same work as in LISP (currently
I am finishing the implementation of a template based generator for natural
language which is implemented in Common Lisp and supports generic backtracking
with different strategies).
Michael Wein German Research Center phone: ++49(0)681/3025303
Research assistant for Artificial Intelligence fax: ++49(0)681/3025341
http://www.dfki.uni-sb.de
Christian Lynbech
>>>>> "Mark" == Mark Pedersen <ma...@cs.uq.edu.au> writes:
Mark> Someone has suggested that Lisp's CLOS might offer me what I'm
Mark> looking for, but they also suggested that Scheme might be nicer
Mark> to use if it supports CLOS. Any comments on using CLOS for NLP,
Mark> or Scheme for that matter?
I am no expert on the NLP side of things, but as to OO systems for
scheme, there is a few. On the top of my head I can remember that STk
(Scheme Tk) has OO builtin and in a fashion modelled after CLOS (and
as powerfull as I understand it). There is also a standalone system
called `meroon' which should be pretty cool and compatible with most
schemes. And there definitely is more.
The downside is (as you may have guessed from the above) that there is
no *standard* OO system in the scheme world currently. CLOS is
standard and (ought to be) supported in all CommonLisps worth their
name.
I can dig up some references if you are interested but check also the
comp.lang.scheme FAQ. It shouild have all this infomation and much
more.
Mark Pedersen
>>>>>> "Mark" == Mark Pedersen <ma...@cs.uq.edu.au> writes:
>Mark> to use if it supports CLOS. Any comments on using CLOS for NLP,
>Mark> or Scheme for that matter?
>I am no expert on the NLP side of things, but as to OO systems for
>scheme, there is a few.
Thanks - I am currently evaluating my options - will post about my
decision if people are interested.
Dorai Sitaram
[Re: OO system for Scheme that is like CLOS]
Another one is scmos, available as
ftp://cs.rice.edu/public/dorai/scmos.tar.gz.
--d
Mark Pedersen
Hmmm - looks good interesting - I'll follow it up.
Thanks,