Larry Wall's comments on Ruby

yeah and as I said, depending on your background , Ruby is just as full
of surprises as C++ is.

Disagree; the Ruby FAQ is quite a bit skinnier than 4" :slight_smile:

>My guess is Ruby won't surpise you too much only if you have Perl/Python 
>background. That's it.

I’ve never written a line of code in Python, BTW.

But you’ve piqued my curiosity: tell me, what did you find
surprising about Ruby? Where “surprising” is defined as
"you thought it worked one way" and then discovered that it did not,
or that it worked that way some of the time and some other way
the rest of the time?

Just learning a new concept doesn’t count as surprising,
but being led astray by inconsistent behavior does.

/\ndy

I would like a quick shot at this.

I was not as much supprised as impressed with Ruby. I was doing HEAVY
Java development (300k line framework) and the dynamic/pure oo nature of
Ruby was VERY different than Java. I read the Pickaxe book in two
days…did not touch the language until a week later. The book just
kept me thinking…internalizing the differences in dynamic vs. static
behaviors objects and classes.

Then I started using it and was functional very quickly…rewriting some
of my java utilities in a fraction of the amount of code/time it took in
Java. I moved on to more complex things…then I hit what I will call
the “refactoring loop”. Ruby lets me code, refactor, code,
refactor…its really awesome (unit tests performing refactoring
validation). I NEVER wanted to refactor my Java code (its just not
fun). With Ruby the language does not supprise me (in its
syntax/architecture), but the code I write very much does.

Matz…thanks for a great language
Andy…thanks for a great book

-Rich

···

-----Original Message-----
From: Andrew Hunt [mailto:andy@toolshed.com]
Sent: Friday, September 06, 2002 4:41 PM
To: ruby-talk ML
Subject: Re: Larry Wall’s comments on Ruby

yeah and as I said, depending on your background ,
Ruby is just as full
of surprises as C++ is.

Disagree; the Ruby FAQ is quite a bit skinnier than 4" :slight_smile:

My guess is Ruby won’t surpise you too much only if
you have Perl/Python
background. That’s it.

I’ve never written a line of code in Python, BTW.

But you’ve piqued my curiosity: tell me, what did you find
surprising about Ruby? Where “surprising” is defined as
"you thought it worked one way" and then discovered that it
did not, or that it worked that way some of the time and some
other way the rest of the time?

Just learning a new concept doesn’t count as surprising,
but being led astray by inconsistent behavior does.

/\ndy

[…]

But you’ve piqued my curiosity: tell me, what did you find
surprising about Ruby? Where “surprising” is defined as
"you thought it worked one way" and then discovered that it did not,
or that it worked that way some of the time and some other way
the rest of the time?

There are a few things. One is operator precedence; to find out that

a = not(b)

does not work at all, and only gives you an unclear error message is
a real puzzler. Another one is

statement while condition

Noting that the condition is tested before the statement is executed
seems to be contrary to how every other language with test-at-end
loops does it. To discover then that

begin statement end while condition

works the other way round is even more confusing.

	Reimer Behrends
···

Andrew Hunt (andy@toolshed.com) wrote:

Learning a new concept that does not fit with your worldview does count as
surprising. And it will continue to be surprising until you change your
worldview. And beginner’s are still taught a procedural worldview.

You just can’t say that Ruby isn’t surprising. If someone come’s to Ruby,
really likes the OO-everwhere aspect, they will often say, “Wow”. And guess
what, they were just surprised. Otherwise, they would say, “Big Deal, I’ve
been doing that in language X for the last 4 years at school. Of course
everthing’s an object.” But they don’t. Because that’s not what they’re
taught.

And if that same procedural person has to re-organize his worldview to do
everything in an OO-everwhere fashion, that person will be surprised over
and over until he successfully changes his worldview.

Let’s be clear: I’m not looking for procedural everywhere, I’m OO all the
way. But Larry hit the nail on the head that beginners will be surprised.
It might be a nice surprise! But it will be a surprise. His choice to not
surprise them with OO can arguably be judged short-sighted. But his
statement about their surprise is spot-on.

Another way of saying it, “Since our beginners are taught inconsistencies,
they may well be suprised by consistency.”

Drew

···

-----Original Message-----
From: Andrew Hunt [mailto:andy@toolshed.com]
Just learning a new concept doesn’t count as surprising,
but being led astray by inconsistent behavior does.

Andrew Hunt wrote:

But you’ve piqued my curiosity: tell me, what did you find
surprising about Ruby? Where “surprising” is defined as
"you thought it worked one way" and then discovered that it did not,
or that it worked that way some of the time and some other way
the rest of the time?

Here are two more:

“abcd”[0] # => 97 (!!! Shouldn’t this be “a”?)

and

“abcd”.sub( /ab/ ) { |match|
match[0] # => 97 (Huh? Shouldn’t match be a MatchData?)
} # => “97cd” (Should be “abcd”)

Ruby is my favorite language, but as long as we are all humans
there will always be surprises…

Cheers,

David

But you’ve piqued my curiosity: tell me, what did you find
surprising about Ruby? Where “surprising” is defined as
"you thought it worked one way" and then discovered that it did not,
or that it worked that way some of the time and some other way
the rest of the time?

well things that surprised me will probably be considered obvious by
you. as I said its only a matter of the background and maybe of the
thinking style.
But here are just a few examples I had to struggle with:

And they’re good points.

  1. && and || are not the same as “and” and “or”. The difference
    is subtle, but why weren’t these made completely synonymous in the first
    place?

Totally agree.

  1. File.open( “myfile” ) { |file| puts “block…” } will automatically
    close it. I keep trying to close it in the end of block. I may see how
    it seems very intuitive to some people but I am used to C.

That’s the Ruby way. Isn’t is great? You can close it yourself if you like:

f = File.open(…)
do_something(f)
f.close()

  1. myString.each { } processes lines not bytes. Why?

It’s a common operation. Strings are not arrays of charaters. They never
were, in any language, and never will be. (My reasoning, C doesn’t have
strings, only arrays of characters). Of course you know to use
myString.each_byte { }; and how long did it take you to find that out using ri?

  1. myBlock = Proc.new { puts “myBlock…” }
    then I intuitively expect to be able to do this: 5.times myBlock
    but it won’t work

Do you expect the following code to work?

5.times Proc.new { puts “myBlock…” }

No, neither did I. 5.times &myblock should work, and it’s consistent with the
general syntax for procs.

  1. Forgiving syntax leaves lots of room to fool yourself. Classical
    example: x = y +z
    It is VERY counter-intuitive to me that this tries to call method y with
    paramter +z instead of adding the two numbers together

Good point. Consider it an enforcement of good style :wink:

I could go on. Anyway, my point is, as with every language you can’t
just blindly rely on your intuition in Ruby, you have to remember how to
do some(many?) things. And just as with every other language, once you
have a feel for it, you can do a lot of things just by pure intuition.
Ruby may have less things to remember than C++ but it doesn’t change the
big picture.

As others have pointed out, C++ does not fit the rule “And just as with every
other language, once you have a feel for it, you can do a lot of things just by
pure intuition.”

It does change the big picture: the surprises in Ruby mostly come at a high
level; the devil is not so much in the detail.

Also, no language is just a language. There are environmental concerns.
Having the sandpit (aka “irb”) to play in makes learning the language soooo
much easier. You ameliorate the surprises before you put them in your code.

Again, you have good points, and it’s interesting to hear the POV of someone
from what seems to be a different language background (from the norm).

Cheers,
Gavin

···

----- Original Message -----
From: “Denys Usynin” usynin@hep.upenn.edu

Denys Usynin usynin@hep.upenn.edu wrote in message news:alb62m$8ag$1@info4.fnal.gov

  1. Forgiving syntax leaves lots of room to fool yourself. Classical
    example: x = y +z
    It is VERY counter-intuitive to me that this tries to call method y with
    paramter +z instead of adding the two numbers together

Why, having the basic concept of unary operators …
having the basic concept of leaving parentheses when
calling functions …
how can the interpreter decide what you meant?

To me it was good to see that Ruby works in some (many)
parts like other languages I know. I felt familiar very soon.

(Well, did not know more than rudimentary Lisp I learned
more about the functional way using Python and was able to
adapt it to my view of some Java codes. Understanding that
concept I easily learned the code block concept (would be
hard otherwise).
Using a special sign prefix for variables ($,@) normally
annoyes me, but not too much, as I’m used to Unix, awk,
a bit of Perl … and so on).

On the other hand I did never expect Ruby to work in any
cases exactly like the other languages I know (if it would
I had no reason to switch :slight_smile: ). Instead I enjoyed learning
knew concepts I did not work with before (like the extensive
use of iterators in combination with code blocks as a
programming style (I did not know Smalltalk) ).

So again: Least surprise does not mean no surprise to
everyone

KR

Dirk Detering -aka Det

Hi –

···

On Sat, 7 Sep 2002, Reimer Behrends wrote:

Andrew Hunt (andy@toolshed.com) wrote:
[…]

But you’ve piqued my curiosity: tell me, what did you find
surprising about Ruby? Where “surprising” is defined as
"you thought it worked one way" and then discovered that it did not,
or that it worked that way some of the time and some other way
the rest of the time?

There are a few things. One is operator precedence; to find out that

a = not(b)

does not work at all, and only gives you an unclear error message is
a real puzzler. Another one is

statement while condition

Noting that the condition is tested before the statement is executed
seems to be contrary to how every other language with test-at-end
loops does it. To discover then that

begin statement end while condition

works the other way round is even more confusing.

And if you add a rescue:

begin statement; rescue; end while condition

it once again tests the condition first, which I’ve always found kind
of anomalous… It means you can’t casually throw in a rescue clause
for debugging purposes, or whatever, because the logic will change.

David


David Alan Black | Register for RubyConf 2002!
home: dblack@candle.superlink.net | November 1-3
work: blackdav@shu.edu | Seattle, WA, USA
Web: http://pirate.shu.edu/~blackdav | http://www.rubyconf.com

I think you are right that it is the change in world view that
is the surprising part. However, after some acquaintance with
more that one programming language, this is sort of expected.

Perhaps school’s should be encouraged to think outside the Java/C/C++
idiom? I would think that the surprise factor would be much less
prevalent if people had exposure to a bunch of vastly different
programming languages/environments.

Might I suggest:

  • C/C++/Java
  • Smalltalk/Ruby
  • Haskell/OCaml
  • LISP
  • FORTH
  • FORTRAN
  • COBOL
  • SQL
  • Oberon/Delphi

All of these approach problems in a different way and are optimised
for different solutions (even if many are “general programming
languages”).

I like ruby, it is fun, quick and very flexible. It is ideal for
what I am doing at work at the moment (talking to network elements)
but I would be -very- surprised if I could embed it onto an 8-bit
micro-controller with 16k of memory …

-mark.

···

At 06:48 AM 9/7/2002 +0900, Drew wrote:

[snip]

And if that same procedural person has to re-organize his worldview to do
everything in an OO-everwhere fashion, that person will be surprised over
and over until he successfully changes his worldview.

Depends on who “our” beginners are. If they’re beginners to Ruby, but
old hands at programming, you’re probably correct. If they’re
complete newbies, it’s not at all clear. I’ve heard (anecdotally)
that programming neophytes find OO much more natural and intuitive
than procedural programming - it agrees with their world view. Once
we’ve put all of the effort of bending our brains to think
procedurally, it seems natural to us - we forget the pain and angst of
our early days, and wonder why it’s so hard for newbies to see the
"obvious" solutions we’ve trained ourselves to recognize. But if all
the patterns were so obvious, we wouldn’t need all of the pattern
books that are so popular these days.

I remember glancing through a C++ patterns book after being an
Objective-C programmer for a while, and snickering. Perhaps one
metric of a good language is how few patterns are needed to use it
productively.

–paul

···

-----Original Message----- From: Andrew Hunt
[mailto:andy@toolshed.com] Just learning a new concept doesn’t
count as surprising, but being led astray by inconsistent
behavior does.

Learning a new concept that does not fit with your worldview
does count as surprising. And it will continue to be
surprising until you change your worldview. And beginner’s
are still taught a procedural worldview.

> You just can't say that Ruby isn't surprising.  If someone
> come's to Ruby, really likes the OO-everwhere aspect, they
> will often say, "Wow".  And guess what, they were just
> surprised.  Otherwise, they would say, "Big Deal, I've been
> doing that in language X for the last 4 years at school.  Of
> course everthing's an object."  But they don't.  Because
> that's not what they're taught.

> And if that same procedural person has to re-organize his
> worldview to do everything in an OO-everwhere fashion, that
> person will be surprised over and over until he successfully
> changes his worldview.

> Let's be clear: I'm not looking for procedural everywhere, I'm
> OO all the way.  But Larry hit the nail on the head that
> beginners will be surprised.  It might be a nice surprise!
> But it will be a surprise.  His choice to not surprise them
> with OO can arguably be judged short-sighted.  But his
> statement about their surprise is spot-on.

> Another way of saying it, "Since our beginners are taught
> inconsistencies, they may well be suprised by consistency."

As others have pointed out, C++ does not fit the rule “And just as with every
other language, once you have a feel for it, you can do a lot of things just by
pure intuition.”

I don’t fully agree(see below). A couple of years ago I had to write
a relatively non-trivial project in C++/STL from scratch (not what I
normally do at work) that ended up being something like 700k of code.
While working on it I very seldom had to look things in the reference.

I think how often you have to pull your hair and go read the reference
is a good measure of how natural/intuitive/consistent is the language.

Now, of course C gives you a lot more room to make mistakes but that’s
the price you pay for the additional power of C. If you want screaming
fast code you won’t do it in Ruby, right? The mistakes you make in C are
usually not because the language syntax/strusture/behavior confuse you
but because you simply forget something. In Ruby there is less to
remember (no dealloc!) and the price is performance. But does this mean
C is less intuitive? I don’t think so.

C++ and Ruby are different tools for different tasks, and it’s not fair
to compare them. As far as I am concerned, they both follow the
Principle of the Least Surprise, except that C can only go so far
following it and must stop before it compromises its ability to do its job.

I find that odd. I do the test/write/test/refactor loop constantly
in Java, and I find the refactoring quite fun. As do my co-workers.

cjs

···

On Sat, 7 Sep 2002, Rich Kilmer wrote:

…then I hit what I will call
the “refactoring loop”. Ruby lets me code, refactor, code,
refactor…its really awesome (unit tests performing refactoring
validation). I NEVER wanted to refactor my Java code (its just not
fun).


Curt Sampson cjs@cynic.net +81 90 7737 2974 http://www.netbsd.org
Don’t you know, in this new Dark Age, we’re all light. --XTC

Actually using IDEA as in IDE I found refactoring in Java actually fun
and easy. Much easier than refactoring ruby code. But refactoring Java
without a tool like IDEA is hard, hard word, though.

-billy.

···

On Sat, Sep 07, 2002 at 06:13:01AM +0900, Rich Kilmer wrote:

Java. I moved on to more complex things…then I hit what I will call
the “refactoring loop”. Ruby lets me code, refactor, code,
refactor…its really awesome (unit tests performing refactoring
validation). I NEVER wanted to refactor my Java code (its just not
fun). With Ruby the language does not supprise me (in its
syntax/architecture), but the code I write very much does.


Meisterbohne Söflinger Straße 100 Tel: +49-731-399 499-0
eLösungen 89077 Ulm Fax: +49-731-399 499-9

Reimer Behrends behrends@cse.msu.edu wrote in message news:slrnani6dp.ejt.behrends@ellington.cse.msu.edu

Another one is

statement while condition

Noting that the condition is tested before the statement is executed
seems to be contrary to how every other language with test-at-end
loops does it.

Hum. First of all I think the “Principle of Least Surprise” does never
say no surprise.

For me it works this way: I read how one thing works. I read how another
thing works and see the similarities, the ‘common concept’. I assume that
a third thing works the same way and it does. Aha, surely, no surprise.
But then I’m surprised, a fourth thing works in another way. Oh, why?
I read for the concepts behind this fourth thing and get an ‘Aha!’-effect
as it has a good reason to work different.
Then I try a fifth thing out, and based on my former experience I can
better estimate which of the two ways will be used. I assume the correct
one, no surprise.

And: I find this way working better in Ruby than in other languages.

(BTW: This way is in general the same for programmers with experience
in other languages changing to Ruby as for absolute novices.
The problems are in another area).

Regarding the above example:
Learning (after the first surprise) that
statement while condition
is not part of the loop-concept of ‘test-at-end’
but part or the syntactic-sugar-concept of
’statement modifiers’ you will automatically
assume that
statement if condition
works the same.
(Contrary, knowing the modifier concept you would
be surprised when the while would work foot-controlled).

To discover then that

begin statement end while condition

works the other way round is even more confusing.

Hum, ok … :wink: .

Bye
Dirk Detering -aka Det

Hi –

···

On Tue, 10 Sep 2002, Det wrote:

On the other hand I did never expect Ruby to work in any
cases exactly like the other languages I know (if it would
I had no reason to switch :slight_smile: ).

That’s a great way to put it. It goes together well with a
quote from “Anonymous” on Ruby Garden a while back:

“I would like to evolve FROM Perl, Java and C++ rather than TO Perl,
Java and C++.”

David


David Alan Black | Register for RubyConf 2002!
home: dblack@candle.superlink.net | November 1-3
work: blackdav@shu.edu | Seattle, WA, USA
Web: http://pirate.shu.edu/~blackdav | http://www.rubyconf.com

Might I suggest:

  • C/C++/Java
  • Smalltalk/Ruby
  • Haskell/OCaml
  • LISP
  • FORTH
  • FORTRAN
  • COBOL
    Absolutely Not! :wink:
  • SQL
  • Oberon/Delphi

Seriously, I have often thought it would be best to teach assembler
and Smalltalk/Ruby as first languages.

···

On Friday, September 6, 2002, at 03:05 PM, Mark Probert wrote:

As an adolescent I aspired to lasting fame, I craved factual certainty,
and I thirsted for a meaningful vision of human life - so I became a
scientist. This is like becoming an archbishop so you can meet girls.
-Matt Cartmill, anthropology professor and author (1943- )

  begin statement; rescue; end while condition

pigeon% ruby -ve 'begin puts 12; rescue; end while false'
ruby 1.7.3 (2002-08-30) [i686-linux]
12
pigeon%

pigeon% ruby -ve 'begin puts 12; end while false'
ruby 1.7.3 (2002-08-30) [i686-linux]
12
pigeon%

···

Tue Mar 26 01:56:33 2002 Yukihiro Matsumoto <matz@ruby-lang.org>

        * parse.y (primary): while/until statement modifiers to "begin"
          statement now work as "do .. while" even when begin statement
          has "rescue" or "ensure" [new].

Guy Decoux

Denys Usynin wrote:

As others have pointed out, C++ does not fit the rule “And just as
with every
other language, once you have a feel for it, you can do a lot of
things just by
pure intuition.”

I don’t fully agree(see below). A couple of years ago I had to write
a relatively non-trivial project in C++/STL from scratch (not what I
normally do at work) that ended up being something like 700k of code.
While working on it I very seldom had to look things in the reference.

I think how often you have to pull your hair and go read the reference
is a good measure of how natural/intuitive/consistent is the language.

I think, a better measure is the satisfaction you feel when
you look at your code. Currently I work on a quite large project in C++
(around 50k LOC), but I am always unsatisfied with the solutions
we produce. And we think quite long before writing down the code,
so that it works well later. And still, there are always
surprises: sometimes compiler errors, sometimes language features.
The most common problem is that there are several alternative solutions
and each is somewhat unnatural and has its own special disadvantages.
I have almost everyday a surprise: how impossible is it to implent
ideally something trivial. About half of our problems would vanish
if we could define iterators like in Ruby.

Regards, Christian

Hi –

···

On Sat, 7 Sep 2002, ts wrote:

begin statement; rescue; end while condition

pigeon% ruby -ve 'begin puts 12; rescue; end while false’
ruby 1.7.3 (2002-08-30) [i686-linux]
12
pigeon%

pigeon% ruby -ve 'begin puts 12; end while false’
ruby 1.7.3 (2002-08-30) [i686-linux]
12
pigeon%

Tue Mar 26 01:56:33 2002 Yukihiro Matsumoto matz@ruby-lang.org

    * parse.y (primary): while/until statement modifiers to "begin"
      statement now work as "do .. while" even when begin statement
      has "rescue" or "ensure" [new].

Thanks for pointing this out. As the original (I think) complainer
about this, I should have tracked it more closely. (Sorry, Matz :slight_smile:

David


David Alan Black | Register for RubyConf 2002!
home: dblack@candle.superlink.net | November 1-3
work: blackdav@shu.edu | Seattle, WA, USA
Web: http://pirate.shu.edu/~blackdav | http://www.rubyconf.com