Too Many Ways?

Discussion in 'Ruby' started by Gavin Kistner, Sep 30, 2004.

  1. 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

    --
    (-, /\ \/ / /\/
    Gavin Kistner, Sep 30, 2004
    #1
    1. Advertising

  2. 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
    Gavin Sinclair, Sep 30, 2004
    #2
    1. Advertising

  3. "Gavin Kistner" <> schrieb im Newsbeitrag
    news:...
    > 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
    Robert Klemme, Sep 30, 2004
    #3
  4. 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.
    gabriele renzi, Sep 30, 2004
    #4
  5. Hi --

    On Thu, 30 Sep 2004, Robert Klemme wrote:

    > "Gavin Kistner" <> schrieb im Newsbeitrag
    > news:...
    > > 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.


    If only the things that make life easier for newcomers could disappear
    later, like training wheels on a bicycle.... :) Personally I've
    never minded the handful of duplicate method names, though I know some
    people do.

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

    >
    > Same here.


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

    irb(main):014:0> l = lambda {|a,b|}
    => #<Proc:0x00000000@(irb):14>
    irb(main):015:0> pr = Proc.new {|a,b|}
    => #<Proc:0x00000000@(irb):15>
    irb(main):016:0> l.call(1)
    ArgumentError: wrong number of arguments (1 for 2)
    from (irb):14
    from (irb):14:in `call'
    from (irb):16
    irb(main):017:0> pr.call(1)
    => nil

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

    >
    > These are two completely different cups of tea.


    I think these two lines go together: Gavin was showing that a method,
    like a block, lambda, or Proc, could be assigned to a variable.

    I tend to feel that the [block, lambda, Proc, method] stuff is too
    complicated. But I know Matz is working on it; hopefully there will
    be some unification/simplification to come.


    David

    --
    David A. Black
    David A. Black, Sep 30, 2004
    #5
  6. Gavin Kistner

    ts Guest

    >>>>> "D" == David A Black <> 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
    ts, Sep 30, 2004
    #6
  7. 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."

    --
    (-, /\ \/ / /\/
    Gavin Kistner, Sep 30, 2004
    #7
  8. Gavin Kistner

    Chris Pine Guest

    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/LearnToProgram/)

    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
    Chris Pine, Sep 30, 2004
    #8
  9. 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, Sep 30, 2004
    #9
  10. 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.)
    --
    (-, /\ \/ / /\/
    Gavin Kistner, Sep 30, 2004
    #10
  11. Gavin Kistner

    Zach Dennis Guest

    Range syntax theory

    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
    Zach Dennis, Sep 30, 2004
    #11
  12. Re: Range syntax theory

    Zach Dennis wrote:
    > 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
    >

    Hello Zach,

    very good point you make. I imagine that the inclusive version is used
    more often, so someone thought, lets save a point here.

    But I have to admit I just learned it and never questioned it. Thats a
    bad thing ;)

    Regards,

    Brian

    --
    Brian Schröder
    http://ruby.brian-schroeder.de/
    Brian Schröder, Sep 30, 2004
    #12
  13. Re: Range syntax theory

    "Zach Dennis" <> schrieb im Newsbeitrag
    news:...
    > 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.


    I never thought about this but it seems you are right. (Sometimes it
    seems better to not think about everything :)

    robert
    Robert Klemme, Sep 30, 2004
    #13
  14. Re: Range syntax theory

    On Thu, 30 Sep 2004 22:30:51 +0900, Zach Dennis <> wrote:
    > 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.


    It's the distinction between
    0..5 == [0, 5] # mathematical notation
    and
    0...5 == [0, 5) # mathematical notation

    In part, this is something that Ruby inherits -- I *think* -- from
    Perl, which uses the .. and ... in this way.

    -austin
    --
    Austin Ziegler *
    * Alternate:
    : as of this email, I have [ 6 ] Gmail invitations
    Austin Ziegler, Sep 30, 2004
    #14
  15. On Thu, 30 Sep 2004 22:28:07 +0900, Gavin Kistner <> wrote:
    [snip]

    > the new), and collect made perfect sense (go traipsing through the
    > entire field of daisies, picking up only the best ones).


    Perfect sense? Your description sounds a lot more like #select than
    #collect :)

    andrew
    Andrew Johnson, Sep 30, 2004
    #15
  16. Programming languages are a lot like philosophy. Nothing ever gets
    thrown away!

    I find the duplicate names for a method a, minor, irritant but getting
    rid of them is not going to be painless.
    Peter Hickman, Sep 30, 2004
    #16
  17. Re: Range syntax theory

    On Sep 30, 2004, at 7:30 AM, Zach Dennis wrote:
    > 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.


    I was thinking this exact same thing in the shower yesterday morning.


    I've tried to memorize what _why said about them, to remember:

    > Think of it as an accordion which has been squeezed down for carrying.
    > (Sure, you can build a great sense of self-worth by carrying around an
    > unfolded accordion, but sometimes a person needs to wallow in
    > self-doubt, carefully concealing the squeeze-box.) The parentheses are
    > the handles on the sides of a smaller, handheld accordion. The dots
    > are the chain, keeping the folds tightly closed.
    >
    > Normally, only two dots are used. If a third dot is used, the last
    > value in the range is excluded.
    >
    > (0...5) represents the numbers 0 through 4.
    >
    > When you see that third dot, imagine opening the accordion slightly.
    > Just enough to let one note from its chamber. The note is that end
    > value. We’ll let the sky eat it.


    Source: http://poignantguide.net/ruby/chapter-3.html#section2
    Gavin Kistner, Sep 30, 2004
    #17
  18. Re: Range syntax theory

    Hi!

    From an intellectual point I sort of understand the '..' and '..'
    notation. What distracts me most, is the visual difference ... that the
    visually longer three dot form contains fewer elements than the shorter
    two dot form.

    (1..5).to_a
    =>[1,2,3,4,5]
    (1...5).to_a
    =>[1,2,3,4]

    Henrik
    Gavin Kistner wrote:
    > On Sep 30, 2004, at 7:30 AM, Zach Dennis wrote:
    >
    >> 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.

    >
    >
    > I was thinking this exact same thing in the shower yesterday morning.
    >
    >
    > I've tried to memorize what _why said about them, to remember:
    >
    >> Think of it as an accordion which has been squeezed down for carrying.
    >> (Sure, you can build a great sense of self-worth by carrying around an
    >> unfolded accordion, but sometimes a person needs to wallow in
    >> self-doubt, carefully concealing the squeeze-box.) The parentheses are
    >> the handles on the sides of a smaller, handheld accordion. The dots
    >> are the chain, keeping the folds tightly closed.
    >>
    >> Normally, only two dots are used. If a third dot is used, the last
    >> value in the range is excluded.
    >>
    >> (0...5) represents the numbers 0 through 4.
    >>
    >> When you see that third dot, imagine opening the accordion slightly.
    >> Just enough to let one note from its chamber. The note is that end
    >> value. We’ll let the sky eat it.

    >
    >
    > Source: http://poignantguide.net/ruby/chapter-3.html#section2
    >
    >
    >
    Henrik Horneber, Sep 30, 2004
    #18
  19. Re: Range syntax theory

    On Thu, 30 Sep 2004 22:58:26 +0900, Henrik Horneber <> wrote:
    > From an intellectual point I sort of understand the '..' and '..'
    > notation. What distracts me most, is the visual difference ... that the
    > visually longer three dot form contains fewer elements than the shorter
    > two dot form.
    >
    > (1..5).to_a
    > =>[1,2,3,4,5]
    > (1...5).to_a
    > =>[1,2,3,4]


    That's a dangerous consideration -- and not always true:

    irb(main):001:0> (1..5).include?(4.99)
    => true
    irb(main):002:0> (1...5).include?(4.99)
    => true
    irb(main):003:0>

    1...5 doesn't include only the numbers 1, 2, 3, and 4 -- it contains
    the infinities between the numbers, and the infinity between 4 and 5,
    but not 5 itself.

    -austin
    --
    Austin Ziegler *
    * Alternate:
    : as of this email, I have [ 6 ] Gmail invitations
    Austin Ziegler, Sep 30, 2004
    #19
  20. Re: Range syntax theory

    Austin Ziegler wrote:

    > On Thu, 30 Sep 2004 22:58:26 +0900, Henrik Horneber <> wrote:
    >
    >> From an intellectual point I sort of understand the '..' and '..'
    >>notation. What distracts me most, is the visual difference ... that the
    >>visually longer three dot form contains fewer elements than the shorter
    >>two dot form.
    >>
    >>(1..5).to_a
    >>=>[1,2,3,4,5]
    >>(1...5).to_a
    >>=>[1,2,3,4]

    >
    >
    > That's a dangerous consideration -- and not always true:
    >
    > irb(main):001:0> (1..5).include?(4.99)
    > => true
    > irb(main):002:0> (1...5).include?(4.99)
    > => true
    > irb(main):003:0>
    >
    > 1...5 doesn't include only the numbers 1, 2, 3, and 4 -- it contains
    > the infinities between the numbers, and the infinity between 4 and 5,
    > but not 5 itself.
    >
    > -austin


    Still, it's the 'larger' Range.
    Otherwise, good point, thx.
    Henrik Horneber, Sep 30, 2004
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. peelman

    How many threads is too many?

    peelman, Jan 13, 2005, in forum: Java
    Replies:
    12
    Views:
    834
    Esmond Pitt
    Jan 15, 2005
  2. Rhino
    Replies:
    33
    Views:
    1,303
    Oliver Wong
    Dec 22, 2005
  3. rbt
    Replies:
    1
    Views:
    349
  4. How many roles is too many?

    , Jun 13, 2006, in forum: ASP .Net Security
    Replies:
    4
    Views:
    190
    Joe Kaplan \(MVP - ADSI\)
    Jun 18, 2006
  5. Dag Sunde
    Replies:
    4
    Views:
    352
Loading...

Share This Page