Helpful Information
 
 
Category: Ruby Programming
Ruby Or Python

I dont know if this has been posted before... but.. i wanted to know... if it is worth learning ruby or python first? i mean.. i know some pythong... and i actually never tried ruby yet.. but what are the advantages of me learning ruby?

Fine then.. i will stick with python :rolleyes:

I was waiting for this question to start a flamewar. How boring :)

Oh well, here I go: in my opinion, Python is far more useful than Ruby because it's got the libraries, it's got the large developer community, in short - it's USEFUL. The only thing Ruby is used for at the moment is Ruby on Rails.

HOWEVER - I'm not saying that Ruby is crap - far from it ( although I DO get sick of ROR fanboys ), and learning a new language is always a good thing. For that matter, I think both Ruby and Python are very similar in syntax and in design principles, and aren't terribly different at all.

--Simon

I was waiting for this question to start a flamewar. How boring :)

--SimonHehe how evil... its probably because they all know that i never tried ruby before.. or never actually seened it in action ( that i know of ) but.. thanx... my last decision was py :), although the flame war would of been good hehe

disagree. not going to start a flamewar about it but even in the core ruby libraries there's enough to make python jealous.

and there's something about being able to read and process a file in one line that's kinda cool

I'm sure you could write an entire operating system in a perl one-liner. This does not mean that it's cool ( well THAT would be, but LOC counts are not a good indicator of readability or power of language ). For that matter, I'm sure I could do the same in python, by using the ; .

So - sell Ruby. What does Ruby do better?

-Simon

So - sell Ruby. What does Ruby do better?
-Simon
thats what i want to know :)

I've been in the same position as you and I decided to learn whichever I found a good book for first. Which ended up being Python. But still, while Python has a lot of good stuff I like Ruby's syntax more, it's cleaner and more readable imho so I ended up gong back and trying to learn Ruby ...

Also I like Ruby's documentation better, even though there's less of it what there is is written in a much clearer fashion leaving for less time wasted trying to figure out how some method works.

Python's integration with GTK is in fact what drove me back to Ruby, the way Python structures this GUI code feels just plain awkward to me, the way ruby deals with it felt quite a bit more natural...

(I'm not talking about ROR, I've never used that, nor do I really intend to)

All of this is my own opinion though. But honestly I'd take a look at both and see which one you like best, they're not that hard to learn if you have a little bit of time :)

ruby? i'll sell it

Say you've got to process a file, you'd do it like this in perl (my python sucks, you don't wanna see it)

open(INFILE,"</path/to/file");
while (<INFILE>) {print $_;}
close INFILE;

or something similar.

In ruby

File("/path/to/file") {|x| puts x}

now understand that's a grossly simplified example. But note that it takes care of allocating and deallocating the filehandle for you.

Now let's try some string manipulation...

We have inline regexps, perl style, lovely, unlike ****ing with the python regexp objects.

x =~ /([a-z]+)/
print $1;

something like that. Saves a lot of time over the python version

Then there's all the lovely methods attached to objects

puts "blah".reverse
print ("2122".reverse.to_i - 100)

see that, i reversed it and then converted it to an integer, all in one statement. quick and easier to follow

The classes that come with ruby are more logical and easier to use, and they have a lot of nice functionality, and many shortcuts. An example is the Marshal class. Being a python god you'll know all about saving dictionaries to file, i presume. Well the marshal class saves any object in a marshalled form that you can get easy access to. Imagine sending it over the net and being able to take it apart again nicely :) Well it's a good example

require 'Marshal'
marshalledhash = Marshal(myhash)

now, we could have passed in a second parameter, filename, which would save us writing this to file, since that's one of the common things you want to do with marshalled objects. Every core class is like this, and other classes try to be like this. An example is ruby-gnome2, which is ridiculously easy to use. Cool, I swear.

Ruby also excels when it comes to hashes (dictionaries) and lists (arrays).

Try this for size

{x=>5,y=>8,z=>9}.each {|x,y| print "#{x} = #{y}"}

that #{} business was interpolation, btw, interpolating the variables into the string.

other methods on hashes include the standard python kit i suppose, keys, values, etc.

what python doesn't allow you to do is construct a simple loop like that with a passed in lamda (the block in brackets is a lambda function, called a block that is activated within the class in a special way). python's lambdas really suck ***, only allowed to be one statement and all... Try this for size

myarray.each do |x|
x.chop!
print x[4]
end

That was two statements, counting as a block too, and i could have done more. And you'll also notice i used array notation on a string. that gets the character at that position, like you'd use on a python list to get a member. you can also use the python syntax to get a subset of the results

x[1...3]

x[-3...-1]

etc.

there are just so many neat things built in, y'know...

creating your own functions that accept blocks is easy too

def myfunc (x,y)
yield #This is what calls the optional lambda block there.
end

if it suits you, you CAN also pass a lambda directly as an argument if that's what the function expects

myfunc(x, lambda {|x| puts x})

but seriously, me talking about it won't do a thing to convince you, you've gotta try it to know.

File("/path/to/file") {|x| puts x}

now understand that's a grossly simplified example. Yes it is lol :)

You may want to consider that python (by design) does not provide protected/private data members - ruby does.
And since it has been mentioned, if you are familiar at all with perl, the transition to ruby may be easier on you: Ruby supports the $_ and such global variables used in mostly the same way (although it is depreciated).

Both ruby and python are capable of / do mostly the same things and have similar (not very similar) ideas. They are both fully object oriented. They both provide internal unit testing. They both present a much cleaner approach to learing a programming language (as compared to something like C).

Ruby has a more flexible syntax. Python has a larger user/support base, but ruby is growing steadily. For current web development, ruby might do you better.

As far as performance, they are about equal and each have internal packages/libraries for testing and monitoring this performance.

Learning each will not make you more qualified at anything per se, as you will still need to use your brain to figure out the problems before implementing the solution. ;)

My suggestion is to try both, see what fits you best and learn that fully. Do not, however, disregard the other as it is always helpful to have another card up your sleave.

Here is a comparison of LinuxPenguins examples and the Python equivalent.



File("/path/to/file") {|x| puts x}


for x in open("/path/to/file"): print x



x =~ /([a-z]+)/
print $1;


import re
match = re.search("([a-z]+)")
print match.group(1)

This is a little more verbose since Python does not have the perl-style $ variables that are set as a side effect of certain operations. However I have read that these are now regarded as bad style in the Ruby community and may be removed in Ruby 2.0.



puts "blah".reverse
print ("2122".reverse.to_i - 100)


print int("2122".reverse())



require 'Marshal'
marshalledhash = Marshal(myhash)

The pickle module does the same thing:

import pickle
# save object to a file
pickle.dump(object, filename)
# create a pickled object in a string
pickledObj = pickle.dumps(object)

Pickle will work with pretty much any type of Python object, just like Marshal.



{x=>5,y=>8,z=>9}.each {|x,y| print "#{x} = #{y}"}


for (x,y) in {'x':5, 'y':8, 'z':9}.items(): print '%s = %s' % (x, y)



myarray.each do |x|
x.chop!
print x[4]
end


for x in myarray:
x = x.rstrip()
print x[4]
[/QUOTE]





def myfunc (x,y)
yield #This is what calls the optional lambda block there.
end


Python generators provide roughly similar functionality, but in a different way. Generators yield a sequence of values that can be passed to a block of code in a for loop. Generators are currently less powerful that ruby blocks since the information can only go from the generator to the block, and not back the other way. This will be fixed in the next version of Python.


Dave

ruby beats python on iterating though each character in a string, i don't think python has a really simple way of doing that.

ruby: "blah".each_char {|ch| puts ch.ljust(500)}

The classes in python don't have protected and private members in python either, which is a pain, and your use of the pickle class shows that it isn't quite as simple as the ruby one, where you get an optional parameter for filename. If it's provided, it writes to file, if not it returns a string, but in yours, you have to use another function.

Don't get me wrong, python's an alright language, and the if-name-main trick looks like crap in ruby, but i prefer ruby overall

Ruby has a few nice Perl-like tricks! On the other hand, Python was written to get away from the complexity of Perl.

Well I'm a perl lover, so that might be why i like ruby some ;)

i think a hybrid of the two languages is called for. overall i prefer ruby, but there are some things that just look nicer in python

ruby beats python on iterating though each character in a string, i don't think python has a really simple way of doing that.

ruby: "blah".each_char {|ch| puts ch.ljust(500)}

The classes in python don't have protected and private members in python either, which is a pain, and your use of the pickle class shows that it isn't quite as simple as the ruby one, where you get an optional parameter for filename. If it's provided, it writes to file, if not it returns a string, but in yours, you have to use another function.

Don't get me wrong, python's an alright language, and the if-name-main trick looks like crap in ruby, but i prefer ruby overall


for ch in "blah": print ch.ljust(500)

Arguably cleaner than in Ruby. I'll reply to the main thread once I've had dinner :).

Mark.

Ruby seems nice but does it really offer anything substantial that Python doesn't?

LinuxPenguin's examples* are all possible in Python (sometimes clearer) and all of the Python examples are all possible in Ruby (also sometimes cleaner). If it came down to a syntax issue then you'd just pick the one that suited your eyes and be done with it.

I'm not an expert in Ruby, in fact I'm pretty new to it however I do know Python intimately – we dated for a long time :).

Over the past three years though I must have looked at Ruby five or more times, thought that's not Pythonic and walked off. In hindsight that was a bad choice IMO because since straying from the Python path I've noticed a lot of apparent deficiencies. Don't hang me for this, it's just my opinion ;).

It's a bad idea to compare languages form the inside because you have to [try] deal with your own bias/opinions.

They're both powerful languages however where Python has had to change a lot over the years Ruby seems to have started out in the "right" direction.

There are no hacked on meta-classes for instance, Ruby started out with full and planned support for OO. Python has steadily been appended on that front and it shows when you compare the two.

Blocks are obviously a powerful feature and they allow things that you simply can't handle elegantly in Python. Closures etc.

Pythons lambda is a travesty to any Lisp user, it's almost useless in comparison to that of other languages and should probably never have been hacked on. The problem is that there was a desire for it.

Python also originally had a very strange and limited scope. Nested/Lexical scope was added in Python-2.1 as part of __future__ but Python still doesn't seem to fully support things like Lexical scoping and or closures :(.

It can be argued that they aren't needed because objects serve a similar purpose however they can be very useful and would provide Python users with a way of safely encapsulating data. Something not possible under Pythons current object system.

Closures also tend to be more flexible, binding data to an action rather than binding actions to data. You could consider them anti-objects ;).

Ruby also seems to have a cleaner concept for functions. In Python they're just classes that overload x y and z in standard Python notation. In Ruby they're methods, with all that that implies. I think this elegance on it's own should be enough to make any hacker smile :).

Ruby's syntax is terser, and maybe way too terse for the average pythonista however some features it makes available are well worthy of envy – it's my unsupported theory that list comprehension's were added into Python as a response to Ruby's more flexible block forms.

On the other hand to Ruby users may well see Pythons forced program flow as unbearable. It's nice at first because you're almost guaranteed that code will be well formed but this quickly becomes a smack in the face of elegance.

It's snakes and ladders people, neither language has really nailed it down yet but I think Ruby comes a lot closer to a coherent whole... even with all those `end' statements which aren't exactly pretty.

When it comes down to it there isn't much between the too, probably why people are having such a hard time choosing between but what is remarkable is the speed at which the Ruby world has exploded.

Two years ago Ruby was nothing but a distant echo. Sales of Ruby books recently surpassed sales of Python books, and not by any small order. Think rocket-ship passing a hand-glider.

Many a time I have read that Ruby will be the next Java (I assume this was meant to be a complement :rolleyes:). It's already being gripped by the business world and that may be enough to carry it far past Python.

It does like everything else come down to a personal choice so I would recommend that you try both. Personally Ruby seems to fit my new mindset much more comfortably.

Where I do still use Python from time to time when I do it quickly dawns on me how even with it's very elegant syntax elegance seems to allude almost all Python code. From a Lispy point of view :cool:.

* You use the same syntax to access elements in Python string and lists; and to a lesser degree Dictionaries.

Slicing in Python also works very similar as in Ruby though I can't comment on things like "somestring"[:7:2] because I don't know if they're possible in Ruby. If it's not then chalk one up for Python :).

Take care guys,

Mark.

somestring[7,2] :)

I'm going to whine at ruby now

Over the past few days i've been trying to go into gtk development with dynamic languages (hey, they're much quicker to write than C), and my natural first choice was ruby, i mean it has the ruby-gtk2 module, gotta be good, right?

Wrong.

Ruby has always been poorly documented, but it's usually not a problem since i happen to have bought a copy of the pickaxe. The problem, is that the pickaxe doesn't cover thrid party modules (and i don't expect it to).

I've been trying to survive on the documentation, and it's shocking, as is all ruby documentation.

I took it upon myself to use the python equivalent, which is much better documented, even if the language isn't quite as nice.

One of the things I'd like to note here is that python has a much better way of inheriting and extending premade classes, as i discovered trying to extend a gtk toolbar... It was much harder in ruby than python because of the way ruby used the blocks. In a lisp you would have passed a lambda as a parameter, but in ruby you receive the lambda as a block instead, and you can't pass the block on to the next function :( This left me in a rather sticky position, and i wished the yield function allowed a little more flexibility. In python you don't use a block and so i was free to subclass everything with no difficulties.

Needless to say my python gtk2 app is going much smoother, with no block issues and good documentation on a module i've never used before...

So maybe it's not just a straight comparison. For most things, I prefer ruby, but in some areas, python really has it beat, partially because of weaknesses in the ruby language.

That said, mark already extolled the virtues of lisp, and while we might disagree about flavours, i've got to agree it's the way forward.

Today I found something that Python doesn't have but Ruby does: continuations. I've known Python doesn't support them* for quite a while but I didn't know that Ruby did.

Continuations are a very general and equally powerful way of expressing program flow – you might think of them a mini time-machines that are capable of bringing one thing back or forward, sort of like Homer Simpsons toaster ;).

They seem to be most commonly used in to implement generators but they're the building blocks for all sorts of coolness including something called tail-call optimization.

This allows recursion to be effectively turned into iteration while maintain it's abstract nature. That's is a very good thing :).

The catch is that raw continuations in the wrong hands can lead to very dense code very quickly. Maybe this is why Python doesn't not to include them? I'm going to look into it later today :).

I've been playing around with them in Scheme – which has first class continuations – and they do seem to be flexible and useful.

* Its technically possible to hack up continuations in any language with closures and a garbage collector (or so I've read) but having them as a core part of the language is obviously going to be much nicer.

Just my $0.0002

Mark.

somestring[7,2] :)

I'm going to whine at ruby now

Over the past few days i've been trying to go into gtk development with dynamic languages (hey, they're much quicker to write than C), and my natural first choice was ruby, i mean it has the ruby-gtk2 module, gotta be good, right?

Wrong.

Ruby has always been poorly documented, but it's usually not a problem since i happen to have bought a copy of the pickaxe. The problem, is that the pickaxe doesn't cover thrid party modules (and i don't expect it to).

I've been trying to survive on the documentation, and it's shocking, as is all ruby documentation.

I took it upon myself to use the python equivalent, which is much better documented, even if the language isn't quite as nice.

One of the things I'd like to note here is that python has a much better way of inheriting and extending premade classes, as i discovered trying to extend a gtk toolbar... It was much harder in ruby than python because of the way ruby used the blocks. In a lisp you would have passed a lambda as a parameter, but in ruby you receive the lambda as a block instead, and you can't pass the block on to the next function :( This left me in a rather sticky position, and i wished the yield function allowed a little more flexibility. In python you don't use a block and so i was free to subclass everything with no difficulties.

Needless to say my python gtk2 app is going much smoother, with no block issues and good documentation on a module i've never used before...

So maybe it's not just a straight comparison. For most things, I prefer ruby, but in some areas, python really has it beat, partially because of weaknesses in the ruby language.

That said, mark already extolled the virtues of lisp, and while we might disagree about flavours, i've got to agree it's the way forward.

Hmmm, I thought Ruby blocks would be first class :confused:. I don't know but it seems to me that if they can be passed around in variables you should be able to pass them on wherever there needed – Ruby does have a lambda form.

Anyway, Ruby's docs are much more minimal thats for sure. Some people like it but I can't agree. I don't like having to wade though masses of documentation to find the answer to a simple question (this is a major problem with Cocoa) but having documentation to look at when you get stuck is a win.

I think it may have something to do with the fact that a lot of the docs are apparently awaiting translation from Japanese. I'm sure things will get better in the future but until then: comp.lang.ruby

I like Strawberry you like Chocolate. What can I say Scheme just suites me :).

Later

Mark.










privacy (GDPR)