[ruby-talk:7181] Re: Ruby in the US

Peter Wood <[e-mail]> wrote:
>
>Ben Tilly writes:
>  > I want to get some perspective on language design.  Some of
>  > my initial impressions are available at:
>  >
>  > 
>http://pub13.ezboard.com/fiwetheytheoryandpracticeofprogramming.showMessage?topicID=286.topic
>  >
>  > (Hmmm...that essay might not do great things for Perl/Ruby
>  > relations, but I think it raises an interesting point.)
>  >
>
>Hi,
>
>In your essay, you write:
>
[...]
>What about Lisp?  Values are what is typed in Lisp, not variables or
>operators.  You *can* declare for efficiency, but you don't have to.
>Lisp has a type hierarchy where every object has more than one type.
>You also write you have a math background.  So I'm surprised you don't
>mention Lisp.

Mathematicians don't learn Lisp.  They learn things like
Lesbegue integration.

> > The advantage of Perl's typing operators is that you do not usually
> > need to cast variables from one type to another. For the kind of text
> > extraction and processing that Perl often does this can be very
> > convenient.
>
>It is a MYTH that perl is competent for text processing.  Does that
>get your goat, Ben?  Well you don't have to take my word for it.  Here
>is what one of the (ex) *perl 5 porters* had to say :

Oh really?  BTW your "ex" is dubious...

>"... the lack of a lot of key text-processing ingredients makes Perl
>solutions for many averagely complicated tasks either extremely slow,
>or not easier to maintain than solutions in other languages (and in
>some cases both)... My current conjecture on why people classify Perl
>as an agile text-handler (in addition to obvious traits of false
>advertisement) is that most of the problems to handle are more or less
>trivial ("system-maintenance"-type problems)."

Perl is excellent at data munging.  If you know what you are
doing it is also excellent at parsing and producing structured
data.  It took me less than an hour to find that incrementally
appending to a string n times in Ruby takes time O(n*n).  It
takes time O(n) in Perl.

Performance on string processing is not something which Ruby
fans should try to wave as an advantage.  (But this problem is
not hard to solve.  I already outlined a sufficient solution.)

>(you can check up on: http://www.perl.com/pub/2000/09/ilya.html)  The
>author of the quote is Dr Ilya Zacharevich, who teaches math at Ohio
>state University.  His work on Perl 5 includes operator-overloading,
>much of the regex-engine, the OS2 port, and the FreezeThaw, Devel::Peek,
>Math::Pari, and Term::Readline modules.

I am very familiar with what Ilya has done.  We discussed the
features of and possible optimizations to Perl's RE engine.
FYI he has been active on p5p in recent weeks.

What you probably didn't experience were the incessant flame
wars that used to be carried on between Tom Christiansen and
Ilya.  For all of Tom's problems, he is right that Ilya has
virtually no eye for what will be a maintainable design.
The performance he gets is unbelievable.  But the APIs that
he produces often are grotesque, and his code is often
virtually impossible for anyone else to understand or review.

In any case what I find telling is that I have found Perl an
extremely good fit for the kinds of problems that I have faced.

> > However this comes with the disadvantage that with every type comes
> > more syntax.
>
>You got it, Ben.  Randall "Nice-book-pity-about-the-language" Schwartz

How would you feel if that was directed at you?  Please
stop and think about what it would mean if Randal made the
decision he made in the early 90's and decided to turn his
pedagogical talents to promoting a promising young scripting
langauge.  Today he has a reputation.  That matters.

I guarantee you that having Ruby get glowing recommendations
from Dave and Andy is a large part of why so many people are
willing to take a second look at it.  I should know, I am one
of them.

>asked what we want to do with Ruby. *I* think Ruby is going to blow
>Python AND Perl out of the water, though it might take a while re the
>latter. Why?  In Python's case, because its just better (faster,
>cleaner, sensible licence, no Guido).

And now anyone who likes Guido just got POed as well.  When
you start by ticking someone off, things usually go downhill
fast.

BTW if you make big promises, you had better be prepared to
meet them.  If you say "blow away", a fan of what you promise
is history will become very dubious.  Unless they (already
biased against) think that it is really ready to blow away the
competition, they will discount anything you have to say.

  In Perl's case, because in the
>real world Perl is used to write spaghetti code, and structured
>spaghetti code (the Ruby way) is better than unstructured spaghetti
>code (the Perl way).

Oh really?  Amateur attempts at OO design are no fun to work
with.  They quickly get as bad as the worst procedural designs.
What is worse is that the grandiose mistakes that result have
performance problems.  Implement that in a language which has
not yet sorted out performance kinks, and you have a recipe for
disaster.

The worst Perl is the result of people who don't know how to
program, don't want to learn, but want cool results.  They
don't know what Perl is, but they have heard that they have
to use it.  Then they discover Matt Wright's Script
Archives...

  It doesn't *matter* what corporate America
>chooses, because the organisations that adopt Ruby are going to have
>an edge.  Corporate America doesn't care about language quality, but
>it does care about the edge.

I disbelieve.

Regards,
Ben
_____________________________________________________________________________________
Get more from the Web.  FREE MSN Explorer download : http://explorer.msn.com