The difference between Ruby and Python.
rzwitserloot posted in programming on May 1st, 2006
Wherein I nail the one true difference between these two programming languages.
The difference, at least, the cause of any non-trivial differences, is this:
In Python, the aim is to have only one way of doing ‘it’, whatever ‘it’ is.
In Ruby, the aim is to have many ways of doing ‘it’.
To give a simple example: In python there is only one way of structuring code: You must program with indentations as indentation is the way python identifies code blocks.
In java, which is in-between on this issue, you have to use accolades { and } which mark the contents inside as being one block.
In ruby, you can use either accolades or the keywords begin and end to mark off blocks of code. In addition, the block can appear in many places:
if something {block}
but also:
{block} if something
or even:
{block} unless not something
And herein lies a dilemma. This dilemma applies to the design of programming languages in general, and not just python and ruby. Everytime I bring up python, I immediatly get complaints about how it enforces code structure. This from people who use formatters and in general ALWAYS write code that has indentation equal to what python requires. Not everyone does this, of course, but a surprising (to me) amount of people do.
Strange to me. Why not eliminate those accolades, clear up something that absolute beginners in programming tend to get wrong, and strongly reduce the opportunity for bugs of the type where an accidental semicolon after an if or for clause causes a somewhat hard to spot problem…. by simply doing what you’re already doing? It even clears up some of the endless battles of style. There no longer needs to be discussion about whether or not the accolades go on a new line or not.
Win, win, win, in other words - and when I bring up the ‘There is only one way to do it’ philosophy of Python, in general everyone agrees that it’s a good idea.
So, in theory (and, eventually, in practice), TIOOWTDI is the right idea, and Python is the better language. Yet, a large amount of programmers get turned off by the fact that they have to make some mostly stylistic adjustments to ‘fit in’ to the language. In effect, TIOOWTDI mindset makes it harder for the programming language to learn.
Yet another case where blind evangelism and anecdotal examples say nothing about the strength of any given programming language. A real shame that those two factors purportedly are a large driving force behind what shapes language choice.
May 1st, 2006 at 0:18
I’ll go so far as to say that TIOOWTDI is merely a part of a larger encompassing point: A programming language benefits if the structure of it is as rigid as possible.
I’ll freely admit I’m a strong fan of strong, declarative typing. I prefer java over just about every other language mostly because right now it’s the only mainstream language where the compiler knows -exactly- what I’m trying to pull. C, with its endless #define directives, does not offer this. Python, Ruby, or any other dynamic language, cannot either.
A further analysis of why exactly rigidity is good in the sense that declarative strongly typed languages will always be the better language in the long run compared to dynamic concepts like python, at least in my mind, will have to wait for another day.
May 1st, 2006 at 7:23
Yeah, I agree. I think Ruby has that kind of flexibility because it is influenced by Perl. Powerful but a little too flexible.
One example of Python not following TIOOWTDI in my mind is the fact that there are distinct types for lists and tuples - two things which seem too similar to me to require two distinct types built into the language.
May 2nd, 2006 at 21:51
Maybe a more generic implementation of the notion of immutability would be better suited to python.
I’m (trying to) lobby sun to add some sort of @Immutable annotation. Helps optimization but mostly, it documents and bugchecks - it’s actually fairly simple to take a class which is supposed to be immutable and accidentally add some mutable aspect, opening up the door to future hard to find bugs. It’s also fairly simple for a compiler to check if a class is really immutable.
May 3rd, 2006 at 8:44
Reinier, maybe a little off topic, but I don’t agree to your statement that it is fairly simple to check immutability.
You yourself already said that side-effects are difficult to check. And then there is lazy instantiation, caching etc. And finally, you need to know, it has to be guaranteed, that when a class states it is immutable, it actually is.
Since you also have to trust classes provided by third party developers, I suggest adding a language feature instead of an Annotation. That way, the compiler can ensure the immutability and the VM can protect you from misbehaving classes.
May 3rd, 2006 at 18:12
Well, ‘@Override’ is an annotation but its checked by the language. The idea of using an annotation is simply to avoid having to declare an endless stream of new modifiers. Also, as an annotation there is a class file for javadocs, it’s a lot easier to add parameters of some sort, and it should integrate nicely with existing IDEs.
Yes, I may have overstated somewhat how simple it is to check for immutability, but don’t forget that no java code has a side-effect - only certain methods from the Runtime do, and the 1.8 (or whatever version this @Immutable thing appears in) version of the runtime library will of course already be fully equipped with the proper tags.
Then there’s some hairy issues like caching (An immutable class may cache values for efficiency reasons but then it looks like its mutable).
Let’s just say: It’s possible
August 18th, 2006 at 16:41
Before you write a rant about a language, at least read a basic tutorial about it (and download the interpreter, oh, maybe you should start it too?). You cannot use {} to delimit blocks in Ruby. The only way is:
keyword
…
end
For example:
if something
…
end
while something
…
end
for i in e
…
end
class Something
…
end
The only use of { and } is small (inline) lambdas/blocks.
do … end style block (used for multiple lines of code):
open(file, ‘r’) do |f|
…
end
Inline style (use if you have one line of code):
arr.map{|e| …}
Ruby is more consistent than Python. len(a) vs a.length. expressions and statements vs everything is an expression.
Wait, have you tried Python?
August 18th, 2006 at 17:35
Nice rant there. I suggest you consider the actual CONTENT of the article. I grant you that I might have gotten some of the details wrong, I haven’t used Ruby much (not much point if you’re more familiar with Python), but in that gleeful pedantic bashing there all you managed to add is that you claim Ruby is more consistent than Python.
Yes, because using accolades for small blocks but ‘end’ for large ones, that’s consistent. As is the validity of both ‘if (condition) dothis’ and ‘dothis unless (not condition)’.
Is ruby more consistent than Python? No. Is Ruby less consistent than Python? I think so, though one might claim only in trivial ways.
The fact that Pythonistas have an actual word for the notion of trying to ensure things only occur in one way, along with some of the basic evidence I’ve been mentioning meansI /strongly/ lean towards Python on this one.
So far you haven’t shown anything to either disprove that idea, or to expand on the concept that TIOOWTDI is an unworthy goal.