
Ruby is beautiful (but I'm moving to Python) - ColinWright
http://wit.io/posts/ruby-is-beautiful-but-im-moving-to-python
======
djacobs
I wrote this article almost a year ago as a tribute to my favorite language at
the time. (That title now belongs to Clojure.) It feels like if you want to do
scientific computing in Ruby, you're met with obstacles at every turn, but
with Python, you're greeted with open arms and tested libraries. That could
change (and I'm beginning work on a stats library for Ruby), but it will take
time. This was partially a call to action to the Ruby community to start
thinking about more than Web protocols and NoSQL databases.

For a more thoughtful comparison, feel free to check out my followup posts.

~~~
Tichy
What is the state of Incantr (or something like that was the name)? A
Scientific Computing framework for Clojure.

~~~
msutherl
For Clojure, there's also Clojuratica:
<[http://clojuratica.weebly.com/>](http://clojuratica.weebly.com/>), which
lets you trade data between Clojure and Mathematica seamlessly.

------
gerggerg
I never really understood the drama around switching tools. Picking the right
one for the job is the first thing you should do.

~~~
jessedhillon
From "Don't Call Yourself A Programmer..."[0] recently seen on the front page:

 _Many asked how to know what programming language or stack to study. It
doesn’t matter. There you go._

That's how I feel about this post -- it doesn't matter. The points he raises
-- either as complaint or as praise -- seem shallow. It's not a very
sophisticated critique of anything.

[0]: [http://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-
pro...](http://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-programmer/)

~~~
rjd
I did something recently I wish I did years ago, I picked up a second language
for personal projects. Which just so happened to be python, but I agree it
probably doesn't matter, but from my experience don't use the same language
you use at work everyday.

I'm not sure if I'm alone but I spend WAY to much time in front of my
computer. 8-10 hours a day working, and then I often use my laptop casually to
write stuff at night in front of the TV.

There came a point several years ago where I became disgusted with Windows.
Not so much Microsoft, more enterprise infrastructure teams. But the
negativity flowed over to personal use. So I brought a mac for personal use, I
wanted the disconnect between work and fun. Windows for me is over, I'll never
have another Windows machine in my house... in fact it will mainly be
appliances for me... and by that I mean Apple products.

For a long time I plugged on using mono, but I lost the drive to program it
just wasn't fun anymore. I'd get 80-90% of the way through a project and just
hate finishing it. As soon as the fun exploration bit was over and I had to
spend time aligning pixels or whatever it just felt like work. I hated it.

By pure chance I started using python to show my unskilled friend some ideas.
He could follow python without much guidance, C# confused him. Since then I've
grown to enjoy programming in the evensong again. I'm not sure if its the same
disconnect I needed between work/fun or what... but its working.

Especially the ability to sit with my macbook, feet up on lazy chair, half
watching TV, terminal open testing bits and pieces, IDE doing the thinking for
me (PyCharm gets a thumbs up from me), and a nice hassle free (and
inspectable) stack. The casual nature of python just seems to click perfectly
with my mood in the evenings.

So theres my advice for languages, separate work and fun. Don't use the same
stack for enjoyment as you do for stress endeavors.

------
sreque
What he says about higher order functions rings very true for me. I learned
Python before Ruby, and while I love using both languages, in Ruby I really
learned for the first time the power of higher order functions because they
are thrown in your face when using it. They are everywhere in the standard
library and the syntax makes them very convenient to read and write. They are
idiomatic Ruby.

Once I learned Ruby, I started using higher order functions in other
languages. Learning Ruby changed the way I wrote Python. Learning Ruby even
changed the way I wrote Java! While I code mostly in Python, C#, and a little
Racket these days, I'll always remember Ruby fondly for changing the way I
thought about coding.

As a side note, The other thing Ruby opened my eyes to was metaprogramming.
Ruby's metaprogramming facilities are dead simple compared to Python's, which
I feel changed practically every release from 2.2 onward. Of course the Lisps
take the cake when it comes to code generation, but Ruby's ability to easily
manipulate symbol tables is a nice easy way to start wrapping your head around
the idea of code that generates code if your brain has already gotten used to
C-style syntax and finds homoiconic s-expression-based languages a little
strange.

~~~
lloeki
> Ruby's metaprogramming facilities are dead simple compared to Python's

I actually have the opposite experience, Ruby's eigenclasses and the _self_
way to handle them to create class methods feels convoluted and shoehorning
whereas __metaclass__ and the way you inherit of Class feels straightforward
to me. The same goes for modules extending/including behaviors versus sane
multiple inheritance combined with metaclasses and the way you manipulate
methods and functions just assigning them as attributes, without any need for
three handfuls of helper methods. Ruby's approach of development is so
pervasive that I (and not only me) always have to check if I won't be tripping
on someone else's wires. When I tell that, the Ruby crowd shouts at me that
Ruby monkey-patching is safe! So let's make it safer[1]! It honestly feels
like needless complexity, over-engineering, or jumping through more hoops.

I know both approaches quite well but I can't help but think that the Python
approach just fits in, like a self-solving Tetris, whereas Ruby feels like I
constantly need to solve puzzles. Granted it's fun when you learn the
language, drawing a picture of where classes, instances and eigenclasses of
each fit, but when you want to be productive you just want it to flow, not
solve another damn puzzle of how I can do this smartly so that things don't
end up making galaxies collide.

PS: don't get me wrong, I actually love both languages, but while it's love-
love with Python, it's actually love-hate with Ruby.

[1] [http://yehudakatz.com/2010/11/30/ruby-2-0-refinements-in-
pra...](http://yehudakatz.com/2010/11/30/ruby-2-0-refinements-in-practice/)

------
Aloisius
The follow up <http://wit.io/posts/the-ugliness-of-python> is in my opinion,
more interesting. I always find it funny how different people think different
languages are ugly.

~~~
michaelchisari
Yeah, I have the opposite reaction. I think python is very elegant, and I
really appreciate it's "one and only one way" philosophy, as opposed to ruby's
"you are a special snowflake" approach.

It really can be just a matter of preference, though. Python and Ruby are so,
so, so similar, that ultimately I find flamewars between them to be tiring at
best.

~~~
treetrouble
Characterizing the Ruby philosophy as "you are a special snowflake" is, well,
starting a flamewar

~~~
michaelchisari
Honest question, how would you characterize it?

~~~
lusis
TMTOWTDI.

Ruby, for all the problems it can cause, gives you. More than one way to solve
a problem. Yes, it sometimes makes it harder to dive into other's code but I
happen to enjoy the expressiveness.

Mind you I love some of the things about python too. Namespacing being one of
the primary ones. Another is that, short of advances pythonfu (like django
does), I can usually pick up someone else's code and dive right in.

Python has amazing access to mathematical and scientific libraries as
mentioned. However with ruby, I would punt to the Java ecosystem via JRuby if
I needed that.

It's a lot like design patterns. Some patterns don't fit in all languagea but
that's usually a case of the language itself giving you another way. Mixins in
ruby are a good example.

------
Locke1689
_In Ruby, everything is an object and responds to messages. And it turns out
that we can ask a number if it’s even or odd. In other words, numbers have our
criterion function built in, and we don’t have to define it at all._

I absolutely hate this. In fact, I'm not a huge believer in object-oriented
programming in general.

<rant>

    
    
        even?
    

Is not an operation that integers perform. Integers do not contain methods --
they are data. even? is _function_ that operates on integers. Integer is a
type. Objects are object types. An object which contains an integer is an
object-integer type. An object-integer type is _not_ the same as the integer
type. Why do we constantly feel the need to wedge objects into everything in
existence when often what we really need are algebraic data types, functions,
and namespacing/modules?

</rant>

As you can tell, I like the ML family.

~~~
gnaritas
Your rant isn't an argument, it's an opinion. I can just as well say integers
are objects like any other and even? makes perfect sense as a method on them
because that's the entire point of objects in the first place, binding state
and behavior together into a single smarter package because it's a convent
method of organizing code.

~~~
Locke1689
I agree 100% that it is my opinion. I would wager that most rants are
opinions.

As far as this being the point of objects -- I see no state. I see no
behavior. All I see is a function which maps the set of integers to booleans.
That's it. It's just a function. The only reason we need packaging or modules
at all is to prevent name collisions and importing the world.

~~~
gnaritas
The integer is state, deciding if it's odd or even is behavior. Yes, it's a
query method, but it's a good one. The only reason we need objects is to make
programming convenient. I don't want my namespace polluted by a free floating
function named even?/odd? when it can be restricted to the only type it cares
about by being bound to it.

In some strictly ease of use sense, _object.function()_ is better than
_function(object)_ because it better helps me organize and scope my code; I
don't have to worry about function name clashes because every instance is
essentially a module for those functions.

My tools also work better when they can see I'm asking what methods are on
integer rather than just show me all functions visible to me right now. It's
easier to say hey Integer, what can you do rather than hey world, what works
with integers.

If you can only see functions, integers, and booleans and you can't realize
those are all themselves perfectly good objects, then that's a failure of your
imagination. Me, I like my functions, methods, booleans, integers, and all
other types being objects because it's damn useful and damn convenient in
making my day to day life easier.

------
jgmmo
I expected a nice article going back and forth debating pros and cons. Really
you argued here that Ruby is better than Java, and then at the end say -- oh
and Python has more Science packages so I'm switching.

You let me down buddy. I was expecting more thought, less fluff.

~~~
lucisferre
This is an older post, not sure the OP is the author. I agree the title is a
big overstatement. Basically boils down to "I'm going to learn a new tool that
I think does X better".

I did like the post though, the follow is good too.

------
Tichy
TL;DR: Ruby has no equivalent to SciPy, hence the need to switch. Probably a
fair point :-(

------
crag
You are right, Python package management is terrible. Even using an OS package
manager (on Mac) like Ports or Brew it's still a nightmare.

The other problem is fragmentation. This package requires python 2.5, that one
wants python 2.6, and that one wants python 3.1 but _might_ me ok for python
3.2.

It's just a mess. And confusing.

Not to mention, even installing python on Mac can be a nightmare. One piece of
advice, if you are going to use python on a mac get py-virtualenv
(<http://pypi.python.org/pypi/virtualenv>). It's as good as rvm (in ruby) and
will save your life.

I miss GEM terribly.

But despite the shortcomings (maddness) I still LOVE python. :)

------
spacemanaki
Previous discussion: <http://news.ycombinator.com/item?id=1947723>

OP appears to have changed domains.

~~~
djacobs
I did, sorry that messed up the HN dupe filter. I git three-letter domains
much more than ones inspired by sentences :)

~~~
djacobs
s/git/dig/

------
finnw
Who is the article (at least the first half of it) aimed at?

Are there any Java developers who still haven't dabbled with dynamic languages
_but_ could still be convinced to?

I imagine that those who will already have done, and the rest will never touch
any language not in the "enterprise" class (Java, C#, C++, COBOL etc.)

~~~
prodigal_erik
I don't see anything suddenly more compelling about Python (which I've always
liked, at least among imperative languages) but I for one was pretty startled
to learn that V8 was already within 2-3x the cost of JVM bytecode. That can
make server-side Javascript feasible for work where Python or Ruby would need
an order of magnitude more rack units today.

------
elrodeo
Congratulations! The most silly article a read today. Comparing languages by
the length of code is something an amateur would do, but not a professional.

Want to filter list with an "ad-hoc" function in Java? Use

Collections2.filter(list, new Predicate<Integer>() { public boolean
apply(Integer i) { return i % 2 == 0; } })

from the Guava library. To read a file I use

Utils.getFileContent("filename")

from my library.

You would say, that the Java verbosity is outsourced to external libraries —
but so it is in Ruby as well. The only difference is that Ruby contains more
libraries than Java. But does it count in a development of a huge
_professional_ project? NO. (You write the libraries once and use the package
everywhere.) Does it count in script writing? Yes. But Java wasn't designed
for script writing, so please please don't compare a fork and a spoon.

------
treetrouble
Seems like it would be a huge opportunity for people to start creating these
science Ruby gems.

Not my field, personally...

~~~
mbell
It's been tried before. mum, Numerical Ruby and SciRuby were all attempts.

The fundamental issue I believe they all had is lack of community. There is a
quite large community of folks using Python for scientific computing. Many are
not professional developers but rather scientists / engineers who aren't as
open to jumping around to different languages as a developer would be.

These issues combined with the fact that Ruby is mostly pigeon-holed as a web
only language would make replicating the community that the
NumPy/SciPy/matplotlib stack enjoys almost impossible.

It also doesn't help that such capability have to be implemented as C
extensions due to performance requirements. This greatly limits the number of
developers that would/could work on such a project.

~~~
treetrouble
These kinds of projects can take years to take hold; you can't expect people
to just all switch right away. Blog posts like this just need to be commented
on with a link to those libraries. Eventually some big lecture, class or
project will use one of those libraries and a whole new group of people will
supplement the community. This doesn't just go for Ruby, it applies to any
language

Ruby performance in general is getting much better and when C extensions are
necessary (as they often are in any high level language) libraries like ruby-
ffi have taken a lot of the pain out of that process.

~~~
jerf
There's more inertia here than you may be thinking. See this recent HN
headliner about the difficulty of getting the NumPy/SciPy community to merely
move from CPython to PyPy:
[http://technicaldiscovery.blogspot.com/2011/10/thoughts-
on-p...](http://technicaldiscovery.blogspot.com/2011/10/thoughts-on-porting-
numpy-to-pypy.html)

If _that's_ a challenge, good luck getting a lot of NotProgrammers to move to
a completely different language.

Besides, if I may be blunt, who in Rubyland cares if these guys are on Python?
By and large, these people are on an island. They are optimizing for things
you pretty much don't care about, for programming styles you're not using, for
libraries you've barely heard of. Trying to entice them off of Python onto
Ruby is a waste of time for everybody. The Ruby community would at best get
nothing, at worst net pain of supporting a lot of newbies, and the scientists
would incur the horrifying overhead of a language shift for the closest thing
to a sidegrade available in the set of the top 20-ish language. If they were
going to do that they probably shouldn't be going for Ruby, they should
probably be going for Haskell or OCaml, both languages for which I could
outline actual advantages to the scientists for the pain of the switch (though
probably not enough to justify the switch).

~~~
treetrouble
You make good points, they're not blunt. I've just read the same basic blog
post many times complaining that there's no SciPy in Ruby. Again, I'm not in
the sciences so I'm out of my element talking about it. I'm just trying to
make the simple point that there does seem to be people out there wanting
science libraries for Ruby

------
phzbOx
<http://sciruby.com> :D

~~~
wedesoft
I don't know whether that qualifies as number crunching, but I am using Ruby
for computer vision.

<http://www.wedesoft.demon.co.uk/hornetseye-api/>

------
phzbOx
tldr: He wants a couple science python library and 'doesn't feel like porting
them in ruby' (to take his wording).

