Subj : Re: Compiler and an interpreter
To   : comp.programming
From : Gerry Quinn
Date : Sat Aug 06 2005 12:18 pm

In article <42f34eba$0$24042$ed2619ec@ptn-nntp-reader01.plus.net>, 
usenet@jdh30.plus.com says...
> Gerry Quinn wrote:

> > LOC is a poor metric for most purposes - it's reciprocal is equally
> > poor.  The bottom line, in any case, is that typing speed is not a
> > bottleneck for most programmers.
> 
> Reading speed is.

No it isn't.  Comprehension speed is.  Code is usually hard to 
understand compared to English text - raw reading speed doesn't matter 
much IMO.
 
> >> You should study the STL...
> > 
> > Look what it did to you!  Seriously, by your own account your excessive
> > respect for arcane STL features eventually resulted in your abandonment
> > of the language.
> 
> No, the presence of a language that lets me write shorter, faster code in
> less time led to my abandonment of C++. The STL lets me write shorter,
> faster C++ code so it actually made C++ more competitive. C++ simply cannot
> compete though.

Earlier in the thread, you went into detail about the many problems you 
had with C++, as a result of the way you used the STL.  Indeed, one of 
your projects never compiled at all.

> >> Perhaps if you give some examples of applications that you believe FPLs
> >> are poorly suited to?
> > 
> > Computer games would be a good example.
> 
> What aspect of games and what types of games do you think FPLs are not
> suitable for? I assume you know that several professional games houses use
> FPLs?

The only one I know of that uses them to a large degree is the one 
often quoted by Lisp advocates, 'Naughty Dog'.  Reading a 'postmortem' 
of their development on the Gamasutra site makes it clear that it 
caused at least as many problems as it solved.  What are the others?

Of course they are used here and there in the form of embedded 
scripting languages.  Zillions Of Games uses a custom language of this 
kind for defining game rules.

For most games, OO is a natural match - they tend to be full of little 
persistent objects that have state!  While there are certainly parts of 
games that can benefit from functional programming, it seems to me that 
its usefulness will be limited to those parts.  [Indeed, just as games 
are often microcosms of the real world, game programming is arguably a 
microcosm of programming in general.] 

> >> Yes. Why do you think these real-world performance-critical programs are
> >> "invalid" as benchmarks?
> > 
> > Because you appear to use unsuitable methodologies in your C++
> > versions.
> 
> What do you believe is a "suitable methodology"?

For efficiency in C++, you start by looking at the data structure with 
efficiency in mind.

- Gerry Quinn

.