From: "Florian G. Pflug" Date: 2001-11-09T10:29:51+09:00 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