I say this as a happy Python user. Ruby seems very similar but I'm reminded of a pg essay on language power: looking up the power curve, you see '$Language plus a bit of weird stuff that is probably irrelevant.' So I don't trust myself.
As someone who loves Python and doesn't know any Ruby beyond a few bits of syntax and the obvious bits that are common to most languages, what am I missing?
So I started Googling for Python vs Ruby. After checking some language basics tutorials, I decided that really, for my purposes they were about equivalent in power (didn't know much about library support yet).
The one thing that pushed me towards Python was that most articles I could find comparing Ruby and Python were written by a happy user of one of these languages. However, all Python users wrote something like "I guess you can do everything in either of them, it's just a matter of preference and I happen to have picked Python", while the Ruby users tended to be somewhat more flaming and arrogant about it, especially in the comments sections.
In the end I went with Python because the community seemed more friendly. However, I stayed for the library support. Especially after that one time I installed pyTwitter and I could just do `import twitter`, I was pretty impressed by that (I assume Ruby has an excellent Twitter lib too, btw).
Also, just a little disclaimer: This was a couple of years back (I forget how many, 5 or so) maybe the Ruby community changed, and it's also totally possible that I just happened to land on a rather "particular" region of the Ruby blogosphere, so take this cum grano salis. I had to make a choice and was about this close to just flipping a coin over it :)
ruby-talk used to have, as one of a number of perma-threads, the question of "Why Ruby over Python". The discussion was almost always entirely civil, with most people suggesting that the questioner try both for a bit and pick the one that clicked best.
I used to host (on ruby-doc.org) a page called "Ruby Eye for the Python Guy" that tried to summarise the comments and offer links to help folks make a decision.
The community on ruby-talk at that time (probably 5 years ago) was extremely polite and helpful, and I'm sorry you landed on some opinionated blog that likely only reflected a small group of developers.
I don't follow ruby-talk much any more, so I can't say how it is, but there has always been a pretty strong tradition of MINSWAN: "matz is nice so we are nice." I expect that's still encouraged. There are, of course, various sub-groups around this or that library or framework that may have zero exposure to that, think they're the shit, etc., but I hope people considering Ruby don't a priori dismiss the majority of Rubyists as rude because of bad reports about a handful of people.
OK, end of Ruby PSA.
Side note: I'm often puzzled by people who think a language or framework or whatever geek thing has to "win." Be happy for happy people.
Idol? He's a nice guy who does admirable work and many people think it ungracious to be rude when publicly discussing his language.
Only reason? Geeks get into stupid pissing matches. Sometimes a little reminder is a good thing, that's all.
For example, there really is no Ruby equivalent to SciPy, NumPy, Matplotlib or NLTK (http://news.ycombinator.com/item?id=3179370). However, there has been some effort in the Ruby community to begin the process of developing some of these libraries (see SciRuby http://news.ycombinator.com/item?id=3180369). but the Python libraries have been in development for years so this will be no easy feat.
Isn't that rather an argument for Java or Perl?
What I don't get is the cheerleading for Python? Ruby has/had something similar going with Rails. I mean, the article even notes that it is a middle of the road choice, optimised to not be extreme.
I'm sure there are probably tons of nice alternatives to Python for this kind of work, and there are tasks that other people need to do for which trying to use Python and some readily-available libs just wouldn't be sufficient. I only suggest Python to people whom I know are doing work where it would be helpful; there's no point in pushing it as a one-size-fits-all solution.
No, because then you'd have to stand either Java or Perl. If you are looking for a language to learn beyond a quick hack, then the language matters more than its libraries. I know Perl, and everybody knows what a boon CPAN is, but still for scripting tasks I have switched to Python. It would have made me feel sick to keep programming in Perl.
As I had to choose between Python and Ruby too, besides the library thing, I picked Python because Ruby seemed like it was trying too hard to be powerful and expressive, to the detriment of clarity. I didn't want to invest too much time in learning a scripting language. It's just for scripting, you know, it's not meant to accomplish much. If I need a powerful and expressive language, then I just reach for the big guns.
Or JRuby.
if result =~ /regex/
that kind of thing is awesome for readability, but it can also be pretty darn slow.
There's also some interesting things about the ruby object model and interpreter that are different from python's approach. Whereas in the python REPL you type help(object) to get the docs on that object, in ruby you type object.methods or object.public_methods, etc. It's less documentation oriented, and more code-exploration oriented, but the two end up delivering the same sort of information.
Hope that's helpful! Ruby's a lot of fun to tool around with, and there are (in my opinion) fewer things about it to trip you up completely than there are when first learning python. But once you use it for a while and get beyond the basics, it becomes clear that there's a lot of unfocused cruft foating about, which fits no rhyme nor reason. Much more than Python has.
(cautionary note: I'm not an expert with either language)
case object
when matcher1; ...
when matcher2; ...
end
case name
when "John Smith"; puts "hello again"
when / Smith$/; puts "are you related to john?"
end
http://en.wikipedia.org/wiki/Ipython (Sadly the homepage doesn't quite get the simpler sell points across as well. http://ipython.org/)
Also, Ruby programmers talk about how readable Ruby is, but I disagree. The lack of consistency between using parenthesis or not, how to separate arguments, or even string formating syntax makes reading Ruby code wrote by someone else much more prone to "WTF" moments than Python.
FWIW though, I get serious library envy, especially with regard to NLTK. Ruby has web development cornered but is decades behind python when it comes to anything around machine learning and scientific computing.
The irony of this is that many folks in the Python scientific computing space pine for better syntax extension facilities so that they could do more "natural" DSLs for data analysis and embedding math inside Python code.
The object lesson here is that communities and passionate users matter. Python took root in some scientific computing environments and certain dedicated individuals built up a software library and invested in growing a community that is now a force to be reckoned with. If the same people had all chosen Ruby and built a community around that, there is no obvious reason why Ruby shouldn't be the one with the great scientific libraries.
The main upside of Ruby is blocks, however limited (compared to Smalltalk's) the ability to craft your own control structures is incredibly powerful and empowering (and you can't really do that in Python, you can abuse decorators for it nowadays but it's not exactly sexy or readable, or generally a good idea)
Ruby also makes metaprogramming easier and more common, though the jury's still out on whether it's a good thing or not.
JRuby is clearly more advanced that Jython. I'm guessing that with the advance of PyPy, other Python interpreters just aren't getting that much attention, which is a bit unfortunate.
They're not comparable, so no.
> I think JRuby is more mature than jpython
Pretty different situations, from 2006 to 2009 two lead JRuby developers were hired specifically for that by Sun (later left for EngineYard) and a third was hired by ThoughtWorks for the same.
For Jython this only happened in 2008, after the project had pretty much gone on freeze due to the original founder leaving to work on the Pypy project.
Compare IronPython to IronRuby instead, and the situation is reversed. Same if you compare Rubinius and Pypy.
> and I know this will start the flames, but I think ruby is clearly better for web stuff
That's your personal judgement, I don't agree.
Second, who cares why JRuby is more mature, it is.
No (and screw you for your unwarranted downvote you ass)
> Python 3 is causing serious pain, does django work with it yet?
I did not deny that, I denied your equation of Python 3 with Ruby 1.9 when they have absolutely nothing in common and had very different goals.
> Second, who cares why JRuby is more mature, it is.
That's not the issue with your question, the issue is that you cherrypick a single alternative implementation which supports whatever claim you're trying to make and ignore all others. That makes your claim both dishonest and irrelevant.
IronPython is more mature than IronRuby, Pypy is more mature than Rubinius, by your comment that makes 2 for 1 therefore Python is superior to Ruby right? That's nonsense, because your original assertion is nonsense.
But hey, at the end of the day I couldn't expect much more from somebody who decided to turn a discussion on relative merits into a dick-size contest. I guess the western ruby community has not matured as much as I thought it did. Thanks for bringing me back to reality.
I think the JVM is the more significant platform compared to the clr and rubinius/pypy. Therefore I think it's maturity is more significant.
Yours is by far the least pleasant and counterproductive thread on this entire discussion
Ruby/Rails seems easier to develop and test the full stack application, from client JavaScript to server Ruby response and back. It supports Ajax through injection of injection of JavaScript into HTTP responses served up, based on specifications in server side code. The test architectures seem to reach across the client/server divide, for example checking server side responses to triggering client-side JavaScript.
Python/Django are trying, with like lettuce and splinter, but these don't yet seem to be quite to the same standard.
Also, because RoR has a lead on web development, new developments in that space seem generally better integrated. For example, Backbone is a young JavaScript MVC style framework for client side development. I've just been fooling with using it with Django, and discovered that its stringification of Json objects for POST doesn't work with Django's parsing of the client request. Maybe more experienced developers spotted and fixed this easily -- my fix is only a couple of lines -- but it's the sort of thing that makes me wonder just how many folks have tried to integrate Django w/ Backbone. I'm guessing that the Backbone community has already spotted and fixed any such issues with RoR.
Now I'm not sure how I feel about RoR, it often feels like magic and I'm a little suspicious of stuff like super-convenient JavaScript injection. Maybe when I understand it better it will seems less magical and more convenient. But it isn't hard to see why the web development community likes it.
Actually, the vast majority of my rails stuff recently has been RESTish (or at least Backbone compatible) json endpoints with a CoffeeScript frontend.
The front and back end in that case are totally decoupled (though rails does do some nice things to help you organize your frontend code).
This would have been hard a few years ago but I've found that as time has wore on rails has become quite a bit more forgiving when you disagree with DHH, e.g.. you can use whatever templating language, testing framework or ORM you like, and there will be others who made the same choice you can look to for support. It's still opinionated about defaults, but you can switch out whatever libraries you like these days, for the most part.
Re: Django & Backbone, you should check out djangbone. It makes it dead simple to create a basic backbone-compatible APIs in Django, and is easy to extend if you need more advanced functionality (full disclosure- I'm its author): https://github.com/af/djangbone
-no distinction between expression and statement (everything has a value)
-lambdas can thus contain any expression
-much bigger range of built-in methods and classes (all permutations of a list, removing duplicates from a list, Rational class, Regexp class, Range class, etc.)
-more flexible syntax and "control operators" like each_with_index
-almost zero distinction between built-in classes and methods and user-written ones: you can open up Hash (dict) or Array (list) and extend it straightforwardly.
Downsides are:
-generally uglier and more ambiguous syntax
-distinction between functions and methods (b/c "all you can do is send a message") leads to a lot of unnecessary duplication of concepts
-so-called "blocks" which are really just a hack to avoid writing the word "lambda" a bunch of times (maybe if the more concise Ruby 1.9 syntax for lambdas had existed earlier blocks wouldn't have been implemented). I think they are based on the idea that most HOFs only require one functional argument, and they encourage functional programming, but they (along with the last bullet point) discourage the general case. They provide some of the functionality of macros.
-you can't define a class inside a method (still haven't quite figured out the reasoning behind this one).
In general Ruby is definitely more powerful than Python, but in its higher ambitions suffers more obviously from clashes between functional and OO programming. Python's dogmatic insistence on "readability" makes it feel like an old grandma in comparison to Ruby.
why would you want to use lambdas if you have generator expressions? eg:
map(lambda c: c.strip(), countries.split(','))
vs
[c.strip() for c in countries.split(',')]
IMHO the latter one is way more readable and generators cover almost all the use cases for lambdas. If you could not do it with a generator expression and choose to use a anonymous function it should have been a method anyway.
> -much bigger range of built-in methods and classes (all permutations of a list, removing duplicates from a list, Rational class, Regexp class, Range class, etc.)
you mean sets, dictionaries(hashtables) etc.? those are built in as well in Python.
Remove duplicates: mylist = list(set(mylist))
Range class: [i for i in range(10)]
you can import the rational class via a simple from fractions import Fraction
same for regex
> -more flexible syntax and "control operators" like each_with_index
you can iterate over dictionaries with for k,v in dict.items()
if you need the index of a list you can use for i,v in enumerate(list)
personally I don't think there is much of a difference between Python and Ruby. One is more mature the other is way hipper and it comes down personal taste which one you choose.
Lambdas (blocks) in Ruby are used for way, way more than just building or manipulating lists. For example, there is no need for the "with" keyword in Ruby, because you can just use blocks for that. As another example, you can specify a block to the Hash constructor to specify code that runs when a key is accessed that is not present.
> Range class: [i for i in range(10)]
That is not a range class, that is an expression for constructing a contiguous list of numbers. The Range class in Ruby is an actual class that you can instantiate and call methods on.
("a".."z").cover?("c") #=> true
("a".."z").cover?("5") #=> false
They have similar capabilities but make very different choices in a lot of ways.
> you can import the rational class via a simple from fractions import Fraction
Sure, you can write a library for anything and by now Python has libraries for most everything. But it still makes a difference to have things in the core language, plus a nice syntax for them.
> why would you want to use lambdas if you have generator expressions?
This is a case of making up for odd semantic choices with special syntax, which then becomes an unnecessarily fixed-in-stone part of the language. Range objects in Ruby are actually like slice objects in Python. But Ruby separates the syntax for ranges from the get-item method, since there are plenty of other places where you would want to use ranges (then you can iterate and map over them, etc.).
Ruby uses blocks to implement things like an each method that fulfills the same function as Python's for statement. (Ruby has a for statement but it is hardly ever used.) In Ruby your example would be
countries.split(',').map &:strip
which is obviously more concise and no less readable. Compare with
countries.split(',').each &:foo
where foo is some side-effectful method.
IMO such a small change in behavior should result in a similarly small change in how the program is written.
require 'set'
Set.new([1,2,3])How does this differ from list(range(10)) (besides being highly suggestive of the power of list comprehensions)?
>IMHO the latter one is way more readable and generators cover almost all the use cases for lambdas. If you could not do it with a generator expression and choose to use a anonymous function it should have been a method anyway.
This is actually why Guido van Rossum wanted to remove lambda from the core language: http://www.artima.com/weblogs/viewpost.jsp?thread=98196 (He didn't, thankfully. I still want reduce back in 3.x, though.)
I got into Ruby by pure accident (No Rails-bait). I needed a scripting language to automate some tasks and one of my friends was playing with it back then and suggested it.
Ruby's weakness (and it's strength at the same time) is that it got popularized by Rails. As a result a huge community has grown around it - but it brought a tunnel vision effect along with it. People don't recognize that there are things besides Rails and it's reflected in weak (non web-dev) library support.
I didn't like the fact that there's a big push in Ruby-land for metaprogramming / DSLs and monkey patching. Ruby's not inherently that great at it. It just happens that you can do it, but it doesn't mean you should. Which has always been in my eyes mostly a big abuse of *_eval, method_missing etc. that leads to performance issues, maintainability issues, and so on. All that just to save a few keystrokes. Couple that with the very implicit nature of Ruby then you get a disaster. How often did I want to use libraries that turned out to be monkey-patching the same built-in classes and clashing with each other, How often did I want to delve to some code base to customize something, make a fix, etc. just to find such coding practices and being unable to reason about it in a regular object oriented fashion which Ruby's foundations are built on.
The more I wanted to build serious things in Ruby the more often I would hit such problems.
This all brings a question: What would happen if Rails had disappeared the next day. What would all these people do? What could they use instead?
It was an obvious choice not to stick with Ruby because it has nothing to offer in the long term over Python. Learning python is a very good investment - I can do web programming, gui programming, scientific computing. I can use it to script blender, gimp, you name it. And unlike Ruby - I have excellent alternatives for each task.
Ruby gets a lot of things wrong, but blocks are one thing they more or less do well. Everything good that has been built from/for Ruby owes a large measure of its success to Ruby's block implementation.
Python programmers are definitely looking up the power curve at Ruby.
Except...
Every interpreter I've tried is just too slow. I recently ported over a networking library I wrote in python to ruby, and the requests per second (CPU limited in this case, since it was talking over a loopback socket -- this was just a test of how fast data could be serialized/deserialized) dropped from 7000 requests/sec in python to 120 in ruby. And that was just with standard CPython. Under PyPy, I was able to process about 20,000 requests/sec after letting the JIT warm up.
I realize it's sort of silly to choose a dynamically typed interpreted language on the grounds of performance when you're already giving up so much performance regardless, but in my mind python hits the sweet spot of "just fast enough for most things I need to do", and with all other things being roughly equal (which, in my opinion, they roughly are), being an order of a magnitude factor faster wins out.
Reverse a string in ruby: string.reverse()
Reverse a string in python: string[::-1]
''.join(reversed(string))
Nothing. Everyone jokes about turing completeness, but Ruby and Python are pretty much exactly equivalent for their users. Python's got the upper hand in some areas, Ruby in others, but you'll get it done.
If Python works for you, use it. I didn't like it, the object model/runtime never felt right[1]. Ruby's did, it's internally consistent.
[1] The classic len(str), the underscored methods, recently decorators…
Ruby/JS everything "is an object" is definitely consistent when it comes to "design principle". But somehow I just can't grok/remember/stick to my head every time I read Ruby/JS code.
I suppose as a user, I'm more concern with the readability (a.k.a coding style) more than the "everything is an object".
You aren't missing much, comparatively.