Ruby - Missed some core computer science world ?

[Lucky Dev]

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.

 

[Mike Stephens]

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.

 

[Sandor Szuecs]

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

 

[Lucky Dev]

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.

 

[Phillip Gawlowski]

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.

 

[Victor Deryagin]

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::]]

Wow, that is really awesome. Thanks for sharing!

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

 

[David Jacobs]

[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

 

[Robert Klemme]

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, arent 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

 

[Mike Stephens]

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.

 

[Robert Klemme]

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/

 

[Adam Prescott]

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

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.

 

[Phillip Gawlowski]

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.

 

[Robert Klemme]

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

 

[Tony Arcieri]

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

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.