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.
RJ>Every bit of the above paragraph is true (IMHO).
Exactly. I personally think a C/C++ header parser is top on the list - everyday there is a new library, so a vendor can't catch up with (for example) Microsoft in new APIs. So better get a standard tool for the job.
RJ>Digitool, Franz, Harlequin, Symbolics. Four, isn't it? Are RJ>there any others (GoldHill, Venue, ...)?
Venue still is up.
RJ>Well, Digitool is currently developing support for OpenDoc RJ>for MCL. For this purpose IDL/SOM support is needed. This could RJ>be the FFI we are looking for. Better to have one approach RJ>on that particular topic.
Actually IDL/SOM is CORBA, so that will be a standard for the future, I think. The problem is, these aren't low-overhead approaches :-)
I still prefer to connect directly to basic system APIs, but this get's more problematic with every new release of system software - the basic APIs are just getting to complex (anyone ever programmed OLE or ACTIVE-X on native APIs without MFC? ;-) )
In article <udranea44f....@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.
* Erik Naggum wrote: > | Unfortunately, a number of CommonLisp's APIs are a tad outdated, > | including its I/O and file system interfaces ... > Could you substantiate this? It is difficult to uncover what you actually > think when you only provide vague conclusions.
Obvious I/O type things that CL is missing are random access to files and some kind of networking API. Of course everyone has these things, but it's a mild annoyance that you have to write glue code each time.
(of course they might be very hard to standardise...)
> 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.
-- ====== 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/ =========
In article <ud7mp2hpq7....@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.
> 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!
> 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.
> > 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 wrote: > [Tim Bradshaw] > | Obvious I/O type things that CL is missing are random access to files > I must have missed something. Is not `file-position' random access?
Yes it is, and I never knew it existed, how embarrassing...
| 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.
> 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.
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.
In article <53govj$...@nic.wat.hookup.net> schaf...@wat.hookup.net writes: > >| 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
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.
Wow! Actually, I have no knowledge of LISP, so I can't comment 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! ;)
In article <325B0122.1...@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++. -- <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
> | 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.
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 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 ====================
In article <325C6020.4...@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 >even sell COBOL because it's too small a market! [...] >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-ti...@nwu.edu> http://www.cs.nwu.edu/~tisue/
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.
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.
| 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.
#\Erik -- I could tell you, but then I would have to reboot you.
cyber_sur...@wildcard.demon.co.uk (Cyber Surfer) writes: >In article <325B0122.1...@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.
: | 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------
