[ruby-talk:23157] Re: Bruce Eckel's opinion of Ruby

Hi Eric,

thanks for the fair statements you have made. I agree with many of
your points. But some not. Let me state that I was also coming from
Perl to Python, and some time (years) thereafter to Ruby. My main
reason was, that there were many points I would like Python to
improve, like others too. But much of them were dismissed by GvR or
moved to a mystical Python 2000 at that time.

When I detected Ruby (ironically lead by a Pythoner congratulate matz
for his nice language in c.l.python ;-) I have found all the nice
stuff, I would like to see in Python ... and more. So I was switching
at once to Ruby and have never regret it. Although, now I can see that
Python will get some of the nicer features I would liked to have seen
some years before :-(

Syntax is not a much hindrance for me, if language features are worth
a try. I like the syntax of Smalltalk, Ruby, Python, Forth and Lisp.
Heck! I even have programmed in Perl ;-)

Ideally I would like Ruby have some of the syntax of Python --
especially the fine block indentation syntax. But hey, its okay for me
that matz do not like it and so decide not to teach it to Ruby. Ruby
is still worth to work with, despite this 'lack' of syntax ;-)

Eric Lee Green wrote:

(...)

> 1. Python's namespace conventions (i.e., no "global" global variables, only
> module-global variables) make it easier to partition a large project amongst
> various programmers, especially projects that require configuration variables
> of some sort (which are "global""), where you can divide them amongst several
> programmers/several modules without worrying about conflicts.

In Ruby you can do the same thing except that explicit global
variables remain global, whereas Python does not offer global
variables. I am more a fan of freedom to do or to no do something. If
I want to mess around with global variables ... let me :-)

But I understand your point. Although I think, there is no way
(concerning the language) to hinder a fool to do some weired stuff in
whatever language he is using right now ... even in Python.

> 4. I like being able to pass around a method in Python. This makes many
> things much easier.

Others will have, for sure, pointed you to Object#method?

> 5. Multiple inheritance is good in Python.

Okay, but its lack is not bad in Ruby, IMHO. At least since all the
time I used Ruby I had not *one* opportunity where I ought to use MI.
SI was enough most of time and often modules were a cleaner choice.

But as I've said: I like freedom to decide to use MI or not. So ideal
would be a Ruby that supports MI, and if only to let me decide *not*
to use it ;-)

> 6. I like the 'module' concept in Ruby, which works around many of the
> problems with multiple inheritence, but not enough to consider it a full
> replacement for multiple inheritance.

:-/ I had never a problem with: only able to use modules but need more
than that, needs MI :-/

> 9. Reference counting (Python) is more memory-efficient than garbage
> collection (Ruby), since it frees up memory as references are destroyed
> rather than waiting until a garbage collector runs. Python does need a
> garbage collector to collect circularly-referenced objects though, so
> Python's lack of garbage collection overhead has to be offset by the fact
> that circular references currently hang around forever.

I second that. But I think it is also true, that often RC will have
more performance penalty as it has to adjust the refcount every time
an assignment will take place. Whereas Rubys GC will have that penalty
if GC actually takes places. And you can decide, when GC should take
place.

But I see your point and I think it is not wrong. There are different
strategies and I like true GC more than RC. But that's me :-)

> 10. Reference counting works hand-in-hand with Python's destructors to handle
> resource cleanups in a real-time manner that's difficult with Ruby (where you
> can set up destructors of a sort but they only run at garbage collection
> time, which may be some time later, in the meantime you still have some open
> files and files on disk hanging around that are not getting cleaned up).

That is true and this I find especially disturbing in Ruby then and
when! But I like true GC more than I hate this 'lack' of feature. So I
will not complain to loud here ;-)

On the other hand ... if I only free resources by accident -- cause no
one refer to it any longer -- it may also stay around for too long
time, if it is still held somewhere else. So only relying on freeing
of resource if nobody use it anymore, is also a bit, ehrm, unclean(?)!

> 12. Python is no speed demon, but is faster than Ruby for the things I do.

And for things I do, it is often vice versa ;-)

> 13. Python has a nice GUI-based debugger, which makes many things easier.

Yes, but Emacs and GUD are a good replacement.

> Final conclusions: I must agree with Bruce Eckel that I could not recommend
> that a Python programmer move to Ruby except in very special circumstances,
> because the two languages are so similar that there's no real advantage to
> doing so. In my case I'm using Ruby because I needed to prototype a

Ha ha ... to late, I already done so! ;-)

> My preliminary conclusion is that Python is a superior language for large
> projects. It is virtually impossible to make a difficult-to-read Python
> program due to its indentation-based syntax, the namespace partitioning makes
> large projects easier to partition amongst multiple programmers or multiple
> programming groups, and there is a large number of enterprise-oriented
> libraries for access to various proprietary and non-proprietary external
> systems. It is also portable to more architectures than Ruby, which is
> important for some large multi-platform applications. Python's syntax is also
> more regular and consistent than Ruby's, which again is important for large
> multi-programmer projects.

I half agree with your objections stated in that last part, and half I
do not agree. But I have to admit, I did not a real multiprogrammer
large project. But I do agree that Python make it difficult to write
read-only programs. But I've told you, I still like to have freedom to
chose to write difficult to read programs althoug I would trying not
to do so ;-)

> Ruby, on the other hand, is a much better scripting language (as vs.
> general-purpose programming language) than Python. It is much easier to chain
> pieces together, especially for distributed applications. It also makes a
> superior language for prototyping Java applications, since many aspects
> (iterators, rinda, single inheritance only, etc.) are similar to Java. I
> would not, however, relish attempting to manage 100K+ lines of Ruby code for
> a project, while Python proved to be quite usable for 100K+ lines of code.

Okay, here I do not agree with you. Although never done, I still very
believe I can do a large scaled Ruby project without difficulties.
Ruby is not self-enforcing to be readable, but it still is also not
self-enforcing to be unreadable. So it is a matter of discipline, I
feel.

And programmers need to have discipline. Especially if they work
together. If there is no discipline, a clean and nice language like
Python will not help the project either. The project is doomed to fail
then, I suppose!

But again let me thank you for you fair and valueable comments on that
thread. It was a joy to read them.


Ciao,
\cle.