[#8566] Visions for 2001/1.7.x development? — Robert Feldt <feldt@...>

Hi matz and other Ruby developers,

18 messages 2001/01/03
[#8645] Re: Visions for 2001/1.7.x development? — matz@... (Yukihiro Matsumoto) 2001/01/04

Hi,

[#8580] bug?? — jmichel@... (Jean Michel)

I don't understand the following behaviour:

19 messages 2001/01/03

[#8633] Interesting Language performance comparisons - Ruby, OCAML etc — "g forever" <g24ever@...>

13 messages 2001/01/04

[#8774] No :<, :>, etc. methods for Array — "Brian F. Feldman" <green@...>

So, why not include Comparable in Array by default? It shouldn't have any

28 messages 2001/01/07
[#8779] Re: No :<, :>, etc. methods for Array — matz@... (Yukihiro Matsumoto) 2001/01/07

Hi,

[#8780] Re: No :<, :>, etc. methods for Array — "Brian F. Feldman" <green@...> 2001/01/07

matz@zetabits.com (Yukihiro Matsumoto) wrote:

[#8781] Re: No :<, :>, etc. methods for Array — gotoken@... (GOTO Kentaro) 2001/01/07

In message "[ruby-talk:8780] Re: No :<, :>, etc. methods for Array"

[#8782] Re: No :<, :>, etc. methods for Array — "Brian F. Feldman" <green@...> 2001/01/07

gotoken@math.sci.hokudai.ac.jp (GOTO Kentaro) wrote:

[#8829] Sandbox (again) — wys@... (Clemens Wyss)

Hi,

20 messages 2001/01/08
[#8864] Re: Sandbox (again) — Clemens Hintze <c.hintze@...> 2001/01/08

On 8 Jan, Clemens Wyss wrote:

[#8931] String confusion — Anders Bengtsson <ndrsbngtssn@...>

Hello everyone,

21 messages 2001/01/09
[#8937] Re: String confusion — matz@... (Yukihiro Matsumoto) 2001/01/09

Hi,

[#8953] Please remove account from files — "Thomas Daniels" <westernporter@...>

Please take my e-mail address from your files and "CANCEL" my =

14 messages 2001/01/09
[#8983] Re: Please remove account from files — John Rubinubi <rubinubi@...> 2001/01/10

On Wed, 10 Jan 2001, Thomas Daniels wrote:

[#9020] time to divide -talk? (was: Please remove account from files) — Yasushi Shoji <yashi@...> 2001/01/10

At Wed, 10 Jan 2001 14:23:30 +0900,

[#9047] Re: time to divide -talk? (was: Please remov e account from files) — Aleksi Niemel<aleksi.niemela@...>

Yasushi Shoji:

27 messages 2001/01/10
[#9049] Re: time to divide -talk? — Yasushi Shoji <yashi@...> 2001/01/10

At Thu, 11 Jan 2001 00:20:45 +0900,

[#9153] what about this begin? — Anders Strandl Elkj誡 <ase@...> 2001/01/11

[#9195] Re: Redefining singleton methods — ts <decoux@...>

>>>>> "H" == Horst Duch=EAne?= <iso-8859-1> writes:

10 messages 2001/01/12

[#9242] polymorphism — Maurice Szmurlo <maurice@...>

hello

73 messages 2001/01/13

[#9279] Can ruby replace php? — Jim Freeze <jim@...>

When I read that ruby could be used to replace PHP I got really

15 messages 2001/01/14

[#9411] The Ruby Way — "Conrad Schneiker" <schneiker@...>

As a member of the "Big 8" newsgroups, "The Ruby Way" (of posting) is to

15 messages 2001/01/17

[#9462] Re: reading an entire file as a string — ts <decoux@...>

>>>>> "R" == Raja S <raja@cs.indiana.edu> writes:

35 messages 2001/01/17
[#9465] Re: reading an entire file as a string — Dave Thomas <Dave@...> 2001/01/17

raja@cs.indiana.edu (Raja S.) writes:

[#9521] Larry Wall INterview — ianm74@...

Larry was interviewed at the Perl/Ruby conference in Koyoto:

20 messages 2001/01/18
[#10583] Re: Larry Wall INterview — "greg strockbine" <gstrock@...> 2001/02/08

Larry Wall's interview is how I found out

[#9610] Re: 101 Misconceptions About Dynamic Languages — "Ben Tilly" <ben_tilly@...>

"Christian" <christians@syd.microforte.com.au> wrote:

13 messages 2001/01/20

[#9761] Re: 101 Misconceptions About Dynamic Languages — ts <decoux@...>

>>>>> "C" == Christoph Rippel <crippel@primenet.com> writes:

16 messages 2001/01/23

[#9792] Ruby 162 installer available — Dave Thomas <Dave@...>

15 messages 2001/01/24

[#9958] Re: Vim syntax files again. — "Conrad Schneiker" <schneik@...>

Hugh Sasse wrote:

14 messages 2001/01/26
[#10065] Re: Vim syntax files again. — Hugh Sasse Staff Elec Eng <hgs@...> 2001/01/29

On Sat, 27 Jan 2001, Conrad Schneiker wrote:

[#9975] line continuation — "David Ruby" <ruby_david@...>

can a ruby statement break into multiple lines?

18 messages 2001/01/27
[#9976] Re: line continuation — Michael Neumann <neumann@...> 2001/01/27

On Sat, 27 Jan 2001, David Ruby wrote:

[#9988] Re: line continuation — harryo@... (Harry Ohlsen) 2001/01/28

>A statement break into mutliple lines if it is not complete,

[ruby-talk:10009] Re: Ruby refs on Slashdot

From: David Alan Black <dblack@...>
Date: 2001-01-28 05:12:15 UTC
List: ruby-talk #10009
On Sun, 28 Jan 2001, Ben Tilly wrote:

> David Alan Black <dblack@candle.superlink.net> wrote:
> >
> >Yes -- I certainly don't dismiss everything he said; it's more that a
> >couple of things caught my attention as being in the category of "OK,
> >now let's see how well Ruby has captured the functionality and flavor
> >of Perl."  Not that I don't expect language comparisons.  But that's
> >not exactly what this is.  It's more like an obstacle people seem to
> >put in their own way, by assuming that Ruby's goal is to shadow Perl.
> >Again, not to pounce on that one writer, but something like: "I'll
> >have delve deeper to see how well they copied the TMTOWTDI philosophy"
> >contains a whole set of presuppositions about Ruby which are going to
> >make the process of *seeing* Ruby (not even understanding it, or
> >liking it, but just perceiving it) much more difficult.
> 
> Well then what is Ruby?
> 
> Is it one easily describable thing?  Is there a clear Ruby
> style that is truly right?
> 
> I doubt that...

I didn't say that there isn't more than one way to do this or that in
Ruby.  (Self-evidently there often is.)  I'm talking more about public
perception and rhetoric than language design and philosophy, at the
moment.

In fact... forget that this case involves TMTOWTDI.  Given *any* Perl
functionality or philosophy/slogan P, to think out loud about "how
well [Matz] copied [P]" suggests (a) that Matz was trying to copy P,
and (b) that one's opinion of Ruby should at least partly be
determined by how good that copy-job was.  That strikes me as a
low-percentage process (even if one comes up with a nicer word than
"copy" :-)

All I'm saying is that I have observed that people get tripped up by
this -- tripped up in the sense of prevented (at least temporarily)
from seeing the things that Ruby can actually do.  

The "#{...}" interpolation mechanism is a good example.  I've seen a
number of people, familiar with Perl, assume that this is strictly the
equivalent of "$var"-style interpolation in Perl.  They then perceive,
incorrectly, Ruby's interpolation mechanism as having "extra"
punctuation characters.  (The slashdot piece we've been talking about
did this, in so many words ["I can see the extra characters getting
annoying"], but I've seen it elsewhere too.)

Once these people realize that #{...} is not (just) for variable
interpolation, they not only stop worrying about the "extra"
characters but actually feel relieved that they don't have to do
"@{[ $x + $y ]}" and such things.  

I'm not taking people to task for lack of sharpness.  (That would come
back to haunt me in short order :-)  Nor is it such a calamity if this
or that person has to work through a layer or two of Perl perception
before seeing Ruby for itself.  (I certainly did.)  Obviously Ruby
occurs at a certain point in history, with a manifestly huge relation
to several antecedents.

In fact, judging from what people said in response to my original
question, it really probably isn't a big deal, from the perspective of
Ruby advocacy, that these misperceptions are played out in public, as
long as people do keep really getting interested in the language and
giving it a more than perfunctory look.  It would be better, I
suppose, if that could happen without the detours, but realistically
that may not be possible.

(Anyone interested in some very interesting and well-stated remarks
about Perl and Ruby should have a look at [ruby-talk:6738] from
Clemens Hintze.)


David

P.S. Congratulations on your 10K-hood!

-- 
David Alan Black
home: dblack@candle.superlink.net
work: blackdav@shu.edu
Web:  http://pirate.shu.edu/~blackdav


In This Thread

Prev Next