On Fri, 9 Nov 2001, Sean Russell wrote:

> > Sure neat program design leads to a good program, but not necessarily to
> > more speed or vice versa.
> > instead, id say the real performant solutions are generally a bit slower
> > than their clean equivalents, but thats another topic.
> 
> I have to voice a strong agreement with you.  This is one of the 
> difficulties I have with XP and "functional programming" that often seem to 
>
Could you elaborate what you mean with "functional programming" in this
context. FP as in Haskell, Ocaml et al or some FP programming style in
imperative prog languages?

> be ignored.  I've often heard that source documentation is optional; that 
> the best way to write good code is to write very small methods and remove 
> redundancy, etc., etc.  In my experience, this is good design, but it makes 
> for poor code.  For example, in REXML I had some places where I had 
>
Just so that I'm following: You're assuming that the only/most important
quality criteria of code is its speed of execution, right?

Do you often find this to be the case in your projects?

IMHO, you should also view the XP stuff in its entirety with unit tests
showing examples of how to use the code etc.

> redundant code that was being called in two different situations many 
> times.  I tried abstracting the code out and removing the redundancy, but 
> this led to a significant decrease in the speed of the processor, because 
> of the large additional number of indirects.  The code may have had better 
> design, but it was slower.  I often find that with this sort of "good 
> design," you tend to get memory bloat, as well.
> 
I doubt that this is true but my experience from XP/Beck-style short
methods etc programming is somewhat limited so maybe there something to
this.

> While I agree with the principle, I disagree with how much many XP folks 
> emphasize refactoring (in the sense of removing redundancy).  Perhaps 
> someday, when the Ruby interpreter is intelligent enough to inline code 
> during execution, this won't be an issue, but for now, when you're trying 
> to attain maximum performance, you often have to sacrifice some of the 
> design.
> 
If you're trying to attain maximum performance then why use Ruby? Sure,
advance in VM's might take Ruby down to 2 times C (although I doubt
it) but there's still a factor of (at least) 2 there (Oh, and dynamic
compilation/optimization could be applied to C-developed programs as well
so probably won't close the gap either...).

I'd think that if you have a good design, profile, attack the
bottlenecks and maybe even lift some of it to C then you'll be better off
than with a poorer design.

Regards,

Robert