From Python to Ruby: Taking a Step Backward(gist.github.com)
gist.github.com
From Python to Ruby: Taking a Step Backward
https://gist.github.com/4242213
14 comments
> Ruby feels like a “more than one way” type of language more closely related to Perl.
Gem issues aside, which Perl doesn't tend to have because CPAN is so rock solid, that was exactly the reason I didn't continue with Ruby when I checked it out, somewhat in depth, a few years ago: Ruby is Perl with OO done right, which is nice, but if you use Perl professionally, Ruby will not provide you with an alternative way of thinking the way Python does.
Gem issues aside, which Perl doesn't tend to have because CPAN is so rock solid, that was exactly the reason I didn't continue with Ruby when I checked it out, somewhat in depth, a few years ago: Ruby is Perl with OO done right, which is nice, but if you use Perl professionally, Ruby will not provide you with an alternative way of thinking the way Python does.
> My assumption is that devs in Python try to stick to the Pythonic way of doing things across modules, which helps maintain interoperability.
Yep. And that's also what I tried to do when I first started with Ruby, until another commenter explained to me that Ruby is different.
We were discussing the syntax of RSpec, and I was griping that RSpec was so linguistically different. Commenter explained that RSpec is very clear that it wants to have a different flow than pure Ruby because RSpec looks like a set of user stories. That means I'm going to have a hell of a time trying to stick RSpec into another use case, but I can't argue that the rationale for RSpec's DSL makes sense.
Yep. And that's also what I tried to do when I first started with Ruby, until another commenter explained to me that Ruby is different.
We were discussing the syntax of RSpec, and I was griping that RSpec was so linguistically different. Commenter explained that RSpec is very clear that it wants to have a different flow than pure Ruby because RSpec looks like a set of user stories. That means I'm going to have a hell of a time trying to stick RSpec into another use case, but I can't argue that the rationale for RSpec's DSL makes sense.
> Ruby feels like a “more than one way” type of language more closely related to Perl
Which is somewhat ironic, given that Perl has one distinct CPAN, and the CPAN tools are so utterly solid.
Which is somewhat ironic, given that Perl has one distinct CPAN, and the CPAN tools are so utterly solid.
I had the same experience as you and OP, doing an RoR implementation from the operations end was a tangled mess of gems with various mangled dependencies onto one another, with those dependencies being to certain badly documented or undocumented version numbers.
Also, when I did this implementation several years ago, the core RoR and gems documentation web pages were a mish-mash of broken links.
These problems drew me to reading the blog postings of the mongrel gem creator, to try to figure out how to get mongrel interacting with the other gems properly. The blog did not exactly inspire my confidence in the software.
In fact, the project went over budget and over deadline. It is the project which went most off the rails, so to speak, in my 2+ years at that company - even more than the attempt to implement Sharepoint. The outside developers thought they would "save time" by doing it all in RoR, but they failed to deliver a production ready system. I know that Twitter made a great effort to pull itself off its initial RoR base, and that it is widely said that RoR is not scalable. It is possible it will straighten out over time, I remember back when Java application servers were slow resource hogs with poor frameworks. My initial experience with RoR has left a sour taste in my mouth. Maybe the operations background of this person has significance - it may look OK from the developer standpoint, but the production operations end needs a lot of work.
Also, when I did this implementation several years ago, the core RoR and gems documentation web pages were a mish-mash of broken links.
These problems drew me to reading the blog postings of the mongrel gem creator, to try to figure out how to get mongrel interacting with the other gems properly. The blog did not exactly inspire my confidence in the software.
In fact, the project went over budget and over deadline. It is the project which went most off the rails, so to speak, in my 2+ years at that company - even more than the attempt to implement Sharepoint. The outside developers thought they would "save time" by doing it all in RoR, but they failed to deliver a production ready system. I know that Twitter made a great effort to pull itself off its initial RoR base, and that it is widely said that RoR is not scalable. It is possible it will straighten out over time, I remember back when Java application servers were slow resource hogs with poor frameworks. My initial experience with RoR has left a sour taste in my mouth. Maybe the operations background of this person has significance - it may look OK from the developer standpoint, but the production operations end needs a lot of work.
> If I want to make a complex application run, chances are I'll need five gems to do it... and versioning is extremely important. I was following an application template that clearly spelled out all the gems and versions I would need to build it, but hit my first snarl when one gem wasn't quite prepared for Ubuntu 12.04...
Five gems? I haven't seen very many production Rails applications that can do with just five gems. More gems is mostly a good thing - each does just one thing, and does it well. It is like having more smaller methods instead of a few large methods.
> Are these gem heartburns a common problem in Ruby/Rails or is this mostly due to my ineptitude with the language?
Yes, gem heartburns can happen, but they are not very frequent. I'm sure the author will find that Bundler makes versioning an almost solved problem as he understands the language and ecosystem better. Good luck!
Five gems? I haven't seen very many production Rails applications that can do with just five gems. More gems is mostly a good thing - each does just one thing, and does it well. It is like having more smaller methods instead of a few large methods.
> Are these gem heartburns a common problem in Ruby/Rails or is this mostly due to my ineptitude with the language?
Yes, gem heartburns can happen, but they are not very frequent. I'm sure the author will find that Bundler makes versioning an almost solved problem as he understands the language and ecosystem better. Good luck!
I think the "understands the language and ecosystem better" is critical, but my expectation is that I need to learn a subset of key gems better more than anything else.
Every hardcore Ruby-ist that I've known has owned a Mac as their primary dev machine. I'm sure that there are plenty of Linux devs out there, but my experience has been that it's heavily Mac-driven. However, by sticking with Linux as my development platform, I'm probably going to learn the guts of gems because I have to get under the hood to make them work on Linux.
Maybe I'll continue to have gem conflicts, but that's okay - I'll know how to hack around them.
Every hardcore Ruby-ist that I've known has owned a Mac as their primary dev machine. I'm sure that there are plenty of Linux devs out there, but my experience has been that it's heavily Mac-driven. However, by sticking with Linux as my development platform, I'm probably going to learn the guts of gems because I have to get under the hood to make them work on Linux.
Maybe I'll continue to have gem conflicts, but that's okay - I'll know how to hack around them.
You shouldn't hit any issues with gems and linux -- most production Ruby systems use linux.
While many Rubyists may use a Mac I'm confident the large majority deploy those applications on Linux. Cross OS compatibility issues are virtually non-existent, especially on non-development focused gems.
[deleted]
I've been developing on Linux since I started. If someone makes a gem that you can't install because you're using Linux, you probably don't need that gem :).
You will not run into this problem. Linux is almost always used for production servers and is popular for development as well.
why so? Mac is a lot like Linux. I've been having little problems with the vast majority of mature gems even on Windows (especially with ruby devkit around, which automagically temporarily puts a GNU environment in my path to build gems that contain c/c++ code, none of which you'll need to worry about on Linux)
No, I agree with the OP. If you want to install some interesting Ruby app or library you quickly find yourself installing all sorts of interdependent gems to get it to work. This is, of course, a matter of YMMV, but I can see where he's coming from.
And with Python, BTW, it's a lot easier, probably because of all the batteries that are included.
And with Python, BTW, it's a lot easier, probably because of all the batteries that are included.
Yes and no. A non trivial project will need multiple interdependent gems. But installing them simply is a matter of running 'bundle'.
On the flip side, just googling around for how to get python modules (eggs?) installed was a maddening experience. About 6 different ways to do it, and the documentation was a bit unclear on all of them.
I just install Ruby from rvm (or rbenv), git clone an app and type 'bundle install' and then its all working.
I just install Ruby from rvm (or rbenv), git clone an app and type 'bundle install' and then its all working.
This is simply an effect of you having full knowledge of Ruby development management, but not python's. In fact, they are quite similar to eachother.
A pythonist would just say:
"I just install a python environment from virtualenv, git clone an app and type 'pip install -r requirements.txt' and then its all working."
virtualenv ~= rbenv, and pip ~= bundler.
Either set of the two make it easy to install appropriate packages for separate projects.
Now maybe the googleability of this knowledge isn't as great as it could be, but ask any good pythonista and they'll set you on the right track.
A pythonist would just say:
"I just install a python environment from virtualenv, git clone an app and type 'pip install -r requirements.txt' and then its all working."
virtualenv ~= rbenv, and pip ~= bundler.
Either set of the two make it easy to install appropriate packages for separate projects.
Now maybe the googleability of this knowledge isn't as great as it could be, but ask any good pythonista and they'll set you on the right track.
Thanks! The issue right now really is the Googlability.
I just searched for "Installing python modules" and of the top 5-6 hits (listed below) none of them mentioned the advice you just gave. The Python 2.7 docs don't mention it at all under their installing modules page. Everything's about RPM and Distutils.
http://docs.python.org/2/install/index.html
http://docs.python.org/release/2.2p1/inst/inst.html
http://stackoverflow.com/questions/739993/get-a-list-of-inst...
https://my.bluehost.com/cgi/help/530
http://stackoverflow.com/questions/9714635/how-to-install-py...
http://discuss.joyent.com/viewtopic.php?id=25044
On the flip side, 'installing ruby gems' does tell you about the gem application, but doesn't mention bundler in the top 5 results.
I just searched for "Installing python modules" and of the top 5-6 hits (listed below) none of them mentioned the advice you just gave. The Python 2.7 docs don't mention it at all under their installing modules page. Everything's about RPM and Distutils.
http://docs.python.org/2/install/index.html
http://docs.python.org/release/2.2p1/inst/inst.html
http://stackoverflow.com/questions/739993/get-a-list-of-inst...
https://my.bluehost.com/cgi/help/530
http://stackoverflow.com/questions/9714635/how-to-install-py...
http://discuss.joyent.com/viewtopic.php?id=25044
On the flip side, 'installing ruby gems' does tell you about the gem application, but doesn't mention bundler in the top 5 results.
90 percent of the time the answer is pip.
Things can get trickier on Windows if there are compiled dependencies. You'd better hope there's a precompiled binary for you in that case.
Things can get trickier on Windows if there are compiled dependencies. You'd better hope there's a precompiled binary for you in that case.
Please don't make this another 'ruby is better' thing, OK?
Just use 'pip install' and forget the rest, this is overwhelmingly the most common advice. If you don't follow this advice and you still complain about installing Python packages, you are inflicting that damage on yourself voluntarily.
Most things you need to use on Windows have exe/msi installers, if you cannot get pip working on Windows (it's not rocket science though)
Just use 'pip install' and forget the rest, this is overwhelmingly the most common advice. If you don't follow this advice and you still complain about installing Python packages, you are inflicting that damage on yourself voluntarily.
Most things you need to use on Windows have exe/msi installers, if you cannot get pip working on Windows (it's not rocket science though)
You claim to have worked with Python for some time, yet you don't seem to recognize the parallel between installing several gems and installing several packages. Sometimes you come across a package which doesn't work with some specific OS, that's not the language but the package.
You have misread the essay. The author wrote:
Ruby makes heavy use of gems, which appear to be like more complex Python libraries. I say "more complex" because they appear to bolt onto each other far more heavily than Python libraries. If I want to make a complex application run, chances are I'll need five gems to do it... and versioning is extremely important.
The point is that the interconnections between Ruby gems appears to be much stronger than between Python libraries, and I interpret the above to mean that version mismatches occur noticeably more frequently in Ruby than in Python.
Ruby makes heavy use of gems, which appear to be like more complex Python libraries. I say "more complex" because they appear to bolt onto each other far more heavily than Python libraries. If I want to make a complex application run, chances are I'll need five gems to do it... and versioning is extremely important.
The point is that the interconnections between Ruby gems appears to be much stronger than between Python libraries, and I interpret the above to mean that version mismatches occur noticeably more frequently in Ruby than in Python.
Third-party Python packages depend on each other all the time, and (once again) breakage is a problem with the packages as they are produced, not with the language itself... on Python as on Ruby
Everyone is in complete agreement with this statement. It's also not the point. The author was observing/positing a
greater degree of version inter-dependency in Ruby gems, not that Ruby gems are inter-dependent and Python packages aren't.
Nor is the discussion regarding the languages only. It is about the additional set of tools that one uses in order to build a web application in those respective language. Consider the phrases "and its associated frameworks" and "similarities between Rails and Django given the structural similarities between Ruby and Python" as clues that this is not about the languages per se. Or from the previously written essay, "the construction of a Ruby on Rails app ... that makes use of Devise for user authentication, RSpec for unit testing and Cucumber for behavior testing."
The author therefore quite clearly "recognize[s] the parallel between installing several gems and installing several packages" and is instead focusing on a specific aspect of that parallelism; inter-depenency.
Nor is the discussion regarding the languages only. It is about the additional set of tools that one uses in order to build a web application in those respective language. Consider the phrases "and its associated frameworks" and "similarities between Rails and Django given the structural similarities between Ruby and Python" as clues that this is not about the languages per se. Or from the previously written essay, "the construction of a Ruby on Rails app ... that makes use of Devise for user authentication, RSpec for unit testing and Cucumber for behavior testing."
The author therefore quite clearly "recognize[s] the parallel between installing several gems and installing several packages" and is instead focusing on a specific aspect of that parallelism; inter-depenency.
Seems more like an attempt to get help, rather than a serious post - although I agree that ruby gems are not as easy to handle as python packages.
It is an attempt to get help, but not in the sense that you're thinking.
Writing helps me solidify what I'm learning as I go, because I have to formalize and explain what I'm experiencing. When I wrote my first gist-post, I was simply trying to capture my own thoughts so I could move on to the next learning experience.
However, I discovered a side benefit: Ruby-ists cannot resist commenting on Ruby posts. The comments, even if critical of me or my approach, have been HUGE in helping me understand what I'm experiencing at a different level. That alone is enough for me to want to post more.
Writing helps me solidify what I'm learning as I go, because I have to formalize and explain what I'm experiencing. When I wrote my first gist-post, I was simply trying to capture my own thoughts so I could move on to the next learning experience.
However, I discovered a side benefit: Ruby-ists cannot resist commenting on Ruby posts. The comments, even if critical of me or my approach, have been HUGE in helping me understand what I'm experiencing at a different level. That alone is enough for me to want to post more.
I don't think it's specific to Ruby-ists. Hackers in general cannot resist commenting when you criticize something that they've devoted time and energy to, and found to be cool. I think this is a good thing.
Actually, I've tried to stir the comment pot on Python posts and have not received near the same feedback. Now, that could easily just be indicative of the languages of choice among Hacker News commenters.
Most rails apps are deployed on linux. I doubt there are any popular gems that depend on OS X. The problem might be with gems' dependencies, but that's a problem with linux, not ruby.
I love both Django and Rails. I like the language of Python more than Ruby, but I like the Rails framework more than Django.
"How can I show you Zen unless you first empty your cup."
If you want to feel better about your python roots and ruby is still not there yet here is the link
http://hammerprinciple.com/therighttool/items/python/ruby
I like ruby and ruby on rails. is it perfect? no, it is evolving constantly .
Anybody can build and release a gem, if people love it it gets adopted more and more, rubygems, rack, bundler, rvm, all came from the community.
So the gem which caused all trouble for you, somebody wrote for solving his itch, released it thinking somebody may use it as well, will it be used by everybody maybe he did not care about, so wrote just enough code to get his thing done, if another ruby programmer finds it interesting uses it, if he finds bugs posts tickets or better fork on github submit a pull request.
Thats the ruby community I know of.
If you want to feel better about your python roots and ruby is still not there yet here is the link
http://hammerprinciple.com/therighttool/items/python/ruby
I like ruby and ruby on rails. is it perfect? no, it is evolving constantly .
Anybody can build and release a gem, if people love it it gets adopted more and more, rubygems, rack, bundler, rvm, all came from the community.
So the gem which caused all trouble for you, somebody wrote for solving his itch, released it thinking somebody may use it as well, will it be used by everybody maybe he did not care about, so wrote just enough code to get his thing done, if another ruby programmer finds it interesting uses it, if he finds bugs posts tickets or better fork on github submit a pull request.
Thats the ruby community I know of.
I would like to know why people compare Python and Ruby by default. There are far more differences than similarities.
True, but they aren't readily apparent to someone who isn't digging through the weeds of both languages.
I looked at 'Hello world!' and FizzBuzz written in both Python and Ruby, and thought that the implementations looked fairly comparable. I haven't seen enough to convince me that Ruby is vastly different - not to say that it won't happen, but I haven't experienced it yet. I think that's why the gut reaction is to think of Ruby and Python as parallel languages.
I looked at 'Hello world!' and FizzBuzz written in both Python and Ruby, and thought that the implementations looked fairly comparable. I haven't seen enough to convince me that Ruby is vastly different - not to say that it won't happen, but I haven't experienced it yet. I think that's why the gut reaction is to think of Ruby and Python as parallel languages.
The comparison seems natural to me. They're both targeting the "trade performance for developer productivity" niche. Regardless of how different they might be in execution, their intended purposes have much more in common with each other than with C, Java, Fortran, or Haskell, to name a few.
> Ruby has no Benevolent Dictator for Life like Guido van Rossum ...
Matz? Or is his role just more informal compared to Guido?
Matz? Or is his role just more informal compared to Guido?
I actually remarked on this on a thread this week:
http://news.ycombinator.com/item?id=4888768
I said it was funny that Matz was the only modern language creator not listed in the BDFL Wikipedia entry...but someone went in and changed that shortly after...
Matz is involved with design decisions but is maybe less demanding, given the number of implementations that compete with MRI?
I said it was funny that Matz was the only modern language creator not listed in the BDFL Wikipedia entry...but someone went in and changed that shortly after...
Matz is involved with design decisions but is maybe less demanding, given the number of implementations that compete with MRI?
Interesting. Given a community, how does the naming of a BDFL come about?
If the original author, say Mr. Hansson, is not interested in taking this task upon himself, can the community elect another individual...especially if some aspect of order needs to be brought about?
If the original author, say Mr. Hansson, is not interested in taking this task upon himself, can the community elect another individual...especially if some aspect of order needs to be brought about?
having worked with ruby & rails both for about 7 years, i've run into my fair share of gem hairballs.
in general, i've had _more_ problems on osx than on linux, mostly due to various ARCH flags required by c extensions.
that being said, the "system rubies" on every linux distro i've used are generally infinitely horrible, and this is likely the case for the poster. system packaged gems are also insanely gross as well.
one of ruby's saving graces is that at least it's not used by the base system for initialization, which has bit me more than once installing a python that conflicted with the system python (though that was many years ago, things may have improved).
rvm has its own issues (and seems to be getting more complex with every rev), but in general, makes for clean living. bundler is nice too.
in general, i've had _more_ problems on osx than on linux, mostly due to various ARCH flags required by c extensions.
that being said, the "system rubies" on every linux distro i've used are generally infinitely horrible, and this is likely the case for the poster. system packaged gems are also insanely gross as well.
one of ruby's saving graces is that at least it's not used by the base system for initialization, which has bit me more than once installing a python that conflicted with the system python (though that was many years ago, things may have improved).
rvm has its own issues (and seems to be getting more complex with every rev), but in general, makes for clean living. bundler is nice too.
I had not really thought about why Python development generally expected a virtualenv until now. If you haven't been in the Python world at all, virtualenv essentially sets up a miniature development environment within your working folder. System Python might be version 2.7.3, but inside my virtual environment I can run Python 3.0. It's a nice little hack around the problem of multiple Python versions... doesn't solve the root cause, but at least you can stitch it up with one step.
> I thought that there would be a fair amount of similarities between Rails and Django given the structural similarities between Ruby and Python. I could not have been more wrong.
Duh? This is just a silly rant that isn't about anything in particular.
Duh? This is just a silly rant that isn't about anything in particular.
Python package management comes down to pip install.
The packages with C bindings I always run into are Postgres and MySQL libraries. On Ubuntu this is easy. On OS X it is a bit of a pain.
That's really about the extent of the pain.
The packages with C bindings I always run into are Postgres and MySQL libraries. On Ubuntu this is easy. On OS X it is a bit of a pain.
That's really about the extent of the pain.
Ruby package management comes down to bundle install.
The packages with C bindings I always run into are Oracle and MySQL libraries. On OS X this is easy. On Ubuntu it is a bit of a pain.
That's really about the extent of the pain.
The packages with C bindings I always run into are Oracle and MySQL libraries. On OS X this is easy. On Ubuntu it is a bit of a pain.
That's really about the extent of the pain.
no error message ....
how to help you ???
doctor doctor my body is hurting! doctor:"where?" i just told you MY BODY doctor:"-_-"
how to help you ???
doctor doctor my body is hurting! doctor:"where?" i just told you MY BODY doctor:"-_-"
I have an operations background so I’m used to supporting these apps rather than writing them but I’ve had a lot more trouble in the package management department with Ruby than Python.
My assumption is that devs in Python try to stick to the Pythonic way of doing things across modules, which helps maintain interoperability. Ruby feels like a “more than one way” type of language more closely related to Perl.