Re: Pragmatic Requirements Summary : update

> Notice that CMUCL is a native-code compiler.  I wasn't comparing the speed 
> of LISP to C, I was comparing the speed of interpreted implementations to 
> statically compiled implementations. 
 
 Ok. 
  
> It's not the language which is fast or slow, so much as as the code  
> written in the language, and the implementation of that language which is  
> used.  The problem with code-as-data is that it encourages the interpreted  
> implementations. 
 
 That is true. In fact, I am not real sure how you could produce native code 
 for a code as data language. Well, thats not true you could probably output 
 a custom interpreter for the langauge, but thats not really native compilation. 
 
[snip cool stuff] 
 
 Very cool.  
>  
> >  Most of this performance penalty can be made up in large programs 
> > with using the right alsgorithm. You made this point yourself. 
>  
> Yep.  Interpretation is just a constant factor slowdown- easily overcome 
> by better algorithms.  Also, large hunks of the programming world simply 
> aren't that performance bound.  Generally anytime you're talking to a 
> database, the database is your main slowdown.  User I/O is also very slow.   
> I had a friend who got bitched at once for writting a DB query in Perl, 
> when C was so much faster.  His response was that the query was hitting  
> the optical jukebox, and would take 15 minutes to complete.  Wether the  
> program spawning the query took 10 milliseconds or 100 milliseconds to run  
> probably wasn't going to be an issue. 
 
 That is true. Though I will say that the general optimization the compilation gives 
you is pretty nice to have in a deployment situation. 
 
> Most programmers, in my experience, have no clue where performance comes  
> from or goes to. 
 
 I agree. 
 
>  
> The fact that any given input will create a reproducable, and in some  
> sense even predictable, result is not in question.  The question is wether  
> the output it produces is the one *intended*.  Otherwise I can simply  
> replace any program with the following C code: 
> #include <stdio.h> 
> int main (int argc, char ** argv) { 
>     fprintf(stderr, "Fatal error- segment fault.  Program exiting.\n"); 
>     return -1; 
> } 
 
 Code generation can be tricky to understand, but I dont believe that it is any more 
or less difficult then some of the other complex things out there. Just because an 
application rewrites itself does not mean that what gets re-written when is 
unpredictable. 
 
 
> Yep.  There's been more than one point where I've wished that ocaml had  
> "instanceof" or something similiar.  I'm just arguing against "instead  
> of". 
 
 Instead of? perhaps I lost the context.  
> Brian 


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Ink Cartridges or Refill Kits for Your HP, Epson, Canon or Lexmark
Printer at Myinks.com. Free s/h on orders $50 or more to the US & Canada. http://www.c1tracking.com/l.asp?cid=5511
http://us.click.yahoo.com/l.m7sD/LIdGAA/qnsNAA/W4wwlB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
pragmatic_lang-unsubscribe-hHKSG33TihhbjbujkaE4pw@public.gmane.org

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/