Page 2 - Ruby Or Python

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 .

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

Hmmm, I thought Ruby blocks would be first class . 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.

Continuations are a pain, because while you might understand them and use them in your code, when the time comes for someone else to edit and improve that code, they're going to sit there going `eh? What's that do?`. It took me a couple of minutes to grasp what it was on about, but not everyone is going to pick it up like that. And inevitably, it will come to be maintenance time, and only you will be able to maintain it.

Shorter is not always better, hence why python may have left them out

Ruby blocks, the problem is that you don't pass a block as a parameter, lets take some CL here

(map (lambda ()) '(a b c))

See there, you can pass an arbitrary lambda in as a parameter.

problem with ruby, you can't get access to your block, you can only call it

x = new sublist(qw(a, b, c))
x.map {|z| print z}

so lets assume i have access to the sublist object and my map function looks like this (actually map is a mixin from enumerable but it doesn't matter for the sake of this)

def map()
#so i've got my block, yummy, i can call it
#yield(member_of_array)
#now what if i wanted to pass it along to, say my parent's mapp function?
#self.mapp {yield}
end

See you can't do that...

So you'd think pass it as a lamdba? Well you need access to the block to be able to do that, it effectively forms a closure.

Ruby's docs have had since 93 to catch up, and they're lagging way behind. As far as i'm concerned, if i didn't have the pickaxe, ruby wouldn't be worth programming in, and the 3rd party libraries are largely unusable (there is an occasional gem, however)

The docs are still fairly crap in japanese, but in comparison, much better. Compare it to python, however, and you're having a laugh. Pythons docs are much much better.

*shrug* to each their own

Just a thought but when learning how to use continuations you invariably have to read other peoples code. As a noobie you manage it – you managed to pick it up in a few minutes – so assuming that a more experienced programmer wouldn't be able to maintain your code may be off base. Then, maybe it isn't .

Pain or not they allow some things which wouldn't be possible otherwise and that's where they're useful. I don't believe that the standard thinking used in some large corporations is a good model to work by. Why have those of average intellect allocating memory etc.

Continuations should probably be treated along similar same lines; if complex code needs to be maintained getting someone with a brain to do it would make sense .

If code is well formatted, commented, thought-out and documented then I don't see a reason why you shouldn't use them where they'd make the solution more elegant. Of course the pointless use of continuations can only lead to trouble but they're not something you'd use in ever task .

It seems to me that you might create a new construct once – say yield and then use that. If you find another area where continuations could provide a similar advantage then you'd add another construct. Obviously yield isn't going to cause the same degree of confusion.

They're of value on web –*rails leveraged continuations somewhere in there. I haven't looked into this very far because rails really isn't of any major interest to me .

Why not stamp a handle-with-care notice on them and be done with it .

Take care LP,

Mark.

I don't know, I can't read Japanese hehe. Maybe one day but not so much right now . Python's docs are very good, well organized and concise.

One thing I don't like about Python (one of the only things I may add) is that Python doesn't seem to follow it's own naming conventions – names appear in places with _, in others all lowercase and in some others camel-case .



Learning Lisp does come in handy, even for playing with totally orthogonal languages . This is the first Ruby I've ever written and it does the impossible.

It has quite a nice syntax, I don't know if it's semantics really measure up to Lisps in my eyes but it's nice all the same.

Take care,

Mark.