Ruby - Missed some core computer science world ?

Discussion in 'Ruby' started by Lucky Dev, Mar 6, 2011.

  1. Lucky Dev

    Lucky Dev Guest

    I am doing ruby programming and been developing rails3 apps for some
    time now (4-5 months). I am just wondering, if the ruby world is sooo
    immersed in its beautiness and is not doing much to embrace cleverness
    in ruby world.

    I mean, the whole world of datastructures and algorithms, seems to have
    much lower importance on a ruby programmer's mind. Is it so?

    I am just enjoying ruby programming for the past few months, but I feel
    that I've missed a lot of internal stuff in C, while was doing C
    programming. Like, datastructures like trees, linked lists, etc., and
    algorithms in C.

    Also, I don't see much "good" books on datastructures and algorithms in
    ruby or Have I missed to notice them in the market. Can you please point
    me to good datasturctures and algorithms learning book using ruby.

    --
    Posted via http://www.ruby-forum.com/.
    Lucky Dev, Mar 6, 2011
    #1
    1. Advertising

  2. Modern computers can have 100 cores and a zillion bytes of memory. There
    is a lot less emphasis on how clever your program is. Who cares how your
    hash is stored? All you want is the most convenient code, fastest to
    build, easiest to maintain.

    I can't imagine why any but the tiniest number of Rails users would ever
    need a linked list.

    --
    Posted via http://www.ruby-forum.com/.
    Mike Stephens, Mar 6, 2011
    #2
    1. Advertising

  3. On Mar 6, 2011, at 10:05 AM, Lucky Dev wrote:

    > I mean, the whole world of datastructures and algorithms, seems to =

    have
    > much lower importance on a ruby programmer's mind. Is it so?


    There was a GSOC called "algorithms" some time ago. Besides algorithms =
    it
    has datastructures like heap, rb_tree_map or trie.
    I think the head of this project is now in a gem called =
    grosser-algorithms.

    All the best, Sandor Sz=FCcs
    --
    Sandor Szuecs, Mar 6, 2011
    #3
  4. Lucky Dev

    Lucky Dev Guest

    We can always say maintenance is more good than any other attribute. But
    the scale in which we solve problems, will always be limited if we don't
    give importance to algorithms and the like concepts, in Ruby.

    --
    Posted via http://www.ruby-forum.com/.
    Lucky Dev, Mar 6, 2011
    #4
  5. On Sun, Mar 6, 2011 at 10:05 AM, Lucky Dev <> wrote:
    >
    > I mean, the whole world of datastructures and algorithms, seems to have
    > much lower importance on a ruby programmer's mind. Is it so?



    Algorithms are algorithms, datastructures are datastructures. They
    exist independent of the programming language used (now, if the
    programming language of choice is up to the task is a different
    matter, and not easy to answer).

    --
    Phillip Gawlowski

    Though the folk I have met,
    (Ah, how soon!) they forget
    When I've moved on to some other place,
    There may be one or two,
    When I've played and passed through,
    Who'll remember my song or my face.
    Phillip Gawlowski, Mar 6, 2011
    #5
  6. Lucky Dev <> writes:

    > Also, I don't see much "good" books on datastructures and algorithms in
    > ruby or Have I missed to notice them in the market. Can you please point
    > me to good datasturctures and algorithms learning book using ruby.


    http://cleveralgorithms.com - book on AI algorithms in ruby (free).
    Victor Deryagin, Mar 6, 2011
    #6
  7. Lucky Dev

    [::psyomn::] Guest

    Wow, that is really awesome. Thanks for sharing!

    On Sun, Mar 06, 2011 at 10:38:32PM +0900, Victor Deryagin wrote:
    > Lucky Dev <> writes:
    >
    > > Also, I don't see much "good" books on datastructures and algorithms in
    > > ruby or Have I missed to notice them in the market. Can you please point
    > > me to good datasturctures and algorithms learning book using ruby.

    >
    > http://cleveralgorithms.com - book on AI algorithms in ruby (free).
    >
    [::psyomn::], Mar 6, 2011
    #7
  8. Lucky Dev

    David Jacobs Guest

    [Note: parts of this message were removed to make it a legal post.]

    Hamster is a good place to look for interesting data structures in Ruby:

    https://github.com/harukizaemon/hamster
    On Sunday, 6 March 2011 at 8:54 am, [::psyomn::] wrote:
    > Wow, that is really awesome. Thanks for sharing!
    >
    > On Sun, Mar 06, 2011 at 10:38:32PM +0900, Victor Deryagin wrote:
    > > Lucky Dev <> writes:
    > >
    > > > Also, I don't see much "good" books on datastructures and algorithms in
    > > > ruby or Have I missed to notice them in the market. Can you please point
    > > > me to good datasturctures and algorithms learning book using ruby.

    > >
    > > http://cleveralgorithms.com - book on AI algorithms in ruby (free).

    >
    David Jacobs, Mar 6, 2011
    #8
  9. On Sun, Mar 6, 2011 at 10:05 AM, Lucky Dev <> wrote:
    > I am just wondering, if the ruby world is sooo
    > immersed in its beautiness and is not doing much to embrace cleverness
    > in ruby world.
    >
    > I mean, the whole world of datastructures and algorithms, seems to have
    > much lower importance on a ruby programmer's mind. Is it so?


    Certainly not for me but it may be the case for the community on average.

    > Also, I don't see much "good" books on datastructures and algorithms in
    > ruby or Have I missed to notice them in the market. Can you please point
    > me to good datasturctures and algorithms learning book using ruby.


    Basically *any* good book on data structures and algorithms will do -
    regardless of programming language used for examples. Transferring
    examples from one language to another is usually easy to do. I never
    grokked why Sedgewick wrote his algorithms books for all sorts of
    programming languages. Note, I am not saying they are bad - actually
    I believe they are pretty good. But I think he overdid it in terms of
    programming languages.

    With regard to lack of data structures, if you need a tree it can be as easy as

    TreeNode = Struct.new :data, :left, :right, :parent do
    include Enumerable

    def each(&b)
    left and left.each(&b)
    b[data]
    right and right.each(&b)
    self
    end
    end

    But of course it depends on the use case how your tree will really
    look like. I don't think you'll gain much by including a generic tree
    in the standard library because it is so easy to implement and you
    need specific code for every real tree anyway.

    Kind regards

    robert

    --
    remember.guy do |as, often| as.you_can - without end
    http://blog.rubybestpractices.com/
    Robert Klemme, Mar 7, 2011
    #9
  10. Robert

    Surely, when you elect to use objects, and you are inclined to use
    things like .each or .sort, you are making a choice to move away from
    worrying about data structures and algorithms?

    There are of course still data structures and algorithms -rather like
    the AI book mentioned above - but what people used to talk about in data
    structures and algorithms were much more prosaic things which I suggest
    are not of the same interest nowadays.

    When someone says "Why aren't there more things about Ruby array
    searches etc?" I think there is a case for saying we treat these more as
    implementation details nowadays and typically only investigate the
    details if a performance issue crops up, so look for a higher level of
    abstraction when you move to Ruby.

    --
    Posted via http://www.ruby-forum.com/.
    Mike Stephens, Mar 7, 2011
    #10
  11. On Mon, Mar 7, 2011 at 3:28 PM, Mike Stephens <> wrote:
    > Robert
    >
    > Surely, when you elect to use objects, and you are inclined to use
    > things like .each or .sort, you are making a choice to move away from
    > worrying about data structures and algorithms?


    No, I don't think so. I worry about DS&A all the time. When I have a
    frequent lookup to do I choose a Hash over an Array even though I can
    use Array for lookups as well (unless the key is an integer in which
    case an Array may work as well or better). It's true, I take
    Array#sort for granted and rely on the fact that it is implemented
    efficiently - much the same as when using qsort() in a C program.

    > There are of course still data structures and algorithms -rather like
    > the AI book mentioned above - but what people used to talk about in data
    > structures and algorithms were much more prosaic things which I suggest
    > are not of the same interest nowadays.


    This could be true (less interest in DS&A) but I really regret it.
    Because this is one cause for bad software - I believe too many people
    writing code are unaware of complexity theory, graph theory etc. and
    pick inefficient data structures or algorithms (or both).

    > When someone says "Why aren't there more things about Ruby array
    > searches etc?" I think there is a case for saying we treat these more as
    > implementation details nowadays and typically only investigate the
    > details if =A0a performance issue crops up, so look for a higher level of
    > abstraction when you move to Ruby.


    I'm not sure. It may also well be that the type of software written
    in Ruby isn't just that demanding with regard to complexity of
    calculations. When did we last discuss the most efficient algorithm
    to solve a graph connectivity problem here?

    So, finally it seems the original statement ("[...] the whole world of
    datastructures and algorithms, seems to have
    much lower importance on a ruby programmer's mind.") very well could
    be true - but the question remains: why is it so? And: what do we
    learn from this? Does the overall importance of DS&A diminish? Or is
    this a specific development in the Ruby community? etc.

    Interesting discussion nevertheless.

    Cheers

    robert

    --=20
    remember.guy do |as, often| as.you_can - without end
    http://blog.rubybestpractices.com/
    Robert Klemme, Mar 7, 2011
    #11
  12. [Note: parts of this message were removed to make it a legal post.]

    On Mon, Mar 7, 2011 at 4:58 PM, Robert Klemme <>wrote:

    > On Mon, Mar 7, 2011 at 3:28 PM, Mike Stephens <> wrote:
    > > Robert
    > >
    > > Surely, when you elect to use objects, and you are inclined to use
    > > things like .each or .sort, you are making a choice to move away from
    > > worrying about data structures and algorithms?

    >
    > No, I don't think so. I worry about DS&A all the time. When I have a
    > frequent lookup to do I choose a Hash over an Array even though I can
    > use Array for lookups as well (unless the key is an integer in which
    > case an Array may work as well or better). It's true, I take
    > Array#sort for granted and rely on the fact that it is implemented
    > efficiently - much the same as when using qsort() in a C program.
    >


    I could be wrong, and I hope this makes sense, because it's not entirely
    clear to me, but I think the argument is that Hash and Array, in their basic
    use, provide interfaces for what could be any concrete implementation of an
    abstract associative array and an abstract list, so that the choice of Hash
    vs Array is less about how Hash and Array are actually implemented, which
    would involve a decision based on performance.

    I believe that's what the ".each or .sort" is in reference to, in that, for
    an Array, we might not care how it's implemented -- it's ordered and we can
    iterate over it with .each.
    Adam Prescott, Mar 7, 2011
    #12
  13. On Mon, Mar 7, 2011 at 3:28 PM, Mike Stephens <> wrote:
    > Robert
    >
    > Surely, when you elect to use objects, and you are inclined to use
    > things like .each or .sort, you are making a choice to move away from
    > worrying about data structures and algorithms?


    How so?

    I can define nodes in a tree as a class, and have the actual nodes
    lying around as objects. It can make life easier, though, since I can
    interrogate the node like an object, resulting in better consistency
    (within OO languages, anyway).

    > There are of course still data structures and algorithms -rather like
    > the AI book mentioned above - but what people used to talk about in data
    > structures and algorithms were much more prosaic things which I suggest
    > are not of the same interest nowadays.


    That could be because search, sorting, trees, etc. are mostly solved
    problems nowadays. Science marching on, and all that.

    Besides: Why should I write my own sorting implementation, when I can
    use one that is in general use by hundreds, thousands of people, and
    take advantage of "many eyes make all bugs shallow", as Linus says? It
    frees me from dealing with issues in my homegrown implementation, so
    that I can solve 'actual' problems.

    --
    Phillip Gawlowski

    Though the folk I have met,
    (Ah, how soon!) they forget
    When I've moved on to some other place,
    There may be one or two,
    When I've played and passed through,
    Who'll remember my song or my face.
    Phillip Gawlowski, Mar 7, 2011
    #13
  14. On 07.03.2011 18:22, Adam Prescott wrote:
    > On Mon, Mar 7, 2011 at 4:58 PM, Robert Klemme<>wrote:
    >
    >> On Mon, Mar 7, 2011 at 3:28 PM, Mike Stephens<> wrote:
    >>> Robert
    >>>
    >>> Surely, when you elect to use objects, and you are inclined to use
    >>> things like .each or .sort, you are making a choice to move away from
    >>> worrying about data structures and algorithms?

    >>
    >> No, I don't think so. I worry about DS&A all the time. When I have a
    >> frequent lookup to do I choose a Hash over an Array even though I can
    >> use Array for lookups as well (unless the key is an integer in which
    >> case an Array may work as well or better). It's true, I take
    >> Array#sort for granted and rely on the fact that it is implemented
    >> efficiently - much the same as when using qsort() in a C program.

    >
    > I could be wrong, and I hope this makes sense, because it's not entirely
    > clear to me, but I think the argument is that Hash and Array, in their basic
    > use, provide interfaces for what could be any concrete implementation of an
    > abstract associative array and an abstract list, so that the choice of Hash
    > vs Array is less about how Hash and Array are actually implemented, which
    > would involve a decision based on performance.
    >
    > I believe that's what the ".each or .sort" is in reference to, in that, for
    > an Array, we might not care how it's implemented -- it's ordered and we can
    > iterate over it with .each.


    Well, that could be. Then "worrying about data structures and
    algorithms" was probably intended to mean "implementing algorithms" -
    for me "worrying" includes thinking about which library algorithm to
    pick for a particular problem (even if it is a library of a procedural
    language). For that you need to know basic properties of algorithms and
    complexity theory.

    But this is not an argument specific to Ruby. Actually, all object
    oriented languages come with data and algorithms nicely packaged
    together - in a class. Even for non OO languages there are libraries
    which contain data structures and algorithms. It's just that in OO
    languages the concept of "class" is more closely related to "abstract
    data type" than in non OO languages. But, as I said, this is in no way
    particular to Ruby as a language.

    Kind regards

    robert

    --
    remember.guy do |as, often| as.you_can - without end
    http://blog.rubybestpractices.com/
    Robert Klemme, Mar 7, 2011
    #14
  15. Lucky Dev

    Tony Arcieri Guest

    [Note: parts of this message were removed to make it a legal post.]

    On Sun, Mar 6, 2011 at 2:05 AM, Lucky Dev <> wrote:

    > I mean, the whole world of datastructures and algorithms, seems to have
    > much lower importance on a ruby programmer's mind. Is it so?



    Not at all. I think Rubyists are some of the foremost users of Redis, a "DSL
    for data structures" implemented in the form of a network server. As far as
    algorithms go, some of the neatest implementations of various algorithms
    I've seen have been in Ruby.

    One thing you can say that is true is from a professional standpoint, most
    Rubyists don't need to worry too much about data structures and algorithms
    in their day job because the various frameworks have made the majority of
    the work straightforward so Rubyists can focus on writing correct software
    rather than spending their time reimplementing a given data structure or
    algorithm umpteen million times. Where a C programmer may find himself
    writing new linked lists or new hashes on a day to day basis, that's not
    really a concern that will generally worry a Rubyist.

    Rubyists only bust out their own implementations of a various algorithm when
    the problem is sufficiently novel to warrant it and there aren't any
    libraries already available.

    --
    Tony Arcieri
    Medioh! Kudelski
    Tony Arcieri, Mar 7, 2011
    #15
    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.

Share This Page