Newsgroups: comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!newsfeed.pitt.edu!gatech!newsfeed.internetmci.com!news.mathworks.com!fu-berlin.de!news.dfn.de!news.dkrz.de!news.rrz.uni-hamburg.de!news.Hanse.DE!wavehh.hanse.de!cracauer
From: cracauer@wavehh.hanse.de (Martin Cracauer)
Subject: Re: efficiency of Lisp compared to other progr. lang.?
Message-ID: <1996Mar4.162214.15901@wavehh.hanse.de>
Organization: BSD User Group Hamburg
References: <1996Feb26.121927.25154@wavehh.hanse.de> <4gtgsh$b13@ra.nrl.navy.mil>
Date: Mon, 4 Mar 96 16:22:14 GMT
Lines: 56

pitre@n5160d.nrl.navy.mil (Richard Pitre) writes:

>In article <1996Feb26.121927.25154@wavehh.hanse.de> cracauer@wavehh.hanse.de  
>(Martin Cracauer) writes:
>> pitre@n5160d.nrl.navy.mil (Richard Pitre) writes:
>> 
>> >Correct me if I'm wrong about these speed tests but I think that they tend  
>to  
>> >be done on C/Pascal turf. If on the other hand the primary data types are  
>> >expression trees of indeterminate size and there is pattern matching  
>involved  
>> >then, before you get to the speed issue, there is a question in the minds of  
>> >many about the availability of C/Pascal programmers who can reliably  
>generate  
>> >useful code of this type. 
>> 
>> Right, I think. However, you can get very far with simple data types
>> when using enough manpower. All this GUI stuff today is implemenated
>> that way. And it *is* faster than Lisp solutions (CLIM, CLIO, Garnet).
>> 
>> Your argument may be turned against CLOS. Using complex data types in
>> Common Lisp usually means loosing all support by the compiler, while
>> C++ doesn't care and produces the same code for "1 + 1" in most cases,
>> even when expressed as call to an object.
>> 

>The one-language-for-everything debate is not constructive. My argument will  
>most certainly be turned against me but then I will stop arguing, shrug, and  
>make sure that my wallet and my towel are secure. I confess here and now, once  
>and for all that you CAN do everything in anything, with dime-a-dozen  
>programmers and its always faster, better, cheaper, more compatible,  
>politically correct and finally and most importantly doable with compatible  
>tools that are popular. If someone really believes that they can just as easily  
>afford to generate and maintain a particular application in C/C++ then, true or  
>not, that is their financial problem. With enough money you can do it in  
>assembler. You can really make it cook if you can afford to have a  
>microcodeable chip made up. I'm sure that a true believer can easily find  
>significant instances where this was accomplished. Better yet, screw the  
>microcode,  make a chip that is a digital emulation of the problem. 

>Outside of a few people who put a rediculously high value on their personal  
>time and who want to actually write code to do something rather than to be a  
>real CODE WARRIOR(there is actually a product named this), who needs Lisp and  
>Prolog?

I hope you didn't misunderstand me. Of course I don't advocate the
skillless programming tendencies widespread today. And actually use
Lisp for some projects I get payed for. Nothingtheless, some problems
in Lisp cause trouble for me.

Martin
-- 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cracauer@wavehh.hanse.de>  -  Fax +49 40 522 85 36
 BSD User Group Hamburg, Germany   -   No NeXTMail anymore, please.
 Copyright 1995. Redistribution via Microsoft Network is prohibited
