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

[Jason Lillywhite]

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

 

[Stu]

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

 

[Sam Duncan]

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

 

[Jason Lillywhite]

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.

 

[Mike Stephens]

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.

 

[Rick DeNatale]

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

 

[Shadowfirebird]

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.

 

[Diego Virasoro]

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!

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

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

Once again, welcome to the Ruby community!

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.

 

[Michal Suchanek]

I believe that's almost 100% wrong. =C2=A0A programming language that doe= sn't
try to make better programmers ends up enabling poor programming practice= s,
which ends up producing poor programs. =C2=A0That 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. =C2=A0It is possible to write good programs in PH= P, but
it's also very, very easy to write bad programs in PHP. =C2=A0The result = is that
most of the PHP samples you find on the web are absolute crap -- delicate= ,
unsafe, unmaintainable. =C2=A0The 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

 

[Martin DeMello]

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

 

[Robert Klemme]

I believe that's almost 100% wrong. =A0A programming language that doesn'= t
try to make better programmers ends up enabling poor programming practice= s,
which ends up producing poor programs. =A0That results in programs and we= b
sites that crash, which brings on a bad reputation for programmers in
general.

PHP is a great example. =A0It is possible to write good programs in PHP, = but
it's also very, very easy to write bad programs in PHP. =A0The result is = that
most of the PHP samples you find on the web are absolute crap -- delicate= ,
unsafe, unmaintainable. =A0The programmers don't realize this, and so the
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


--=20
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

 

[deepak]

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

 

[Michal Suchanek]

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.

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

 

[Robert Klemme]

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")
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.

Kind regards

robert

 

[Eleanor McHugh]

=20
The point is that there is no one right way, the right way depends on = context.
=20
The python zen does not work for me at least. Take a small example:
=20
Python is supposedly an object oriented language but you don't have
=20
"string".len
=20
you only have
=20
len("string")
=20
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).

Funnily enough this "special case" style is one of my single greatest =
annoyances with OO in Go, and yet to the Python programmers who =
constitute a large part of that community it's considered a plus point.

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.

Technically this doesn't break OO per se, rather it's a special form =
known to the compiler/interpreter which mirrors object manipulations as =
the application of functions rather than the sending of messages. =
Instead of asking if a particular object can respond to a particular =
method this styles asks whether that object is the right "shape" to be =
passed to a given function. =46rom what I recall of Python it doesn't do =
a huge amount with this concept, but Go really runs with it thanks to =
its combination of interfaces and type inference.

This is great for a statically typed language that wants to feel like a =
dynamic language, but the downside is that a programmer needs to keep =
that model in their head as well as any others that the language =
supports. As both Python and Go allow message passing syntax as well =
that means supporting two world views where in Ruby or Smalltalk we'd =
only need the message passing model.

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

One of the great strengths of Ruby is that it exposes the interpretation =
infrastructure to programs in a very clean and manipulable manner which =
is why it's so DSL friendl. We pay a certain performance and memory =
footprint cost for this flexibility but it puts more constrained =
languages at a great disadvantage for real-world problems. And of course =
we need to put that bit more care into how code if we want it to be =
maintainable.


Ellie

Eleanor McHugh
Games With Brains
twitter: @feyeleanor

 

[Eleanor McHugh]

=20
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.
=20
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.
=20
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.

I wouldn't claim to be a good programmer, but I'm certainly a =
knowledgable one and that in large part because I've worked with =
languages which did their best not to get in my way. That has certainly =
resulted in some hideous abominations at various times but each of these =
has been deeply instructive and subsequent reflection has helped advance =
my knowledge and improve my instincts. Had I pursued the safer course =
and languages which insist on particular orthodoxies my coding life =
would have definitely been much poorer.

Or to stick with your analogy: whilst it's true that a philips =
screwdriver happens to be a very good fit for a philips head screw, in =
the absence of that screwdriver it's better to know how to use another =
tool to achieve the same effect than to sit there worrying about how =
inappropriate your tools are. After all no toolbox can ever have every =
tool you might need, and the more tools contained in the toolbox the =
more knowledge is required before you can start using any of them =
competently.


Ellie

Eleanor McHugh
Games With Brains
twitter: @feyeleanor

 

[Mike Stephens]

Eleanor McHugh wrote in post #965090:

...the more tools contained in the toolbox the
more knowledge is required before you can start using any of them
competently.

I don't think that is logically correct. As long as you can use some
tools, it is irrelevant whether there are others in the box, as long as
when you want to use your tools nobody else has removed them.

The analogy however is fundamentally flawed. Programming is different to
other areas of human endeavour. You can botch things with entirely the
wrong tool and the magic of computer chips covers the whole thing up.
You may just notice slower performance, more memory usage etc but
chances are you won't.

If Ruby gives you more tools, so that two different artisans appear to
be doing quite different things when they are actually trying to achieve
the same ends, the impacts are only likely to arise when other people
start to look at the code later. That problem however started many
decades before Ruby and Python arrived on the scene.

A better analaogy is when you buy a box of assorted chocolates because
there are a couple that you really love but can't buy by the bag.
Normally you can't afford to buy confectionary and waste it but Ruby is
free. So all that matters is whether you get the items you're after.

 

[Jason Lillywhite]

Thank you everyone for taking the time to reply to my question. This has
been a very enlightening experience for me.