[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Too Many Ways?

Gavin Kistner

9/30/2004 2:10:00 AM

At what point do you cross over from:
"Various ways to accomplish the same goal is good,
because it allows the language to work the way
different people think about working."
into the land of:
"Duplicate names and techniques to do the same
atomic thing ends up confusing the nubys"
?

results = my_array.collect{ ... }
results = my_array.map{ ... }

a = Proc.new{ ... }
b = lambda{ ... }
def whee; ...; end
c = self.method( :whee )

def foo &blockAsBlock
blockAsBlock.call
yield
end

foo &a
foo &b
foo &c

def bar blockAsParam
blockAsParam.call
end

bar a
bar b
bar c

Regexp globals vs. MatchData
#insert your own examples here

--
(-, /\ \/ / /\/



98 Answers

Gavin Sinclair

9/30/2004 2:31:00 AM

0

On Thursday, September 30, 2004, 12:09:33 PM, Gavin wrote:

> At what point do you cross over from:
> "Various ways to accomplish the same goal is good,
> because it allows the language to work the way
> different people think about working."
> into the land of:
> "Duplicate names and techniques to do the same
> atomic thing ends up confusing the nubys"
> ?

[snip good examples]

AFAIC, there's no objective answer. I dislike the extremes in both
directions (that goes for any topic, really). Python is way too
strict for my taste. Ruby is pretty much fine, IMO. If I were king,
I'd tighten it up just a little, and probably screw the whole thing
up.

Gavin



Robert Klemme

9/30/2004 6:02:00 AM

0


"Gavin Kistner" <gavin@refinery.com> schrieb im Newsbeitrag
news:C3144C65-1285-11D9-BDE2-000A959CF5AC@refinery.com...
> At what point do you cross over from:
> "Various ways to accomplish the same goal is good,
> because it allows the language to work the way
> different people think about working."
> into the land of:
> "Duplicate names and techniques to do the same
> atomic thing ends up confusing the nubys"
> ?
>
> results = my_array.collect{ ... }
> results = my_array.map{ ... }

IMHO these were introduced to match other languages notations. I think it
makes life easier for newcomers.

> a = Proc.new{ ... }
> b = lambda{ ... }

Same here.

> def whee; ...; end
> c = self.method( :whee )

These are two completely different cups of tea.

> def foo &blockAsBlock
> blockAsBlock.call
> yield
> end

Same here: the &b notation converts the block into a proc making it possible
to store it somewhere or pass it on.

> def bar blockAsParam
> blockAsParam.call
> end

I'd consider this a different case, too, because here the block can't be
handed over via "foo { ... }".

> Regexp globals vs. MatchData
> #insert your own examples here

*That* is an area where I definitely like to see improvements (see the
thread some time ago about String#scan and MatchData).

On the whole I feel pretty comfortable with the way Ruby does things
although I recognize a certain tendency to increase redundancy ("lambda" and
"proc" comes to mind). As far as I remember I wasn't confused when I was a
RubyNuby. But then again, everybody feels different about this.

Kind regards

robert



gabriele renzi

9/30/2004 8:36:00 AM

0

Gavin Kistner ha scritto:

> #insert your own examples here
>

%{x}

%q{x}
%Q{x}
"x"
'x'
and heredocs.
Definitely too many ways for me :)
Amnyway I subscribe robert klemme's Ideas in the other response.

dblack

9/30/2004 10:04:00 AM

0

ts

9/30/2004 10:10:00 AM

0

>>>>> "D" == David A Black <dblack@wobblini.net> writes:

D> I tend to feel that the [block, lambda, Proc, method] stuff is too
D> complicated.

I'm agree with you, just make it more complex to solve the
complication :-)

svg% cat b.rb
#!/usr/bin/ruby
require 'aa'

class A < Proc
def self.new(&block)
proc(&block)
end
end

a = A.new {|x, *y| p x,y }
p a.class
a.call([1, 2])
svg%

svg% b.rb
A
[1, 2]
[]
svg%


Guy Decoux


Gavin Kistner

9/30/2004 1:05:00 PM

0

On Sep 29, 2004, at 8:30 PM, Gavin Sinclair wrote:
> AFAIC, there's no objective answer.
> [...]
> If I were king, I'd tighten it up just a little, and probably screw
> the whole thing up.

Yeah. I suppose the question was sort of rhetorical, my way of saying
"I raise my hand as someone who feels that there is too much
duplication, but then again, I'm not king, and I don't wish to be."

--
(-, /\ \/ / /\/



Chris Pine

9/30/2004 1:13:00 PM

0

On Thu, 30 Sep 2004 11:09:33 +0900, Gavin Kistner wrote:
>?At what point do you cross over from: "Various ways to accomplish
>?the same goal is good, because it allows the language to work the
>?way different people think about working." into the land of:
>?"Duplicate names and techniques to do the same atomic thing ends up
>?confusing the nubys" ?

Simple: nubys should only be taught one way to do a thing. What's harder than learning to program? Learning to program twice. Or you could ask, I'm getting ready to teach someone two things about Ruby... shouldn't they be *different* things?

(This is something I really tried to follow in my tutorial, which even has a TMTOWTDI section near the end: http://pine.fm/Learn...)

So I think the cross over is really in the other direction: from nuby to TMTOWTDI.


On Thu, 30 Sep 2004 19:04:00 +0900, David A. Black wrote:
>?If only the things that make life easier for newcomers could
>?disappear later, like training wheels on a bicycle.... :-)

So naturally I completely disagree with this! :)

Duplicates do *not* make things any easier for newcomers. Learning something twice is just that much harder, and then having one of them disappear later would be disastrous. Again, I think it really moves in the other direction: from nuby to TMTOWTDI.

(Yes, if you are teaching Ruby to a functional programmer, you use map instead of collect (are those really the same? I just always avoided collect: wrong english word, I think), but you still teach them only *one* of them.)

First you learn one way to do it. (Depending on your background, lambda might make more sense than proc (nevermind that these *aren't* the same, though I'll never keep up with that).) Then, once you are doing a pretty good job of coding Ruby on your own, you learn a few other ways to do things so you can read other people's code (which is always a little trickier, anyway).

Just some thoughts,

Chris




Gavin Kistner

9/30/2004 1:22:00 PM

0

On Sep 30, 2004, at 4:04 AM, David A. Black wrote:
> On Thu, 30 Sep 2004, Robert Klemme wrote:
>>> results = my_array.collect{ ... }
>>> results = my_array.map{ ... }
>>
>> IMHO these were introduced to match other languages notations. I
>> think it
>> makes life easier for newcomers.
>
> If only the things that make life easier for newcomers could disappear
> later, like training wheels on a bicycle.... :-)

I suppose that's my wish, too. As unrealistic as it may be.
("Sorry, play time is over. All your existing code may crash and burn,
but in the end it'll make you a better programmer.")

What I'd think was nice is if a bunch of things were officially
deprecated; no runtime warning (although perhaps with a -w or
something) but where exact duplicates exist, the King from on High
would say "thou shalt use #foo and not #bar". (I was even thinking of
removing the deprecated names from the documentation, but then that's
no good for someone needing to decipher existing code.)



> Proc.new and lambda aren't the same as each other, though:

Whoa, that I didn't know.
So a lambda is more like a method (currently)?

Actually, I'd say this is an argument for merging, or something. My
personal principle of least surprise was violated when I found that I
couldn't create a block with default parameters. Procs, blocks,
methods, lambdas ... four ways to do almost exactly the same thing.


On Thu, 30 Sep 2004, Robert Klemme wrote:
>> On the whole I feel pretty comfortable with the way Ruby does things
>> although I recognize a certain tendency to increase redundancy
>> ("lambda" and "proc" comes to mind). As far as I remember I wasn't
>> confused when I was a RubyNuby. But then again, everybody feels
>> different about this.

I'm not sure if I'm a nuby or not; I certainly am when it comes to
grokking lambdas. The concepts are all pretty clear (not confusing when
learning), but when I was designing the EventTarget module, I kept
waffling between:
def add_event_listener( evt_type, callback_proc )
and
def add_event_listener( evt_type, &callback_proc )

Proc-as-param allows multiple params to be procs, and makes it easy to
pass methods/procs/lambdas (which are what would most likely be used
for a callback: an existing, centrally-defined procedure)...but
prevents blocks from being used without Proc.new. That's bad, because
Ruby people LIKE blocks. I know I do.

Proc-as-block allows no more than one 'proc', and requires &foo to be
used when passing method references or procs or lambdas..but *does*
allow blocks.

I suppose this is a case where subtle flexibility is important
(different functionality), but it's the case of the blank canvas
scaring and stymying the novice artist: "Where do I begin?" There's so
much/too much flexibility; so much overlap muddled in with the
tradeoffs it's frustrating. But now I'm getting onto the specific topic
of merging the features and fun of both sides, instead of the general
"I'd like to see a little less duplication in the future, please"
topic.
--
(-, /\ \/ / /\/



Gavin Kistner

9/30/2004 1:28:00 PM

0

On Sep 30, 2004, at 7:12 AM, Chris Pine wrote:
> (Yes, if you are teaching Ruby to a functional programmer, you use map
> instead of collect (are those really the same? I just always avoided
> collect: wrong english word, I think), but you still teach them only
> *one* of them.)

Funny, I never understood what #map did. People used it all the time
and it baffled me. I kept saying "I should learn this method, because
people keep showing how to use it for powerful, terse solutions,
but...I'm baffled."

Then someone showed me the #collect method, and I fell in love. It's
awesome. I extended arrays in Javascript to use it, I love it so much.

...it was a week later than I pulled up the documentation and saw that
they're the same thing. Something about 'map' made absolutely no sense
to me (it implies a hash-like permanent connection between the old and
the new), and collect made perfect sense (go traipsing through the
entire field of daisies, picking up only the best ones).

So if we were deprecating duplicates, I vote to get rid of #map.
(This is the part where 100 rubyists say "No! #collect sucks, #map is
king!" and my entire argument for less duplication is shot down by the
fact that people like different things.)
--
(-, /\ \/ / /\/



Zach Dennis

9/30/2004 1:31:00 PM

0

I have been thinking lately about rangess and I will give you the two
different range operators and what comes to mind first.

Operator One: .. (two dots)
Example: 1..5
What comes to mind: Exclusive
How It Works: Inclusive (the last number 5, is included)

Operator Two: ... (three dots)
Example: 1...5
What comes to mind: Inclusive
How It Works: Exclusive (the last number 5, is excluded)

How range operators work seems sort of backwards to me. It would appear
as if the "..." (three dots) would be the inclusive one, including the
last value and the ".." (two dots) would be exclusive and exclude the
last value.

Am I off in my own little world here or have others pondered this?
(Perhaps it has been brought up before?) I am not requesting a change on
this, I am merely pointing out what seems unnatural in a very natural
language.

Zach