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.
From: Staffan Larsson
Subject: Re: Future of LISP in NatLang/AI
Date:
Message-ID: <3180B324.65D3@cling.gu.se>
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
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
In article <························@ehdup-n-5.rmt.net.pitt.edu>
·······@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))
·······@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.
In article <·············@cling.gu.se> Staffan Larsson <········@cling.gu.se> writes:
>From: Staffan Larsson <········@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
In article <························@ehdup-n-5.rmt.net.pitt.edu>
·······@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: ···@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/
[This is a repost - I think my news poster stuffed up - sorry if you've
seen this before. ]
In <··········@m1.cs.man.ac.uk> ·······@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 : ·····@cs.uq.oz.au | http://student.uq.edu.au/~s303080
"When freedom destroys order, the yearning for order will destroy freedom."
Mark Pedersen wrote:
>
> In <··········@m1.cs.man.ac.uk> ·······@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?
>
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 : ·····@cs.uq.oz.au,
> Dept. Computer Science | http://www.cs.uq.edu.au/personal/markp/index.html
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 <·················@emf.net> ·····@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: ······@harlequin.com
1010 El Camino Real, #310 | http://www.harlequin.com
Menlo Park CA 94025 | http://www.cs.berkeley.edu/~russell/norvig.html
>>>>> "Mark" == Mark Pedersen <·····@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.
---------------------------+--------------------------------------------------
Christian Lynbech | Computer Science Department, University of Aarhus
Office: R0.32 | Ny Munkegade, Building 540, DK-8000 Aarhus C
Phone: +45 8942 3218 | ·······@daimi.aau.dk -- www.daimi.aau.dk/~lynbech
---------------------------+--------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- ·······@hal.com (Michael A. Petonic)
In <··············@cobalt.daimi.aau.dk> ·······@cobalt.daimi.aau.dk (Christian Lynbech) writes:
>>>>>> "Mark" == Mark Pedersen <·····@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.
Mark
--
-----------------------------------------------------------------------------
Mark Pedersen | email : ·····@cs.uq.oz.au | http://student.uq.edu.au/~s303080
"When freedom destroys order, the yearning for order will destroy freedom."
In <··········@larry.rice.edu> ·····@cs.rice.edu (Dorai Sitaram) writes:
>[Re: OO system for Scheme that is like CLOS]
>Another one is scmos, available as
>ftp://cs.rice.edu/public/dorai/scmos.tar.gz.
Hmmm - looks good interesting - I'll follow it up.
Thanks,
Mark
--
-----------------------------------------------------------------------------
Mark Pedersen | email : ·····@cs.uq.oz.au | http://student.uq.edu.au/~s303080
"When freedom destroys order, the yearning for order will destroy freedom."
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?]
>
> 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.
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.
: 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
In article <··········@usenet.srv.cis.pitt.edu>
·······@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."
From: Patrick Logan
Subject: lisp-haters-haters (Was: Re: Future of LISP in NatLang/AI)
Date:
Message-ID: <318A17F5.5822@ccm.hf.intel.com>
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!
--
···············@ccm.hf.intel.com
In article <··········@usenet.srv.cis.pitt.edu>,
·······@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
·······@engr.sgi.com
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/
In article <················@vapor.Franz.COM> ···@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!
--
<URL:http://www.enrapture.com/cybes/> "You can never browse enough."
In <············@wildcard.demon.co.uk> ············@wildcard.demon.co.uk writes:
>In article <················@vapor.Franz.COM> ···@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. [...]
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>
In article <··········@aplcenmp.apl.jhu.edu>
····@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.
--
<URL:http://www.enrapture.com/cybes/> "You can never browse enough."
Vijayaraghavan Raman (·······@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
······@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]
| 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
In article <················@arcana.naggum.no>
····@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."
Now back from hospital and recovering...
In article <················@arcana.naggum.no>
····@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...
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
In article <············@wildcard.demon.co.uk> Cyber Surfer <············@wildcard.demon.co.uk> 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".
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
In article <················@vapor.Franz.COM> ···@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>
--
<URL:http://www.enrapture.com/cybes/> "You can never browse enough."
In article <··········@grandcanyon.binc.net>
······@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!
--
<URL:http://www.enrapture.com/cybes/> "You can never browse enough."
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.
In article <··········@dfw-ixnews1.ix.netcom.com>
·······@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...
--
<URL:http://www.enrapture.com/cybes/> "You can never browse enough."
··@elissa.hc.ti.com (Paul Fuqua) writes:
>In article <············@wildcard.demon.co.uk> Cyber Surfer <············@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
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?
--
···············@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
...
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
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. :-}
In article <·················@math.utexas.edu> Benjamin Shults <·······@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)
In article <···············@elissa.hc.ti.com>
··@elissa.hc.ti.com "Paul Fuqua" writes:
> In article <············@wildcard.demon.co.uk> Cyber Surfer
> <············@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."
Now back from hospital and recovering...
>>>>> "Heiko" == Heiko 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 ······@csi.compuserve.com
--
---------------------------------------------------------------------------
Arun Welch 5000 Arlington Centre Blvd
Lead Software Engineer Columbus, OH 43220
CompuServe ······@csi.compuserve.com
Jeffrey Mark Siskind wrote:
>
> In article <·················@math.utexas.edu> Benjamin Shults <·······@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
In article <··········@fido.asd.sgi.com>
·······@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.
--
<URL:http://www.enrapture.com/cybes/> "You can never browse enough."
Now back from hospital and recovering...
In article <··············@quagmire.ghouston.actrix.gen.nz>
········@actrix.gen.nz "Gary Houston" writes:
> Erik Naggum <····@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".
--
<URL:http://www.enrapture.com/cybes/> "You can never browse enough."
>>>>> "Cyber" == Cyber Surfer <············@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 | ·······@daimi.aau.dk -- www.daimi.aau.dk/~lynbech
---------------------------+--------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- ·······@hal.com (Michael A. Petonic)
In article <··············@cobalt.daimi.aau.dk>
·······@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.
Thanks.
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough.