From: Gavin Sinclair Date: 2004-01-20T06:11:22+09:00 Subject: Re: Fighting Ruby's bad fame On Tuesday, January 20, 2004, 6:45:01 AM, GGarramuno wrote: > Gavin Sinclair wrote in message > news:<33606556942.20040120002034@soyabean.com.au>... >> On Monday, January 19, 2004, 1:05:02 PM, GGarramuno wrote: >> >> > I've been using ruby for about 1 week & 1/2 and already run into that. I >> > created String#expand_tabs() function in a module of mine only to find a >> > similar (but less efficient implementation) of that function in another popular >> > ruby library. >> >> Could you send me the efficient implementation? :) >> > Sure, here it is. [...] Thanks. That'll make 0.3. >> What's so bad about name clashes? > Nothing much. Just that it is something I wouldn't be giving any > thought with python or perl, but that you tell me I may have to watch > out it for in ruby. That's right: nothing much. And many of the things you have to watch out for in P* are not an issue in R*. There's no perfect language, just different sets of compromises. >> And, >> short of clashing with a library whose explicit purpose is to extend >> the built-in classes, I bet you don't even find any name clashes. :) >> > Not sure I agree. Do you know how many vector, matrix and so forth > libraries are out there? All of them more or less incompatible with > each other? Even if that's true, how many are you going to use at once? >> I don't like the sound of that "feature". A well-designed library >> should be loaded in full. In OO languages especially, you either load >> a class or you don't; you don't pick and choose methods. >> > Personally, I'm not too interested in choosing methods, but I am in > choosing classes. > Also, think of it negatively, as I do. I prefer to think positively when programming, and Ruby rewards that! > What if the library you have to use was not well designed? What if > this is found out only in the middle of the project? What if the > person maintaining the library has no time on their hands to fix it > (or worse, refuses to change it for some other reason)? Do I just > hack into the library and start maintaining my own incompatible > version which I would then have to keep updating every time a new > update to the master library is released? An ugly situation, but that's a LOT of what-ifs. > Between being tied and just going on my own tangent, I'd rather take > the comprise of just picking and choosing what I want to use... > without hacking into the original code. > Will I'll be using that feature often? Heck, I hope never! But I'll > sleep well at nights knowing that if I ever HAVE to, that feature is > already there. Like I said before, since Ruby is missing a few features you look for in an ultimate solution (especially in a particular domain), try it as a prototyping solution. I'd be interested to see what problems you hit and how you deal with them. >> > Personally I like this phisolophy of ruby, but I NEED to have the ability to >> > easily keep changes to base classes local to my class or in an easy way to >> > revert them. >> >> At the risk of re-igniting an old flamewar, no you don't. Not until >> you prove that you need it anyway. At the moment it's mere paranoia. >> > Paranoia is good in programming. Keeps you sane later on. > And this fear must be a plague, as searching for solutions in the ruby > world, I've seen at least 3 or 4 proposals trying to address this same > issue, including: > - behaviors > - matz's namespaces > - profile method visibility > That tells me that: a) it is a problem already or b) it is enough of a > potential future problem to merit a solution. It tells you what you want to hear. Likewise for me :) > [...] Cheers, Gavin