Ruby's "More than one way to do things."

There is one point made about Python vs. Ruby on this site:
http://c2.com/cgi/wiki?PythonVsRuby that interests me:

It is this:
Ruby: “There is more than one way to do it.”
Python: “There should be one - and preferably only one - obvious way to
do it.”

Do you agree that Ruby emphasizes having more than one way to do it more
than Python does? Do you believe this is a good thing for Ruby? Why?

I personally like to have structure in my life and feel okay with having
only one way, but then - I’ve never really programmed anything in Python
before so I can’t really make a good comparison.

Thank you for any thoughts.

Jason

Also: Even though we are all computer programmers (kind of), we come
from a diversity of fields of expertise, let alone different worlds of
programming languages / paradigms / experiences.
Ruby is imho the language that allows developers who’ve done Perl, C,
asm, (python), JavaScript, Pascal, whatever before to all work on the
same page, while everyone still gets some aspects of their most
comforting language.

Hi,

In message “Re: Ruby’s “More than one way to do things.””
on Thu, 25 Nov 2010 06:16:16 +0900, Jason L.
[email protected] writes:

|There is one point made about Python vs. Ruby on this site:
|http://c2.com/cgi/wiki?PythonVsRuby that interests me:
|
|It is this:
|Ruby: “There is more than one way to do it.”
|Python: “There should be one - and preferably only one - obvious way to
|do it.”
|
|Do you agree that Ruby emphasizes having more than one way to do it more
|than Python does? Do you believe this is a good thing for Ruby? Why?

“There is more than one way to do it” is the slogan we borrowed from
the Perl community. I cannot speak for the Perl community, but for
us, the slogan expresses the importance of diversity. But we do not
love diversity for no reason. We do not want confusion, for the sake
of diversity. So to rephrase: “There should be more than one way to
do it, if having many way is rational, depending on often untold
context”.

          matz.

On Nov 24, 2010, at 1:31 PM, Yukihiro M. [email protected]
wrote:

|Python: “There should be one - and preferably only one - obvious way to
do it, if having many way is rational, depending on often untold
context”.

                       matz.

I couldn’t agree more. There is no island of simplicity. Ruby is a
pragmatic language and wants to be exploited—not shoe-horned.

There are more than one way to do things because different programmers
come from different languages may prefer different style. In python
everything can be readable from one python programmer to the next
because of how it is.

Ruby expects people to be migrating from C, C++, Java, Python, Perl,
Lisp, sh, etc.

Each type of programmer may have a different perspective on the “one
true way” to express themselves.

Though a couple of years old please refer to this link:
http://www.artima.com/intv/ruby3.html

On Wed, Nov 24, 2010 at 3:16 PM, Jason L.

Thanks everyone for commenting. I really enjoy using Ruby compared to
Java and the documentation and community is great. That has kept me a
big fan of Ruby.

I’m honored to see that Matz himself has commented on this thread.

I use Ruby for math and scientific purposes so this is the main reason I
started looking at Python in the first place - it is used a lot by
people like me.

If I want to walk to my friend’s house, why should I have to go in the
same manner as you? When you walked to my friend’s house it was raining,
so you didn’t take the newspaper with you, and you didn’t dally. Today I
am going to my friend’s house and it is sunny. I think I will take him
the newspaper, and stop periodically under nearby trees for some shade.
I might even detour to the ice cream shop.

It’s good to know however, that we can both walk to my friend’s house.

Sam

Ruby is very laid back. Although able to talk passionately at great
length about sophisticated object oriented issues, it is equally relaxed
about spending the entire evening in the company of down-to-earth
procedural programmers.

You ought to enjoy choosing which way you want to do things. We’re
pushed about too much these days.

On Wed, Nov 24, 2010 at 4:16 PM, Jason L.
[email protected] wrote:

t is this:
Ruby: “There is more than one way to do it.”
Python: “There should be one - and preferably only one - obvious way to
do it.”

I think that that word ‘obvious’ is rather subjective. I’ve found
lots of things in programming, and life, which are obvious to others
but not to me.

What we’ve experienced before shapes what seems obvious.

So if there’s more than one way to do something, I might find a
different one (or ones) obvious than someone else. If there’s only
one way some folks will have a harder time finding it.

This is somewhat related to Ruby’s Principle of Least Surprise. This
also is subjective, and really means at the end least surprising from
Matz’s view point. Luckily for me, I tend to see things similarly to
him more often than not.


Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Github: http://github.com/rubyredrick
Twitter: @RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale

Ruby: “There is more than one way to do it.”
Python: “There should be one - and preferably only one - obvious way to
do it.”

Programming languages – at least, good programming languages –
shouldn’t try to make programmers into better programmers, or force them
to work in a certain way in order to get results. (Imagine a toolbox
that told you off for using the wrong screwdriver!)

The two main reasons I really, really love Ruby: (1) Good cognitive fit:
the easy way is generally the way my brain works. (2) on the rare
occasions when (1) isn’t true, I’m usually free to do it my way anyway.

In article [email protected],
Yukihiro M. [email protected] wrote:

I cannot speak for the Perl community, but for
us, the slogan expresses the importance of diversity. But we do not
love diversity for no reason. We do not want confusion, for the sake
of diversity.

As someone who still has much more Perl under their belt than Ruby, mark
me down as one of the people who appreciates that. I can’t count the
number of times I’ve come across Perl code that does crazy stuff just
because someone wanted to show off how well they knew deep language
tricks more than they wanted write maintainable code. Combined with the
cruft Perl has accumulated over the years, it’s not hard to explain to
people why Ruby makes a better go-to scripting language in most cases.

Shadowfirebird [email protected] wrote:

Ruby: “There is more than one way to do it.”
Python: “There should be one - and preferably only one - obvious way to
do it.”

Programming languages – at least, good programming languages – shouldn’t
try to make programmers into better programmers, or force them to work in
a certain way in order to get results. (Imagine a toolbox that told you
off for using the wrong screwdriver!)

I believe that’s almost 100% wrong. A programming language that doesn’t
try to make better programmers ends up enabling poor programming
practices,
which ends up producing poor programs. That results in programs and web
sites that crash, which brings on a bad reputation for programmers in
general.

PHP is a great example. It is possible to write good programs in PHP,
but
it’s also very, very easy to write bad programs in PHP. The result is
that
most of the PHP samples you find on the web are absolute crap –
delicate,
unsafe, unmaintainable. The programmers don’t realize this, and so the
crap reproduces like a virus.

A toolbox certainly OUGHT to tell me off if I try to unscrew a slotted
head
screw with a Philips screwdriver, if that saves me from taking a chunk
out
of my hand as I do it.

On Nov 24, 11:35pm, Jason L. [email protected]
wrote:

I use Ruby for math and scientific purposes so this is the main reason I
started looking at Python in the first place - it is used a lot by
people like me.

Welcome to the community: you’ll love it here! :slight_smile:

Indeed the diversity is one of the strongest assets of the Ruby
community, and hence the Ruby ecosystem too. Both in the way the
language works, the people, the interests, etc… And it’s full of
people ready to push the envelope who are always trying to improve the
status quo (so much so that some may find the community suffers a bit
from ADHD, but personally I love it that way! :slight_smile: )

That said as a fellow math/science Ruby programmer, most of the
scientific community seems to have “chosen” Python. Personally I think
that’s a pity, maybe due to some misunderstanding on what Ruby is (I
got people surprised when I tell them I program in Ruby: “But I
thought Ruby was just for the web, like PHP”). The Ruby language I
think it’s an excellent language for science, but alas the poor usage
by the math/science community has resulted in very few libraries.

A lot of the original hype behind Ruby was due to Rails, so it’s
understandable that a lot of libraries are web-oriented. As time
progresses the interest has spread out, first to “neighbouring” topics
and now to more general things. That said science/math seems still a
bit far from where the “action” is, and hence we hardly get much in
terms of fancy, cutting edge libraries.

I don’t want to discourage you! As I said I use Ruby too, and there’s
no real reason why Ruby could not become a great scientific language.
But I thought it only fair to warn you: the language is great, but the
libraries are a bit lacking. It’s a “fixable” problem, but we need
“brave” people to break this chicken and egg situation. (this is all
personal opinion, of course, others may disagree). :slight_smile:

Once again, welcome to the Ruby community! :wink:

Diego

P.S. Make sure to check the NArray gem. It’s pretty much a requirement
for anything math related. You may also be interested in Tioga or the
Gnuplot gem if you need to do plotting, and RSRuby if you need to use
R.

On 29 November 2010 05:40, Tim R. [email protected] wrote:

I believe that’s almost 100% wrong. A programming language that doesn’t
try to make better programmers ends up enabling poor programming practices,
which ends up producing poor programs. That results in programs and web
sites that crash, which brings on a bad reputation for programmers in
general.

I believe you are 100% wrong, There is no way to force people into
writing good code as there is no way forcing people into writing good
novels. You can learn to write decently one or the other by education
and training but neither can be forced, and the less expressive the
language the poorer the result. While the programs are also read by
the computer good code should be readable by humans and freedom in
choosing your expression gives you the option to express things
differently to fit a particular context.

PHP is a great example. It is possible to write good programs in PHP, but
it’s also very, very easy to write bad programs in PHP. The result is that
most of the PHP samples you find on the web are absolute crap – delicate,
unsafe, unmaintainable. The programmers don’t realize this, and so the
crap reproduces like a virus.

PHP is a poor example as it is a poor language in general. By its
inconsistency, inflexibility and lack of crucial features it
encourages poor code and code duplication so it is much harder to
write good code in a Personal Homepage Preprocessor than an actual
programming language.

Thanks

MIchal

On Thu, Nov 25, 2010 at 5:05 AM, Jason L.
[email protected] wrote:

I use Ruby for math and scientific purposes so this is the main reason I
started looking at Python in the first place - it is used a lot by
people like me.

This is an interesting blog post and discussion on the topic

http://www.reddit.com/r/programming/comments/ecyef/ruby_is_beautiful_but_im_moving_to_python

martin

Tim R. wrote in post #964583:

I believe that’s almost 100% wrong. A programming language that doesn’t
try to make better programmers ends up enabling poor programming
practices,
which ends up producing poor programs. That results in programs and web
sites that crash, which brings on a bad reputation for programmers in
general.

PHP is a great example. It is possible to write good programs in PHP,
but
it’s also very, very easy to write bad programs in PHP. The result is
that
most of the PHP samples you find on the web are absolute crap –
delicate,
unsafe, unmaintainable. The programmers don’t realize this, and so the
crap reproduces like a virus.

A toolbox certainly OUGHT to tell me off if I try to unscrew a slotted
head
screw with a Philips screwdriver, if that saves me from taking a chunk
out
of my hand as I do it.

The problem with PHP isn’t necessarily that it’s easy to write bad
programs in PHP; it’s probably easy to write bad programs in any
language. The issue is that its (or at least was) extremely difficult to
write good programs in PHP. Not only is the standard library just a
nasty pile of random, often -mostly- duplicate functions with no
conventions to unify them, but historically the PHP environment is be
default configured to be as insecure as possible, with what
register_globals being on be default (I know it isn’t anymore), the
existence of magic_quotes, mysqli (most importantly for its prepared
statements) not being part of any standard PHP install package, etc.

This isn’t even including the fact that PHP didn’t support namespacing
(or even emulation of it) until 5.3.0, its typecoersion rules are even
more mind-bending than Javascripts, OO is cripplingly limited…

Ruby, although also not imposing any sort of philosophy on the
programmer at least readily provides all the tools a competent
programmer needs to adhere to his own philosophy. Matz understands that
there’s very rarely only one correct way to tackle any possible problem,
and thus that a key of language design isn’t telling you how to solve
those unforeseen problems, but to give you, the expert, the best tools
you need to solve them.

On Mon, Nov 29, 2010 at 5:40 AM, Tim R. [email protected] wrote:

crap reproduces like a virus.
After all those years I am unsure how big the impact of a language is.
What I’d consider facts (in no particular order):

  1. A programming language can do little to nothing to help you decide
    how you lay out functionality across program code artifacts
    (functions, procedures, methods, classes). But this (along with
    naming of things) has a dramatic impact on readability and
    reusability.

  2. Good libraries which enforce particular usage patterns can do a
    great deal to guide their users to a proper code structure. - But they
    cannot prevent creating a mess if one tries to.

  3. A key factor for writing good code is the person doing the writing.
    People not interested to learn or otherwise improve their work are
    unlikely to write better code. The same holds for people who do not
    have a chance to improve because they are constantly buried under
    loads of work since they lack the time needed for reflection.

  4. Removing obstacles to writing good code (compare for example Ruby’s
    OO with Perl’s) certainly helps people writing better code.

My 0.02 EUR.

Kind regards

robert

hi,
saw this on twitter today:
http://guide.python-distribute.org/introduction.html#current-state-of-packaging
where he was making a point that “it sure is complicated for a
language having one way of doing things”

It is good to have multiple options, find the best solution to a
problem by applying common sense and good taste, take feedback/
benchmark and iterate.

Not really sure how the python zen works. Maybe having no choice in
indentation, multi-line lambdas etc are obvious. i dunno. If it comes
with experience and then it is no better than having options and
discovering the best option through experience, irc, mail-group,
benchmarks, awesome community, pretty ok docs and your own common
sense and good taste.

cheers,
deepak

On 29 November 2010 19:40, deepak [email protected] wrote:

Not really sure how the python zen works. Maybe having no choice in
indentation, multi-line lambdas etc are obvious. i dunno. If it comes
with experience and then it is no better than having options and
discovering the best option through experience, irc, mail-group,
benchmarks, awesome community, pretty ok docs and your own common
sense and good taste.

The point is that there is no one right way, the right way depends on
context.

The python zen does not work for me at least. Take a small example:

Python is supposedly an object oriented language but you don’t have

“string”.len

you only have

len(“string”)

supposedly for the case when an object does not implement len by
itself but the length can still be determined (possibly to be 1 or or
0 on scalars).

Sure, in Python you can’t just monkey-patch a len to something that
could have it determined but does not implement it so to have only one
true way you need a procedural len() which goes against OO.

In Ruby you have “string”.length and you can always write procedural
len() if it makes your code look nicer and you can also add length to
any object you want (well, except for integers but you could use some
voodoo if you really insisted).

Thanks

Michal

On Mon, Nov 29, 2010 at 11:21 PM, Michal S. [email protected]
wrote:

Python is supposedly an object oriented language but you don’t have

“string”.len

you only have

len(“string”)

Ouch.

supposedly for the case when an object does not implement len by
itself but the length can still be determined (possibly to be 1 or or
0 on scalars).

Sure, in Python you can’t just monkey-patch a len to something that
could have it determined but does not implement it so to have only one
true way you need a procedural len() which goes against OO.

That sounds strange.

In Ruby you have “string”.length and you can always write procedural
len() if it makes your code look nicer and you can also add length to
any object you want (well, except for integers but you could use some
voodoo if you really insisted).

It’s not too difficult. Just for the fun of it:

irb(main):001:0> class Numeric
irb(main):002:1> def length;size;end
irb(main):003:1> end
=> nil
irb(main):004:0> 123.length
=> 4
irb(main):005:0> (1<<100).length
=> 16

length is in bytes. :slight_smile:

Kind regards

robert

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs