Lisp versus C++ for AI. software
Carlos Cid
Hi everybody,
This is a request for your opinion about the subject theme.
I'm working on Machine Learning and I wish to know your opinion about what
is the best language to implement ML. (in general AI.) software. The
discussion is focused on software for researchers, not for comercial tools.
My workgroup is now discussing what is best, but we haven't take a decission
yet. We are mainly interested in:
- Existing implemented ML. algorithms.
- An easy maintenance (easy to understand and easy for group working).
- Language standarization.
- Multiplatform support.
- Interface with graphic enviroments.
- Software Engineering methodologies developed.
We think both of them have its advantages and disadvantages. Perhaps your
experience could help us.
I know there are other good languages for AI. implementations, but we want
to restrict the discussion to Lisp and C++. Of course, you are free to aswer
this message to defend your favourite language. Any opinion is welcome.
Thank you in advance for your help.
Carlos Cid.
#-------------------------------------------#--------------------------------#
# JOSE CARLOS CID VITERO (Charlie) ITIG. | http://www.eis.uva.es/~charlie #
# Grupo de Ciencias Cognitivas Aplicadas y | mailto:cha...@dali.eis.uva.es #
# Vision por Computador. | #
# Dpt. Ingenieria de Sistemas y Automatica. | Tlf : (983) 42-33-55 42-33-58 #
# Escuela Tecnica Superior de Ingenieros | Fax : (983) 42-33-10 42-33-58 #
# Industriales. Universidad de Valladolid. | Paseo del cauce S/N. 47011 VA #
#-------------------------------------------#--------------------------------#
Benjamin Shults
I am responding to Carlos Cid's request. I am basing my opinions on my
own experience in doing something much like what he wants to do.
Carlos Cid wrote:
>
> My workgroup is now discussing what is best, but we haven't take a decission
> yet. We are mainly interested in:
>
> - Existing implemented ML. algorithms.
A lot is available for Lisp. See the CMU-AI archive.
> - An easy maintenance (easy to understand and easy for group working).
Programming language theory experts say that Lisp has the advantage over
C++ here.
> - Language standarization.
Common Lisp is an ANSI standard and many implementations have attained
or nearly attained that standard.
> - Multiplatform support.
> - Interface with graphic enviroments.
The basic common lisp language is implemented on many platforms and
common lisp code runs on all of them. If you want a fancy interface to
run an any Unix or Linux machine, that is no problem. If you want a
fancy
interface to run on any Windows(TM) machine, that is no problem. If you
want a single fancy interface to run on both Unix and Windows(TM) then
you need to do a bit more work (look into CLIM or TCL/Tk, and see the
Lisp
FAQ) but it is possible.
I suppose this is true of C++ also.
If a text-based interface is good enough, then that is perfectly
portable.
> - Software Engineering methodologies developed.
I'm not sure what you are referring to here. Lisp is a very old and
mature
language which is being used in industry all over the place. C++ is
relatively
young but it is widely used.
Lisp is a lot of fun. It's not a drag to program.
--
Benjamin Shults Email: bsh...@math.utexas.edu
Department of Mathematics Phone: (512) 471-7711 ext. 208
University of Texas at Austin WWW:
http://www.ma.utexas.edu/users/bshults
Austin, TX 78712 USA FAX: (512) 471-9038 (attn: Benjamin
Shults)
Pete Grant
On Oct 01, 1996 10:39:15 in article <Lisp versus C++ for AI. software>,
'Carlos Cid <cha...@eis.uva.es>' wrote:
This article was posted to a number of newsgroups. I'm answering from
comp.lang.c++.
If you have no other restrictions than mentioned, Lisp wins by a mile.
Yes, I'm a C++ programmer now but I still haven't seen anybody come
even close to my productivity level when I'm developing in Lisp. Of
course, this presumes a first class development environment. I still
use Symbolics Genera and to a lesser extent Franz Allegro.
The primary drawback of Lisp is deliverability to an end user. The
executable is usually very large and tends to run slow compared to
a C++ program.
I doubt, however, if any team could produce a true AI application in
C++ in twice the time an equally competent team completes the project.
Most likely, the multiplier would be closer to four than two. On the
other hand, it's probably easier finding C++ gurus than Lisp experts.
A super C++ team could conceivably give a mediocre Lisp team a run
for their money.
>Hi everybody,
>
>This is a request for your opinion about the subject theme.
>
>I'm working on Machine Learning and I wish to know your opinion about what
>is the best language to implement ML. (in general AI.) software. The
>discussion is focused on software for researchers, not for comercial
tools.
>
>My workgroup is now discussing what is best, but we haven't take a
decission
>yet. We are mainly interested in:
>
>- Existing implemented ML. algorithms.
>- An easy maintenance (easy to understand and easy for group working).
>- Language standarization.
>- Multiplatform support.
>- Interface with graphic enviroments.
>- Software Engineering methodologies developed.
>
>We think both of them have its advantages and disadvantages. Perhaps your
>experience could help us.
>
>I know there are other good languages for AI. implementations, but we want
>to restrict the discussion to Lisp and C++. Of course, you are free to
aswer
>this message to defend your favourite language. Any opinion is welcome.
>
>Thank you in advance for your help.
>
>Carlos Cid.
>#-------------------------------------------#--------------------------------#
># JOSE CARLOS CID VITERO (Charlie) ITIG. |
http://www.eis.uva.es/~charlie #
># Grupo de Ciencias Cognitivas Aplicadas y |
mailto:cha...@dali.eis.uva.es #
>
># Vision por Computador. |
#
># Dpt. Ingenieria de Sistemas y Automatica. | Tlf : (983) 42-33-55
42-33-58 #
>
># Escuela Tecnica Superior de Ingenieros | Fax : (983) 42-33-10
42-33-58 #
># Industriales. Universidad de Valladolid. | Paseo del cauce S/N. 47011
VA #
>
>#-------------------------------------------#--------------------------------#
--
Pete Grant
Kalevi, Inc.
Software Engineering & Programming
George Van Treeck
Carlos Cid wrote:
> - Existing implemented ML. algorithms.
A lot more LISP code out there -- much of it outdated though. Most
new stuff is in C++.
> - An easy maintenance (easy to understand and easy for group working).
Only very wierd people think LISP is readable... Writing obtuse
code is equally easy in either language. LISP is better for
prototyping and C++ better for production.
> - Language standarization.
Toss up.
> - Multiplatform support.
C++ is on many more vendor's platforms. Hardly any systems vendors
provide LISP -- have to rely on some small company. Due to the
much larger market for C++, it tends to be more optimized, bug free,
etc.
> - Interface with graphic enviroments.
Portable GUI frameworks are available for both LISP and C++.
Personally, I would use Java's AWT for making a 100% portable GUI
code. It can call out to C++ code for the compute intensive
portions. Java is about as fast as LISP, so you might be able
to write the whole thing in Java.
> - Software Engineering methodologies developed.
C++ wins hands down. Go to any book store with computer section.
Many books on methodologies with examples in C++ -- nothing with
examples in LISP.
You forgot one other important category -- performance. If
you ML code is very compute intensive, e.g., GA, neural nets,
etc. then C++ is the only way to go.
-George
Juliana L Holm
George Van Treeck (tre...@sybase.com) wrote:
: C++ wins hands down. Go to any book store with computer section.
: Many books on methodologies with examples in C++ -- nothing with
: examples in LISP.
LISP is a very useful language for learning about AI. It forces you to
code symbolically.
--
---------------------------------------------------------------------------
Julie Holm (ENTP)| DoD #1604 AMA#397939 UKMC# 0001 VOC# 4672
jh...@gmu.edu | 1985 Virago 700 "Maureen"
|*** Nasty Girlie Gang Armourer, Shopping Consultant,
| and Travel Agent!!!
| I'm home at http://osf1.gmu.edu/~jholm
---------------------------------------------------------------------------
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/L/IT d@ s-:- a+ C++$ UX/H/O/S+>+++$ p+ L E---() W++(+++) N+++ o? K-
w$ O M-- V PS++(--) PE@ Y+ PGP- t+(+++) !5 !X R tv-- b++ DI+ D--- G e++
h---- r+++ x++++
------END GEEK CODE BLOCK------
vanc...@ohstpy.mps.ohio-state.edu
In article <52v7nr$a...@portal.gmu.edu>, jh...@osf1.gmu.edu (Juliana L Holm) writes:
> George Van Treeck (tre...@sybase.com) wrote:
> : C++ wins hands down. Go to any book store with computer section.
> : Many books on methodologies with examples in C++ -- nothing with
> : examples in LISP.
>
> LISP is a very useful language for learning about AI. It forces you to
> code symbolically.
I am using a combination of C++ and Lisp in a current game I am writing.
The game is coded in C++, while I use a customized Lisp interpreter
for the AI. The C++ program feeds lisp commands into the interpreter
which then returns commands.
I am also able to use the interpreter to reprogram itself (i.e. learn).
I am new to Lisp myself, but I am impressed with its ability to bind
functions dynamically.
-G
Raymond Toy
George Van Treeck <tre...@sybase.com> writes:
>
> Carlos Cid wrote:
> > - Existing implemented ML. algorithms.
>
> A lot more LISP code out there -- much of it outdated though. Most
> new stuff is in C++.
>
> > - An easy maintenance (easy to understand and easy for group working).
>
> Only very wierd people think LISP is readable... Writing obtuse
A misleading statement, to put it mildly. Consider this: I know C far
better than I know Lisp. Yet, after an hour at looking at the
compiler for CMUCL, I was able to make some enhancements to it that
helps the compiler produce significantly better number code. I can't
imagine being able to do any significant change with gcc after an hour
of study, for example. The CMUCL compiler code is very well written
and extremely clear.
> code is equally easy in either language. LISP is better for
> prototyping and C++ better for production.
As Paul Graham says in "On Lisp", Lisp is like living in a rich
country, where you have to work to keep thin, but that is better
living in a poor country where thinness is a matter of course.
Ray
Norman Ma
C>I'm working on Machine Learning and I wish to know your opinion about what
C>is the best language to implement ML...
Either way, try not to use both languages. You may spend more
time on integration than research. I've worked on a project
that had to interface LISP and C++ (LISP:intelligence, c++:simulator).
The end statistics was that we spent more than 50% of labor hour
on LISP-C++ interface and close to 70% of code was written to
transoform data structure back and fourth between the 2 languages
on multiple platforms.
Project was a success, after we re-implemented the design (yes,
we actually had a design, thanks to the insistence/threat of the
customer) in a single language.
--Norman
John P DeMastri
vanc...@ohstpy.mps.ohio-state.edu wrote:
>
> I am also able to use the interpreter to reprogram itself (i.e. learn).
>
> I am new to Lisp myself, but I am impressed with its ability to bind
> functions dynamically.
>
This kind of self modifying code can be EXTREMELY difficult to debug and
especially maintain, so these features of Lisp should be used with the
utmost caution...
John DeMastri
Howard R. Stearns
George Van Treeck wrote:
>
> Carlos Cid wrote:
> > - Existing implemented ML. algorithms.
>
> A lot more LISP code out there -- much of it outdated though. Most
> new stuff is in C++.
>
> > - An easy maintenance (easy to understand and easy for group working).
>
> Only very wierd people think LISP is readable... Writing obtuse
> prototyping and C++ better for production.
Why?
>
> > - Language standarization.
>
> Toss up.
I have to disagree. Common Lisp is ANSI standardized, and there are many fine
implementations that support the standard. My experience and understanding of C++ is
that the commonality between implementations is far less than that guaranteed by ANSI
Common Lisp. Consider, for example, that ANSI Common Lisp defines run-time typing,
exception handling, stream I/O, automatic memory management, iteration, parsing
readers, advanced formatted output, file system interaction, complex number
arithmetic, non-overflowing integer arithmetic, polymorphic sequence and set
operations, ...
Some C++ implementations and/or class libraries provide many of these features (as do
Java implementations/class libraries), but I believe that there is no approved ANSI
specification for these in C++. Am I wrong?
>
> > - Multiplatform support.
>
> C++ is on many more vendor's platforms. Hardly any systems vendors
> provide LISP -- have to rely on some small company. Due to the
> much larger market for C++, it tends to be more optimized, bug free,
> etc.
My PERSONAL experience is that commercial Common Lisp implementations are of higher
quality and have much less significant bugs than commercial C++ implementations --
better even than C implementations from some large vendors. Perhaps other people have
had a different experience?
>
> > - Interface with graphic enviroments.
>
> Portable GUI frameworks are available for both LISP and C++.
> Personally, I would use Java's AWT for making a 100% portable GUI
> code. It can call out to C++ code for the compute intensive
> portions. Java is about as fast as LISP, so you might be able
> to write the whole thing in Java.
>
> > - Software Engineering methodologies developed.
>
> C++ wins hands down. Go to any book store with computer section.
> Many books on methodologies with examples in C++ -- nothing with
> examples in LISP.
It is sometimes said that those who can't do, teach; those that can't teach, write
books; those that can't write, give seminars.
If we are to judge by teaching at leading computer science universities, we should all
be writing in Scheme -- a dialect of Lisp that some might argue does not have direct
support for OO methodologies at all, and yet which is often used to teach the core
concepts of OO programming.
(If we are to judge by seminars, then you must use Java/Powerbuilder/VisualBasic.)
Some issues in favor of Common Lisp as providing direct support for OO methodologies
are:
- Methods and classes are themselves first class objects. This is tremendously
important for creating tools which analyse the relationships between objects.
- Direct support for multi-methods.
- Direct support for objectizing method combination semantics.
- No syntactical distinction between method invocation and other function calls.
- A Meta-Object-Protocol which provides the ability to change the way the object
system works. Admitedly, this is not part of the ANSI standard, but most
implementations provide some support for this de-facto standard.
- A macro facility which provides support for defining new languages which provide
explicit, enforced support for a PARTICULAR methodology. Some commercial products
CAD systems, knowledge servers, etc.) are actually implemented by Lisp macros
which provide and enforce the methodology used by the product, sometimes combined
with portable modifications to the standard reader that provide a non-lispy syntax
for these macros.
An issue against Common Lisp as providing direct support for OO methodologies is that,
as defined by ANSI, methods may be syntactically separated from the objects which
specialize their behavior. This upsets some people's notions of encapsulation. Of
course, the macro facility can be used to define new constructions which provide such
enforced syntactic encapsulation. (I spent many years on a commercial knowledge based
engineering system which did this.) (To be fair, there are other encapsulation issues
which some people have with Common Lisp. These are discussed in the book I cite,
below.)
There are other languages (Sather) which are intended to provide very explicit support
for certain OO methodologies.
An excellent reference on the issues involved in OO programming in Common Lisp is:
"Object Oriented Programming, the CLOS Perspective", edited by Andreas Paepcke.
MIT Press, 1993.
Here are the articles it includes (CLOS is the Common Lisp Object System):
-An Introduction to CLOS
-CLOS in Context: The Shape of the Design Space
-User-Level Language Crafting: Introducing the CLOS Metaobject Protocol
-Metaobject Protocols: Why We Want Them and What Else They Can Do
-Metaobject Programming in CLOS
-The Silica Window System: The Metalevel Approcach Applied More Broadly
-CLOS and C++
-CLOS, Eifel, and Sather
-CLOS and Smalltalk
-Documenting Protocols in CLOS: Keeping the Promise of REuse
-CLOS & LispView: Users' Experiences Distilled
-Using CLOS to Implement a Hybrid Knowledge Representation Tool
-TICLOS: An Implmentation of CLOS for the Explorer Family
-Efficient Method Dispatch in PCL
Note that there are several comparisons with other languages, including C++.
>
> You forgot one other important category -- performance. If
> you ML code is very compute intensive, e.g., GA, neural nets,
> etc. then C++ is the only way to go.
Why?
>
> -George
Carl L. Gay
From: George Van Treeck <tre...@sybase.com>
Date: Wed, 02 Oct 1996 14:15:10 -0700
> - An easy maintenance (easy to understand and easy for group working).
Only very wierd people think LISP is readable...
This is a ridiculous and inflamatory statement.
> - Interface with graphic enviroments.
Portable GUI frameworks are available for both LISP and C++.
Personally, I would use Java's AWT for making a 100% portable GUI
code. It can call out to C++ code for the compute intensive
portions. Java is about as fast as LISP, so you might be able
to write the whole thing in Java.
On what do you base this last statement? Do you have benchmarks? Are
you comparing Java to interpreted or compiled Lisp? I would be amazed
if Java were as fast as compiled Common Lisp code.
vanc...@ohstpy.mps.ohio-state.edu
Well, I should have clarified that the routines can be reprogrammed by
the C++ program which calls it (the interpreter isn't directly
reprogramming itself, rather it will). AT any rate, I haven't really
tried any of that yet, since I am still getting basic stuff working.
My point was that generic functions can be changed without having to
recompile the code. My ultimate objective is to have user-programmable
doctrines (using some sort of natural language interface) to
control fleets and other necessary but repetitive maintennce tasks.
I also defined a new defun and defmacro set of functions which
call defun and defmacro, but also keep a list of fun/macro names
which can be accessed later and written to disk during shutdown...
Oh well, I am using Lisp because these kinds of tasks would be a nightmare
in c/c++, and I enjoy being able to playu with AI modifications
directly while the host program is running.
(Sorry for the waste of bandwidth...)
-G
>
> John DeMastri
John Nagle
"Howard R. Stearns" <how...@elwoodcorp.com> writes:
>I have to disagree. Common Lisp is ANSI standardized, and there are many fine
>implementations that support the standard. My experience and understanding of C++ is
>that the commonality between implementations is far less than that guaranteed by ANSI
>Common Lisp.
He's right. ANSI C code is quite portable, and Common LISP code is
quite portable, but C++ is still in flux. There's lots of little
stuff that's gone in since the ARM, and various compilers have various
subsets of the new features. The ANSI committee needs to get the
standard out the door while people still care about it.
Java may be the next AI language. Java is actually closer to LISP
than is generally realized.
John Nagle
Steve Brecher
t...@intentionally.blank-see.headers wrote:
> In article <3253F13C...@elwoodcorp.com> "Howard R. Stearns"
<how...@elwoodcorp.com> writes:
[snip]
> Some C++ implementations and/or class libraries provide many of these
features (as do
> Java implementations/class libraries), but I believe that there is no
approved ANSI
> specification for these in C++. Am I wrong?
>
> The ANSI C++ standard provides a lot of that functionality in one way
> or another (but geared towards entirely different application areas).
> ANSI C++ doesn't have to bother with standardizing a lot of external
> interfaces because other people are doing the work: POSIX, X11,
> Win32/Open32, and lots of smaller APIs are expressed in C already.
> [...]
Howard Stearns correct: there is as yet no ANSI C++ standard; the
proposed standard is in progress, and -- based on my reading of some
relevant newsgroups -- implementations which correctly and completely
implement the current draft of the standard are at best rare.
It is common for C++ programmers (including myself) to speak of "the ANSI
C++ standard" but that is shorthand for "the current draft working paper
of the standardization committee."
--
st...@brecher.reno.nv.us (Steve Brecher)
Rainer Joswig
In article <TMB.96Oc...@best.best.com>,
t...@intentionally.blank-see.headers wrote:
> Yes, the fact that Lisp-C++ interfaces take that much code is a
> problem, but trying to avoid it by not interfacing with C/C++ at all
> is throwing out the baby with the bathwater. There are too many
> useful libraries with C APIs out there that you can't reimplement.
> You may take the academic stance that you don't want to interface with
> all that icky stuff, but all the languages that succeed have those
> interfaces. Lisp vendors must address this issue better:
Agreed.
> (1) They should include many more Fortran/C/C++ libraries already
> interfaced to their systems. This includes image I/O, video,
> audio, databases, compression, Web protocols, etc., both vendor
> specific (eg. SGI's libraries, Windows) and vendor neutral (third
> party, reference implementations). There is nothing that will be
> more discouraging to a potential customer than having to spend a
> few weeks building tools that they get automatically and for free
> with other systems before they can start solving their problems.
> Where are the Tools.h++, Linpack.h++, and Socket.h++ wrapper
> libraries of the CommonLisp world?
MCL accesses almost everything on the Mac (the complete toolbox
and standard shared libraries). Compile your stuff with
the usual compilers as a shared library and call it
from Lisp. People are doing this all the time.
> (2) By making FFI a lot easier. This includes automatic parsing
> of C/C++ header files, conservative stack marking, C++ classes
> to manipulate Lisp values, etc. One may not like it (I
> certainly don't), but current APIs are almost all build around C,
> with a little bit of C++ and Fortran.
Every bit of the above paragraph is true (IMHO).
> (3) By standardizing at least a portable subset of FFI facilities.
> There are only two vendors left.
Digitool, Franz, Harlequin, Symbolics. Four, isn't it? Are
there any others (GoldHill, Venue, ...)?
Poplog includes a CL implementation.
> I guess if one of them goes
> out of business, we have standardization in the commercial
> implementations :-( Seriously, to avoid that, addressing this
> issue would be a good idea.
Sure. We need a common approach for FFIs.
> Systems like ILU and CORBA provide a partial solution, but they
> are still distinct from a true, low-overhead FFI.
Well, Digitool is currently developing support for OpenDoc
for MCL. For this purpose IDL/SOM support is needed. This could
be the FFI we are looking for. Better to have one approach
on that particular topic.
Greetings,
Rainer Joswig
Rainer Joswig
Rainer Joswig
> portable, machine independent platform, for many more applications
> (e.g., WWW, UI, semi-numerical), CL is, in practical terms,
> considerably less well standardized than C++, since those applications
> require facilities that simply aren't addressed by the current CL
> standard.
Which facilities are you thinking of and where are these
"standards" for C++?
Greetings,
Rainer Joswig
R. Glen Garner
Carlos Cid wrote:
>
> Hi everybody,
>
Here's my opinion: Go with C++ and don't rule out Java
> - Existing implemented ML. algorithms.As stated earlier, more examples in Lisp but they may be "older"
C++ and Java can both utilize processes written in C.
> - An easy maintenance (easy to understand and easy for group working).C++ is OO, good for maintenance and group working, same with Java.
> - Language standarization.I should think this would be of less importance for research purposes than it
would be for commercial distribution of a product. Also, current trends indicate
that C++ will become more and more standardized.
> - Multiplatform support.yep.
> - Interface with graphic enviroments.C++ and Java both lend themselves to graphical development.
> - Software Engineering methodologies developed.yep.
Java is a clear choice in developing applications for the web. C++ has
a speed advantage running locally, but if your application requires more
speed than Java has to offer, you can always use C as your workhorse doing
the intensive stuff.
--Robby Garner
http://www.fringeware.com/usr/robitron
Scott Musman
>Yes, the fact that Lisp-C++ interfaces take that much code is a
>problem, but trying to avoid it by not interfacing with C/C++ at all
>is throwing out the baby with the bathwater.
You might want to take a look at what ILOG has tried to do with their
Talk product. It specifically attempts to tackle the issue of mixing the
best features of the different languages, ISO Lisp and C/C++ in a
seamless way. It also helps you with the application delivery problem
too.
I haven't actually used their product (I've only browsed some of
the documentation), but a free version of it is available for Linux
that you can down-load and evaluate.
-- Scott
John David Stone
t...@intentionally.blank-see.headers writes:
> In article <steve-03109...@brecher.reno.nv.us>,
> st...@brecher.reno.nv.us (Steve Brecher) writes:
>
> Vendors have been
> working hard to implement the "draft" ANSI C++ standard, there are
> numerous textbooks explaining it, ...
Very amusing. The best part of the draft standard, as opposed to
existing implementations of C++, is the Standard Template Library. Of the
scores of introductory C++ textbooks currently on the market, I'll bet
there aren't half a dozen that so much as tell the student what's _in_ the
Standard Template Library, let alone how to use it correctly. Accurate
coverage of function objects is even rarer. And far more textbooks give
complete C++ source code for the bubble sort (!) than mention the sort()
function from the algorithm library.
--
====== John David Stone - Lecturer in Computer Science and Philosophy =====
============== Manager of the Mathematics Local-Area Network ==============
============== Grinnell College - Grinnell, Iowa 50112 - USA ==============
========== st...@math.grin.edu - http://www.math.grin.edu/~stone/ =========
Steve Brecher
John David Stone <st...@math.grin.edu> wrote:
> t...@intentionally.blank-see.headers writes:
>
> > In article <steve-03109...@brecher.reno.nv.us>,
> > st...@brecher.reno.nv.us (Steve Brecher) writes:
> >
> > Vendors have been
> > working hard to implement the "draft" ANSI C++ standard, there are
> > numerous textbooks explaining it, ...
Please be careful with quotes/attributions, folks. The "Vendors..."
statement was written by t...@intentionally.blank-see.headers in a followup
in which he did in fact quote me, but John David Stone's followup fails to
note that he (John David Stone) is quoting selectively. The inclusion of
"> In article ... Steve ... writes:" in the quote was unnecessary and
misleading -- which is not to say I think it was other than an innocent
error.
> Very amusing. The best part of the draft standard, as opposed to
> existing implementations of C++, is the Standard Template Library. Of the
> scores of introductory C++ textbooks currently on the market, I'll bet
> there aren't half a dozen that so much as tell the student what's _in_ the
> Standard Template Library, let alone how to use it correctly. Accurate
> coverage of function objects is even rarer. And far more textbooks give
> complete C++ source code for the bubble sort (!) than mention the sort()
> function from the algorithm library.
I originally pointed out that the C++ standard is in process -- not final
-- because it is in fact an issue in my own work with C++. My vendor is
indeed working hard (as best I can tell :) but I don't as yet have an
implementation of the current draft standard nor of the Standard Template
Library that I consider appropriate for production use. The last time I
used LISP was eons before there was a CL, but -- if standardization is the
only criterion -- CL would have to get the nod over C++ right now.
--
st...@brecher.reno.nv.us (Steve Brecher)
Oleg Moroz
On 04 Oct 1996 15:03:44 -0500, John David Stone <st...@math.grin.edu> wrote:
>> Vendors have been
>> working hard to implement the "draft" ANSI C++ standard, there are
>> numerous textbooks explaining it, ...
>
> Very amusing. The best part of the draft standard, as opposed to
>existing implementations of C++, is the Standard Template Library. Of the
>scores of introductory C++ textbooks currently on the market, I'll bet
>there aren't half a dozen that so much as tell the student what's _in_ the
>Standard Template Library, let alone how to use it correctly. Accurate
>coverage of function objects is even rarer. And far more textbooks give
>complete C++ source code for the bubble sort (!) than mention the sort()
>function from the algorithm library.
Well, I won't go deep into discussing STL (in my opinion it's really pretty good
does what it was intended for - to show that templates and generic programming
can be used to make C++ libraries more flexible and useful - but it's too weak
and non-obvious to use to be included in the standard), but isn't the purpose of
the textbooks on C++ to teach the student program in C++ first ? And the bubble
sort, while being one of the worst sorting methods, can be used just nice to
demonstrate many of the C++ (and most other procedural/hybrid languages)
features. I think that the standard library (streams, STL, etc) should be taught
much after the first principles, if at all, at least its crrent usability is
pretty low, when comparing with, say MFC and OWL.
Oleg
William Paul Vrotney
In article <udranea...@post.math.grin.edu> John David Stone <st...@math.grin.edu> writes:
>
> Very amusing. The best part of the draft standard, as opposed to
> existing implementations of C++, is the Standard Template Library. Of the
> ...
STL is *not* good at all for doing AI software. There are no symbols, no
singly liked lists, no conses, and nothing for building heterogeneous
structures. You can try imitating some of this with STL's version of doubly
linked lists and virtual functions, but it feels like you are forcing you
algorithms to be awkward because of the limitations of C++. Iterators seem
to be fit better with arrays but make list operations awkward.
--
William P. Vrotney - vro...@netcom.com
John David Stone
Oleg Moroz writes:
> Well, I won't go deep into discussing STL, ... but isn't the
> purpose of the textbooks on C++ to teach the student program in C++
> first?
Under the draft ANSI standard, STL is part of C++. It's just as
much part of C++ as, say, cout or pow(). A C++ textbook that doesn't cover
the STL is about as useless as one that doesn't mention streams or the math
library.
One of the first lessons that novice programmers should learn is
the one about not re-inventing the wheel. C++ textbooks that spend half of
their pages laboriously constructing poorly-designed versions of classes
that are already in the STL are setting a very bad example.
> And the bubble sort, while being one of the worst sorting
> methods, can be used just nice to demonstrate many of the C++ (and most
> other procedural/hybrid languages) features.
True. So can insertion sort, selection sort, merge sort, or quick
sort, any of which would be a better choice of example than bubble sort --
provided of course that students also learn that they should use sort()
instead in most cases.
David Seibert
In article <ud7mp2h...@post.math.grin.edu> John David Stone <st...@math.grin.edu> writes:
>
> One of the first lessons that novice programmers should learn is
>the one about not re-inventing the wheel. C++ textbooks that spend half of
>their pages laboriously constructing poorly-designed versions of classes
>that are already in the STL are setting a very bad example.
Point taken. However, example code for classes that are already in
standards is relatively easy to find, and textbook authors don't want to
reinvent the wheel, either. Until someone writes a book with better
examples, authors won't change their behavior (and then they'll just try to
copy the better book :-). Plus, if an author came up with really useful
example classes, he/she could probably make more money by *not* publishing
them in a textbook before they had already been implemented by someone who
would pay real money for the privilege.
David Seibert
George Van Treeck
William Paul Vrotney wrote:
>
> STL is *not* good at all for doing AI software. There are no symbols, no
> singly liked lists, no conses, and nothing for building heterogeneous
> structures.
Symbols, linked lists, consing, etc. are a wasted effort by people
who know little about neuropsych and figure they could use
introspection to deduce and brain functions. All programs that
use such methods have been complete failures at such simple things
as recognizing a hand written characters, voice recognition, etc.
I haven't seen any interesting software written in a symbol
processing language in last 7 years.
The only software (and hardware) that has ever had any success at
all with these "intellegence" problems are those that emulate
neural structures to some degree. And NONE of that software
does it "symbolically." That software is number crunching
software -- generally written in a language like C or C++.
And even if you were to do symbolic processing for say,
parsing natural language text, a language like Prolog is
far superior to Lisp!
-George
George Van Treeck
Carl L. Gay wrote:
>
> From: George Van Treeck <tre...@sybase.com>
> Date: Wed, 02 Oct 1996 14:15:10 -0700
>
> > - An easy maintenance (easy to understand and easy for group working).
>
> Only very wierd people think LISP is readable...
>
> This is a ridiculous and inflamatory statement.
It's only rediculous and inflamatory to those in love with Lisp.
It's like telling a mother her child is ugly. Those without
vested interest will simply nod and read on.
>
> > - Interface with graphic enviroments.
>
> Portable GUI frameworks are available for both LISP and C++.
> Personally, I would use Java's AWT for making a 100% portable GUI
> code. It can call out to C++ code for the compute intensive
> portions. Java is about as fast as LISP, so you might be able
> to write the whole thing in Java.
>
> On what do you base this last statement? Do you have benchmarks? Are
> you comparing Java to interpreted or compiled Lisp? I would be amazed
> if Java were as fast as compiled Common Lisp code.
I base the statement on some background in writing interpreters and
compilers. The methods are for byte code interpreters and JIT
compilers is pretty mature and there won't be big differences.
Java JIT compilers are appearing now on Macs, PCs, and some UNIX
workstations. It won't be long until Java JIT compilers much
prevalent on all vendor's computers and performance will be in
the same ballpark.
Bottom line: The proof of which is better (C++ or Lisp) is to
look at the commercially successful applications. If Lisp is such
a hot language, how come most applications are all written in C and
C++? Is that that Lisp is not used because it's difficult to read
and maintain? Is Lisp's problem lack of performance, portability,
what? Must be some major weaknesses.
-George
William Paul Vrotney
>
> William Paul Vrotney wrote:
> >
> > STL is *not* good at all for doing AI software. There are no symbols, no
> > singly liked lists, no conses, and nothing for building heterogeneous
> > structures.
>
> Symbols, linked lists, consing, etc. are a wasted effort by people
> who know little about neuropsych and figure they could use
> introspection to deduce and brain functions. All programs that
> use such methods have been complete failures at such simple things
> as recognizing a hand written characters, voice recognition, etc.
> I haven't seen any interesting software written in a symbol
> processing language in last 7 years.
>
> The only software (and hardware) that has ever had any success at
> all with these "intellegence" problems are those that emulate
> neural structures to some degree. And NONE of that software
> does it "symbolically." That software is number crunching
> software -- generally written in a language like C or C++.
I was not talking about brain functions. I just have a need to implement
basic AI algorithms. Perhaps you should write a book to help some of us
understand how we can replace all AI algorithms with neural nets.
Erik Naggum
[George Van Treeck]
| Bottom line: The proof of which is better (C++ or Lisp) is to look at
| the commercially successful applications.
this is obviously a convenient argument as long as what you already think
is better is also commercially successful. however, is your taste in music
or entertainment equally likely to argue for "commercially successful" over
other qualities? when does "commercially successful" break down as _the_
argument to support something? my take: when what you think is best is not
the most commercially successful thing around, or when what you think is
commercially successful is bad for some reason or another, like drugs.
it is extremely interesting to watch people who argue for the choice of the
"people" or the "market" through whatever is "commercially successful", and
see their arguments against things they don't like (popular music), think
are immoral (pornography), or otherwise find reasons to consider exceptions
to their sure-fire rule of quality.
in other words, the "commercially successful" argument is a statement of
shallowness on the part of he who uses that argument.
| If Lisp is such a hot language, how come most applications are all
| written in C and C++?
I have news for you: they are not written in C or C++, either.
| Is that that Lisp is not used because it's difficult to read and
| maintain? Is Lisp's problem lack of performance, portability, what?
| Must be some major weaknesses.
yes, there are major weaknesses, but as with everything else in our market
society, perception is more important than facts. for instance, the
negative attitude among programmers to languages they were taught by people
who didn't know them, and perpetuated myths about Lisp instead of teaching.
include in this "attitude problem" such articles as your own that display
no interest in learning facts about Lisp, but instead insist on finding
mostly invalid reasons not to look at it. no matter how good the language
is, the kind of marketing that would be necessary to convince you to look
at Lisp has nothing to do with your actual arguments against it.
if C and C++ are so hot, how come they haven't always been? how did they
become hot? how did they overcome the "how come most applications are all
written in Fortran and Cobol" argument? how does Java face the same
argument?
I hope you see that your line of argumentation is utterly without merit and
relevance -- the sorry fact is that it is only useful as long as your
audience already agrees with you before you started to argue. since your
audience is largely made up of people who have never looked seriously at
any other programming languages, they won't even stop to think that your
invalid argument is invalid. and _that's_ how C and C++ manage to live on,
regardless of their obvious costs and problems.
#\Erik
--
I could tell you, but then I would have to reboot you.
scha...@wat.hookup.net
In <30538559...@naggum.no>, Erik Naggum <er...@naggum.no> writes:
>[George Van Treeck]
>
>| Bottom line: The proof of which is better (C++ or Lisp) is to look at
>| the commercially successful applications.
Not so long ago this argument could have been used (in the PC world) to
demonstrate the superiority of Basic.
Hartmann Schaffer
Tom Fawcett
> a hot language, how come most applications are all written in C and
> and maintain? Is Lisp's problem lack of performance, portability,
> what? Must be some major weaknesses.
Actually, most commercial applications are written in COBOL.
What does that say about the quality of C and C++ ?
Must be some major weaknesses!
"popularity=quality" is never a very good argument.
-Tom
Cyber Surfer
> >| Bottom line: The proof of which is better (C++ or Lisp) is to look at
> >| the commercially successful applications.
>
> Not so long ago this argument could have been used (in the PC world) to
> demonstrate the superiority of Basic.
It still is. ;-) It's actually tools like form designers that
make a particular Basic (um, like VB) popular. Now, if Bill Gates
felt the same way about Lisp as he does about Basic, we might
not be having this discussion.
Now, just imagine what we might be comparing Lisp with if Unix
had been written in BCPL. Objective BCPL? Hmm.
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
Future generations are relying on us
It's a world we've made - Incubus
We're living on a knife edge, looking for the ground -- Hawkwind
Glen Clark
Erik Naggum wrote:
> I hope you see that your line of argumentation is utterly without merit and
> relevance -- the sorry fact is that it is only useful as long as your
> audience already agrees with you before you started to argue. since your
> audience is largely made up of people who have never looked seriously at
> any other programming languages, they won't even stop to think that your
> invalid argument is invalid. and _that's_ how C and C++ manage to live on,
> regardless of their obvious costs and problems.
much on the substance. But I can't help but notice the vigor.
Even though it is not his native cause, I wonder if we could
hire him as a mercinary for comp.lang.fortran.vs.C which has
been raging at a different place on your radio dial since before
the Serbs hated the Croats. Such vigor! ;)
--
Glen Clark
gl...@clarkcom.com
Cyber Surfer
In article <325B01...@sybase.com>
tre...@sybase.com "George Van Treeck" writes:
> Bottom line: The proof of which is better (C++ or Lisp) is to
> look at the commercially successful applications. If Lisp is such
> a hot language, how come most applications are all written in C and
> C++? Is that that Lisp is not used because it's difficult to read
> and maintain? Is Lisp's problem lack of performance, portability,
> what? Must be some major weaknesses.
I suspect it's because C++ has some major money behind it,
and a significant amount of it is being poured into marketing.
Lisp's image suffers because of this.
If you saw endless adverts for C++ compilers, tools, magazines,
and endless articles about using C++, and very little about Lisp,
what would _you_ think? Esp if you knew little or nothing about
Lisp, but already used C++.
George Van Treeck
Erik Naggum wrote:
>
> [George Van Treeck]
>
> | Bottom line: The proof of which is better (C++ or Lisp) is to look at
> | the commercially successful applications.
>
> is better is also commercially successful. however, is your taste in music
> or entertainment equally likely to argue for "commercially successful" over
> other qualities? when does "commercially successful" break down as _the_
> argument to support something? my take: when what you think is best is not
> the most commercially successful thing around, or when what you think is
> commercially successful is bad for some reason or another, like drugs.
That's a very good point! If you're a professor in some ivory tower
you can afford to savor your favorite computer language. If you
develop software that must be sold to put food on your plate, then
you become much more conservative! Your definition of best becomes
more dominated in terms of what is the "safe" choice. And the
safe choice is one that is popular -- has support from many vendors,
books, lots of staff you hire that already know the lanugage, etc.
That means your favorite is something commercially successful.
You know that if it's commercially successful, that there is a
high probability you can get the project out the door with sufficient
quality to sell it.
>
> in other words, the "commercially successful" argument is a statement of
> shallowness on the part of he who uses that argument.
It is not shallowness. It's pragmatism.
>
> | If Lisp is such a hot language, how come most applications are all
> | written in C and C++?
>
> I have news for you: they are not written in C or C++, either.
What language do you think the product comprising Microsoft Office
or Claris Works are written in? What about the latest version
Autodesk's 3D software? Relational DBMS from Oracle, Sybase and
Informix? Electronics design tools from Cadence, Mentor Graphics,
Viewlogic, etc.?
Name some commercial applications written in Common Lisp. A
couple of expert system shells is about it.
If you go to an engineering manager and propose a product, do
you think the manager will agree to using a language that no
one else uses to get product out the door? Get real.
>
> | Is that that Lisp is not used because it's difficult to read and
> | maintain? Is Lisp's problem lack of performance, portability, what?
> | Must be some major weaknesses.
>
> yes, there are major weaknesses, but as with everything else in our market
> society, perception is more important than facts. for instance, the
> negative attitude among programmers to languages they were taught by people
> who didn't know them, and perpetuated myths about Lisp instead of teaching.
> include in this "attitude problem" such articles as your own that display
> no interest in learning facts about Lisp, but instead insist on finding
> mostly invalid reasons not to look at it. no matter how good the language
> is, the kind of marketing that would be necessary to convince you to look
> at Lisp has nothing to do with your actual arguments against it.
It's not myths. At Digital, a CAD tool was written in Lisp and dumped
because it Lisp was just too slow. Lisp can't be used in real-time
applications, because you need to guarantee response time. A 911
call needs to routed over the phone lines and can't afford to wait
for Lisp program to take a coffee brake (garbage collect for some
indeterminate period). And the code size is too large to be
quickly activated and used for small utility applications. Perl,
Tcl, C/C++ are used instead.
It's not that Lisp is "bad." The issue is range of applications
where Lisp clearly excels. That range of applications is so small
that only a few of very small companies can afford to develop
and support Lisp.
>
> if C and C++ are so hot, how come they haven't always been? how did they
> become hot? how did they overcome the "how come most applications are all
> written in Fortran and Cobol" argument? how does Java face the same
> argument?
Applications written many years ago were done in FORTRAN and COBOL.
Today, many large computer vendors and software companies don't
even sell COBOL because it's too small a market! They OEM COBOL
from some small compiler company. FORTRAN and COBOL are sold
mostly to maintain legacy software. For example, Microsoft
OEMs it's FORTRAN and COBOL.
Virtually all new commercial applications are developed in C/C++.
If you worked in the "real-world" (companies that develop
commercial software) you know that. Look in the new paper for
programming jobs. Count the number of ads wanting C/C++ vs.
FORTRAN/COBOL.
Many in-house applications are being developed in VisualBasic
or some 4GL/GUI tool like PowerBuilder, because it requires
less technical skill ($25/hr labor for VisualBASIC programmer
vs. $60/hr for C++ programmer) and development is quicker
using something like PowerBuilder. Lisp could never
cut it in that market either.
-George
Douglas Blank
George Van Treeck wrote:
> Bottom line: The proof of which is better (C++ or Lisp) is to
> look at the commercially successful applications. If Lisp is such
> a hot language, how come most applications are all written in C and
> C++? Is that that Lisp is not used because it's difficult to read
> and maintain? Is Lisp's problem lack of performance, portability,
> what? Must be some major weaknesses.
Ah, yeah. By that measure, COBOL is the best language, followed closely
by Fortran 77, and then Visual Basic. Lisp doesn't have much marketing
force. I'll wagger a pretty penny that the language that you'll be using
the most in the next few years will have a lot more in common with
Lisp than C++ (i.e., Java).
You really can't answer the original question anyway. It's like asking
"what is the best human language in which to talk about poetry?" They
all are different, have pros and cons, but when it comes down to it,
use the one you know and your friends speak.
-Doug
>
> -George
--
=====================================================================
dbl...@comp.uark.edu Douglas Blank, University of Arkansas
Assistant Professor Computer Science
==================== http://www.uark.edu/~dblank ====================
Seth Tisue
In article <325C60...@sybase.com>,
George Van Treeck <tre...@sybase.com> wrote:
>Erik Naggum wrote:
>> if C and C++ are so hot, how come they haven't always been? how did they
>> become hot? how did they overcome the "how come most applications are all
>> written in Fortran and Cobol" argument? how does Java face the same
>> argument?
>
>Applications written many years ago were done in FORTRAN and COBOL.
>Today, many large computer vendors and software companies don't
>Virtually all new commercial applications are developed in C/C++.
>If you worked in the "real-world" (companies that develop
>commercial software) you know that.
You're missing the point here. Of course FORTRAN/COBOL are a thing of
the past, everyone knows that (do you really think your opponents in
this argument are so ignorant? please!). The point is, there once was
a day when they were the dominant languages, and C and Smalltalk (the
original source of the OOP ideas in C++) were funny little obscure
languages used only by researchers and idealistic hackers, exactly the
"ivory tower" types at which you seem to be so angry. Then, gradually
over time, the situation changed, and today C and C++ occupy the
position that FORTRAN and COBOL used to occupy.
When people argue today for non-dominant languages like Lisp or Eiffel
or whatever, we are not arguing that all real-world commercial
developers should immediately drop all their C/C++/VB development and
switch to the new language. We know this is not immediately possible
or practical. We are not that stupid! What we are doing is arguing
for change, the kind of long term sea change that eventually caused
C/C++ to supplant FORTRAN/COBOL. Change will happen. C/C++ will not
last forever. The argument is over what direction change will take.
--
== Seth Tisue <s-t...@nwu.edu> http://www.cs.nwu.edu/~tisue/
Howard R. Stearns
I admit that this is way off from relevant to the original posting, and
I appologize for furthering the thread and not pruning groups, but I ask
two questions that a large distribution might help answer.
George Van Treeck wrote:
> ...
> What language do you think the product comprising Microsoft Office
> or Claris Works are written in? What about the latest version
> Autodesk's 3D software? Relational DBMS from Oracle, Sybase and
> Informix? Electronics design tools from Cadence, Mentor Graphics,
> Viewlogic, etc.?
>
> Name some commercial applications written in Common Lisp. A
> couple of expert system shells is about it.
I guess I'm confused. I was under the impression that the really hard
parts of three of products you mention ARE written in Lisp. (From
Autodesk, Oracle, Viewlogic). I would add Parametric Technologies and
Cognition. Can anyone who actually knows tell us? Anyway, check out
the customer pages of vendors such as Franz and Digitool.
>
> ...
> It's not myths. At Digital, a CAD tool was written in Lisp and dumped
> because it Lisp was just too slow. Lisp can't be used in real-time
> applications, because you need to guarantee response time. A 911
> call needs to routed over the phone lines and can't afford to wait
> for Lisp program to take a coffee brake (garbage collect for some
> indeterminate period). And the code size is too large to be
> quickly activated and used for small utility applications. Perl,
> Tcl, C/C++ are used instead.
Actually, there ARE real-time garbage collectors, I believe that one is
used in Lucent's (formerly Bell Labs) new real-time network switching
system. I don't know if American Express is using a real-time gc, but I
would think that it's credit card order processing system would count as
real-time. Again, maybe someone who has direct experience can tell us.
As for start up times, gcl, ecl, and cmucl all start up in less than one
second. That compares pretty favorably with VB and large C++ apps. One
might also use a "lisp server" to run small utilities. This gives you
zero start up time plus lets you retain state between invocations of
small utilities.
Carl L. Gay
From: George Van Treeck <tre...@sybase.com>
Newsgroups: comp.ai,comp.ai.genetic,comp.ai.neural-nets,comp.lang.lisp,comp.lang.c++
Date: Tue, 08 Oct 1996 18:34:26 -0700
> Only very wierd people think LISP is readable...
>
> This is a ridiculous and inflamatory statement.
It's only rediculous and inflamatory to those in love with Lisp.
It's like telling a mother her child is ugly. Those without
vested interest will simply nod and read on.
It's inflammatory to those who find Lisp extremely readable, not those
in love with Lisp. Calling someone extremely weird because they can
understand something you can't is ridiculous, or at best childish
(like this argument).
> Portable GUI frameworks are available for both LISP and C++.
> Personally, I would use Java's AWT for making a 100% portable GUI
> code. It can call out to C++ code for the compute intensive
> portions. Java is about as fast as LISP, so you might be able
> to write the whole thing in Java.
>
> On what do you base this last statement? Do you have benchmarks? Are
> you comparing Java to interpreted or compiled Lisp? I would be amazed
> if Java were as fast as compiled Common Lisp code.
I base the statement on some background in writing interpreters and
compilers. The methods are for byte code interpreters and JIT
compilers is pretty mature and there won't be big differences.
Java JIT compilers are appearing now on Macs, PCs, and some UNIX
workstations. It won't be long until Java JIT compilers much
prevalent on all vendor's computers and performance will be in
the same ballpark.
I assumed you were comparing Java byte-code interpreters with Lisp
compilers since JIT compilers still aren't widely used. Not an
entirely unreasonable assumtion, I guess, since you haven't actually
done the comparison. Of course I realize that compiled Java can be
just as fast.
Erik Naggum
[George Van Treeck]
| That's a very good point! If you're a professor in some ivory tower
| you can afford to savor your favorite computer language. If you
| develop software that must be sold to put food on your plate, then you
| become much more conservative! Your definition of best becomes more
| dominated in terms of what is the "safe" choice. And the safe choice
| is one that is popular -- has support from many vendors, books, lots of
| staff you hire that already know the lanugage, etc. That means your
| favorite is something commercially successful. You know that if it's
| commercially successful, that there is a high probability you can get
| the project out the door with sufficient quality to sell it.
in other words, the specific _language_ you use is utterly irrelevant. it
could be Cobol or APL or C or Java or whatever, as long as it is "safe" and
all those other parameters are present. you argued that C and C++ were
better languages because they were commercially successful. in fact, you
have argued for the irrelevancy of the choice of programming language
compared to other factors that complely overshadow language merit.
David Finton
cyber_...@wildcard.demon.co.uk (Cyber Surfer) writes:
>In article <325B01...@sybase.com>
> tre...@sybase.com "George Van Treeck" writes:
>> Bottom line: The proof of which is better (C++ or Lisp) is to
>> look at the commercially successful applications. If Lisp is such
>> a hot language, how come most applications are all written in C and
>> C++? Is that that Lisp is not used because it's difficult to read
>> and maintain? Is Lisp's problem lack of performance, portability,
>> what? Must be some major weaknesses.
Maybe not. People don't always choose the best language to write in.
Often that choice is highly influenced by perception, ignorance about
Lisp, lack of Lisp software in the organization, or peer pressure.
Paul Graham has a nice discussion of "why Lisp?" in the first six
pages of his book, _ANSI Common Lisp_. He notes:
Programming languages teach you not to want what they cannot provide.
You have to think in a language to write programs in it, and it's
hard to want something you can't describe.
Graham also notes: GNU Emacs, Autocad, and Interleaf are all written
in Lisp.
--David Finton
Juliana L Holm
Erik Naggum (er...@naggum.no) wrote:
: [George Van Treeck]
: | That's a very good point! If you're a professor in some ivory tower
: | you can afford to savor your favorite computer language. If you
: | develop software that must be sold to put food on your plate, then you
: | become much more conservative! Your definition of best becomes more
: | dominated in terms of what is the "safe" choice. And the safe choice
: | is one that is popular -- has support from many vendors, books, lots of
: | staff you hire that already know the lanugage, etc. That means your
: | favorite is something commercially successful. You know that if it's
: | commercially successful, that there is a high probability you can get
: | the project out the door with sufficient quality to sell it.
: in other words, the specific _language_ you use is utterly irrelevant. it
: could be Cobol or APL or C or Java or whatever, as long as it is "safe" and
: all those other parameters are present. you argued that C and C++ were
: better languages because they were commercially successful. in fact, you
: have argued for the irrelevancy of the choice of programming language
: compared to other factors that complely overshadow language merit.
When you're in school, the best language may be the one that illustrates
the concepts that you are learning best. In school you might use
Prolog, LISP, whatever. The point is to learn the concepts.
When you are in business you use the language they already have. Or you
use the language that they can hire programmers who already know. Or
that the existing programmers can "get up to speed" on best. Rarely,
you can do an evaluation of several different development platforms to
decide what languages and tools you will use. But your evaluation must
include considering not only the choice of language for the AI poriton
of the project, but also the GUI, the interaction with other systems,
the external functions, the interaction with the database.
Portability between platforms. Scalability, Speed. How stable is the
company that sells the product(s) you will choose. HOw much money is
budgeted. How important is the system to the company. What is the
support like, how much do classes cost. Etc. Etc. Etc.
It becomes very complex.
--
---------------------------------------------------------------------------
Julie Holm (ENTP)| DoD #1604 AMA#397939 UKMC# 0001 VOC# 4672
jh...@gmu.edu | 1985 Virago 700 "Maureen"
|*** Nasty Girlie Gang Armourer, Shopping Consultant,
| and Travel Agent!!!
| I'm home at http://osf1.gmu.edu/~jholm
---------------------------------------------------------------------------
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/L/IT d@ s-:- a+ C++$ UX/H/O/S+>+++$ p+ L E---() W++(+++) N+++ o? K-
w$ O M-- V PS++(--) PE@ Y+ PGP- t+(+++) !5 !X R tv-- b++ DI+ D--- G e++
h---- r+++ x++++
------END GEEK CODE BLOCK------
Will
>Name some commercial applications written in Common Lisp. A
>couple of expert system shells is about it.
Abuse, which is a recently released video game is written in Lisp.
There is a web server written by someone at MIT which is in Lisp.
The products are there, they just aren't as obvious. When do you
see a sticker on a box saying, "Programmed in C++, language of
champions!!" That type of thing just doesn't happen, it doesn't matter
what language you're talking about.
Cheers~
Will
Glen Clark
George Van Treeck wrote:
> For example, Microsoft
> OEMs it's FORTRAN and COBOL.
You're saying that Powestation 4.0 was developed out-of-house?
Didn't know that. Who actually wrote it?
--
Glen Clark
gl...@clarkcom.com
Rainer Joswig
> What language do you think the product comprising Microsoft Office
> or Claris Works are written in? What about the latest version
> Autodesk's 3D software? Relational DBMS from Oracle, Sybase and
> Informix? Electronics design tools from Cadence, Mentor Graphics,
> Viewlogic, etc.?
Oh, "Electronics design tools" do like Lisp.
> Name some commercial applications written in Common Lisp. A
> couple of expert system shells is about it.
We have gone through this before. There is quite a lot
software written in and running in Lisp. See the
customer list of Digitool (at http://www.digitool.com/).
Pretty impressive.
Ford designs cars with Lisp software, Boeing designs
turbines with Lisp software, latest games
on the market have been designed with Lisp software
(Crash Bandicoot for Sony and Super Mario 64 for
Nintendo), TI designs 586 compatible processors
with Lisp software, Swissair eliminates double
bookings with Lisp software, commercial development
environments use Lisp software (just got a
letter from SUN about their C++ development environment,
which editor are they using? XEmacs!), Apple
has been prototype a new multimedia environment
in Lisp (SK8), Siemens has developed natural
language translation software in Lisp (Metal,
recently redone in C/C++), ...
To give you an example, we are a small company. Scripting
on Unix is being done in scsh (the Scheme shell). We have
developed some accounting stuff for inhouse purpose
in MCL (Macintosh Common Lisp). This enables us to be
very flexible and we can produce bills on the first
of a new month.
Another example: here in Hamburg there is a software that
guides people through the local public transport
system. It computes optimal ways through the huge
system of busses, trains, underground trains and ships
of a city with 1.5 million people. Its algorithms
have been scaled to handle the complete transport
system (and not some subset) and to use
additional constraints (handicaps, no tunnels,
shorts ways between stations to walk, etc.).
It has been developed to support the phone supports
of the HVV (the local Hamburg public transport company). If you
go to the central station, you will see people standing
in front of a 21" touch screen. The system displays
graphically the routes and informs about times, etc.
You can print out your personal plan, etc.
People will never notice, but the software is written
completely in Common Lisp. Some of the basic algorithms
have been developed on Macintosh Common Lisp running
on a PowerBook 180 (a friend of mine has done work
on that). A company has brought it to market. Former
Cobol programmers were happily hacking in Lisp.
Now it runs in Lucid Common Lisp on SPARCstations.
You don't now any Lisp software out there? Maybe its
your fault. Even President Clinton's web site
is partly run on Lisp machines. Better have a look
how the White House distributes electronic
documents over the Web. Running on a system
the combines forms processing via the Web and
via Email, using document classification,
built with an object-oriented database.
Yes, running on a Lisp machine.
> It's not myths. At Digital, a CAD tool was written in Lisp and dumped
> because it Lisp was just too slow. Lisp can't be used in real-time
> applications, because you need to guarantee response time.
Some how has Lucent built its high-speed switching system
on a Lisp architecture? Ever heard of th company Gensym?
> A 911
> call needs to routed over the phone lines and can't afford to wait
> for Lisp program to take a coffee brake (garbage collect for some
> indeterminate period). And the code size is too large to be
> quickly activated and used for small utility applications. Perl,
> Tcl, C/C++ are used instead.
You have no idea how Lisp system work? How can I type
to a Lisp-based editor like Emacs? Either it takes to long
to be activated or it is constantly garbage collecting
for long times. ;-) Still I can type very fluently to it.
I have used my Lisp machines editor (Zmacs) a couple of
time when "tools" under Unix were unusable. Under
Zmacs I can still edit a 100 MB file and do cut and
paste with 20 MB parts. Technology from 15 years ago.
> Virtually all new commercial applications are developed in C/C++.
Besides all the other applications that are being
developed in Pascal (ever heard of Delphi?) or Basic
(ever heard of Visual Basic?) or Java or SmallTalk
(did you hear that IBM sells and uses SmallTalk?)
> Many in-house applications are being developed in VisualBasic
> or some 4GL/GUI tool like PowerBuilder, because it requires
> less technical skill ($25/hr labor for VisualBASIC programmer
> vs. $60/hr for C++ programmer) and development is quicker
> using something like PowerBuilder. Lisp could never
> cut it in that market either.
AutoCad is a good counter example. A lot of AutoCad software
is being done in Lisp. A new CAD system from Germany
(FelixCad) also uses Lisp and claims AutoCad compatibility.
Rainer Joswig
In article <325AF9...@sybase.com>, George Van Treeck
<tre...@sybase.com> wrote:
> Symbols, linked lists, consing, etc. are a wasted effort by people
> who know little about neuropsych and figure they could use
> introspection to deduce and brain functions. All programs that
> use such methods have been complete failures at such simple things
> as recognizing a hand written characters, voice recognition, etc.
"Simple things"?
> I haven't seen any interesting software written in a symbol
> processing language in last 7 years.
That might be *your* problem. I have seen such software.
> And even if you were to do symbolic processing for say,
> parsing natural language text, a language like Prolog is
> far superior to Lisp!
Hear, Hear. You should have told this all the people
who wrote successful AI software in Lisp.
Obviously you have no idea of AI and AI software development.
Tim Bradshaw
* George Van Treeck wrote:
> If you go to an engineering manager and propose a product, do
> you think the manager will agree to using a language that no
> one else uses to get product out the door? Get real.
Someone has to, some time. Someone must have been the first to use
C/C++/Cobol.
> It's not myths. At Digital, a CAD tool was written in Lisp and dumped
> because it Lisp was just too slow. Lisp can't be used in real-time
> applications, because you need to guarantee response time. A 911
> call needs to routed over the phone lines and can't afford to wait
> for Lisp program to take a coffee brake (garbage collect for some
> indeterminate period). And the code size is too large to be
> quickly activated and used for small utility applications. Perl,
> Tcl, C/C++ are used instead.
You should read at least some papers on real-time systems and GC
before posting something like this. Pausing for an indeterminate
period is just the sort of thing that using garbage collected
languages can avoid which is hard to avoid in a traditional
malloc/free type system.
To give more content to this thread -- does anyone have real figures
for GC overheads for real programs (in Lisp or any other GC'd
languages, not just real-time stuff). XEmacs has some kind profiler
now, and I ran that for a few days, and it spends only about 2-3% of
its time in GC, despite using large & consy elisp packages like gnus &
VM.
--tim
Eddy Young
Glen Clark <gl...@clarkcom.com> wrote in article
<325C3D2C...@clarkcom.com>...
I never knew that C++ could be used for AI programming. Anyway, if it can
be, it must be very tedious. LISP was created with AI programming as
objective; so, it should be the best suited.
But, the most complete AI programming package I've found so far comes from
the NASA. It's called CLIPS (derived from LISP???)
Eddy
Rainer Joswig
In article <30539515...@naggum.no>, Erik Naggum <er...@naggum.no> wrote:
> [George Van Treeck]
>
> | That's a very good point! If you're a professor in some ivory tower
> | you can afford to savor your favorite computer language. If you
> | develop software that must be sold to put food on your plate, then you
> | become much more conservative! Your definition of best becomes more
> | dominated in terms of what is the "safe" choice. And the safe choice
> | is one that is popular -- has support from many vendors, books, lots of
> | staff you hire that already know the lanugage, etc. That means your
> | favorite is something commercially successful. You know that if it's
> | commercially successful, that there is a high probability you can get
> | the project out the door with sufficient quality to sell it.
>
> in other words, the specific _language_ you use is utterly irrelevant. it
> could be Cobol or APL or C or Java or whatever, as long as it is "safe" and
> all those other parameters are present. you argued that C and C++ were
> better languages because they were commercially successful. in fact, you
> have argued for the irrelevancy of the choice of programming language
> compared to other factors that complely overshadow language merit.
Most of the **crashing** software I'm forced to use is written in C
or C++.
Michael B. Wolfe
In article <325C22...@comp.uark.edu>, dbl...@comp.uark.edu wrote:
> George Van Treeck wrote:
>
> > Bottom line: The proof of which is better (C++ or Lisp) is to
> > look at the commercially successful applications. If Lisp is such
> > a hot language, how come most applications are all written in C and
> > C++? Is that that Lisp is not used because it's difficult to read
> > and maintain? Is Lisp's problem lack of performance, portability,
> > what? Must be some major weaknesses.
>
> Ah, yeah. By that measure, COBOL is the best language, followed closely
> by Fortran 77, and then Visual Basic.
Actually, the first example that jumped to my mind of "inferior products
dominating the market" was VCRs--Beta vs. VHS. I'm not implying that C++
is inferior to Lisp, but it's clear that you can't always argue from
market success backwards to which product is superior....there are too
many other factors to consider that have very little to do with the actual
quality of the product.
Just noticed the distribution list on this thread, too...apologies to
those who think it should have died a long time ago.
--
--Michael Wolfe
--The Institute for the Learning Sciences
--Northwestern University
--wo...@ils.nwu.edu
scha...@wat.hookup.net
In <325C60...@sybase.com>, George Van Treeck <tre...@sybase.com> writes:
>> ...
>> if C and C++ are so hot, how come they haven't always been? how did they
>> become hot? how did they overcome the "how come most applications are all
>> written in Fortran and Cobol" argument? how does Java face the same
>> argument?
>
>Applications written many years ago were done in FORTRAN and COBOL.
>Today, many large computer vendors and software companies don't
>even sell COBOL because it's too small a market! They OEM COBOL
>from some small compiler company. FORTRAN and COBOL are sold
>mostly to maintain legacy software. For example, Microsoft
>OEMs it's FORTRAN and COBOL.
>
>Virtually all new commercial applications are developed in C/C++.
>If you worked in the "real-world" (companies that develop
>commercial software) you know that. Look in the new paper for
>programming jobs. Count the number of ads wanting C/C++ vs.
>FORTRAN/COBOL.
But there was a time were proposals to do software in C were rejected because
"everybody writes in Pascal / FORTRAN / COBOL", i.e. the same argument you are
using now to establish the superiority of C (or do you have another explanation
why you need FORTRAN and COBOL for the legacy software?).
>Many in-house applications are being developed in VisualBasic
>or some 4GL/GUI tool like PowerBuilder, because it requires
>less technical skill ($25/hr labor for VisualBASIC programmer
>vs. $60/hr for C++ programmer) and development is quicker
>using something like PowerBuilder. Lisp could never
>cut it in that market either.
If the $60/hr person can do the job in a day where the $25/hr person need a
week, who is cheaper?
>-George
Hartmann Schaffer
kransom
Howard R. Stearns wrote:
> I guess I'm confused. I was under the impression that the really hard
> parts of three of products you mention ARE written in Lisp. (From
> Autodesk, Oracle, Viewlogic). I would add Parametric Technologies and
> Cognition. Can anyone who actually knows tell us? Anyway, check out
> the customer pages of vendors such as Franz and Digitool.
Cadence have an embedded extension Lisp, HLDS are remarketing through
Mentor and all their stuff is in Lisp, Viewlogic have a set of silicon
compilers (SILCSYN) implemented in Lisp. Yes, and Parametric and
Cognition are also using Lisp. Check it out at www.franz.com.
Charles E. Matthews
George Van Treeck wrote:
> Virtually all new commercial applications are developed in C/C++.
> If you worked in the "real-world" (companies that develop
> commercial software) you know that. Look in the new paper for
> programming jobs. Count the number of ads wanting C/C++ vs.
> FORTRAN/COBOL.
>
> Many in-house applications are being developed in VisualBasic
> or some 4GL/GUI tool like PowerBuilder, because it requires
> less technical skill ($25/hr labor for VisualBASIC programmer
> vs. $60/hr for C++ programmer) and development is quicker
> using something like PowerBuilder. Lisp could never
> cut it in that market either.
>
Geez, chill out guys! Saying that Lisp sucks because people can't build
database apps quickly like they can with PowerBuilder is a bit like
saying that a whale is a miserable excuse for an animal because it
doesn't fly as well as a sea gull. (Yeah, OK, let's see how good the sea
gull does below a 40 foot water depth.)
The point is that each of these languages has a value and purpose which
is appropriate for completely different circumstances. Which language is
best suited for building turnkey database apps quickly? PowerBuilder.
Which language is best suited for modelling and simulating complex
problem domains? Lisp.
I'm always amazed when people leap from isolated questions like those
above to the grand pronouncement that "xxxx is better than yyyy in all
cases that REALLY matter" with such religious fervor and righteousness.
Regards,
Chuck
______________________________________________________________________
Charles E. Matthews
Software consulting in knowledge
Synergistic Technologies based systems and object oriented
chu...@infonet.isl.net analysis and design
Mukesh Prasad
> Graham also notes: GNU Emacs, Autocad, and Interleaf are all written
> in Lisp.
This may be slightly misleading. I don't know about Autocad,
but GNU Emacs and Interleaf are both written in C. But in
both these cases, the C code also has an embedded Lisp (or
Lisp-ish, in case of GNU Emacs) interpreter. Thus once the
basic system is up, various extensions written in Lisp
can be loaded and executed. It is doubtful that in these
two cases, the basic system itself would have been usably
fast if all of it was written in Lisp -- but it is certainly
the case that the usage of Lisp as an extension language
has proved to be a very powerful and flexible extension mechanism
in both. It would have been much more cumbersome and
error prone, to try to provide C or C++ as a user-level
dynamic extension language to the base system (it is
possible to do this, e.g. in "plug-in"s such as found in
Netscape Navigator, but these interfaces are nowhere near as
flexible, powerful and convenient as GNU Emacs and Interleaf user
extensions.)
Tim Menzies
In article <joswig-ya0231800...@news.lavielle.com> jos...@lavielle.com (Rainer Joswig) writes:
>In article <325AF9...@sybase.com>, George Van Treeck
><tre...@sybase.com> wrote:
>
>> Symbols, linked lists, consing, etc. are a wasted effort by people
>> who know little about neuropsych and figure they could use
>> introspection to deduce and brain functions. All programs that
>> use such methods have been complete failures at such simple things
>> as recognizing a hand written characters, voice recognition, etc.
>
>"Simple things"?
>
>> I haven't seen any interesting software written in a symbol
>> processing language in last 7 years.
perhaps you should read:
Paradigms of Artificial Intelligence Programming: Case
Studies in Common Lisp
http://www.harlequin.com/books/norvig/paip.html:
Peter Norvig
A book published by Morgan Kaufmann, 1992.
Paperbound, xxviii + 946 pages, ISBN
1-55860-191-0.
Over 8 million pages sold!
now this text contains nothing "new": but my goodness it does lots of
"old" things so succinctly!!! e.g. bobrows ENTIRE phd thesis in less
than 33 pages, with full soruce code source and comments
--
Dr. Tim Menzies rm EE339 |
ti...@cse.unsw.edu.au | And for the tourist who
,-_|\ www.cse.unsw.edu.au/~timm | really wants to get away
/ \ AI Dept, School of Computer | from it all- safaris in
\_,-._* Science &Engineering, Uni NSW | Vietnam.
v Sydney, Australia, 2052 | -- Newsweek, late 1960s
+61-2-93854034(p)93855995(f) |
Gary Brown
George,
> George Van Treeck wrote:
> If Lisp is such a hot language, how come most applications are all written in C and
> C++?
COMMON LISP is big, slow, expensive, and somewhat esoteric. It is a
great language to
program in for many applications. However, the programming language is
invisible to
end-user. LISP gives the end-user nothing for the extra resources it
requires.
Compiled LISP can approach other languages in speed. But, that imposes
constraints
that restrict most of the functions that makes LISP desirable in the
first place.
LISP is still my favorite language by far. I programmed in LISP for
several years.
Mostly simulations but also a simple schematics editor.
Gary
Matt Grice
wi...@one.net (Will) wrote:
>In article <325C60...@sybase.com>, George Van Treeck <tre...@sybase.com> wrote:
>
>>Name some commercial applications written in Common Lisp. A
>>couple of expert system shells is about it.
>
>Abuse, which is a recently released video game is written in Lisp.
No it isn't. Abuse has a LISP embedded interpreter, and the various
game objects are controlled via LISP scripts. This is less than 20%
of the total source code of Abuse.
It seems to be a common mistake in this thread to say something which
has an embedded interpreter for language 'x' is 'written in X.' LISP
scripts may be essential to the operation of each program mentioned,
but almost none I have seen mentioned are primarily written in LISP.
I don't think this concept is too hard to grasp, but perhaps most do
not have direct knowledge of the products they are mentioning.
Dozens of windows apps have embedded basic interpreters... doesn't
mean they are written in basic, as I am sure everyone understands. On
another note, I keep hearing about the Apple LISP compiler - are many
mac applications written in LISP?
Rainer Joswig
In article <3260dca7.5106933@news>, mgr...@iastate.edu (Matt Grice) wrote:
> Dozens of windows apps have embedded basic interpreters... doesn't
> mean they are written in basic, as I am sure everyone understands. On
> another note, I keep hearing about the Apple LISP compiler - are many
> mac applications written in LISP?
No, Apple has (again) done a bad job. Thank god, "Digitool" now ensures
the ongoing development of Macintosh Common Lisp. Their new versions
(PPC MCL 4.0 and MCL 3.1) are out maybe this months. The biggest
and most important contribution from Digitool until now is the port
of MCL to the PowerPC, so that Lisp developers on the Mac again
have adequate speed on the newer machines.
Some commercial software (public and inhouse) has been written with MCL and
a lot more have been developed or prototyped with the help of
MCL. Just see the customer list of Digitool (http://www.digitool.com/)
and you will read a lot of familiar names. If I remember
correctly, Apple has done
early work on what we see as "Apple Guide" (the online
help system) in MCL. There are sure more examples. Even
Microsoft (!!!) had an user interface mock-up of
Microsoft Word written in MCL.
Greetings,
Rainer Joswig
Glen Clark
Matt Grice wrote:
>
> wi...@one.net (Will) wrote:
>
> >In article <325C60...@sybase.com>, George Van Treeck <tre...@sybase.com> wrote:
> >
> >>couple of expert system shells is about it.
> >
>
> No it isn't. Abuse has a LISP embedded interpreter, and the various
> game objects are controlled via LISP scripts. This is less than 20%
> of the total source code of Abuse.
>
> It seems to be a common mistake in this thread to say something which
> has an embedded interpreter for language 'x' is 'written in X.'
Somebody who already had a competency in C went to the trouble of
cross-linking a second language into the application because it
brought something to the table not found in C. Doesn't that tell
you something?
I'm a FORTRAN hack, myself. So you two guys can club each other
into pink mush and I have nothing invested emotionally.
And I accept your point... that having a *percentage* of an
application written in language X does not entitle someone to
call it an "X application".
But from a view of formal logic, it seems that, in the process
of making your point, you have conceeded something all of us
already knew: "There is no one 'best' language. Each has it's
strong and weak points. Where there is an excess of hardware
resources, you can afford to be inefficient in some places and
have the luxury of living in a one-language paradigm. Where hardware
is dear (How muct does it cost to put a 20_cents_more_expensive
CPU in 10 million Nintendo's?), sometimes you have to cherry-pick
the best technology for each sub-task and glue them together."
--
Glen Clark
gl...@clarkcom.com
Glen Clark
Erik Naggum wrote:
> my guess is that the intense hatred for AI in some quarters can
> be attributed mostly to the desire to externalize the feeling of stupidity
> in having believed the hype to begin with.
Who hates AI? Can you give some examples. This is not a bait.
It is a serious question.
--
Glen Clark
gl...@clarkcom.com
Felix Kasza [MVP]
Rainer,
> Hear, Hear. You should have told this all the people
> who wrote successful AI software in Lisp.
> Obviously you have no idea of AI and AI software development.
I have no intention to join a pissing contest.
Rather, I will gladly admit to my ignorance in AI matters: "successful
AI software"? Does that mean there's a piece of software out there that
survives the Turing test and everything else you can throw at it?
I don't care what language it's written in, but unless something drastic
happend in the past six months, "successful AI software" is rather
far-out a concept.
Cheers,
Felix.
scha...@wat.hookup.net
In <53i5rv$j...@Godzilla.cs.nwu.edu>, ti...@cs.nwu.edu (Seth Tisue) writes:
> ...
>a day when they were the dominant languages, and C and Smalltalk (the
>original source of the OOP ideas in C++) were funny little obscure
I always thaught C++'s OO concept was derived from Simula67
Hartmann Schaffer
Dan Winkler
> Bottom line: The proof of which is better (C++ or Lisp) is to
> a hot language, how come most applications are all written in C and
> C++?
I would even set aside the question of MOST successful applications and
just ask someone to show me ONE successful Lisp application. By "show
me" I mean something I can download and try. By successful I mean
something
I would use regularly. I have lots of programs written in C that meet
those
criteria but none in Lisp.
I think it is much easier to prototype in Lisp than in C. You don't have
to
worry about memory management, you can make incremental changes to
a running program, and usually you get to use nice high-level interfaces
onto
the machine's resources. Also, your mistakes don't crash the machine.
But in my experience Lisp can be much slower than C. Especially for
character processing. I once wrote a program to read some ascii and
decode it into binary. C was much faster at that than Lisp. Of course,
you
can always write low level things like that in C and call them from your
Lisp
program.
Another big problem with Lisp is you can't make a small, stand-alone binary
with it. The smallest application you can build is usually about a
megabyte.
Hard drives are so large now that this may finally not be such a problem
anymore. (I'm referring now to my experience with Common Lisp. I'm sure
Scheme systems can make smaller binaries.)
So can anyone point me to a useful application, written in Lisp, that I can
download and try? I can show you plenty done in C.
Erik Naggum
[Felix Kasza]
| Rather, I will gladly admit to my ignorance in AI matters: "successful
| AI software"? Does that mean there's a piece of software out there
| that survives the Turing test and everything else you can throw at it?
no, that is not what it means.
| I don't care what language it's written in, but unless something drastic
| happend in the past six months, "successful AI software" is rather
| far-out a concept.
yes, your concept of AI is rather far-out. this cannot be attributed to
Artificial Intelligence as an area of research, however.
it is true, on the other hand, that some of the ambitious speeches were
overly optimistic and thus hurt the field over time, but they also produced
strong interest and enthusiasm in their time. ironically, the research
produced most of the fuel used to discredit it later, by discovering just
how hard their problems were. previously, people didn't know, and would
listen to their hype, which they did, in large numbers, even.
in moral terms: who is to blame for believing something that turns out to
be false? my guess is that the intense hatred for AI in some quarters can
be attributed mostly to the desire to externalize the feeling of stupidity
in having believed the hype to begin with.
as a general comment: if we are to discredit all fields that have had any
hype at some point in their life that turned out to be optimistic pep talks
more than the conservative statements of truth that seems to be required of
AI by AI-haters, nothing would be left. if we allow fields to use hype to
generate interest (as is done for Java, C++, WWW), we must allow for it in
the past, as well. anybody can have 20-20 hindsight.
Daniel Pflager
> > ...
> >a day when they were the dominant languages, and C and Smalltalk (the
> >original source of the OOP ideas in C++) were funny little obscure
>
> I always thaught C++'s OO concept was derived from Simula67
>
In his book, The Design and Evolution of C++, Bjarne mentions lots of
influence from both these languages, but C++ seems to borrow more directly
from Simula than Smalltalk.
For example, C++'s inheritence mechanism is more similar to Simula than
Smalltalk.
Daniel Pflager
Rainer Joswig
In article <32613c48...@babya.shd.de>, fel...@mailbag.shd.de (Felix
Kasza [MVP]) wrote:
> Rainer,
>
> > Hear, Hear. You should have told this all the people
> > who wrote successful AI software in Lisp.
>
> > Obviously you have no idea of AI and AI software development.
>
> I have no intention to join a pissing contest.
You already did.
> Rather, I will gladly admit to my ignorance in AI matters: "successful
> AI software"? Does that mean there's a piece of software out there that
> survives the Turing test and everything else you can throw at it?
Again, obviously you have no idea of AI and AI software development.
Who cares about the "Turing test"? Very few people (maybe
Mr. Loebner).
> I don't care what language it's written in, but unless something drastic
> happend in the past six months, "successful AI software" is rather
> far-out a concept.
Read literature about AI, get some idea what AI is about (I can
give you a hint: it is a very diverse field with many different
ideas), and then you will see how silly your questions are.
Greetings,
Rainer Joswig
> Cheers,
> Felix.
Carlos Cid
Hi,
Tanks everybody for your help. I have collect your replies to this message
and I post them by request.
Some of this replies have not been posted to newsgroups so I'll try to cite
only the opinion, not the sender. To all those senders: I hope you never
mind that I have cited your opinion.
I have only included replies to my message, you can follow the rest of the
discussion on newsgroups.
At the end of this message you can find our final decission.
=============================================================================
THIS IS THE ORIGINAL MESSAGE
=============================================================================
Hi everybody,
This is a request for your opinion about the subject theme.
I'm working on Machine Learning and I wish to know your opinion about what
is the best language to implement ML. (in general AI.) software. The
discussion is focused on software for researchers, not for comercial tools.
My workgroup is now discussing what is best, but we haven't take a decission
yet. We are mainly interested in:
- Existing implemented ML. algorithms.
- An easy maintenance (easy to understand and easy for group working).
- Language standarization.
- Multiplatform support.
- Interface with graphic enviroments.
- Software Engineering methodologies developed.
We think both of them have its advantages and disadvantages. Perhaps your
experience could help us.
I know there are other good languages for AI. implementations, but we want
to restrict the discussion to Lisp and C++. Of course, you are free to aswer
this message to defend your favourite language. Any opinion is welcome.
Thank you in advance for your help.
Carlos Cid.
=============================================================================
THOSE ARE YOUR REPLIES
=============================================================================
You should also consider using functional languages such as ML (not
machine learning, but the ML language, like SML -standard ML- or
Ocaml).
=============================================================================
=============================================================================
HI
I know that you want to restrict to C++ or lisp, but let me introduce
you another language that mixed the best of both in my opinion.
TCL/TK. This language is interpreted and work with the comcept of
list like LISP. The TK is the visual interface. All that stuff TK and
interpreter exist for unix, mac and windows with the same visual
interface object, so the code is close to be fully portable. Moreover,
you can call C++ lib in TCL/TK. So you can build C++ librairy that does
the hard stuff and that you can compile on different platform in the
rest of the interface can be in TCL/TK which will run on many platforms
too.
This is my point of view i'am not considering myself an expert in none
of those language. I hope the information can help you.
=============================================================================
=============================================================================
Dear Carlos,
I went into AI wanting to do everything in LISP or
Prolog as these are the AI languages, I thought.
Since then I have had my mind changed on this subject.
Lisp and Prolog are high level languages. A high-level language
means the compiler makes a lot of assumptions about what you are
going to be doing, in order to make programming a lot easier.
I have used a high-level language in a business environment,
and I think it's a great idea.
HOWEVER. In AI research you will quickly find that your
high level language has made the _wrong_ assumptions about
what you are going to do. Lisp and Prolog were not designed
with neural nets and genetic algorithms in mind, for example.
What you want is a programming environment that lets you specify your own
assumptions about your future programming needs, in order to facilitate
future programming. But it should also allow you to _change_ those
assumptions as necessary at a lower level.
Voila. C++. A fixed high level language is OK in a business environment,
but at the cutting edge of technology you need C++. For "facilitating
assumptions" read "class libraries".
=============================================================================
=============================================================================
Hello. A while back I worked in the Computer Science dept. at the
University of Aberdeen. There, the feeling amongst the ML people
was that lisp/prolog was good for prototyping code, but for anything
using large datasets, C was the language choice. I suppose like all
software engineering, once the technology stabilises, it will be ported
from lisp/prolog to C (ie Progol, c4.5 etc etc).
=============================================================================
=============================================================================
There aren't any good answers, unfortunately. It depends on how
good your researchers are, how high performance the implementation
needs to be, how much money you want to spend, etc. C++ is a pain
to develop in, difficult to learn, and difficult to port, but it
is efficient and there is a lot of software for it. Lisp
is a bit easier to learn and develop in, but whatever OS APIs it
has are proprietary, it is tricky to get good performance out
of it, and it is very expensive.
One language to consider is Objective-C, preferably using a garbage
collector like Boehm's: it combines most of the advantages of C and
Lisp, and it is cross-platform (the OpenStep libraries for Windows and
UNIX). It is simple, efficient, powerful, and free.
=============================================================================
=============================================================================
"ILOG Talk" is a Lisp dedicated to the development in Lisp with C++
libraries (including your extensions). This certainly a way to get
the best of both worlds.
cc> - Existing implemented ML. algorithms.
Dunno. If there are in C++, then you get them for free in ILOG Talk too.
cc> - An easy maintenance (easy to understand and easy for group
cc> working).
There is some kind support for groupware modular development. So far
a training session is the most appropriate approach to groupware in
ILOG Talk.
cc> - Language standarization.
ILOG Talk is close to ISLISP (the ISO standard for LISP), with many
extensions.
cc> - Multiplatform support.
Plenty Unixes, plus Windows NT and Windows 95.
cc> - Interface with graphic enviroments.
Any the C++ (and C) libraries you want! We recommend ILOG Views,
which is a C++ graphic library widely ported, efficient, and powerful.
Check http://www.ilog.fr/ for more about ILOG Views.
cc> - Software Engineering methodologies developed.
Object-oriented modeling is best addressed by ILOG Power Classes.
Please ask in...@ilog.fr for more information about ILOG Power Classes.
cc> We think both of them have its advantages and disadvantages. Perhaps your
cc> experience could help us.
Almost all our ILOG Talk customers are Lisp programmers now enjoying
using C++ libraries. Most of them still write no C++ code, some now
code in both languages.
ILOG Talk is not Common Lisp (smaller footprint, modular runtime,
simpler, etc), but it is definitely in the same familly of Lisp
dialects (an extension of the ISO standard). You can get it for free
on Linux (1), or buy it for Unix and Windows (2).
I hope you'll enjoy!
(1) Please check ftp://ftp.ilog.fr/pub/Products/Talk/linux/ilog-talk-3.2.tar.gz
or ftp://sunsite.unc.edu/pub/Linux/Incoming/ilog-talk-3.2.tar.gz on sunsite
or any sunsite mirror
(2) Please check http://www.ilog.fr/Products/Talk/ and/or ask in...@ilog.com
=============================================================================
=============================================================================
I am responding to Carlos Cid's request. I am basing my opinions on my
own experience in doing something much like what he wants to do.
Carlos Cid wrote:
>
> My workgroup is now discussing what is best, but we haven't take a decission
> yet. We are mainly interested in:
>
> - Existing implemented ML. algorithms.
A lot is available for Lisp. See the CMU-AI archive.
> - An easy maintenance (easy to understand and easy for group working).
Programming language theory experts say that Lisp has the advantage over
C++ here.
> - Language standarization.
Common Lisp is an ANSI standard and many implementations have attained
or nearly attained that standard.
> - Multiplatform support.
> - Interface with graphic enviroments.
The basic common lisp language is implemented on many platforms and
common lisp code runs on all of them. If you want a fancy interface to
run an any Unix or Linux machine, that is no problem. If you want a
fancy
interface to run on any Windows(TM) machine, that is no problem. If you
want a single fancy interface to run on both Unix and Windows(TM) then
you need to do a bit more work (look into CLIM or TCL/Tk, and see the
Lisp
FAQ) but it is possible.
I suppose this is true of C++ also.
If a text-based interface is good enough, then that is perfectly
portable.
> - Software Engineering methodologies developed.
I'm not sure what you are referring to here. Lisp is a very old and
mature language which is being used in industry all over the place.
C++ is relatively young but it is widely used.
Lisp is a lot of fun. It's not a drag to program.
=============================================================================
=============================================================================
Carlos Cid wrote:
> - Existing implemented ML. algorithms.
A lot more LISP code out there -- much of it outdated though. Most
new stuff is in C++.
> - An easy maintenance (easy to understand and easy for group working).
Only very wierd people think LISP is readable... Writing obtuse
code is equally easy in either language. LISP is better for
prototyping and C++ better for production.
> - Language standarization.
Toss up.
> - Multiplatform support.
C++ is on many more vendor's platforms. Hardly any systems vendors
provide LISP -- have to rely on some small company. Due to the
much larger market for C++, it tends to be more optimized, bug free,
etc.
> - Interface with graphic enviroments.
Portable GUI frameworks are available for both LISP and C++.
Personally, I would use Java's AWT for making a 100% portable GUI
code. It can call out to C++ code for the compute intensive
portions. Java is about as fast as LISP, so you might be able
to write the whole thing in Java.
> - Software Engineering methodologies developed.
C++ wins hands down. Go to any book store with computer section.
Many books on methodologies with examples in C++ -- nothing with
examples in LISP.
You forgot one other important category -- performance. If
you ML code is very compute intensive, e.g., GA, neural nets,
etc. then C++ is the only way to go.
=============================================================================
=============================================================================
C>I'm working on Machine Learning and I wish to know your opinion about what
C>is the best language to implement ML...
Either way, try not to use both languages. You may spend more
time on integration than research. I've worked on a project
that had to interface LISP and C++ (LISP:intelligence, c++:simulator).
The end statistics was that we spent more than 50% of labor hour
on LISP-C++ interface and close to 70% of code was written to
transoform data structure back and fourth between the 2 languages
on multiple platforms.
Project was a success, after we re-implemented the design (yes,
we actually had a design, thanks to the insistence/threat of the
customer) in a single language.
=============================================================================
THE FINAL DECISSION
=============================================================================
We finally decided to use C (not C++) for our implementation. Before telling
why I think you should knew a little bit more about my project.
We wish to build a Machine Learning System and we wish to apply it to voice
recognition problem. The workgroup is interested on any kind of ML
algorithms but my personal work is restricted to the ID3 family (proposed
by Quinlan); other kind of algorithms should be added to this system in
future.
I have been searching for existing implementations of those algorithms. I
have found lots of them in Lisp, Prolog, C, and C++. We choose three:
- MLC++ a ML system with a complete library of ML algorithms
implemented in C++ at Silicon Graphics.
- A Lisp implementation of C4.5 by Ray Mooney at the University of
texas.
- The implementation of C4.5 by Quinlan in C at the University of
Sidney.
Now let me reply myself based on my personal experience, your opinions and
the information I have found:
> - Existing implemented ML. algorithms.
Of course, I have found good implementations on all languages.
> - An easy maintenance (easy to understand and easy for group working).
We thought that C++ should be the best by its philosophy (as an object
oriented language), but we have found that this language are not mature
enought and is changing continously trying to join other formal object
oriented languages.
We think that Lisp is more easy to understand than C, but C is best for
group working. The advantage of Lisp is not too real because most people
(at least in my enviroment) know a lot of C but rarely a bit of Lisp.
> - Language standarization.
Lisp lose here. Although exists a good standard (Common Lisp) you need
to use some other layers (for example CLOS to use an object oriented Lisp)
and there isn't a good standard for those layers.
C++ have a new good standard (ANSI) but C++ compilers do not implement the
standard 100% or are too spensive compilers and run over a more expensive
computer. Perhaps GNU compiler should be a solution in future.
C is a very mature and stable language and exists a good standard (ANSI).
C compilers usually have its own dialect, but compile a standard ANSI C
code if you wish.
> - Multiplatform support.
[NOTE: We really want to build a system kernel suitable to run on a
personal computer and on a UNIX workstation.]
You can found compilers for all this languages for a PC or a Unix WS, but
the problems are refered to language standarization. If you use C++ or Lisp
you probably must reimplement parts of code to port it from a WS to a PC.
My personal experience porting C code demostrate (at least for me) that
C it's the best (of course for a system kernel, not for GUIs).
> - Interface with graphic enviroments.
Lisp GUIs have a very bad performance but we never say performance was
important. C++ is interesting because exists a lot of visual programming
tools. The advantage of C is that you ever find a way to build a GUI and
good graphic libraries. All of them are suitable.
> - Software Engineering methodologies developed.
Well, at this point I have found that object oriented methodologies are
in a good state-of-the-art now but some experts have said me that the
methodologie used should not depend on the implementation language and
we have to choose the best for the problem type.
Finally we choose C because:
- I have been programming with C for seven years.
- Quinlan works on it an he is contoinouslly increasing ID3
capabilities and he use C.
- We can easilly build a system kernel for both, a PC and a WS.
On a WS we have a very good performace. The PC version of the
software is very "transportable" because lot of people have one
and is a cheap platform.
- In future, developers should wish to work on C++ using the MLC++
implementation. It's very easy to include my C code on their C++
system.
Thanks again for your opinions.
#-------------------------------------------#--------------------------------#
# JOSE CARLOS CID VITERO (Charlie) ITIG. | http://www.eis.uva.es/~charlie #
# Grupo de Ciencias Cognitivas Aplicadas y | mailto:cha...@dali.eis.uva.es #
# Vision por Computador. | #
# Dpt. Ingenieria de Sistemas y Automatica. | Tlf : (983) 42-33-55 42-33-58 #
# Escuela Tecnica Superior de Ingenieros | Fax : (983) 42-33-10 42-33-58 #
# Industriales. Universidad de Valladolid. | Paseo del cauce S/N. 47011 VA #
#-------------------------------------------#--------------------------------#
Rainer Joswig
In article <01bbb94b$46a00ac0$ec953ccf@default>, "Dan Winkler"
<hey...@tiac.net> wrote:
> I would even set aside the question of MOST successful applications and
> just ask someone to show me ONE successful Lisp application. By "show
> me" I mean something I can download and try. By successful I mean
> something
> I would use regularly. I have lots of programs written in C that meet
> those
> criteria but none in Lisp.
Well, I'm using XEmacs daily. It is my preferred editor on Unix
(maybe there is a version for Windows).
If you would have a Lisp machine you could download CL-HTTP from
MIT AI Lab. Well, on a Lisp machine you don't need to download
it, you can directly install from the FTP server. It is
a web server written in Common Lisp - I use it daily. It is also
available in source with ports for MCL, ACL and LispWorks.
You may want to look at WebMaker from Harlequin. It translates
FrameMaker docs into HTML. Well, it has been used by
Apple to translate all their "Inside Macintosh" volumes.
If you have a Mac you may look at "Interaction/IP" written
by Terje Norderhaug (Te...@in-Progress.com):
I am proud to say that the application has developed quite a bit from its
conception as one of the first threaded forums on the web back in 1994.
Interaction is now a solid framework for advanced web services, with chat
rooms and shopping as two manifestations. A high number of web sites use
Interaction every day for purposes such as:
* Visitor Entertainment
* On-line customer support
* Open discussions
* Virtual Cafe's
* Socializing
* Dating services
* Distance meetings
* Intranet Groupware
* Dynamic websites
...
> But in my experience Lisp can be much slower than C. Especially for
> character processing. I once wrote a program to read some ascii and
> decode it into binary. C was much faster at that than Lisp.
Depends on how you write this stuff in Lisp. To see how to get
a reasonable performance even with a object-oriented design
you may want to look at the sources of CL-HTTP. This may
give you an idea how real world Common Lisp code can look like.
> Of course,
> you
> can always write low level things like that in C and call them from your
> Lisp
> program.
If we can't do it in Lisp, then there should be something wrong.
Complete OS were written in Lisp.
> Another big problem with Lisp is you can't make a small, stand-alone binary
> with it. The smallest application you can build is usually about a
> megabyte.
> Hard drives are so large now that this may finally not be such a problem
> anymore. (I'm referring now to my experience with Common Lisp. I'm sure
> Scheme systems can make smaller binaries.)
True.
> So can anyone point me to a useful application, written in Lisp, that I can
> download and try? I can show you plenty done in C.
If you happen to have a running Common Lisp or Scheme, there is
plenty of Lisp software out there. See ftp.digitool.com
for MCL specific stuff, or see the CMU AI repository,
see the Scheme repository, ...
Rainer Joswig
Erik Naggum
[Rainer Joswig]
| Well, I'm using XEmacs daily. It is my preferred editor on Unix
| (maybe there is a version for Windows).
FWIW, GNU Emacs runs on Windows 95 and NT, too.
| > Another big problem with Lisp is you can't make a small, stand-alone
| > binary with it. The smallest application you can build is usually
| > about a megabyte. Hard drives are so large now that this may finally
| > not be such a problem anymore. (I'm referring now to my experience
| > with Common Lisp. I'm sure Scheme systems can make smaller
| > binaries.)
|
| True.
but... Wade L. Hennessey's WCL uses shared libraries to produce very small
binaries (smaller than C++ with GCC). granted, the shared libraries are
enormous, but enormous shared libraries don't stop people who use other
enormous shared libraries from pointing to their small, not-so-stand-alone
binaries and gloat. with WCL, Common Lisp programmers can do the same if
they wish. WCL runs on SPARCs with SunOS and Solaris. it seems not to be
maintained. <URL:ftp://cdr.stanford.edu/pub/wcl/>
Erik Naggum
[Glen Clark]
| Who hates AI? Can you give some examples. This is not a bait.
| It is a serious question.
I don't want to broadcast a professor's name, but his reaction to anything
that resembles AI has been so strongly negative that the whole department
has not done any research into AI techniques at all for the past 15-20
years, despite research in areas where AI researchers have gained important
progress, such as image processing. he's unfortunately not alone.
Bruce Tobin
Mukesh Prasad wrote:
>
>
> This may be slightly misleading. I don't know about Autocad,
> but GNU Emacs and Interleaf are both written in C. But in
> both these cases, the C code also has an embedded Lisp (or
> Lisp-ish, in case of GNU Emacs) interpreter. Thus once the
> basic system is up, various extensions written in Lisp
> can be loaded and executed. It is doubtful that in these
> two cases, the basic system itself would have been usably
> fast if all of it was written in Lisp -- but it is certainly
> the case that the usage of Lisp as an extension language
> has proved to be a very powerful and flexible extension mechanism
> in both.
This is itself misleading. I don't know about
Interleaf, but GNU Emacs is written in Lisp. The
distribution, for reasons of portability, includes
C source for the Lisp interpreter. Unfortunately
C compilers are a lot more common than Lisp
compilers, making this mode of distribution a
practical necessity. An Emacs editor written from
scratch in Common Lisp would be faster, not
slower-- take a look at Hemlock.
Harley Davis
"Dan Winkler" <hey...@tiac.net> writes:
> > Bottom line: The proof of which is better (C++ or Lisp) is to
> > look at the commercially successful applications. If Lisp is such
> > a hot language, how come most applications are all written in C and
> > C++?
>
> I would even set aside the question of MOST successful applications
> and just ask someone to show me ONE successful Lisp application. By
> "show me" I mean something I can download and try. By successful I
> mean something I would use regularly. I have lots of programs
> written in C that meet those criteria but none in Lisp.
How do you feel about Java?
-- Harley Davis
-------------------------------------------------------------------
Harley Davis net: da...@ilog.com
Ilog, Inc. tel: (415) 944-7130
1901 Landings Dr. fax: (415) 390-0946
Mountain View, CA, 94043 url: http://www.ilog.com/
scha...@wat.hookup.net
In <325E82...@dma.isg.mot.com>, Mukesh Prasad <mpr...@dma.isg.mot.com> writes:
>> Graham also notes: GNU Emacs, Autocad, and Interleaf are all written
>> in Lisp.
>
>but GNU Emacs and Interleaf are both written in C. But in
>both these cases, the C code also has an embedded Lisp (or
>Lisp-ish, in case of GNU Emacs) interpreter. Thus once the
>basic system is up, various extensions written in Lisp
>can be loaded and executed. It is doubtful that in these
>two cases, the basic system itself would have been usably
>fast if all of it was written in Lisp -- but it is certainly
>the case that the usage of Lisp as an extension language
>has proved to be a very powerful and flexible extension mechanism
>error prone, to try to provide C or C++ as a user-level
>dynamic extension language to the base system (it is
>possible to do this, e.g. in "plug-in"s such as found in
>Netscape Navigator, but these interfaces are nowhere near as
>flexible, powerful and convenient as GNU Emacs and Interleaf user
>extensions.)
It seems to me that the C code is solely to provide the elisp and bytecode
interpreter. Granted, Elisp has lots of datatypes and fubctions designed to
make editing tasks written in Elisp easier, but the editor itself seems to be
written in Elisp.
Hartmann Schaffer
Cyber Surfer
In article <32618AFA...@clarkcom.com>
gl...@clarkcom.com "Glen Clark" writes:
> Erik Naggum wrote:
>
> > my guess is that the intense hatred for AI in some quarters can
> > be attributed mostly to the desire to externalize the feeling of stupidity
> > in having believed the hype to begin with.
>
> Who hates AI? Can you give some examples. This is not a bait.
> It is a serious question.
Mrs Thatcher, ex Prime Minister of Great Britain (an ironic name
for an island - er, set of islands - if ever there was one). It
was allegedly a comment by Marvin Minsky about "AI"s someday
wanting to keep us as pets that prompted Mrs Thatcher to kill
the Alvy (? I'm not sure of the name...) project. For those who
don't know, that was a big AI project in this country.
I hope this is a serious answer, even if I can't provide many
details. All I know about it comes from watching TV, so don't be
too suprised if some of them are wrong! On the other hand, I do
remember the project being cancelled, whatever the reason may
have actually been.
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
Future generations are relying on us
It's a world we've made - Incubus
We're living on a knife edge, looking for the ground -- Hawkwind
Rainer Joswig
> but... Wade L. Hennessey's WCL uses shared libraries to produce very small
> binaries (smaller than C++ with GCC). granted, the shared libraries are
> enormous, but enormous shared libraries don't stop people who use other
> enormous shared libraries from pointing to their small, not-so-stand-alone
> binaries and gloat. with WCL, Common Lisp programmers can do the same if
> they wish. WCL runs on SPARCs with SunOS and Solaris. it seems not to be
> maintained. <URL:ftp://cdr.stanford.edu/pub/wcl/>
Right, there is also CLICC, a Common Lisp to C Compiler.
You can compile a subset (the dynamism removed) of
Common Lisp directly to C. I never have used
it, but it should generate small binaries, too.
Then there was the expensive Lisp-to-C compiler
from Chestnut, I wonder how big the generated
applications were (minimum that is).
MCL also uses shared libraries.
Rainer Joswig
Stephen Wolstenholme
>In article <32618AFA...@clarkcom.com>
> gl...@clarkcom.com "Glen Clark" writes:
>
>> Erik Naggum wrote:
>>
>> > my guess is that the intense hatred for AI in some quarters can
>> > be attributed mostly to the desire to externalize the feeling of stupidity
>> > in having believed the hype to begin with.
>>
>> Who hates AI? Can you give some examples. This is not a bait.
>> It is a serious question.
>
>Mrs Thatcher, ex Prime Minister of Great Britain (an ironic name
>for an island - er, set of islands - if ever there was one). It
>was allegedly a comment by Marvin Minsky about "AI"s someday
>wanting to keep us as pets that prompted Mrs Thatcher to kill
>the Alvy (? I'm not sure of the name...) project. For those who
>don't know, that was a big AI project in this country.
>
I think the Alvey project came to an end when it ran out of money
after it's initial phase. Wasn't it European rather that just British?
No doubt Mrs Thatcher did have some involvement in not providing the
money.
Steve
--------------------------------------------------------------------------
Stephen Wolstenholme, Cheadle Hulme, Cheshire, UK
st...@tropheus.demon.co.uk
Author of NeuroDiet.
Windows 95 Neural Network Health & Fitness Diet Planner
http://www.simtel.net/pub/simtelnet/win95/food/ndiet10.zip
ftp://ftp.simtel.net/pub/simtelnet/win95/food/ndiet10.zip
Harley Davis
jos...@lavielle.com (Rainer Joswig) writes:
Ilog Talk seems to be the only extant commercial Lisp system which
compiles to C and generates and uses shared libraries.
Marty Hall
Gary Brown <gbr...@thebrowns.ultranet.com> writes:
> Compiled LISP can approach other languages in speed. But, that imposes
> constraints
> that restrict most of the functions that makes LISP desirable in the
> first place.
I'm confused by this. Could you give some examples of where compiling
your code restricts you? In the case of Common Lisp, most people I
know *always* run compiled, even during development. Some Common Lisps
(e.g. Allegro CL/Windows) only compile, and never run anything
interpreted.
- Marty
Lisp Programming Resources: <http://www.apl.jhu.edu/~hall/lisp.html>
Norman Ma
In article <01bbb6ef$726ff740$Loca...@intnet.mu.intnet.mu> "Eddy Young" <yo...@arbornet.org> writes:
:But, the most complete AI programming package I've found so far comes from
:the NASA. It's called CLIPS (derived from LISP???)
CLIPS stand for C Language Integrated Production System.
--Norm
Cyber Surfer
In article <326559b8.3542463@news>
st...@tropheus.demon.co.uk "Stephen Wolstenholme" writes:
> I think the Alvey project came to an end when it ran out of money
> after it's initial phase. Wasn't it European rather that just British?
> No doubt Mrs Thatcher did have some involvement in not providing the
> money.
Well, it's her alleged attitude to AI that interests me, not
so much what part she played in killing Alvey. I find it more
significant that she's given credit for the killing - but perhaps
that's just anti-Thatcher propaganda? I dunno.
In these post-Thatcher days, it's very hard to tell. Almost
nobody who knows anything about it can be objective. Today,
the pro/anti "European" issue is more relevant - but that's
a whole different matter! Let's not get into _that_, please.
Of course, just withholding money can successfully kill a
project. That may be what was refered to. As for the cause,
I dunno. Did she actually meet Minsky? If so, what _did_
he say to her? Etc, etc.
A more interesting question might be: who makes more money from
lecture tours, Minsky or Thatcher? ;-) No, don't answer that!
I doubt that anybody cares.
Mukesh Prasad
>It seems to me that the C code is solely to provide the elisp and >bytecode
>interpreter. Granted, Elisp has lots of datatypes and fubctions >designed to
>make editing tasks written in Elisp easier, but the editor itself seems >to be
>written in Elisp.
>
>Hartmann Schaffer
I would have to disagree. The C code for byte code
interpreting is small compared to the rest
of the emacs C code. Also, most of the core editor
algorihtms were in C the last time I looked.
Elisp provides several "facilities" and "hooks"
on top, not at the core level.
Though I am sure rms placed as much functionality
in Lisp as he felt he reasonably could.
Richard A. O'Keefe
George Van Treeck <tre...@sybase.com> writes:
>That's a very good point! If you're a professor in some ivory tower
>you can afford to savor your favorite computer language.
There are very few ivory towers left, and professors don't get to live
in them. (You have to be an "Entrepreneur" for that, which is today's
eumphemisum for a rich criminal. But I digress...)
Tertiary education in this country faces continuing funding cuts
and a government which is actively hostile to the idea of "social good"
or anything except "private enterprise" doing anything. (For a critique
of what undiluted pursuit of the almighty dollar has actually accomplished,
read the book "The Coming Plague". Consider also the fact that an
*advocate* of private health stated in a TV interview here that private
health is 6 times more expensive than public health. And it doesn't make
you 6 times healthier either.)
The pervasive attitude is "I don't want to know anything if it isn't in
the final exam; how dare you put anything in the final exam if it isn't
relevant to industry; so what you _used_ to work in a software company,
you don't have a PC on your desk, you know _nothing_ nya nya".
In short, today's professors are stuck with the languages their students
are willing to pay to learn. Just this year, a very good place that was
doing a great job of teaching people, using Ada, was forced to switch to
C++ as an introductory language (now _there's_ a nightmare; whatever the
merits of C++ for experts, it's hell for novices), even though Ada 95 is
superior on every metric I'm aware of except popularity. That was a bad
day for education in this country.
>If you
>develop software that must be sold to put food on your plate, then
>you become much more conservative! Your definition of best becomes
>more dominated in terms of what is the "safe" choice.
I am fully in agreement that a software engineer chooses a language
to reduce risk and lifecycle costs.
>And the safe choice is one that is popular --
But there are *many* popular languages, not just C.
There are a lot of applications where Visual Basic or Delphi, to name
just two popular languages, might be a much better choice than C.
>has support from many vendors,
>books, lots of staff you hire that already know the lanugage, etc.
These are independent properties. For example, Perl has lots of books
(some of them very bad, but none that quite matches the badness of most
C books) and a lot of people know it, but there is only one implementation.
>That means your favorite is something commercially successful.
Yes, but the fact that a *tool* sells well doesn't mean that a
*product* made using that tool will work. Philips head screws
are commercially successful, but other kinds of screws are still
deservedly popular (and indeed there is a much better head that
has been available for a couple of years know but has not yet
reached popularity; check through the last decade's Scientific
American and Discover if you are interested).
>You know that if it's commercially successful, that there is a
>high probability you can get the project out the door with sufficient
>quality to sell it.
This is absolutely false. C and C++ are commercially successful.
There have been *numerous* failed projects using those languages.
In fact the C code I see follows a "Sturgeon's Square Law".
Sturgeon's Law: "90% of _everything_ is crud."
Sturgeon's Square Law: "99% of C programs are crud."
Just to give two examples:
for many years it was a popular passtime for UNIX-haters to try
$ANY_UNIX_UTILITY </vmstat
Many UNIX utilities (written in C) would crash.
Just the other day I reported a bug to Sun via our technical
support group. The UNIX editor 'ed' has been around since
the 1970s, something like 20 years now. I made a one-character
typing mistake in a common command, and ed dumped core. Guess
what language ed is written in?
>> in other words, the "commercially successful" argument is a statement of
>> shallowness on the part of he who uses that argument.
>It is not shallowness. It's pragmatism.
Pragmatism has no such tunnel vision. Following the other sheep into
the freezing-works-bound truck is not pragmatism. Pragmatism relies
on experiments, measurements, trying things out, not taking things on
authority. Professional programming doesn't take _any_ tool for
granted, but makes a serious attempt to estimate costs and risks for
_all_ choices.
>It's not myths. At Digital, a CAD tool was written in Lisp and dumped
>because it Lisp was just too slow. Lisp can't be used in real-time
>applications, because you need to guarantee response time. A 911
>call needs to routed over the phone lines and can't afford to wait
>for Lisp program to take a coffee brake (garbage collect for some
>indeterminate period).
I've got some bad news for you. Several emergency phone systems
in several countries have seriously misbehaved.
I've got some even worse news for you: Ericsson, a major international
telecoms company, has developed a programming language for real-time
distributed programming of things like telephone switches. It's called
Erlang. Lisp programmers would find it _much_ more familiar than C
programmers.
>And the code size is too large to be
>quickly activated and used for small utility applications. Perl,
>Tcl, C/C++ are used instead.
Oh the same tired old lie. Lisp code is as small as you want it
to be. Perl, with *none* of my code in it, is larger than most of
the Lisp systems I have ever used.
>Virtually all new commercial applications are developed in C/C++.
>If you worked in the "real-world" (companies that develop
>commercial software) you know that.
I worked in a real-world company that developed commercial software.
We used C, assembler, two Lisps, and Prolog, plus a bit of Awk and
shell scripts. Perhaps because we weren't developing *mass market*
code for PCs, you will dismiss us as "not real world". But we made
millions of dollars a year and stayed in business until we were bought
out and the purchaser put some of our key programmers onto other tasks.
>Look in the new paper for
>programming jobs. Count the number of ads wanting C/C++ vs.
>FORTRAN/COBOL.
The adds do not tell you how much work is being done in any
particular language. They only tell you how much work is NOT
finished because they still need people.
>Many in-house applications are being developed in VisualBasic
>or some 4GL/GUI tool like PowerBuilder, because it requires
>less technical skill ($25/hr labor for VisualBASIC programmer
>vs. $60/hr for C++ programmer) and development is quicker
>using something like PowerBuilder. Lisp could never
>cut it in that market either.
It could be the implementation language underneath such a tool,
though. Some of the earliest 4GLs _were_ developed in Lisp,
but at a time when the market didn't believe in 4GLs.
--
Mixed Member Proportional---a *great* way to vote!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.
Bjarne Stroustrup
Yes. For some reason, there is a tendency to exaggerate the influence of
Smalltalk on C++ (possibly because of the pure-OOP hype and the relative
obscurity of Simula).
I don't list Smalltalk among C++'s ancestor languages (see the chart on
page 6 of D&E) whereas C and Simula are listed as the primary and direct
ancestors. Simula provided my original inspiration in both the area of
language features and in the area of programming/design techniques.
- Bjarne
Bjarne Stroustrup, AT&T Research, http://www.research.att.com/~bs/homepage.html
Alexey Goldin
Mukesh Prasad <mpr...@dma.isg.mot.com> writes:
>
> >It seems to me that the C code is solely to provide the elisp and >bytecode
> >interpreter. Granted, Elisp has lots of datatypes and fubctions >designed to
> >make editing tasks written in Elisp easier, but the editor itself seems >to be
> >written in Elisp.
> >
> >Hartmann Schaffer
>
> I would have to disagree. The C code for byte code
> interpreting is small compared to the rest
> of the emacs C code. Also, most of the core editor
> algorihtms were in C the last time I looked.
> Elisp provides several "facilities" and "hooks"
> on top, not at the core level.
On my Sparc 5 running Sparc Linux:
cd /usr/share/emacs/19.34/
spot:/usr/share/emacs/19.34$ du lisp
du lisp
239 lisp/term
19722 lisp
spot:/usr/share/emacs/19.34$
20 Megs seems like quite a lot to me.
I also believe that 20 megabytes of Lisp "facilities" and
"hooks" have way more functionality than 20 megabytes of C code.
Erik Naggum
* Mukesh Prasad <mpr...@dma.isg.mot.com>
| I would have to disagree.
on what basis do you make conclusions about Emacs? do you know the code
intimately? well, I do.
| The C code for byte code interpreting is small compared to the rest of
| the emacs C code.
ahem, the issue was the Lisp machine, not the byte code interpreter. if
you insist on being silly and twisting people's words, do not expect to be
respected.
what distinguishes a C program from a Lisp program? first of all, it has
functions defined in a C-like fashion, and makes function calls in the
normal C way. in Emacs, 90% of the C code consists of Lisp-like C-code and
Lisp-like calls to such functions. second, if a C program contains
assembly code for efficiency, it is no less a C program -- it just has some
sections of itself that are hand-compiled because that would speed things
up or do something that is hard to do in C. (and believe you me, C is
_not_ the all-purpose language it is believed to be.)
90% of the C code in Emacs is effectively hand-compiled Lisp.
how can I say that? because I'm working on an Emacs Lisp to C compiler for
these things, such that (1) one may write in Lisp instead of the tortous
output of the imaginary compiler that exists today, and (2) one may compile
functions in any package that turns out to need the speed.
| Also, most of the core editor algorihtms were in C the last time I
| looked.
you haven't looked at all, have you, Mukesh?
| Elisp provides several "facilities" and "hooks" on top, not at the core
| level.
Emacs is written in Emacs Lisp. the display system and the Lisp machine is
written in C for two reasons: (1) speed, and (2) portability, respectively.
| Though I am sure rms placed as much functionality in Lisp as he felt he
| reasonably could.
it is better to say that as little of the functionality is in C as possible
because it sacrifices (1) readability, and the purpose of free software is
to make people able to learn from other programmers, (2) flexibility, as it
takes much more effort to be flexible in C than in Lisp.
(note that XEmacs goes the other way: with more and more code hidden in
impenetrable C code with "abstract types" implemented solely in C and used
only by Lisp through an "API". one _might_ say that Emacs is written in
Lisp because its programmers think in Lisp, whereas XEmacs is written in C
because its programmers think in C.)
Felix Kasza [MVP]
Eddy,
> LISP was created with AI programming as objective
I seem to recall that it was intented to process arbitrary lists --
witness both the name (LISt Processor) and its primitives (car, cdr,
...).
Cheers,
Felix.
Neil Henderson
> > Ah, yeah. By that measure, COBOL is the best language, followed closely
> > by Fortran 77, and then Visual Basic.
My solution to this dispute is to look at the career ads in the newspapers
and on the web. You will notice that C++ is being used to build MANY more
applications than LISP. (Actually I haven't seen a job ad for LISP). C++
is far more flexible than LISP in terms of what can be done, is much better
supported, and if you're really hurtin for hyper-fast code you can still
write inner loop functions in assemby language.
I'll sum up:
Learn LISP and be unemployed.
nh
Jim Veitch
Go look at the jobs offered at our Web page. Subscribe to
ai+ai...@cs.cmu.edu and ai+lis...@cs.cmu.edu. One problem for
companies using Lisp is that all the competent Lisp people are being
lured away to work in companies to implement Java, implement dynamic
network languages, implement dynamic Web servers, etc., for huge
salaries (these jobs don't normally list Lisp as a requirement, its just
that if Lisp people apply they seem to have what it takes). Makes it
tough for an ordinary Lisp company to find people. I have yet to hear
of an unemployed Lisp user except maybe one in the U.K.
Jim.
David Hanley
> My solution to this dispute is to look at the career ads in the newspapers
> and on the web. You will notice that C++ is being used to build MANY more
> applications than LISP.
There are more ads specifically requesting C++ coders, but this does
nothing to elucidate the effacy of programming in the two languages.
For one thing, it might mean it takes more C++ coders. :)
(Actually I haven't seen a job ad for LISP). C++
> is far more flexible than LISP in terms of what can be done,
In what way? Both languages are turing-complete.
>is much better
> supported,
True. Hopefully, the lisp companies will eventually catch up in this
department.
> and if you're really hurtin for hyper-fast code you can still
> write inner loop functions in assemby language.
You can do that in lisp too.
dave
scha...@wat.hookup.net
In <01bbbbcb$8cc31150$558ad2cd@paris>, "Neil Henderson" <vor...@worldchat.com> writes:
>> > Ah, yeah. By that measure, COBOL is the best language, followed closely
>> > by Fortran 77, and then Visual Basic.
>
>and on the web. You will notice that C++ is being used to build MANY more
>is far more flexible than LISP in terms of what can be done, is much better
>supported, and if you're really hurtin for hyper-fast code you can still
>write inner loop functions in assemby language.
>
> Learn LISP and be unemployed.
>
>nh
>
>
I submit that Lisp is a better vehicle to learn programming concepts. Once
you know those, it's essentially a question of picking up the paradigms and
syntax of tha actually used language to get going (later it is a question of
overcoming your frustration about being stuck with a language that puts up
roadblocks).
I am very frustrated when I see people taking programming classes where the
whole class contents is going over the syntax and a little bit of semantics
of one language. Graduates from classes like that all too often end up knowing
nothing about programming.
Hartmann Schaffer
Felix Kasza [MVP]
Erik,
> my guess is that the intense hatred for AI in some quarters
I do hope that my original post doesn't classify me as an AI-hater. My
original question remain unanswered, however. All my dictionaries tell
me that "intelligence" refers to either the household meaning of
intelligence (a whole field of research on its own) or to the gathering
(and product thereof) of information -- as in "military intelligence".
I therefore expect the name "Artificial Intelligence" to refer to either
any kind of mechanism that displays "intelligent behaviour" in the first
sense, or that makes up pseudo-facts and disguises them to look like
information (second sense).
The WWW hype you refer to is quite different; after all, the name is
much less of a claim that "Artificial Intelligence".
To summarize, I fail to see how any current product can claim to be
"intelligent"; this served as my argument to Rainer Joswig, who in a
most impolite manner told another poster, "Obviously you have no idea of
AI and AI software development.".
All I wanted is show Rainer that he was just as clueless, or he would
realize that AI doesn't exist, with or without Lisp.
Cheers,
Felix.
Milind G Pandit
There are a lot of applications developed using (IDL)/Lisp from Concentra Corp.
This company has product called ICAD, which is very popular with Boeing, Pratt
and Whitney, GE and many more. I do not know if they have any application you
can download and use, but you can visit their WEb page. I have been using their
product for a few months now and it is working well. It is very expensive
though.Their URL is WWW.concentra.com.
--Milind
George Van Treeck
Please make all continuing responses on this topic to this note.
That way responses won't be cross-posted to comp.ai.genetic and
comp.ai.neuralnets (the only two comp newsgroups I read). These
two areas do not use symbolic processing at all. They are
computationally intensive, using primarilly C and C++. In other
words, take your smelly dead horse discussion elsewhere!
thomas hennes
Gary,
>Gary Brown wrote:
>
> > If Lisp is such a hot language, how come most applications are all written in C and
> > C++?
>
> COMMON LISP is big, slow, expensive, and somewhat esoteric. It is a
> great language to
> program in for many applications. However, the programming language is
> invisible to
> end-user. LISP gives the end-user nothing for the extra resources it
> requires.
>
Well, i am not sure about this. Consider the case of software agents
--which is directly linked to AI if you bear in mind that GOOD agents
are genetically evolutive (ideally). When dealing with networked agents,
you just cannot let pointer arithmetic (an automatic feature of C/C++)
get into the way, for obvious security reasons. LISP, on the other hand,
is one language that manages this pretty well, as do others such as
SafeTCL (another interpreted language!!).
What i actually believe is that interpreted languages and compiled
languages have very different application domains. Interpreted languages
work wonders when used as tiny specialized scripts.
Thomas
David J. Sieber
scha...@wat.hookup.net wrote
> I submit that Lisp is a better vehicle to learn programming concepts.
Once
> you know those, it's essentially a question of picking up the paradigms
and
> syntax of tha actually used language to get going (later it is a question
of
> overcoming your frustration about being stuck with a language that puts
up
> roadblocks).
Would you have any recommendations for books and/or approaches for a
long-time C/C++ programmer who would like to "move up" to Lisp? I
downloaded a trial of Franz's Allegro, but haven't done anything with it
yet (but it looks fascinating).
-- Dave Sieber
dsi...@terminal-impact.com
http://www.terminal-impact.com
Carl L. Gay
From: thomas hennes <aie...@pobox.oleane.com>
Date: Sat, 19 Oct 1996 03:48:28 +0100
Well, i am not sure about this. Consider the case of software agents
--which is directly linked to AI if you bear in mind that GOOD agents
are genetically evolutive (ideally). When dealing with networked agents,
you just cannot let pointer arithmetic (an automatic feature of C/C++)
get into the way, for obvious security reasons. LISP, on the other hand,
is one language that manages this pretty well, as do others such as
SafeTCL (another interpreted language!!).
Another?
What i actually believe is that interpreted languages and compiled
languages have very different application domains. Interpreted languages
work wonders when used as tiny specialized scripts.
No, Common Lisp is not an interpreted language.
Yes, Lisp interpreters exist.
All commercial Common Lisps that I'm aware of are compiled by default.
Even if you type in a "tiny specialized script" it is usually compiled
before it is executed.
Harumph. :)
Scott J. McCaughrin
In a previous article, cg...@ix.cs.uoregon.edu (Carl L. Gay) says:
>
> What i actually believe is that interpreted languages and compiled
> languages have very different application domains. Interpreted languages
> work wonders when used as tiny specialized scripts.
>
>No, Common Lisp is not an interpreted language.
>
>Yes, Lisp interpreters exist.
>
>All commercial Common Lisps that I'm aware of are compiled by default.
>Even if you type in a "tiny specialized script" it is usually compiled
>before it is executed.
>
"by default" -- Does that allow the possibility of interpreted CL? If so,
then it would be both an interpreted and compiled language.
I don't believe languages are necessarily interpreted or compiled per se:
I believe the choice to interpret or compile is made outside of the lan-
guage.
Erik Naggum
* Felix Kasza <fel...@mailbag.shd.de>
| I therefore expect the name "Artificial Intelligence" to refer to either
| any kind of mechanism that displays "intelligent behaviour" in the first
| sense, or that makes up pseudo-facts and disguises them to look like
| information (second sense).
this reminds me of the etymology of two words in ordinary English that
differ quite remarkably from their perceived meaning. "muscle" comes from
the Latin "musculus", dimunitive of "mus", our "mouse". this is allegedly
because muscles show movement much like small mice, contracting and
stretching as they do when they move. would you raise an eyebrow should
someone complain loudly that muscles are emphatically _not_ small mice? a
"compilation" (a collection of writings) comes from the Latin "compilare",
which means "to plunder". because some authors plundered the writings of
others and put them together as their own 400-odd years ago, today's
"compile" means "to collect". I would find it surprising if somebody who
has duplicated software in violation of license agreements (I think a
"pirate" is an evil man who kills and robs at sea, and I refuse to use it
about computer users, regardless of their crimes, alleged or real), would
defend himself by arguing that the programs were "plundered" to begin with.
the real question, of course, is which dictionary you use. used wrongly, a
dictionary of etymology will make a man a source of much ridicule. used
wrongly by a patient, a medical dictionary will do nothing but frustrate
the medical doctors who has to deal with that patient. your looking up
"intelligence" alone in a dictionary shares many of these qualities.
Rainer Joswig
In article <32665ffa...@babya.shd.de>, fel...@mailbag.shd.de (Felix
Kasza [MVP]) wrote:
> I therefore expect the name "Artificial Intelligence" to refer to either
> any kind of mechanism that displays "intelligent behaviour" in the first
> sense, or that makes up pseudo-facts and disguises them to look like
> information (second sense).
As you may guess, you are not the first German who doesn't
understand it. Again, read the literature about AI and
you will see that making human-like thinking beings
is not the top priority of most AI researchers.
Instead they have completely different goals.
The debate about the term "Artificial Intelligence" is
old, such as the misunderstandings caused by these words.
German translation is "Kuenstliche Intelligenz", which
is even worse, because it misses the meaning
of "intelligence". Some people prefer "Wissenabasierte Systeme",
"Kognitive Systeme", etc., depending of the field they are working
in.
> To summarize, I fail to see how any current product can claim to be
> "intelligent"; this served as my argument to Rainer Joswig, who in a
> most impolite manner told another poster, "Obviously you have no idea of
> AI and AI software development.".
Yes, and I may have that to say again. If you want to discuss
this topic, some prior knowledge of this area may be required.
For example it would be worth knowing something about the
history of "AI" and the various developments that have taken
place. As you can imagine, a field with thousands of researchers
is very diverse and many opinions do exist about what
AI is. Also knowing a bit about AI software in industry may
help (hint: for some years there have been conferences
devoted to this topic.).
Example:
People are working on a new generation of ships. Ships,
that have diagnosis systems on board, ships that can
do navigation (for example builing a simple convoy, etc.).
Who cares whether the ship will pass the Turing test?
It may be sufficient, that it can safely find a way
on the ocean.
Example two:
There are systems with gather data from those
high-voltage power lines all over the country.
If some interruptions happens these systems
try to identify the location of the problem.
Obviously you need some diagnosis capability.
This enables to send repair teams directly to
the place where the cause of the power outage
is, without searching it for some time. Who
cares if this system will pass the Turing test?
Example three:
The European Union has to translate huge amounts
of texts. Many texts can be translated with
some support from computers (for example see
the Metal system from Siemens). Who cares
if the machine translation software will pass
the Turing test? Still it does useful work.
Example four:
American Express has to look at every money
transcation of their customers. Most of
them are pretty trivial and can be
checked very fast. But some of these transaction
may require more background knowledge about
the customer. Think, a company like
American Express has to maximize customer
satisfaction. The complicated decisions are being
handled by some Lisp machines. I don't care
whether these machines will pass the Turing test.
Still they have to decide whether a money transaction
is o.k.
Are these examples not AI software? If not, why?
> All I wanted is show Rainer that he was just as clueless, or he would
> realize that AI doesn't exist, with or without Lisp.
Your remark is a stupid one. You may have a completely
different definition of AI than I have. Which basic
books about AI do you have read? (Seems like reading
books is a bit out of fashion and posting is easier.)
For a modern introduction into AI you may look into the latest
book by Russel/Norvig. Or read Mark Stefik's book about
knowledge systems. Email me, in case you need an
ISBN Number. Some books about Expert Systems, Machine Translation,
Image Processing, Automated Reasoning, Knowledge Representation,
Robotics, Planning may give you an idea what AI is about.
Rainer Joswig
Marty Hall
"Neil Henderson" <vor...@worldchat.com> writes:
> You will notice that C++ is being used to build MANY more
> applications than LISP.
True.
> (Actually I haven't seen a job ad for LISP).
See the last entry in the "Internet Resources" section of
<http://www.apl.jhu.edu/~hall/lisp.html> for several recent Lisp job ads.
>C++ is far more flexible than LISP in terms of what can be done
Obviously, this depends on what you are trying to do. Give an example
of the kinds of things you want to do, then some meaningful
comparisons can be drawn. For many (but not all) of the things *I*
typically do, Lisp is more flexible.
- Marty