From: Curt Hibbs <curt@...>
Date: 2001-11-09T10:37:29+09:00
Subject: [ruby-talk:24725] Re: Why is ruby slow (compared to perl)

XP is does not really advocate "never break the rules". The XP
guidelines explicitly say its not necessary to "swallow the XP elephant
whole", but rather to use what works for you (or your organization) in
its current context. XP advocates would contend that the more XP
practices you adopt the more benefits you will realize.

Curt Hibbs
Coyote SOftware

-----Original Message-----
From: Florian G. Pflug [mailto:fgp@phlo.org] 
Sent: Thursday, November 08, 2001 5:30 PM
To: ruby-talk ML
Subject: [ruby-talk:24724] Re: Why is ruby slow (compared to perl)


On Fri, Nov 09, 2001 at 08:45:56AM +0900, Sean Russell wrote:
> No, I'm assuming that in some cases, the most important criteria of 
> code is
> the speed of execution.  Furthermore, I'm rebelling against the trend
I see 
> to completely ignore issues such as speed.  I'm hyper-sensitive, I
suppose, 
> because I've been coding exclusively in Java for the past 7 years, and
I've 
> seen what a difference speed can make in the general acceptance of any

> software.  The most beautiful, functional code is absolutely worthless
if 
> it isn't used because it is too slow.  On the other hand, fast code
will 
> tend to be used even if it is really, really.  In the end, the users
(whom 
> we're writing the software for) don't care what the code looks like;
they 
> just want it to work right and run fast.
> 
> Before you jump on me about the hidden benefits of "pure" XP code, a 
> couple
> of caveats:  (1) I'm an XP convert -- we're better off with it than
without 
> it, and (2) I'm not ignoring the benefits of clean code.  I know as
well as 
> you that clean code tends to be less buggy and is certainly more 
> maintainable.  However, code speed is almost never stressed by XP 
> advocates, who tend to stress "never break the rules".

Well, I consider "never breaking the rules" to be a bad guid - in almost
any situation, especially in software design.

I think knowing a lot of rule is very important - and being able to
design good, clean code is very important too.

But I also believe that breaking rules (being it code desing, database
design, interface design,..) is ok - but you should be always aware of
the fact that you are about to break a rule, and know what the
consequences could be.

I break some normalisation principles of relational database design
quite often, but I know that I'm breaking them, and I know why.

Thats what rules are for - know about them, and break them if it's
necessary.

greetings, Florian Pflug