Slashdot Log In
Why not Ruby?
Posted by
Cliff
on Sun Jul 08, 2001 03:15 PM
from the why-the-resistance dept.
from the why-the-resistance dept.
flounder_p queries: "I have recently started playing with the
Ruby programming language and think it's really great. I was just wondering why you
guys think Ruby has not caught on more in the open source community than it has? How many of you guys are using it? Will it ever catch on or will it always be looked at as yet another scripting language? Don't get me wrong scripting languages are great (and I live by Perl) but I still hope to see Ruby catch on more. I would like to hear opinions on things on why Ruby is good or bad not on why OOP is good or bad. We have already had that discussion
here." On a side note, a little birdy tells me that BlackAdder has plans for Ruby support in its next beta.
This discussion has been archived.
No new comments can be posted.
Why not Ruby?
|
Log In/Create an Account
| Top
| 316 comments
(Spill at 50!) | Index Only
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
1995: Who needs Java when we have C? (Score:3)
Or 'who needs Linux when we have UNIX®', 'who needs Netscape when we have Mosaic', etc.
Don't write Ruby off until you play with it. And, having played with it, I've written it off. I was looking for something on the client side that was more powerful than JavaScript but not as hefty as Java. Perl moved across the wire would be beautiful and that was the goal of the Penguin [cpan.org] module. Alas, it seems to have withered on the vine.
Be a little more open. It'll keep you young.
Less tran truthful advertising... (Score:3)
Python types are more limited (no inheritance/subclassing; cannot add methods to existing types). What are they smoking ? No inheritance in Python ? Python has had inheritance since day one as far as I know. Cannot add methods to existing types. Not ? How about:
class chair:
"Class with no methods"
pass
def siton(obj):
print "You sit on the chair"
chair.siton = siton
Just an example, I don't know Perl or tcl well enough to comment, but when I find mistakes in simple factual claims I get a whole lot more skeptical of other claims that I am myself unable to verify.
Re:Object Oriented programming is overrated (Score:3)
When you domain model is appropriate for OOP, then by all means use an OO language. Sure, you can do it in C. But you could also do it in assembler. If you're going to use OO, then use a language that supports and facilitates OO.
Re:Namespaces (Score:3)
What annoys me more, is 'OO' languages which tie namespaces to modules or objects, instead of the other way 'round.
-- Crutcher --
#include <disclaimer.h>
Re:Because Ruby Rocks! :-) (Score:3)
Such orthogonality has aesthetic merit, but is bad for performance. There are a lot of things one can do to reduce the cost, but there is a cost.
Variable punctuation is evil regardless of whether it determines scope or type. Sure, some people like putting an MFC-ish "m_" before member names etc., and they should be free to do so, but they shouldn't be forced to do so by the language.
Again the performance issue rears its ugly head, and also the issue of assignments etc. having side effects. Sure, it can be "cool" to overload access/modification, e.g. to enforce range/consistency limits or to create "magic" variables such as r/theta when what you're really storing is x/y. However, the cost and potential for abuse aren't worth it. You can already get almost the same effect with explicit accessor functions, or with a keyword attached to declarations. People who really like being able to go in after the fact and change the semantics of an assignment in one of their classes can just always use the keyword; people who want to be able to do the same for other people's classes generally have no business doing so lest they cause all sorts of "spooky" failures when they violate the class implementation's internal dependencies.
BTW, I'm not really that hung up on performance, in the usual sense. If your application doesn't run fast enough in an interpreted (including byte-code interpreted) language, you should profile, refactor, and rewrite necessary portions in native code. However, I am concerned with performance in the sense that I hate to see billions upon billions of cycles wasted for little or no functional benefit. Machine cycles are cheap, but programmer cycles aren't. If a language runs 10% faster then that might be enough for some large number of applications, so instead of all that refactoring and rewriting I just mentioned the programmers can spend more time on adding features or making the program more robust.
What, and Python doesn't? (Score:3)
If you're going to bash a language, you really should make it a point to at least learn the language first.
Python 2.1 is free software (Score:3)
Please don't spout FUD regarding Python's license. Instead, call a spade a spade and say, "Python is free software, but is not GPL-compatible. In this sense, it's no worse than the Mozilla Public License."
Re:Perl (Score:3)
It could be said, as well,
Currently I'm using, and loving, Perl. It has a very active and helpful community, plus tons of modules that come with the system. While I do like Python, it doesn't have the support behind it that Perl does. Thats why I use Perl, and not Python.
Java seems to have the mark of the corporate beast on it: while it has its benefits and benefactors, it hasn't kept steam like Perl has. Personally, I'm liking the looks of JDK 1.4, with select(), assert(), faster Swing, and mostly-Perl-friendly regex classes built in.
Another Scripting Language, Ho Hum (Score:3)
If Ruby has some features that I need and no scripting language I already know fits the bill, I might make an effort to learn it, but I'm not going to go out of my way to pick up Yet Another Scripting Language.
Popularity of Ruby in Japan (Score:3)
I've seen Ruby used for AI/machine-learning code as well as some math applications. It turns out that one may extend the language using other code, such as C. Add in the untyped OO as others have discussed and you can easily write programs for multiple platforms/languages without giving up speed (write speed-critical code in a C extension).
Re:Python (Score:3)
For more Ruby info, check out their homepage [ruby-lang.org]
-----
"Goose... Geese... Moose... MOOSE!?!?!"
Object Oriented programming is overrated (Score:3)
I say Object Oriented Programming is highly overrated.
Many programmers I know seem to believe there are about 2 ways to program in the world: procedural (uncivilized, messy spaghetti code, no support for large programs, etc.) and object oriented (civilized). The fact is that all modern languages spanning many different paradigms support civilized programming, even if they are not "object oriented". And what I infer from this is that objects are primarily useful only when the data you are processing are neatly expressed as objects, that is, they actually *are* objects. (For instance, if they describe operations, then higher order functions are much handier.)
Every civilized language that I know of supports the features that I believe most people think of as object-oriented. Even languages which are adamantly *not* Object Oriented (such as SML, of which I am a stalwart fan) support them.
Some examples are aggregate data (in the case of SML, aggregate data is supported much more cleanly than OO languages I know of, since one can make anonymous "classes"), abstract data types, exceptions, threads, polymorphism, garbage collection, and type safety. (The advanced languages I'm implicitly referring to also support some really nice features typically not in OO languages, such as higher-order functions, static typing, parameterized modules, and generics or "parametric polymorphism".)
So what really separates Objects from regular old modern programming? I say two things: inheritance and subtyping. Essentially, if you are not making use of subtyping (using it for polymorphism doesn't count, since other modern languages support polymorphism in their own way) in your program, then you aren't using any OO-exclusive features. Do you actually write programs the way that they introduce OO in textbooks? (A motorcycle derives from wheeled_vehicle, which derives from vehicle?)
So I guess what I'm saying is, be sure you know what you mean when you say "OOP", since there is very little which is particularly special about OO languages. In my opinion, there is not much need in scripting language for subtyping. So I say that emulating Java or C++ is not a very worthwile goal, except inasmuch as it might engender comfortable syntax/semantics for those who have only used those kinds of languages. Let's look to some other advanced languages to get us useful features in our scripting languages, and encourage the use of them.
The Truth Ain't Purdy (Score:3)
Why not Haskell?
Why not Mozart-Oz?
Why not Prolog?
Why not Pict?
Why not Programming Language X?
The truth is, most people do not choose a programming language based on the technical merits of the language, but instead, most people choose a programming language based on a mix of the following list of reasons:
Hey, its the reason most have for why they use their natural language. I use English because it is the first language I learned, but English is not necessarily the best natural language.
For example, most people simply aren't educated in computer science, and therefore don't understand Object-Orientation, functional programming, declarative programming, etc, and therefore, these people are turned off my languages that they simply cannot understand. Why do you think that Visual Basic is so popular?
Never under estimate the horrible effects of legacy. It comes in many forms, from having large amounts of code written in previous languages, to only having experience with writing code in previous languages. If you have legacy code, then moving to another language requires allot of work to migrate the code or you could end up complicating things by keeping the old code base and introducing the new latest and greatest programming language. And the other form of legacy, mindshare legacy, is even worse. A programmer should constantly be on the hunt for tools that will make him/her more productive, but the fact is that most people are lazy and really only know how to efficiently code in one programming language... even when something better comes out, people that have already become efficient in their one favorite programming language are very reluctant to change. Why do you think that C++ is so popular?
Its obvious that hype and its flip-side, FUD, heavily influence the average person's choice in programming languages. Over the past 5 years, the ultimate way to sell a programming language was to fill the description of the language with all sorts of "Object-Oriented" buzz words. However, big dollar marketing campaigns have made at least two programming languages catch on: Java and Visual Basic. Meanwhile, FUD has been used to slam alternative programming languages into the background. Whoever thought that the words "procedural programming" would become programming language profanity?
Too many already (Score:3)
Too much diversity can be a bad thing, especially in open source where people have to be able to read the code to extend it.
Just my two cents.
Somebody's looking for free advertising (Score:3)
Given the number of posts above to the effect of "What the heck is Ruby?" -- as well as the lack of any critical details in the post (such as comparisons between Ruby and the alternatives) -- one can't help but get the impression that the poster is merely looking for free advertising for his/her pet language.
Re:Answer is simple (Score:3)
I don't know how many times I've heard a fellow techhead complain "Yeah, I went to work for these guys. But they have a proprietary system that they have to teach to people. It took weeks to understand." In this world, "proprietary" means "rarely used and I've barely seen it before". That's why you see ads in the paper for jobs requiring Perl and C++ and less requiring Ada programmers.
Give Ruby time, a strong open source (or not) base, and people using it to create prefabricated programs not requiring little reprogramming, and it will get the audience it deserves.
From Java to Ruby (Score:3)
In my case, I came to Ruby from the Java world. A friend forwarded me an email announcing the release of the Programming Ruby [rubycentral.com] book and so I decided to check out the language. Since I enjoy learning about new programming languages I wasn't agaist learning "yet another language." A search on Google yielded the main Ruby-lang [ruby-lang.org] web-site, and after some reading I decided it was worthwhile to take the time to really learn it. That was about 4 months ago.
Since then, I've read through the on-line version of Programming Ruby as well as the printed version, which I recommend very highly. It is one of the best computer language books I have ever read (and I have a Computer Engineering degree.) I have also gotten very good at programming Ruby after only a month and half of serious study. In fact, I'm probably as good (or better) at programming Ruby as I am in Java (which I've been using for 3 years.) Now that is impressive. Of course I will admit I've been somewhat obsessive with Ruby and have studied it very extensively over this last month and a half, so your mileage may vary. But still: 3 years versus 1.5 months? Hmmm....
Of course I can't say the same wouldn't happen if I seriously studied Perl or Python, but I will say I don't intend to learn those languages now. They are fine and dandy for what they do, but just like all those out there who don't want to switch to Ruby since they know Perl (or Python), I don't want to switch to them because I know Ruby. So given that, I can probably respect those who decide not to learn Ruby for this reason.
But I have heard other Ruby users who have used Perl or Python say it is an improvement to them in some ways, so it may actually be worthwhile to at least take an hour or so to give Ruby a good look. I would say the same for Java programmers. If you've never touched a so called "scripting language", learning Ruby will change how you think about programming permanently. I'm sure former Java users now using Perl or Python could say the same thing. Of course Ruby is much more than a scripting language. In fact, I really wish I could just totally stop programming Java and just use Ruby (since it can solve the same problems), but I really don't think that is possible now since Ruby is so new (to the United States.) And of course Java is pretty much the corporate mantra these days.
But in the long run I could certainly forsee Ruby replacing Java in the enterprise. In fact, I think this should in some way unite Perl, Python and Ruby users, since we have a "common enemy" in Java, heh. Of course Java has it's uses too I suppose. And before Java advocates flame me, consider that I hold this view after 3 years of being a Java advocate and switching to Ruby for about 1.5 months (as noted above.) That's how much better I think Ruby is compared to Java.
Now other complaints about Ruby usually revolve around it's newness:
- It's doesn't have a big library like Perl's CPAN.
- No one uses it.
- I can't get paid to use it.
- I don't know it and won't learn it.
Now the first argument is valid (in fact I'm working on my take on the solution), though of course like the others it is kind of a self-fullfilling prophecy. If people had used these arguments and logic with Linux, this web site wouldn't be here right now, and the world would be a much different (and probably worse) place. So given this, at least give Ruby a chance before you just bash it because it is new and you perceive it as a "threat" to your own personal favorite programming language (why are languages so much like religions to programmers?)So, to conclude, at least give Ruby a chance and try not to be so fanatical about programming languages :)
--
Ryan
Re:This has been mentioned before, but... (Score:4)
Consensus Answer: I don't need it (Score:4)
If people don't need it, it doesn't stand a chance. The helpfulness of Ruby is outweighed by the cost of learning it.
The cost is greater than the benefit, just like [insert your other underused neato technology here]. Come back when the benefits are greater than the costs; preferably when they're MUCH, MUCH greater.
We use OO-style in scripts all the time (Score:4)
If you are doing sysadmining, you may or may not want OO. Perhaps you have some conceptual objects, perhaps you don't. For the most part, I'd suggest that you don't.
I found for web applications, the database handles so much of your processing, that many of your public display components are simple are simple procedural displays.
However, if you are building an infrastructure, real OO style approachs can help you build up your concepts. I've found that we can often take advantage of OO design, even if not implementation.
We try to do, as you call it, text-book OO. It helps as the project scales. We have tremendous code-reuse for our client projects. This lets us stay in business despite being smaller than our competitors, because we can reuse so much of our code base. It also lets us undercut the big-boys, because we've maximized code reuse, not just taken what we've got.
Alex
Namespaces (Score:4)
I really like coding in object oriented languages. Right now I'm working on quite a major project in Python, and objectising everything is making it a lot more convenient. I'm using inheritance and polymorphism and so on, but it took me a while to figure out how that was useful in a scripting language where there isn't any strong typing.
I don't have anything against procedural languages, although I tend to write in objects more when they're available just because I'm more used to the technique. In general though, I think one of the most useful things that I get out of using objects besides all the polymorphism stuff is namespaces.
Classes are simply a really convenient way to package related things together without getting them messed up. I know this can be done without too much trouble without objects using packages or naming conventions, but classes are a much more general way to do it. Certainly it's one of the main reasons I prefer C++ over C, even for relatively simple programs, because C doen't have any natural way of assigning namespaces in a clean way that's guaranteed not to clash.
===
Ruby Resources (Score:5)
Here's some references ...
DDJ's January Article on Ruby [ddj.com] (Thomas and Hunt)
Ruby Presentation [pragmaticprogrammer.com] (Thomas and Hunt)
Programming in Ruby Book [rubycentral.com] (Thomas and Hunt. Available from Addison Wesley, online version is under an open content license)
And some web pages ...
Ruby Home Page [ruby-lang.org]
Ruby Central [rubycentral.com]
Why not not switch? (Score:5)
I think the simple answer is that most people are quite happy with the scripting languages they already use.
Many people enjoy Perl, many enjoy Python, some enjoy /bin/tcsh. The latter population should however, needless to say, be put into working camps. Many also enjoy other languages, but I see Ruby mostly as a contender with Python and Perl.
So why should people switch to Ruby? Because they can do everything in Ruby they can in their current choice? Not likely. They can by definition already do that already. Because Ruby has an extensive library of ready-made code? No, because it doesn't have one compared to Perl or Python. Becuse it's a nice language design? Thats not enough reason to learn a completely new language if the one you use does what you want.
I might be prejudiced here, but i basically believe that many who like Perl do so because it's a very free-form (write-only :-) language, suitable for quick hacks. And those who like Python do so because it is a "cleaner" language, suited to write easy-to-read code. Both camps also enjoy the fauna of ready-made objects/functions/classes/modules that lets you do things easily without reimplementing the wheel.
There are probably Perlies that think Perl is a bit too loose, and Pythonettes that think Python is a bit too strict, and these people can probably find a new friend in Ruby once it gets the library support Python and Perl has.
But for most people that are already into Perl or Python, I think that the potential gain of switching languages simply isn't even close to the effort. And most Python-lovers don't want a looser language, just like most Perl-lovers probably don't want a stricter one. They're quite happy with what they've got.
In order for a new language to be able to make it as a strong contender to Python and Perl, I think it would have to supply something that neither language has, but that all programmers want (I can't think of anything matching that criterium at the moment, if I could I would've implemented that super language already! :-) If the language was then inbetween Python and Perl, both sides would have an easier time switching.
But only being between Perl and Python, which is just about everything Ruby seems to be at this point, isn't a reason to switch. It's just an advantage to ease migration if you happen to have something unique. Until Ruby actually invents something that makes it that much more valuable, I think most people will stay with the language they already use.
I do however wish the Ruby developers the best of luck. It is indeed a quite nice language, one I could definately imagine myself switching to if it gave me a clear advantage.
Some Annoying Features of Ruby (Score:5)
1. Strings are not value objects. Ouch! So you constantly have to worry about aliasing when you're passing strings around. Java got this right. (Though both languages fail on this count when it comes to date/time objects...sigh.)
2. I18N support is poor. Again, Java did this right (or got it much better, anyway)and made Strings sequences of characters, not bytes. This forces you to worry about your character set at the place (input) where you're actually in a position to deal with it, and then you never have to worry about it elsewhere. Ruby has some things (such as the Integer#char method) that just make no sense from an I18N point of view. Return the character represented by the receiver's value? In what charset?
3. Float uses the native architecture's floaing point. So FP programs' behaviour may differ (in very interesting ways, if you work with numbers such as the infinities and NaN) from system to system.
4. It's only related to certain styles, of course, but the semicolon-free syntax is, for me, more annoying than the semicolons. For continuation lines, I often try to split at operators (+, =, etc.) and put the operator at the beginning of the continuation line. Since a statement can't start with an operator (aside from C/Java constructs like ++, which I don't use in those situations), this makes it very natural to see the continuations, but in Ruby I have to put backslashes at the ends of all the continuation lines, now, and worse yet, make sure I edit them in and out properly when reformatting.
5. The Time object includes time zone information. This is confusing. Most stuff (such as comparating two times) seems to operate on the UTC value of the time, regardless of the time zone. But does #hour return the UTC hour or the hour in that time zone? If the latter, we can have two time objects that compare equal but where a.hour != b.hour.
Time zones are complex things. UTC and GMT are not the same thing (as Ruby seems to claim). Time zones do not have standardised unique three-character abbreviations (which is what Ruby seems to use for them. The time zone support, besides being fundementally broken in this way, is also implemented poorly; there's no easy way even to figure out the offset of the time zone of a given Time object.
And all this even before we start to get into date processing. Ruby doesn't seem to acknowledge the existence of different calendars. (Yes, even today different calendars are in use in a fairly major way. Take a look at a Japanese driver's licence if you don't believe me.)
I'm sure I could find more. And there's a bunch of stuff in Ruby that I like, too. But just from this glance, the language seems to have enough annoyances of its own that I can't see any reason for it to take over from Perl, Python, Java, or whatever.
cjs
Advantages over Perl (Score:5)
1) RUby has much nicer OO syntax than Perl - advantage is that when you go back to read the code after a month you can tell what's going on.
2) Perl's alarm doesn't work on the windoze platforms (sometimes in the corporate environement they make you use windoze), Ruby's timeout does.
3) Threads - With perl you actually have to compile a special threaded version. Ruby threads work - even on windoze.
4) Ruby has dRuby a distributed object system that is very easy to use (compared to SOAP, and other XML based approaches).
5) Hashes, arrays, strings have many more builtin functions (methods since they are objects) than Perl's Hashes, arrays and strings.
6) ease of writing extensions in C for Ruby(thoug