What is Ruby's biggest strength ?

[Tuan Minh]

I'm learning Ruby an Rails.
But I can't answer this question
"What is Ruby&Rails 's strength and
What helps Ruby stronger than other programming languages ?"

Who can helps me! Thanks

 

[Chinna Karuppan]

I think it is enumerables and thier block syntax...it is so easy...I am
also a nuby...learning ruby

 

[ara howard]

I'm learning Ruby an Rails.
But I can't answer this question
"What is Ruby&Rails 's strength and
What helps Ruby stronger than other programming languages ?"

Who can helps me! Thanks

the abstraction facilities, metaprogramming, using blocks to emulate
syntax, open classes, etc., coupled with with a concise syntax enables
the programmer to build systems within the language that match more
closely that other languages the way we think. solving complex
problems requires the burden understanding to language and libraries
to be low enough to allow the mental bandwidth to solve the *real*
problem - ruby excels in this area.

kind regards.

a @ http://drawohara.com/

 

[sean_n]

I'm learning Ruby an Rails.
But I can't answer this question
"What is Ruby&Rails 's strength and
 What helps Ruby stronger than other programming languages ?"

Who can helps me! Thanks

I've glanced at the ruby source code, it's very clean and obviously
well designed and orderly. No run on functions--everything is small
and compact. Why is this important? I have confidence that ruby can
be maintained and expanded w/o too many things breaking.

 

[James Britt]

I'm learning Ruby an Rails.
But I can't answer this question
"What is Ruby&Rails 's strength and
What helps Ruby stronger than other programming languages ?"

How much research into various programming languages and Web tools did
you do before deciding on Ruby on Rails?

Seems you should first see if there is a satisfactory answer to your
question before deciding what to pursue.



--
James Britt

www.rubyaz.org - Hacking in the Desert
www.risingtidesoftware.com - Wicked Cool Coding
www.jamesbritt.com - Playing with Better Toys

 

[Avdi Grimm]

I'm learning Ruby an Rails.
But I can't answer this question
"What is Ruby&Rails 's strength and
What helps Ruby stronger than other programming languages ?"

Three things:
1. Fear
2. Surprise.
3. Ruthless efficiency
4. A fanatical devotion to the pope

No, FOUR things!

 

[Rodrigo Bermejo]

"What is Ruby&Rails 's strength andRuby is fun.

 

[Scott Preston]

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

I have been looking at a new language to learn for some time. I was looking
at either Groovy, Python or Ruby. These 2 things that stood out for me:

1) The community is really active and forward thinking. For example: our own
Columbus Ruby Brigade has a bunch of cool oaks and they think like I do.
2) Syntax is easy and looks nice in an editor.

A few things keep me from being a complete convert: I still like my PHP for
web programming, something about weak-dynamic typing on the web that appeals
to me. While the library support is growing, I still need a lot of Java for
my robotics & vision processing, and while I could use JRuby, Groovy seems a
better fit.

 

[Joel VanderWerf]

Three things:
1. Fear
2. Surprise.
3. Ruthless efficiency
4. A fanatical devotion to the pope

No, FOUR things!

I thought that was Python

 

[Marc Heiler]

What helps Ruby stronger than other programming languages

I cant answer the question in regards to rails, but I can give my point
of view about Ruby.

When I started with ruby, I needed something better than PHP, and less
ugly than perl (actually, I was more productive with PHP than perl bacak
then... I think perl is a "write once, dont maintain afterwards"
language, and I cant stand this specific attitude. I think it is wrong.
Code should evolve too, and for this to happen, people need to
understand the complexity, and ugly syntax does not help to maintain it.
And PHP's biggest problem is that outside of the www world, it just
falls flat on its nose ... It is also ugly, though not as much as perl.)

The question was - pick ruby, or pick python?

Two factors made me choose ruby back then.

- a) An interview with Matz. I normally do not understand people from
the distant east, they seem to think differently but the interview
was one of the best interview as far as thinking "strategy" was
concerned. I loved the concept of elegance, beauty etc... which I
lateron found. It all seemed very natural. I also saw ruby being
mentioned where a few people wrote a quick webserver in few lines of
code, and I am naturally lazy so I like to write only few lines of code
and achieve much, so back then I was very impressed with that ;-)

- b) Ruby felt much more OOP back then, compared to python.
I dont like a len(foo) approach, i think it does not fit into object
concentrated thinking.

I think objects should be in:
foo.bar
or
foo bar

I saw this first in LPC language where it was like so:
sword->move(find_player("aramil"));

to move a sword to the player object aramil (i.e. in a MUD)


That was it back then for me.



These days, I would give the following reasons for ruby:


- Extremely clean code compared to the other languages I know/look at.
It can become very terse at times, but this is not so bad as long as you
know what is
happening. And at least my code is beautiful!

- Yaml (seriously, I think using Yaml was one of the best decisions
every taken. I have moved all my system config stuff to yaml, and ruby
generates all config files I ever need, no matter if xml or whatever is
the end result. I no longer have to care if Linus thinks he needs to use
udev rules, introduce UUID or HAL or SeLINUX or something - yes,yes, its
not him doing so, but lets ignore that for now, its just that the Linux
world adds complexity ... - I simply denote how my system should behave
via the yaml files, and let a few ruby scripts generate the glue things.
I have since then changed my approach to think about code AND data - i
think the underlying data should be decoupled from programs completely.
I use yaml config files for all my bigger ruby projects, hopefully every
language out there will include yaml in their default library sooner or
later, it is so amazingly useful IMHO, and it is a joy to modify a
simply yaml file to have effect the ruby code base, without ever
touching that code base)
Seems like a nice way to present a GUI solution to a user too, this way
he can change the system using a few buttons and stuff, and doesnt even
really need to open up an editor anymore

- Its fast to write ruby code!

- There is more than one way to do it. People might prefer python's
approach to have only one way, and in theory this is good - i personally
try to pick always the first way to solve something (or the best way, if
i know about it) - but the problem is that, IF this way sucks, then you
have no real choice to avoid it. The best example is case menu, which in
python does not exist. But in ruby, I think a case menu is really really
useful and beautiful.
(Also i dont like the implicit self and __foo__ methods all over the
place coupled with the : at the end of the line but ask guido why he
thinks this is needed ...)
And lets face it, in Ruby one has to make choices what to use, and what
not to use. I was very appealed at the objects, but I didnt really need
a lot of metamagic or proc/lambda magic. I still dont really feel the
need to use it, others feel differently, but this is fine since I dont
have to use it anyway

 

[grocery_stocker]

I'm learning Ruby an Rails.
But I can't answer this question
"What is Ruby&Rails 's strength and
 What helps Ruby stronger than other programming languages ?"

Who can helps me! Thanks

I'm going to use standard mathematical terminology for the following
speel -).

I think some of Ruby's biggest strengths are

1)You can abstract higher order functions. This in turn allows you to
increase the expressiveness of the language. This is sort of analagous
to how the summation in Differential Calculus increases the
expressiveness.

2)The use of symbols. Even though I think the Ruby implementation is
half-assed attempt at copying the Common Lisp Implementation, I still
feel the use of symbols is a strength.

3)The language doesn't appear to make the distinction between
statements and expressions. If memory serves me correctly, the
distiction between statements and expressions first appeared in
FORTRAN.

 

[7stud --]

These days, I would give the following reasons for ruby:


- Extremely clean code compared to the other languages I know/look at.

In my opinion that is a a lie perpetuated by the ruby community. In my
opinion, ruby syntax is ugly. But even if you think the syntax is
clean, ruby is all about cramming 4 or 5 function calls into one line
and sprinkling some regex's in for spice, which is creates an
indecipherable mess. I've never encountered any language that is coded
so poorly by its community. Most of the code I see posted is very hard
to decipher, but if you say perl is worse, I'll believe you.

 

[Gregory Seidman]

In my opinion that is a a lie perpetuated by the ruby community. In my
opinion, ruby syntax is ugly. But even if you think the syntax is
clean, ruby is all about cramming 4 or 5 function calls into one line
and sprinkling some regex's in for spice, which is creates an
indecipherable mess. I've never encountered any language that is coded
so poorly by its community. Most of the code I see posted is very hard
to decipher, but if you say perl is worse, I'll believe you.

Actually, I think you're seeing a strength and misinterpreting it. The
advantage of being able to express things tersely is that when you have a
page of code on your screen (or printed out, if you prefer) you can grasp a
lot of what's going on. This often comes up when comparing Java with other
languages (even C++); Java advocates point to IDEs with code completion and
generation as offsetting the time it takes to write the numerous lines of
code it takes to express functionality, ignoring the much more important
aspect of understanding all those lines of code. Now, this can't be taken
to absurd extremes. Long, descriptive variable and method names make the
code easier to understand, and are more valuable than less descriptive
names even though they shorten the code.

What you may also be seeing is a more functional programming style, where
methods are chained one after the other. This, too, is a strength rather
than a weakness. Thinking in terms of dataflow, which is just another way
of talking about functional programming, is very effective for
understanding what kind of data is being taken in, how it's being
processed, and what the result will be. It is a terse (but clear)
expression of functionality.

I'll also point out that much of the code you see posted is from people who
are just learning how to work with Ruby, and are looking for help with that
code; it's unsurprising that it would be poorly written. Most of the gems
that are out there, particularly those that have reached a 1.x version, are
much better written.

--Greg

 

[Jeremy McAnally]

Have you ever actually written code in another language, especially Perl?

Ruby's lack of line noise is a God-send for me. Just because people
suck at using the syntax doesn't mean it's ugly.

--Jeremy

In my opinion that is a a lie perpetuated by the ruby community. In my
opinion, ruby syntax is ugly. But even if you think the syntax is
clean, ruby is all about cramming 4 or 5 function calls into one line
and sprinkling some regex's in for spice, which is creates an
indecipherable mess. I've never encountered any language that is coded
so poorly by its community. Most of the code I see posted is very hard
to decipher, but if you say perl is worse, I'll believe you.

--
http://jeremymcanally.com/
http://entp.com

Read my books:
Ruby in Practice (http://manning.com/mcanally/)
My free Ruby e-book (http://humblelittlerubybook.com/)

Or, my blogs:
http://mrneighborly.com
http://rubyinpractice.com

 

[Julian Leviston]

So, you think this:

#include <stdio.h>
for(count = 1; count <= 200; count++) {
printf("%d ", count * 300);
}


is less ugly than this:

puts (1..100).map{|num| num * 300}.join(" ")

are you serious?

Even if you spell all the ruby out fully, then you end up with less
code, and it's much nicer looking and easier to understand, even to
non-programmers:

range = (1..100)
multiplied_numbers = range.map{|num| num * 300}
string_to_output = multiplied_numbers.join(" ")
puts string_to_output

 

[Xeno Campanoli]

Ruby's biggest strength is that it is such a good set of designs that
many of the best people have come to try and work with it, and that
makes it better again. If you look at any code in Ruby, it tends to be
relatively well designed and clean if it's in the public sphere.
Contrast that to, and I have to admit this is my favorite example, the
code for Perl's LWP. Sorry perl programmers, but I used to be a Perl
programmer, and I had to dig through that thing. Look then at the code
for similar tools in Ruby, and they are better designed, easier to read,
and generally more helpful.

That being said, Perl, Smalltalk, Python are very important ancestors to
Ruby, and I particularly respect them all for what they were in their time.

xc

 

[Alex Fenton]

So, you think this:

#include <stdio.h>
for(count = 1; count <= 200; count++) {
printf("%d ", count * 300);
}


is less ugly than this:

puts (1..100).map{|num| num * 300}.join(" ")

are you serious?

Even if you spell all the ruby out fully, then you end up with less
code, and it's much nicer looking and easier to understand, even to
non-programmers:

range = (1..100)
multiplied_numbers = range.map{|num| num * 300}
string_to_output = multiplied_numbers.join(" ")
puts string_to_output

It's a trite example, and I agree that both your implementations are
ugly. With any language, the unfamiliar will tend to write clumsy code
that obscures their intention. I get the impression you're not
interested in being persuaded, but:

1.upto(100) do | i |
printf "%d ", i * 300
end

You're missing the point that iterators - one of the commonest tasks -
are easier, clearer and terser to write in Ruby than your C-esque
for(...) loop or even a Perl "foreach @array" or "each %hash".

The fact that some people choose to use all the space which they saved
in not writing tedious loop verbiage to cram multiple method calls into
a line is a matter for their taste, or lack of it. I think you'd be
hard-pushed to find examples in, for example, the ruby standard libraries.

a

 

[Brian Adkins]

So, you think this:

#include <stdio.h>
for(count = 1; count <= 200; count++) {
printf("%d ", count * 300);

}

is less ugly than this:

puts (1..100).map{|num| num * 300}.join(" ")

are you serious?

Do you really want to collect all the numbers into a sequence and then
join with a separator into a string just to print the string and
discard? Consider your solution when using very large N.

 

[Marc Heiler]

You're missing the point that iterators - one of the commonest tasks -

are easier, clearer and terser to write in Ruby than your C-esque
for(...) loop or even a Perl "foreach @array" or "each %hash".

I believe 7stud might not realize this point.

 

[Christopher Dicely]

In my opinion that is a a lie perpetuated by the ruby community.

I think its more of a matter of taste. One man's clean code is another
man's Perl.

In my opinion, ruby syntax is ugly.

Degustibus non est disputandum.

But even if you think the syntax is clean, ruby is all about cramming 4 or 5 function calls
into one line and sprinkling some regex's in for spice, which is creates an
indecipherable mess.

While in Ruby you certainly can cram as many function calls as you can
tolerate on a line,
and sprinkle in as many regex's as you'd like, that's not what Ruby is
all about.

I've never encountered any language that is coded so poorly by its community. Most of the
code I see posted is very hard to decipher, but if you say perl is worse, I'll believe you.

Ruby can be hard to decipher coming from many other popular languages,
as many use
very similar (to each other) C-like syntax, and Ruby is both different
in important ways and
freer (optional parens, for instance) than most C-like languages. This
isn't an issue of hygiene
("clean" code) so much as it is one of familiar syntax. TMTOWTDI also
means that different
programmer's will express things in the ways most natural to them,
which may not be the
most natural to other readers.