From: Clemens Hintze Date: 2001-10-24T17:29:49+09:00 Subject: [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.