Larry Wall's comments on Ruby

Kent Starr says:

>While complexity theory has been
>around since the 70's (some would say off and on since the time of the
>Egyptians) but was not widely known outside of very tight academic
>circles before the mid-90's.

Hmm. As it turns out, I keep finding out about more and more neat
theories that aren’t currently well known. Odds are I’ll be embarassed
by one of those twenty years from now :slight_smile:

>> I think that's a load of crap; exposing native types as non-objects
>> in Java, for instance, is to me one the largest failings of that language.
>> 
>
>Unfortunately, it is worse than just a "mere load of crap"

Well, I was trying to be being polite…

>had to replace their Java-based e-commerce solution in order to
>efficiently scale up. (My contact solved their problem with perl/MySQL.)

Interesting. What was the specific issue that killed them? In other
words, was it badly written Java, or just the fact that it was Java?

>I suspect, as time unfolds many more such issues will arise, especially
>regarding maintainability.  

Unfortunately, I agree. Maintainability is one of those dark subjects
that no one wants to talk about. Dave and I were part of an OOPSLA
workshop last year on Software Archeology that talked around those
issues; this year Brian Marick has asked us back to talk about
Software For Life. It’s an interesting and underappreciated subject,
but as you note, I suspect that will change in time as well.

>OO isn't taught well IMO. "Pickaxe" is a rare exception. 

Thanks!

>The irony is
>that Ruby is closely modelled in accordance with contemporary thinking
>in modern theoretical physics where everything -is- an object (in
>concept, not necessarily name). The physical world in which we live is
>de facto Rubyesque. :-)

Ha ha! I love it! God is a Ruby programmer, after all :slight_smile:

/\ndy

had to replace their Java-based e-commerce solution in order to
efficiently scale up. (My contact solved their problem with perl/MySQL.)

Interesting. What was the specific issue that killed them? In other
words, was it badly written Java, or just the fact that it was Java?

Well, the “incident” occurred a little over two years ago and involved a
major online/offline retailer with a highly seasonal business. Because
this was told to me in confidence I can’t be more specific about those
details.

The application was a custom implemented e-commerce app, Java based.
Well into season the avg daily hit count ranged into the very high five
figures and – the whole bleedin’ thing crashed! That’s when my contact
was called in. During the day and half the site was down (which cost
cles to a half million dollars in lost revenue, I’m told) the contact
and two of his programmers worked non-stop to recast the whole thing in
perl and MySQL. The last I heard the redone site was still pumping with
an avg daily hit count in the low six figures.

Was it badly written Java? I never saw the source code, of course. But I
do know from other experiences and contacts that badly written Java is
not too difficult to achieve, especially in a crunch (which nearly
everything e-commerce related tend to be.) The only thing I -do- know is
that the Java app failed (with costly results) and the open source
solution saved the day.

Unfortunately, I agree. Maintainability is one of those dark subjects
that no one wants to talk about. Dave and I were part of an OOPSLA
workshop last year on Software Archeology that talked around those
issues; this year Brian Marick has asked us back to talk about
Software For Life. It’s an interesting and underappreciated subject,
but as you note, I suspect that will change in time as well.

Bright on the buzzword radar these days is TCO – total cost of
ownership. Over he lifetime of any given software projects, as with
ships, the bulk of TCO is maintenance, not original construction. All
other things being equal, the easier (read cheaper) a solution is to
maintain, the lower the TCO over time. With IT turnover still is the
double digits (despite the economic downturn) a lot of fresh hands will
be involved in that maintenance so the issues of expressiveness and
clarity, as they relate to software projects, are critical ones.

The irony is
that Ruby is closely modelled in accordance with contemporary thinking
in modern theoretical physics where everything -is- an object (in
concept, not necessarily name). The physical world in which we live is
de facto Rubyesque. :slight_smile:

Ha ha! I love it! God is a Ruby programmer, after all :slight_smile:

Well, Wolfram would likely cast God as a Mathematica programmer. :slight_smile:
Searls, Locke, et al. would say God created the bazaar but man built the
cathedrals, and thus gave rise to “original sin”. :slight_smile:

Regards,

Kent Starr

···

On Fri, 2002-09-06 at 15:45, Andrew Hunt wrote:

Was it badly written Java? I never saw the source code, of course. But I
do know from other experiences and contacts that badly written Java is
not too difficult to achieve, especially in a crunch (which nearly
everything e-commerce related tend to be.) The only thing I -do- know is
that the Java app failed (with costly results) and the open source
solution saved the day.

That’s one spin; another might be that a poor [set of] programmer[s] who
happened to USE java screwed the pooch, as it were, and your competent friend
saved the day.

“It’s a poor carpenter that blames his tools.”, “You can write bad [perl] in any
language”, as they say.

In an attempt to throw the authorities off his trail, W Kent Starr elderburn@mindspring.com transmitted:

had to replace their Java-based e-commerce solution in order to
efficiently scale up. (My contact solved their problem with
perl/MySQL.)

Interesting. What was the specific issue that killed them? In
other words, was it badly written Java, or just the fact that it
was Java?

Was it badly written Java? I never saw the source code, of
course. But I do know from other experiences and contacts that badly
written Java is not too difficult to achieve, especially in a crunch
(which nearly everything e-commerce related tend to be.) The only
thing I -do- know is that the Java app failed (with costly results)
and the open source solution saved the day.

I think the Perl guys got it right, as far as the ideal quote is
concerned; I believe that it was Larry Wall that observed, more or
less, that “There’s not a problem with Y2K-compliant Perl code; the
problem is whether or not the programmer is Y2K-compliant.”

Badly written anything is certainly possible, and this is
particularly true when a particular technology reaches the point in
its adoption where it reaches what might be called “gratuitous
popularity.”

XML and C++ and Java and Perl have all had points in time when they
have achieved “gratuitous popularity,” and at that point, you start
getting books like “XML for Incompetent Buffoons,” and you get
incompetent buffoons doing XML/C++/Java/Perl.

It is entirely likely that the problem can be primarily attributed to
"incompetent buffoons." Unfortunately they tend to get attracted to
"hot" technologies in much the way bugs are attracted to outdoor
lights at night.

···

On Fri, 2002-09-06 at 15:45, Andrew Hunt wrote:

(concatenate 'string “cbbrowne” "@ntlug.org")
http://www3.sympatico.ca/cbbrowne/internet.html
Rules of the Evil Overlord #66. "My security keypad will actually be a
fingerprint scanner. Anyone who watches someone press a sequence of
buttons or dusts the pad for fingerprints then subsequently tries to
enter by repeating that sequence will trigger the alarm system."
http://www.eviloverlord.com/