Ian Bicking: the old part of his blog

Updates

There's a lot of content in this article, some of which I'm not 100% sure about. I'll try to fold in any corrections provided, and note the updates in this comment.

2005-08-17: Updated per Seo Sanghyeon's comments to note Ruby's Safe, distutils C compilation, and Ruby's rdoc. I'll probably put some of his other comments into a "VM" section.

2005-08-21: Updated per Florian Gross's comments: Ruby threads are preemptive for I/O; utility of continuations for breakpoints; source code generation might just be common in Rails; that Psyco is not alone in concept, but alone in terms of maturity.. Noted projects: ruby-contract, rubyscript2exe, Exerb, Ruby Numeric alternatives.

Changed some of the finalization commentary in Ruby Blocks; PEP 348 and Ruby blocks are more similar than I originally realized when I first wrote this. Added section on "Performance & Environment". Also added table of contents.

Added link to benchmark in aforementioned section.

2005-08-29: Added a note to the intro, that my asymmetric knowledge of the two languages can actually lead to a pro-Ruby bias to the comparison. Fixed commenting.

Comment on Ruby, Python, "Power"
by Ian Bicking

Comments:

I would like to comments three points.

First, about threads, the use of Python GIL makes OS threads not that different from Stackless threads. Let say that if you deal only with Python code there won't be any differences at all as in both case it is the Python interpreter who decides when a context switch will occure (in one case byu releasing the GIL, in the other by actually switching the current thread). There are two situations where you'll see some differences. First, if you use some extension library performing long tasks without accessing any Python function, it can release the GIL, allowing a true multi-threading, even multi-processor computation. Second, if you have to interface Python with some other library (like, say, Qt) you can use Qt threads and, along with that, Qt cross-thread message system.

Second, about multiple inheritance. Python syntax does allow for multiple inheritance and it does work with pure-Python objects. However, it does not work (in CPython) with built-in objects (try deriving from both str and dict). As Python's main force is the possibility to extend it with efficient languages and that you can seemingly replace a full-Python object with a built-in object, probably as a required optimisation, multiple inheritance is bad practice as it would forbid you to replace a full-Python object with an extended one. Until CPython resolve this problem, I will consider Python not being able to handle multiple inheritance.

At last, about OO. Just to say that I really don't care if a language is 100% OO, whatever that might mean. The main reason is: no two person has the same feeling about what "100% OO" is ! Another is: if the language is efficient and "just work", who cares if it's 100% OO or 0% OO or whatever ??? Nevertheless, I agree with your comments about OO and Python, I found it very interesting !

# Harbort

There are two situations where you'll see some differences. First, if you use some extension library performing long tasks without accessing any Python function, it can release the GIL, allowing a true multi-threading.

Do you realize that "Some extension library" includes any file operation, any socket operation, and in general, any blocking system calls? CPython's fileobject.c and socketmodule.c is full of Py_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS to enable this.

# Seo Sanghyeon

At last, about OO. Just to say that I really don't care if a language is 100% OO, whatever that might mean.

I care a lot. For instance, if Python classes were not objects (but syntactic constructs or something, like in Java) that would be awful. If I had to worry about boxing, that would be awful. If Python isn't 100% class based, no problem. Smart OO programmers know that OO is not the same thing as classes. Python is 100% object based, and that's really really important. IMHO, that makes it substantially more OO than Java.

# Ian Bicking

Well, my point was more about: what does it add to get the "100% OO" label ? IMHO, nothing ! Even more: "100% OO" might means (and apparently mean) different things to different people.

I really don't care about the label ! But I do care about the language coherency ... In Python everything you manipulate is seen as object (at least syntacticaly) and that's enough for me. But if someone feels it is not enough to be "100% OO", well, he might be right, but I don't care ! That's all I wanted to say ...

# anonymous

Ruby is 102% OO then.

# anonymous

Examples please?

# Mark

http://www.insula.cz/dali/material/rubycl/RubyIOClasses.jpg http://www.insula.cz/dali/material/rubycl/RubyExceptionClasses.jpg http://www.insula.cz/dali/material/rubycl/RubyDataClasses.jpg http://www.insula.cz/dali/material/rubycl/RubyCoreClasses.jpg

The entire language was built from the ground up using OOP concepts. IMHO that makes it more oop than just about anything else. Every aspect of the language can be manipulated including the object "Class" which can be manipulated on the fly as it's created.

It makes the language very easy to learn because so much of the language is polymorphic. Got a file handle, try the put method. Got a standard out handle, try the put method. Got a network socket, try the put method. . . . you get the idea. Working with ruby I feel like I need less of a reference than other languages. Once I get used to a particular class hierarchy I understand that most of the inherited methods are available for all classes in that tree.

I had a python stint and really liked the language, but feel that Ruby code is more expressive. I know that is cosmetic or semmantic which you seem to be trying to avoid. I think if I were defending python I would avoid them as well. :) In all seriousness tho, python is great . . . ruby is great. It's all about enjoying what you do and if python makes you happier than ruby then that's what you should do.


http://www.insula.cz/dali/material/rubycl/RubyIOClasses.jpg http://www.insula.cz/dali/material/rubycl/RubyExceptionClasses.jpg http://www.insula.cz/dali/material/rubycl/RubyDataClasses.jpg http://www.insula.cz/dali/material/rubycl/RubyCoreClasses.jpg

The entire language was built from the ground up using OOP concepts. IMHO that makes it more oop than just about anything else. Every aspect of the language can be manipulated including the object "Class" which can be manipulated on the fly as it's created.

It makes the language very easy to learn because so much of the language is polymorphic. Got a file handle, try the put method. Got a standard out handle, try the put method. Got a network socket, try the put method. . . . you get the idea. Working with ruby I feel like I need less of a reference than other languages. Once I get used to a particular class hierarchy I understand that most of the inherited methods are available for all classes in that tree.

I had a python stint and really liked the language, but feel that Ruby code is more expressive. I know that is cosmetic or semmantic which you seem to be trying to avoid. I think if I were defending python I would avoid them as well. :) In all seriousness tho, python is great . . . ruby is great. It's all about enjoying what you do and if python makes you happier than ruby then that's what you should do.