[ruby-talk:23317] Re: Bruce Eckel's opinion of Ruby

Emiliano wrote:

>> Why not hire decent programmers ;-) No, really. If someone doesn't know
>> how to use the tool properly, don't hire them for the job.
> 
> Not everyone who programs is necesarily trained to be a programmer.
> And under time pressure, even excellent programmers will occacionally
> take short-cuts they'll regret later.

Yeah, I guess so.  I know I do, especially with applications that start out 
as a quick, on-off hack to solve some specific problem that ends up having 
broad application and mutates into a large, unwieldy codebase that more 
resembles a tumor than anything else.

*That's* when refactoring comes in handy.  Even if the worst programming 
constructs were avoided (because they were impossible), the best solution 
is often to re-write the code.

>> If you're
>> already employing them, they either need training, or a pink slip.
> 
> Ah, you American you :) Firing people is not so easy here :)

Where's that?  Western Europe?

I won't disagree with you on that point; training is vastly superior to 
firing/rehiring; it is easier in America, too.  The pink slip is for people 
who *won't* be trained (we also call it "reprogramming", or "dissident 
processing").

On a more abstract level, I wonder if Europeans (I'm assuming that you're 
European) are more likely to accept the dictums of a language like Python, 
because they're more conciously accepting of conformism.  Please note that 
I'm not saying Americans are less conformist, but only that most Americans 
aren't conciously aware that they're conformist.

>> Aaah. This sounds like the infamous "Yeah it sucks, but we have to
>> maintain backward compatibility" argument. :-)
> 
> It may sound like it, but what it actually says is "You got used to
> driving a car, which is unintuitive and takes practice, yet you found it

Good lord, don't get me started on how stupid cars are.  That's another 
process that has needed serious rethinking for a long time.

> to be worth the hassle. You got used to behaving properly at home and
> listen to the missus, which is unintuitive and takes practice, yet you
> found it to be worth the hassle (presumably :). If you can handle those,

Oh, you don't have mothers over there?  I had *plenty* of practice taking 
orders from women long before my missus.  ;-)

> I don't see why you can't handle this."

My point is that sometimes the existing process is bad.  Inflexability is 
always bad.  Inflexability means an inability to adapt, which means 
evolutionary death.

>> Aside from the fact that nobody but Guido has any choice in the matter.
> 
> *shrug*. Somebody has to make the decision. What I'm saying is that -
> even though I'll not likely use Python soon myself - I can accept the
> premise that setting an enforceable standard can be a Good Thing.

Ok.  We agree on this.  We disagree on under what circumstances 
enforcablility is Bad.

> Between Ruby and Python, I'm slightly in favor of the Ruby syntax.
> Slightly. I hate the enforced whitespacing of Pyhton as much as you
> appearantly do. OTOH, I don't like the 'typical Perl' dense coding and
> invisible operands that Ruby seems to encourage.

Oh, I haven't made that obvious? ;-)

I don't know that Ruby encourages it so much as allows it, but I get your 
point.  I think the problem is that the code condensing is useful.  I use 
Ruby as much on the command line for scripting little tasks as I do for 
large application development, and I'd guess that this is true for many 
Ruby coders (the *nix ones, at least).  In that environment, the code 
condensing is invaluable; without it, Ruby would be just as unwieldy as 
Python for short, on-off tasks.  However, once you become used to the code 
condensing, I think you tend to unconciously use it in your application 
code as well, and this is where it creeps in.

BTW, this was probably the first reason I didn't choose Python.  Python 
didn't offer enough benefits over Java for large applications for me to 
learn it, and it was terrible for the command line.  Ruby is exceptionally 
good for both.

> (first get it right, then get it fast vs. first get it right, then get
> it dense), and most of the ruby code I've seen takes that tack to a

Yeah.  Dense is good for, as I've said, the command line, and it is Good 
that Ruby CAN be dense.  There is also a certain aesthetic to denseness, of 
the same flavor that generates such interest in the yearly "Obfuscated C 
Code Contest".  I agree that, while this is Neet and can be occasionally 
Usefull, people need to understand that, like anything, there is an 
appropriate use and an inappropriate use.  Inappropriate use in this case 
would be application development.

> That too depends on the situation. Even though I do use Linux, I see
> my chances of getting in contact with Linus and getting him to change
> bits to suit me personally as very slim indeed. Nor would I care to.
> I'd rather have a system that works like my cow-orkers for
> consistencies sake. I see the same reasoning from Python users.

Ahh, but with Linux, if you *really* wanted to, you could make the change 
yourself.  Python is to Ruby as Windows is to Linux, and this is *exactly* 
my point about local control.

--- SER