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:char...@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 # #-------------------------------------------#------------------------------ --#
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: bshu...@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)
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 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------
In article <52v7nr$...@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.
> 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.
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.
> 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...
> 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.
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.
> 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.
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.
>> 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...
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.
"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.
> From: George Van Treeck <tre...@sybase.com> > [...] Java is about as fast as LISP [...] > 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.
It strikes me that a lot of the issues in optimizing Lisp compilers would also apply to Java compilers, and the performance would be similar. So I wouldn't be amazed.
Unfortunately (or perhaps fortunately :-), there aren't too many platforms on which to do this comparison. On UNIX, where there are several good Lisp compilers, there are not yet any released Java JIT compilers (Guava is in beta, and Sun's not yet out at all), only interpreters. On Windows 95/NT, there are at least three Java compilers (Borland, Symantec, Asymetrix), but AFAIK only one serious Lisp compiler to compare to (Franz). On the Mac, I think Metrowerks and Symantec (?) are the only Java compilers already released, but I'm not personally aware of any Power-PC native Lisp compiler (or is Digitool's MCL now PPC native? Pardon my ignorance).
t...@intentionally.blank-see.headers wrote: > In article <3253F13C.FF6D...@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."
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.
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.
(Newsgroups trimmed to comp.lang.lisp. Removed newsgroups: comp.ai, comp.ai.genetic, comp.ai.neural-nets, and comp.lang.c++.)
[t...@intentionally.blank-see.headers] (Believed to be Thomas Breuel)
| One thing that makes generating efficient numerical Java code so much | easier is that numbers are not objects, so passing them among compiled | functions, including structure accessors, without boxing is easier to | generate code for than in Lisp, where a compiler has to worry about the | possibility of boxed calls. Sadly, all Lisp compilers seem to throw in | the towel in that area, apart from some half-hearted special cases.
I have used CLISP, GCL, WCL, and CMUCL extensively. They all represent fixnums as unboxed machine words. With proper declarations, they generate code that neither expects nor returns boxed fixnums. CMUCL is faster for unchecked fixnum-only functions than C is. (That is, when C does not do bignums, does not detect overflow, etc, neither does the Common Lisp code, and the Common Lisp code wins by about 10% in performance.)
Methinks you have never actually programmed numerical code in Common Lisp.
#\Erik -- I could tell you, but then I would have to reboot you.
> On UNIX, where there are several good Lisp compilers, there are not > yet any released Java JIT compilers (Guava is in beta, and Sun's not > yet out at all), only interpreters.
Sorry for becoming off-topic, but some JIT Java compilers for Unix have recently become available:
SGI has a Java development environment called CosmoCode whose latest release includes a JIT compiler. You can download the beta version from http://www.sgi.com/Products/cosmo/beta/
Then there was an announcement for a commercial product called "Guava" (not to be confused with another, free, product with the same name) in comp.lang.java.programmer <URL:news:52osbg$hpg@floyd.sw.oz.au> which is a JDK-compatible run-time system with JIT compilation for Solaris 2.5. -- Simon.
t...@intentionally.blank-see.headers wrote: > 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++?
> This is a request for your opinion about the subject theme.--snip--
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.
>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.
Simon Leinen <si...@switch.ch> writes: > Marty Hall wrote > > On UNIX, where there are several good Lisp compilers, there are not > > yet any released Java JIT compilers (Guava is in beta, and Sun's not > > yet out at all), only interpreters.
> Sorry for becoming off-topic, but some JIT Java compilers for Unix > have recently become available:
> SGI has a Java development environment called CosmoCode whose latest > release includes a JIT compiler. You can download the beta version > from http://www.sgi.com/Products/cosmo/beta/
> Then there was an announcement for a commercial product called "Guava" > (not to be confused with another, free, product with the same name) in > comp.lang.java.programmer <URL:news:52osbg$hpg@floyd.sw.oz.au> which > is a JDK-compatible run-time system with JIT compilation for Solaris 2.5.
I hadn't realized that the SGI product included a JIT compiler. Note that the Guava you mentioned is the same one I mentioned, and is still in beta.
Anyhow, even though Carl is very knowledgeable about Lisp and knowledgeable about Java, on this particular issue ("amazed" if [compiled] Java were as fast as compiled Lisp), I beg to differ. I see no technical reason why Java need be any slower. Right now, I still think it is relatively hard to get good numbers for comparison, since there are few (no?) platforms for which there is more than one commercial non-beta Java compiler *and* more than one commercial Lisp compiler.
> 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/ =========
> > 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.
