Follow Slashdot stories on Twitter


Forgot your password?

Programming Ruby 169

While Ruby isn't new, it's one scripting-and-everything else language which has yet to break out (in the U.S. at least) the way Perl and Python have. Chromatic may help buck that non-trend -- he says that Ruby is one polished gem of a language, and below he introduces a book on Ruby that he compares in importance with the O'Reilly Camel book.

Programming Ruby
author David Thomasand Andrew Hunt
pages 564
publisher Addison-Wesley
rating 9
reviewer chromatic
ISBN 0-201-71089-7
summary A no-nonsense, clear guide that's as clean and usable as Ruby itself.


The Scoop

Ruby is a growing language that combines the power and conciseness of Perl with the Smalltalk object model. Though popular in Japan, it hasn't reached its potential in English speaking countries, lacking appropriate documentation. Enter Dave Thomas and Andy Hunt. On the heels of The Pragmatic Programmer, they've produced the Ruby equivalent of Perl's Camel.

What's to Like?

Programming Ruby starts with a general language overview. A dozen short and sweet chapters form this tutorial. Readers with no programming background won't feel too out of place, though they will need to be comfortable with terminology explained once and used throughout the rest of the book. Topics range from language basics to multithreading and using the debugger. Rather than starting from syntax rules, the authors introduce concepts as their context dictates. There is some conceptual overlap between chapters, but this approach is preferable to discussing one topic at a time, referring briefly to future chapters.

The next section shows how to connect Ruby to other languages and tools. Besides information on Ruby modules and the command line, chapters include CGI programming, Ruby GUI programming with Tk, and automating Windows. The chapter on embedding Ruby in C is short but comprehensive. Within the 200 pages of these two sections, experienced programmers will have learned enough Ruby to be quite productive.

Section three expands further on the core language. Though covering the same areas as the tutorial, these chapters delve into the gory details. (As gory as Ruby gets, which is to say, surprisingly little spit and bailing wire.) Thomas and Hunt write with the authority of language designers producing a standard reference. Chapter 19, Classes and Objects, particularly stands out. It describes Ruby's simple object model, using a handful of well-chosen examples and clean diagrams to punctuate the point.

The final section takes up nearly half of the book. This library reference lists Ruby's built-in and common classes and objects. Each class has a description, a named parent, and a list of mixins and class and instance methods where appropriate. Modules fare similarly. Most explanations include common usage examples.

Four appendices and an impressive index round things out.

What's to Consider?

Ruby itself makes a fine starting language. To get the most benefit from the book, it's handy to have experience with OO programming and a similar scripting language. (Python and Perl hackers will have little trouble, Smalltalk coders will feel right at home, and Java and C++ fans will do well.) Beginning programmers won't have their hands held for very long.

A handful of advanced concepts are mentioned but not explained. This is only a minor gripe -- techniques like runtime code generation are beyond the scope of the average hacker's needs. The flexibility of Ruby's object model and the loose distinction between compile-time and run-time obviate the need for much of this trickery anyhow.

Some might find the class reference section slightly hard on the eyes. The repeated horizontal lines are visually distracting -- indentation would improve readability. On the positive side, the class, library, and module sections are arranged alphabetically, with a tabbed margins to improve navigation.

The Summary

This attractive tome ought to be on the desk of any serious Ruby programmer -- and Ruby itself deserves consideration as a clean and powerful development language. Aimed at moderately experienced programmers, Programming Ruby is a great introduction and a handy reference. Read it online here!

Table of Contents

  1. Roadmap
  1. Facets of Ruby
    1. Ruby.New
    2. Classes, Objects, and Variables
    3. Containers, Blocks, and Iterators
    4. Standard Types
    5. More About Methods
    6. Expressions
    7. Exceptions, Catch, and Throw
    8. Modules
    9. Basic Input and Output
    10. Threads and Processes
    11. When Trouble Starts
  2. Ruby in Its Setting
    1. Ruby and Its World
    2. Ruby and the Web
    3. Ruby Tk
    4. Ruby and Microsoft Windows
    5. Extending Ruby
  3. Ruby Crystallized
    1. The Ruby Language
    2. Classes and Objects
    3. Locking Ruby in the Safe
    4. Reflection, ObjectSpace, and Distributed Ruby
  4. Ruby Library Reference
    1. Built-in Classes
    2. Built-in Modules
    3. Standard Library
    4. Object-Oriented Design Libraries
    5. Network and Web Libraries
    6. Microsoft Windows Support
  5. Appendices
    1. Embedded Documentation
    2. Interactive Ruby Shell
    3. Support
    4. Bibliography

Besides reading online, you can purchase this book at ThinkGeek

This discussion has been archived. No new comments can be posted.

Programming Ruby

Comments Filter:
  • by Anonymous Coward
    Do we really need another Dave?

  • by Erich ( 151 )
    The readability and maintainability of perl with the blazing speed of smalltalk! This is even better than Java! Count me in!
  • It's ironic that a language so villified for its OO support by OO fanatics has better real-world code reuse - one of the promises of OO techniques - than pretty much anything else.

  • You need Perl 6. Please stay tuned.
  • Yes, Ruby is a cool language. The coolest thing about Programming Ruby the book is that it's libre, free as in free speech, even according to the Free Software Foundation.
  • Ugh, that's scary.

    The C Shell has to be one of the worst things ever created for scripting. It was designed specifically for interactive use, and does not work well as a scripting langauge.

    If you're going to write shell scripts, you should generally use the Bourne Shell. It's standardized, found on every unix machine in the world, and was designed to be a reasonable scripting language, as well as an interactive language.

    Also, read csh Programming Considered Harmful [] for a well written and comprehensive analysis of the numerous problmes with C Shell scripting.

    Now, as to scripting in general, the above statement is complete and totally untrue. You should use the best tool to get the job done, regardless of whether that's a sh script, a perl script, a python, ruby, scheme, lisp, etc, script. Or, if a script isn't appropriate, you should use a compiled language, such as C, C++, Java, assembly, etc.

    The choices available are as many as the problems they're used to solve. Find the right tool for the matter at hand, and stop trying to force square pegs into round holes.

  • Ruby stands to perl (quick and dirty programming) or PHP (perl for people to stupid to perl) as Objective C does to C++ or Lisp to a useful programming language. They are great in the laboratory, and for pointy-headed geeks to play with, but they are completely useless in practice.

    Objective-C will serve you better ( practically! ) than C++ in some situations (GUI frameworks or other places where dynamism count). C++ will serve better in others (systems programming or where performance counts). Lisp is a fantastic language for list processing (surprise) and has many applications in artificial intelligence.

    Pick the right language for the job
  • by chrome ( 3506 )
    I'm not sure about ruby.

    I have a friend at work here who loves it, thinks it's the greatest thing since sliced bread. It can do threading and all the other kinds of tricks you would expect a modern scripting language to have, but its syntax and keywords are confusing to say the least.

    I don't see why any company would introduce Ruby as their scripting environment since everyone else knows perl? You'd have to train everyone up on Ruby.

    I think it's too late to bring in a new scripting language unless its *lightyears* ahead of anything else, and Ruby is not lightyears ahead of Perl.
  • ...ported from Perl to Ruby, I have no doubts about its value: We had about two years worth of code in Perl, including some difficult problems relating to aspect-oriented programming and code generation. Within weeks our Ruby version caught up and we are now way ahead of where we would have been had we stuck with Perl.

    druby saved us a lot, and the Smalltalk-style mix-ins (what others might call "OO interfaces") completed the package.

    All of this could not been possible without this book because the Japanese-language docs do not Babelfish well. (Because the concepts are very abstract, the translations become incomprehensible to the point of providing quite a bit of unintentional humor.)

    One caveat, however, about the language and this book: Ruby is VERY object-oriented. Otherwise it makes a good first language. But OO languages are not usually taught to beginners, and I haven't seen anyone really figure out a way to explain object-oriented concepts to newbies.

    This book makes a cursory attempt to do so in the beginning chapters, but it is less than totally successful. Thus I would recommend this book more to experienced programmers than to beginners.

    Perhaps Perl will face this same dilemma with Perl 6 (which is looking more and more like Ruby, as I read the proposals, etc.). I don't think an OO for beginners book is impossible <note target="Tim O'Reilly">I'd even be willing to write it</note> and Ruby is the language to do it for. But this book is not it.

    The Ruby archive is still sparse compared to CPAN, but the code is clean and functional. If you are a young programmer looking to make a name, this is a great place to contribute code which will be used. Ruby is fun to use, and you can use CPAN as a guide for what is needed.

    The only really big hole in the Ruby archive is the lack of a fully functional DBI equivalent. The DBI architecture (a clearly defined interface which is theoretically usable with all database-specific implementations) is ideal for Ruby's capabilities. Hopefully someone is working on such a class for Ruby. (I also hope the specific implementations will not break the interface quite as often as Perl's DBI is broken. Perhaps we can learn from past mistakes.)

    My prediction: As dynamic code generation and meta-objects really come into their own, Ruby will become a major force.
  • We're working on that problem specifically. We've got a CGI templating system that is really superior and really object-oriented (i.e. perfect for Ruby). We're porting it to Ruby.

    The only holdup is it requires Text::Balanced (a truly incredible piece of code) and Parse::RecDescent. As soon as we have those ported (and Damian Conway has offered help), we'll be able to post our templating system.

    DBI is another kettle of fish, however. I hope somebody is working on it. We do have a TableAdapter interface which gives us a really good OO interface to databases designed to hold complex objects. But DBI offers a better interface for strictly SQL-like stuff. It is not trivial, especially if you're trying to offer one interface which works for many different databases (which is the idea of DBI).
  • So would that be 'roobi', 'loobi' or 'ryubi'?

    ; )

  • The major advantage of Ruby that everyone seems to be overlooking is that it is built around the principle of least surprise, and had a very simple and intuitive syntax. It is also a dynamically-typed language. There is no need to consult reference manuals, or sit thinking about the correct sequence of brackets, braces, parentheses, asterisks and arrows to express the ideas in your head. Code just flows from your fingertips.

    Because Ruby code costs the programmer so little effort to write, experimentation becomes easy and fun. If a simpler and more elegant solution presents itself, it is easy to rip up code and start again because there are no memories of hours of blood, sweat and tears getting that code to work. The result is clean and robust code that, looking back, was a joy to write.

  • Yes, I am actually a programmer. A professional programmer, too. I'll try and write using simpler language:

    Ruby is so easy to use that you can spend most of your time thinking about the problem you're solving and very little thinking about the language you're writing in. You end up with good code and you don't overheat your melon in the process.

    Better? =)

  • True, True.

    The fact that it's being sold doesn't make it worth buying.

    I think the same hidden conspiracy that gave us "Server push" (remember when that was going to save the world?) is behind the constant flogging of the object-oriented approach to programming.
  • >> isn't a comment in Ruby; it uses # as a comment symbol. The lines like "2+2 >> 4" you saw in the tutorial were annotations by the tutorial authors, saying "that expression evaluates to this".
  • One can argue that java was different, because it was initially released for an in-browser operation of applets,

    EHH? Java was "initially released" as a cross-platform language and compiler. The applet was simply one of the language's uses. Try this link [].


  • I have some simple performance comparisons of Python, Ruby, and Lua on my ScriptPerf page at: []

  • For those looking to get started, I recommend that you check out The Ruby Cookbok []. (Not dead trees, just web-based.) It's quite helpful.

  • In Ruby, 'self' is spelled '@'.

    As in Moria and Angband. Now that cools (cool and rules).

  • >> isn't a comment in Ruby; it uses # as a comment symbol.

    What decent language can overload the comment symbol in this fashion?


  • by toriver ( 11308 )
    ASP is not a programming language. It's a mechanism for using Windows Scripting Host server-side. The host language can be any of VBScript (apparently what people think of when they write "ASP"), JScript, ActiveState PerlScript or Python. Possibly others as well.
  • Of course I noticed it was inside a string. I have no problems with any symbols used inside string literals or whatever - the parser should not see them as language elements.

    But as you point out, they are treated as language elements. and hence they are "overloaded" with respect to the use as comments. My point still holds.

  • Maybe one day, someone will invent a scripting language that a) Doesn't have a moronic syntax & b) Actually does something useful.

    Javascript? True the function prototype-style objects are kinda messy, but I'm fairly comfortable with it. (Before the pop-up haters attack me, try it with something other than a browser DOM.)
  • I've rewritten a bunch of my perl scripts in ruby and I've found that the perl versions tend to be faster but the ruby versions are MUCH easier to understand/maintain. For what I'm doing ruby is "fast enough" so maintainability becomes the deciding factor.

    I use ruby today everywhere that I used to use perl.

  • However, "correctness" is debatable. A (probably large) number of people would say that any programming language that restricts you to single inheritance is not "correct" (despite pragmatic arguments about the real world usefulness of multiple inheritance). Others would argue that the absence of preconditions, postconditions, and invariants prevent Ruby from being called "correct". Yet others might take issue with its exception handling. Or the lack of tuples. Or any number of things.
  • by kaisyain ( 15013 ) on Tuesday April 17, 2001 @06:42AM (#286317)
    I don't think Ruby's lack of documentation has anything to do with why it hasn't broken out. After all, Ruby's web site has tons of perfectly good documentation that any competent programmer shouldn't have any problems making heads or tails of.

    Ruby's main problem is it doesn't offer clear benefits over the existing solutions. For instance, take a look at Ruby's comparison page. It's improvements over Perl are: nicer syntax, different default scoping, cleaner integration of object-orientedness. Those are hardly decisive. Compare Ruby to Python and you'll find a similarly non-compelling argument.
  • PHP (perl for people to stupid to perl)

    While I tend to find some things about PHP annoying in comparison to perl -- PHP is, in most things, just a little less convenient, and I'm used to perl -- I think that comment is just way off. Much better, I think, is Mark Jason-Dominus' view [].

    "In my world, PHP can be a good solution, and Perl can be a good solution, because maybe a problem can have more than one good solution. In my world you use what works, and using PHP can't possibly reflect badly on Perl."

    as Objective C does to C++

    Now I know you're smoking crack. For years, a small group of people called NeXT programmers wrote serious software with ease and speed the rest of the world -- especially the C++ world -- only dreamed of. Yes, back when (and perhaps before) perl was still in version 4.

    And the functional and logical paradigms are VERY useful in the right problem domains (and/or with the right mindset). Which can be said of just about every language. Yes, perl is cool, and multiparadigmatic, and it is the swiss army chainsaw it's touted as, but that doesn't mean that other languages are all useless. There's more than one way to do it.

  • For me it was very much a case of comparing Ruby to Python and finding compelling arguments to use Ruby.

    In my opinion, Ruby is what many pro-Python folks claim Python to be: a better OO alternative to Perl. I find Python syntax painful at best. Whereas I feel comfortable with Ruby.
  • Hmm, I seem to remember about a year or so ago, when python really started to get noticed. I remember reading posts on slashdot with a lot of people saying "why do we need python, we have perl?!". Now it seems that those people are saying "why do we need ruby, we have perl and python?!". Anyone except me see the irony here?

  • I, too, found one of the biggest hurdles with Ruby to be the lack of quickly accessible man-page equivalents for the standard classes; I'm quite spoiled by Perl's perldoc(1), with its ability to quickly look up the syntax of some function or operator while in the midst of writing scripts.

    Well, Dave Thomas (yes, one of the book authors) recently released a program called ri [] (the Ruby Interactive reference), which gives you quick command-line access to the documentation (same text as in the book) for any of the standard classes and methods! Makes Ruby much more programmer-friendly. You can find it here [].

  • If Ruby is a 'correct' language, how does it compare to Python, which I heard described the same way? Python might be stricter in syntax, but are they otherwise similar?

    btw, isn't PHP useful for static pages with some dynamic content, as opposed to almost completely dynamic pages? I mean, if you want to take a standard template and stick the current news story into it, isn't PHP easier because you do up the page and insert of PHP where you want the news story to go, instead of writing the page in perl, were you have more work to wrap an existing page around dynamic content?

    For example - Blue's News ( would be a good case for PHP, where slashdot (with completely customizable pages) makes more sense to go all the way and do the whole thing in perl (or the cgi language of your choice). I didn't think they were targeted at the same area, just that they overlapped in the middle.

    I haven't used PHP, nor really had anyone explain its purpose in life, so this is just speculation.
  • What high perfromance site is using Ruby?

    there's more to programming than web sites. really.


  • Ruby isn't just another scripting language - its a better one. And its not marginally better. Its an order of magnitude better.

    People like perl for two reasons - easy exploitation of regular expressions and hash tables. That's exactly why I started using perl five years ago, and why I still use it once in a while.

    But as has been pointed out by countless people - a perl program shouldn't be any longer than what you can rewrite from scratch in an hour - because its just not worth the expense of learning someone else's big perl program. Its cheaper to figure out what it does and rewrite from scratch. These efforts to extend perl, add OO, build up CPAN, etc. are ridiculous. Like fitting Concorde wings onto a Volkswagen beetle. A reusable perl module is an oxymoron; perl is about regexps and hashes - its offers nothing to aid modular reusable programming - and that's largely exactly why its so good as duct tape. It cannot be both good duct tape and a secure, reliable environment for writing reusable modules. Sure CPAN is huge and heavily used. But its just a big semi-organized pile of duct tape. Citing the size of CPAN is like saying there are so many Winblows programs that Winblows must be the best OS.

    Python was is often presented as a pure OO language - a better perl. But if you like OO, python is just OO enough to make you wish you really had OO. A minor annoyance is that you have to explicitly pass "self" to methods. A major annoyance is that, as in java, there are data structures that are not objects - thus you have an unnecessary and uncomfortable mix of methodologies.

    Ruby nails it to the wall. Its is as pure OO as a non-statically typed language can be; if you like OO you'll like Ruby, if you don't then move along.

    But the real leap in Ruby is its iteration control. This is where Ruby truly is superior to Perl and Python and worth switching to.

    The iteration control is a dynamically typed version of the "iters" introduced in the Sather programming language from Berkeley. Just as Ruby is the finest scripting OO language, Sather is the finest statically typed OO language.

    My goal is to be a great programmer, make lots of money and do cool stuff with computers. Sather and Ruby have helped me to do those things. CPAN just wasted my time.

  • Don't forget the people saying, "There are a bunch of modules available for Perl, why should I use a language that doesn't have stuff like CPAN and mod_perl already written for me?"

    It sounds like some of the less-convincing Windows advocacy. "There are a lot of programs available for Windows, why should I use an OS that doesn't have as many programs?" "Windows works well enough and a lot of people know it - why do we need another OS?" Those are just lazy attitudes - reject something new because it's new, not because of a comparison of its merits with what came before.

    That's not to say "new" stuff doesn't have to justify its existence. It's just that "Something already does something like that" isn't a good enough reason to reject something new out of hand.

  • Ruby's main problem is it doesn't offer clear benefits over the existing solutions.

    Yep, the cryptography world is similar to this. You have a lot of newbies offering up impenatrable algorithims demanding they be broken without realizing they are offering nothing that is not already available and worked on. Some are snake oil salesman others are well meaning but ignorant.

    It is generally good that choices exist, but, let's face it every language that comes down the pike will have an evangelist behind it. Doesn't mean there is any substance there. Most people will be using what the company wants to anyway.
  • You can find out about mod_ruby here:
    mod_ruby [].
  • Well, Java is both an API and a language. Witness Jython, which is a Java-based Python interpreter that uses Java APIs instead of standard Python APIs to handle things like graphics. Perhaps I should've been more clear about the fact that Java's AWT & Swing APIs are much cleaner and easier to program for than Motif & X Windows. GTK, however, it a thing of beauty compared to those two. I do find Java's way of doing things a lot more intuitive than even GTK's way, though. While AWT & Swing are "merely" evolutionary, rather than evolutionary, they exemplars of simplicity and clean design -- especially Swing, which makes even AWT look clunky in comparison.

    (I didn't know Java could do PS generation as a builtin feature. That's kind of cool.)
  • I can't believe you used Motif and X Windows as examples of good procedural APIs. They're horrible to program in! If you want a good, clean procedural GUI API, look at GTK.

    However, give me Java anyday for writing GUI apps. The well-constructed OO model and exception handling in Java's GUI framework is simply a thing of joyous beauty. It makes writing event-driven windowed apps a joy. Motif and X Windows (especially when you start worrying about internationalization) are not anywhere nearly as well designed. Sure, they're old, large, and widely used. That doesn't mean that they work well or that they can be considered "mature." Both are examples of hacked together standards attempting to please all the people who had implemented proprietary solutions before. ICCCM alone makes X Windows a hideous beast. There is simply no comparison.
  • Ruby implements multiple-inheritance type stuff using "mixins."

    Sorry, but there's really no complete substitute for true multiple inheritance. Yes, mixins or interfaces might be preferable in the vast majority of cases, but if you hit a case where MI is the right approach and it's not supported then that sucks. At least Java had the excuse that it's hard to reconcile MI with code mobility. It seems to me that a lot of language designers are inventing alternatives to MI as much to get out of the work of implementing it as for any other reason, and then trying to rationalize their choice after the fact with a wall of academic BS.

  • much clearer syntax for things like instance variables (non of this execrable 'self' gunk that python forces upon you).

    There's a reason for 'self' in Python, which is that if you don't distinguish local variables from instance variables then you can forget which something is, and then you either have to go hunting for the declaration or you risk getting yourself in trouble. Ruby acknowledges this by using '@', which is easier to tune out (which is dangerous) and contributes to the "line noise" appearance of the language (beloved of Perl weenies, loathed by real programmers) without actually adding anything compared to "self".

    Python and Perl always feel like procedural scripting languages with some OO bolted on

    While the object model in Python is less than complete, it's generally only noticeable in some edge cases, and objects are far from "bolted on". They've been there since Day One, and they're integral to the language despite their incompleteness.

    That actually leads into a question: can you create dynamically-loaded modules containing first-class extension types in Ruby? The not-quite-first-class nature of Python's extension types has always bugged me quite a bit.

    And iterators -- baby, they are the coolest

    Yes, they are very cool, though I'm not as convinced as you seem to be that they always improve readability. I think in some cases they can have the opposite effect.

  • This being the sort of place that it is, some people will probably not realize you're being sarcastic. It wouldn't hurt to add explicit markers so that people won't flame you for being an idiot.

  • If you want the length of a string:

    BFHD. Yippee. I just don't find x.length all that superior to len(x). If "length" acts *exactly* like any other method - e.g. accessible by name, can be passed as a bound method, etc. - then maybe there's a certain aesthetic coolness to it, but other than that it's pretty meaningless.

    You can never get overflow, numbers are automatically converted to the Bignum class if they get too large

    That's actually a bad thing, IMO. I'd prefer that the language not try to "save me from myself" by doing such conversions behind my back. Give me an overflow exception, please.

  • I'd rather Ruby (and Python) did the scoping without *any* lexical gyrations.

    From a compiler or interpreter writer's point of view "@" is more of a lexical gyration than "self" - which is just an entry in a namespace, not syntactically interesting at all.

    Part of the problem with Python's object model comes from how it is introduced. If you slog through the books, or th tutorial, it really gets short shrift.

    That's simply incorrect. Both the tutorial and the book - I assume you mean the Lutz book - give OO a quite reasonable amount of attention.

    And once you get used to the concept of iterators (we are all used to the concept of classes, loops, etc.), iterators are marvelously clear.

    Perhaps so, perhaps not. Almost any language construct can be used to obfuscate code, and iterators are no different. Also, while I'm not generally in favor of catering to the lowest common denominator, the fact that iterators are slightly "exotic" with respect to other common languages does have implications for readability.

  • Personally, I find ruby a lot simpler to use -- but python is always my second choice, and I have to be dragged into perl...

    We all have our own tastes and biases. Personally, my few complaints about Ruby are pretty similar to many people's complaints about Python. For example, the #1 complaint about Python is obviously the whitespace thing. I have to admit it's not my favorite feature and I might very well have made the decision differently in GvR's place, but that's the way it is and instead of whining I cope and get on with my work. So maybe it doesn't make sense that I find many of the "cosmetic" or secondary aspects of Ruby so infurating. For example:

    • Perlisms such as "@" and other syntactic markers make me ill.
    • Using ">>" as a comment delimiter just feels wrong.
    • The syntax for iterators is ugly. While the idea seems cool in the abstract, the more I think about iterators the less I like them. In general, I'd prefer that complex behaviors be encapsulated in functions or objects, not in arbitrarily complex expressions that end up spreading over several lines. If you want that, use LISP.

    None of that should bother me, but it does. I also have more substantive complaints with Ruby, just to show that appearance isn't the only thing I care about:

    • The private/protected/public stuff borrowed from C++/Java is just crap. IMO a language should either have a real data-hiding system or just do without (like - surprise! - Python).
    • Mixins just aren't the same as multiple inheritance. No, they're not. Really.
    • Ruby advocates love to justify mixins by pointing out how much trouble you can get into with MI - and then Ruby supports operator overloading, which is the #1 most effective mechanism used by C++ programmers to make a mess of things. I've heard that overloading can be done right, but I've stopped believing the claim. I've never once seen a real-world example, and many coding standards rightly disallow this blighted misfeatures' use.

    To be fair, Ruby also has its strenghts:

    • Making everything a first-class object, accessed similarly, is at some level The Right Thing To Do.
    • Virtual attributes are a good thing.
    • Real GC is a good thing.
    • It looks like the extension interface does allow subclassing of C types, which would be a nice thing to have in Python.

    So, when you add it all up, what do you get? Basically, Yet Another Language. Sure, it has some neat aspects. It also has some warts. Just like Python, pretty much (see my web page for some discussion of Python's warts). As a first script language, Ruby seems very much worth consideration, but I don't see any reason why someone already familiar with a decent language - almost anything but Perl or Tcl - should switch. In particular, for large or long-lived projects, I think Ruby's borrowing from Perl and C++ raises some genuine doubts about maintainability.

  • The thing is, ".length" is something you always can use. While len(x) only works for a limited set of types.

    Again, big deal. It's not actually *useful* for x.length to return a value if x is an integer. The only possibly meaningful value for an integer would be the size of the integer, which is (a) not the same concept as the length of a list/array/hash, and (b) might change anyway due to Ruby's sneaky bignum conversions. In fact, having x.length return a value for an integer could be a source of error. If I expect an integer in Python and apply len() to it accordingly, I get a nice juicy exception to tell me I screwed up. If I do the equivalent in Ruby, I get a value and go blithely on my way to screw things up even worse.

    No, thanks. Orthogonality is nice, but sometimes life just doesn't break down into nice orthogonal pieces. It's like the old saying about things being as simple as possible, but no more so.

  • * Perlisms such as "@" and other syntactic markers make me ill.
    It's like scope by indentation, but much better ...

    Other than your personal (anonymous) opinion, what argument can you give for it being better?

    * The syntax for iterators is ugly.
    Try using them ...

    Been there, done that, not in Ruby but in other languages. I stand by my claim that Ruby's syntax for them is ugly. I would much prefer a statement-like syntax over that gobbledygook.

    Ruby has overloading only by different number of arguments, if that matters.

    Untrue. It also has operator overloading, which is the most heinous kind.

    While we're here, let's consider another of Ruby's warts:

    return @songs[i] if key == @songs[i].name

    That's straight from the Ruby book (chapter on blocks and iterators) and it's a construct only a Perl weenie could love. Let me give a non-programming equivalent:

    To defuse the bomb, cut the red wire...if there's no blue wire.

    Good way to get blown up, eh? Really, there's just no excuse for countertemporal counterintuitive crap like that in a language.

    As I've said before, Ruby has some good features but also some warts. At least it's not all wart like Perl or Tcl, but there are other languages that also have good features and some warts. Compared to those languages, the case for Ruby's superiority is extremely weak at best. Use it if you like, have fun, be productive. More power to you. Just don't try to act all superior because your language choice is better than someone else's.

  • Well, everyday on Bugtraq I see tons of examples of programmers who need to be saved from themselves.

    You're seriously misinterpreting the significance of what you see on Bugtraq. Those are the results of programmer errors that *weren't even caught* but we're talking about what should happen after the error is caught. The problem with trying to "save programmers for themselves" is twofold:

    • Truly saving the programmer would mean guessing correctly what the programmer really meant. Software - written by other stupid programmers - can't do that with any accuracy. More often than not, you just end up exchanging one kind of error (e.g. wraparound to zero) for another (e.g. counting to infinity). Quite often, you'll be worse off than if you weren't trying to be so "clever".
    • If you cover the programmers' asses, they won't learn to cover their asses themselves. They will persist in sloppy habits, sooner or later they'll encounter a situation where the safety net they've come to rely on isn't there or is faulty (see above), and they'll create still more bugs.

    The alternative, which I and a great many others (who've either studied this carefully or learned the hard way) prefer, is not to mask errors but to make them as explicit as possible as soon as possible. Force the *programmer* to make the decision about what should happen in that boundary case. If you can't do it with an error at compile time, do it with an exception at run time. The programmer will have no choice but to provide a *real* fix, and both the software and the programmer will be better for it.

    If you're worried about an unhandled exception causing a crash, don't be. My experience in both high-availability systems and in security has taught me that a crash is better than a hang every time, and *way* better than the spooky unreproducible non-linear behavior that often results from software that tries to second-guess programmer intentions.

  • What is the point of throwing an exception if a number is too big? Hey Computer Language/Program, I told you to multiply two numbers, so you just do it.

    What if the result is bigger than it was ever "supposed to be" according to some program-specific constraint? What if an index or hash or address calculated from the new value causes you to trash memory or return the wrong data? What if it only happens once in a while, and you never knew the offending code had anything to do with those mysterious crashes that just seemed to happen "every once in a while" so that you *thought* it had gone away but you actually shipped with the bug still there? Undisciplined programmers might not like it, but being forced to think about and deal with boundary conditions properly is A Good Thing for software quality.

    And if you ask me, counting to infinity is preferable to wraparound.

    For you. In your opinion. Not for everyone. That's just the problem: languages that do these sorts of things are making decisions that programmers should be making. Sure, having an integer type that can handle larger sizes but that uses more efficient smaller ones when the values fit might be very convenient, but having that be a default, unchangeable property of the smaller integer types is bad.

    If the programmer really wanted a wraparound, then the programmer would be more likely to think of writing it in.

    And if the programmer wanted to handle large integer values, they should use a large integer type. The point is that *the programmer should choose*. If you have an exception, you can catch the exception and choose what to do with it, but you can't just punt. If you want to switch to using larger integers, fine. If you want to allow wraparound, fine. If you want to treat it as a fatal error, fine. What's important is that you as the programmer have to make an explicit choice about what to do. Abdication of that choice, expecting the language to take up the slack, is not an option.

    I've written machine code programs where cycle counting was important - all the various paths had to take exactly X cycles. Maybe I'll do that sort of stuff again if I have to, but to do nitty gritty stuff like this for every program is a waste of time.

    That's exactly it. If it's such a waste of time worrying about nitty gritty stuff like integer sizes, then why are you obsessing over just using a bignum for something that might hold a large value? It's just not a problem for most people or programs. The int-to-bignum thing is purely a performance hack; if performance is that critical you shouldn't be using an interpreted language anyway, and the difference between multiplying ints or multiplying bignums only matters to the cycle-counters. People who write in Ruby - or Python, or Perl - should be focusing more on program correctness and functional issues than on micro-optimizing interpreted code or expecting the language to do it for them.

  • You miss my point I'm not obsessing about using bignum. I'm obsessing about numbers just being numbers in a high level language.
    I just want _numbers_

    So just use bignums, not automatically-promoting small integers. Your numbers will just be numbers, and you'll never have a problem. Small integers should only be used in a higher-level interpreted language when it's *important* for them to be small numbers, and therefore probably important for them to *stay* small numbers.

    I not a great programmer, so I'd let the experts do that sort of stuff.

    So maybe you should listen to those experts when they say that *if* you took the trouble to specify a particular integer size other than the largest available you probably mean for it to stay that size.

    But so far looking at Bugtraq, there aren't that many experts in writing bulletproof stuff in low level languages.

    Auto-promoting integers won't help with that. In fact, Ruby won't help with that. If you want to approach that particular problem (secure systems) at all through language design, you'd have to go to a language with at least some of the following features:

    • Mandatory specification of actual integer ranges, with strict checking.
    • Total type-safety.
    • Strict access checking (e.g. capabilities).
    • Sandboxing.
    • Enforcement of arbitrary programmer-defined correctness conditions (not just assertions).

    Does Ruby fit that requirement? No. Nothing that borrows so heavily from Perl will ever even come close. Among widely-adopted languages, Ada or Java probably come closest, and there are a bunch of academic languages that go even further. Ruby might eliminate a couple of classes of security problems arising from overflows and such, but the same could also be said for most other scripting languages. Python, Perl, or Tcl programs are as secure as Ruby programs, and VB less so only because of usage rather than the language itself.

  • It's as convenient as having an automatic transmission in your car. No need to shift manually. That's one of the reasons why I use those sort of high level languages.

    And I drive a manual, because I have yet to find an automatic that shifts in a way I consider reasonable. ;-)

  • I knew Perl, and I know Python. Your statement about Ruby can be said about Python over Perl, yet people are now loving python, Ruby has it's place, Python has been around as long as Perl, yet look how many people are using it. The same is why Ruby hasn't broken out, it takes time for new languages to become accepted. In Japan, Ruby has broken out, much more popular than Python for sure.
  • yes, pretty much all modern languages are coming with huge libraries, java, python and ruby of course is doing the same.
  • by segmond ( 34052 ) on Tuesday April 17, 2001 @07:05AM (#286344)
    I am afraid you don't know ruby, Ruby is what Python should have been + 100. I say this as a passionate python lover, I have known about ruby for sometime, and really respect it tho I haven't adopted it fulltime yet. Your comment is exactly what some people said about Python, dare you say that anymore? In Japan, people/companies are doing lots of productive work with Ruby, you need to grow up, Man, even functional languages are being used to solve real problems. I suggest you go to ruby's site, read up on the tutorial, there was an article on dr dobbs journal a month or two ago on ruby, read that too, and perhaps you will eat your words.

  • there _is_ a mod_ruby and an eRuby for embedded code. Jeez! You folks oughtta at least look around before saying stuff like that.

    Check out the application archive, there are a lot of really cool things being developed for this language.

    Personally, I am writing a wicked web served system with ruby. This language is wonderful -- Please don't be fooled by these posts... I feel such a bad energy here on slashdot where so many people (supossedly openminded, smart people) slag on something because it is new and is trying to be better. goodness!
  • You posit exactly no backing or evidence in your post. Ruby is _not_ sold in fact. It is free to use and its authors make no effort to "sell" it.

    So... what exactly do you mean when you say... well. everything you said. You sound like a Pointy haired boss, or Phillip Greenspun. or something like that.
  • Ruby implements multiple-inheritance type stuff using "mixins."

    You should really check it out. 9 out of 10 ex-Perl/Python junkies agree that mixins are super-way-cool!
  • I really don't know what any of this has to do with Ruby. Ruby is a different language from the rest of them, like any language is. Man, you all sound like you haven't read anything about the langauge at all. You should, all you are doing by not making the effort to learn about it is keeping yourself away from what might become your langauge-of-choice. I'm certainly glad I checked it out.

    More importantly: This book is __great__ it is a very very clear into to bothj Ruby and OO programming. I understand OO principles much better having read it. You all oughtta check it out. Also "The Pragmatic Programmer" by the same authors.
  • Ruby's doc handling tools are both:

    very similar to Python's and Perl's, bit so similar to LISP's.


    totally user extendable.

    so, what is the problem? Oh, you wanted to sound like you knew it all.... That _can_ be a problem.
  • Code maintainability is by some accounts the _main_ attribute of any langauge. Have you ever spend three weeks decoding someone's perl code ona production system? This kind of thing is a big problem.

    It is easy to write clean, modular, readable code in Ruby. It also helps that it is as or more OO than Java but with great additional features. Also the irc and mailinglist community is superior to any I'ev been involved with. It is really is a great langauge to look into. And this book is also very very good.
  • um. eruby is simple, if that's what you are pointing toward. It allows you to embed Ruby code into HTML. That's all. I personally have been working on an extensive web backend using ruby and found it to be a delight to use, to have no noticable performance issues that I have seen and to be a peer in every way to Perl and Python with the execption to pre made modules, etc. But that is what I am working on after all.

    People: Don't worry, Ruby is not going to _make_ you use it. Seems like a lot of folks are pretty defensive against this lang for some reason. I think that the proper response is to check it out, do the Hello World and the Fib examples from the book, which is free to read cover-to-cover online, and see what you think.

    BTW: please, everyone, check out some books that are not O'reilly. You'll be doing yourself a favor... My personal feeling is that O'Reilly books are lagging in quality more and more often these days.

    I guess I'm rooting for the underdog as always:

    Blackbox as windowmanager,
    vim as editor,
    mutt as mailer,
    ruby as language of choice.

    Everyone using something does not make it the best choice. A tool that does everything is not the (oldschool) UNIX way. The right tool for the job.
  • I feel that learning perl is an excellent book fro using Perl procedurally -- as a scripting language. I have had very mixed feelings about "Programming Perl," though. I feel it is very rambling and disorganized. "Programming Ruby" is written in a way that allows you to read the first 100 pages straight through and comprehend it.
  • yes, pretty much all modern languages are coming with huge libraries, java, python and ruby of course is doing the same.

    CPAN's a bit different - it's not a load of libraries which come bundled with perl. It's a gigabyte-sized online archive of perl modules (classes etc.). This mean's it's filled with far more weird and wonderful junk than you would ever want to bundle as a default library. For example, Mac::Apps::MacPGP. Or HTML::Embperl. Or Apache::GzipChain. Or Parse::RecDescent. Or Statistics::MaxEntropy. You get the idea; tonnes of stuff for all sorts of different jobs, of varying quality, ranging from the indispensible to the utterly useless.

    Once you get into the habit of using it, it saves you a lot of time reinventing stuff. Why write your own postcode/zip-code/phone-number/ISBN validator when someone else has done it already? Why sit around trying to kludge your own XML searching when there's XML::XPath and XML::XQL?

  • All these ($%@;\) make perl unreadable and undistinguischable to line-noice.

    So chucking all your scalars, hashes, arrays and subroutines into the same namespace is somehow wiser than learning a simple mnemonic like $calar, @rray and %ssociative_array?

    I see there's an argument for doing it but I don't think it's as clear-cut as you make it sound.

  • One can argue that java was different, because it was initially released for an in-browser operation of applets, though I don't think that would be a good point considering the direction towards server-side that has really legitimized java.

    However in Java's case, I believe that the difference lies in the way that it was introduced. It was hyped (arguably over-hyped) by Sun upon its release, which assured a good corporate backing and thus a developer base. If you look at something like Ruby for aexample, it's a language that was quietly released, with noone hearing much about it. So whatever it's merits, it's a far cry from being established as an industry standard.

    Which means it will be more difficult to learn, to get help with, to troubleshoot and to maintain.

  • I meant to point out the difficulty in maintaining code written in the language. If your Ruby programmer leaves ofr greener pastures and the project needs an update (either due to spec change or a newfound bug), you're stuck with having to train another guy in Ruby for no other reason than making a few small changes to the existing codebase.
  • Thanks for the link. I believe that the very first result on the google search (which was a pretty interesting read) proves my statement. I didn't say java was developed for its applet functionality. But it's this functionality that was seized upon by both the industry and the media, a fad that allowed Java to gain acceptance and then move to the server and embedded markets where it is now used most.

    It was because Sun saw the trend and seized on the opportunity of the largely useless but very hip sounding applet technology that Java is a major player in today's market. This is exactly the sort of novelty that so many new languages lack and that therefore prevents them from making a substantial splash.

  • It seems to me that there's currently more languages out there right now than there are programming project types. I mean I can see how you would want one language for a web application and another for a 3d game, but do we really need to have a choice of almost a dozen languages to do just a small variety of tasks? Aren't resources wasted by educating programmers to use a language which, even though it may be slightly better suited to a given task, will not save more time than it takes to master?
  • A minor annoyance is that you have to explicitly pass "self" to methods.

    wrong. you do not pass "self" to methods, the interpreter does that for you. all you have to do is declare your class methods with at least one argument, which is by convention, "self". oh, and yes, i know that you have to pass an instance to an unbound method, but that's not the same thing.

    A major annoyance is that, as in java, there are data structures that are not objects - thus you have an unnecessary and uncomfortable mix of methodologies.

    to which data structures are you referring? iirc, there are a *few* like this in python, but damn near everything is a "first class object".
  • bash$ wget --mirror


  • > Object-oriented programming is way, way overrated.

    I'd vote this down if I had mod-points right now. (-1, uninformative).

    An openly unpopular opinion without any reasons behind it is just a troll. We can't even tell if you are an old-school procedural coder or a functional programmer.

    OOP may not work for you, but it works very well for me and many others. Perhaps your grasp of OOP (what it is, when to use it, and how to make the most of it) is what is overrated.
  • So is linux.
  • by Binary Tree ( 73189 ) on Tuesday April 17, 2001 @07:33AM (#286364)
    "i've been programming for 18 months now and i don't see why we need another programming language. i'd write more, but my mother's calling."

    -- David Thomas, in response to the comments in this article

  • OO may be a pain to write some 200 line program to put a web counter, but if you are actually writing libraries or designing applications that have to be used and maintained, OO is better than its procedural alternative.

  • Yes, but it is easier to read and type, but more importantly, it does *not* appear in the function declaration!
  • While @ is much like self, it IS easier to tune out -- as it should be. If I need to differentiate in the code, I'll do it myself. I'd rather Ruby (and Python) did the scoping without *any* lexical gyrations.

    Part of the problem with Python's object model comes from how it is introduced. If you slog through the books, or th tutorial, it really gets short shrift.

    And once you get used to the concept of iterators (we are all used to the concept of classes, loops, etc.), iterators are marvelously clear.

  • Yeah, I know they are online, but they aren't easily downloaded for my laptop, so i cancode ruby at the beach -- something i did last summer with Python ...
  • You're right in that self is less of a gyration for the compiler/interpreter, but it isn't for me. It's just 4 characters (counting .) longer, and adds no benefit.

    And both the book and the tutorial give it a reasonable amount of attention -- that wasn't my complaint. My beef is that it is introduced relatively late.

    And while iteraters may be exotic -- if we don't introduce some higher level concepts into languages soon, we are just pushing the semantic noodle around.

    Don't misunderstand me -- I use both ruby and perl and have coded 1000+ line programs in each of them in the last 3 months. Personally, I find ruby a lot simpler to use -- but python is always my second choice, and I have to be dragged into perl...

  • by The Code Hog ( 79645 ) on Tuesday April 17, 2001 @06:43AM (#286370)
    I'm sure there will be a raft of "do we need another script language -- isn't python/perl enough?" comments.

    The answer is yes we do -- if it is ruby. Ruby offers a much better OO model than either Python or (gahk) Perl, with much clearer syntax for things like instance variables (non of this execrable 'self' gunk that python forces upon you). Ruby is so OO that it is scary, whereas Python and Perl always feel like procedural scripting languages with some OO bolted on.

    And iterators -- baby, they are the coolest. Forget for loops and while loops for counting, just use the iterators. They are used throughout the language and make your code both small and readable.

    The main barrier for ruby i the lack of online docs for the library -- the original docs are in Japanese. I ended up having to carry my "Programming Ruby" book in my laptop case for reference. That is what I miss most from my python days -- online reference docs.
  • Rubyu sucks (IMHO). I just don't care about its closeness to Smalltalk - that was last decade's problem. What I care about this week are document handling tools and this LISP-like serial concatenation model of document creation just doesn't cut it.
    Someone having a problem understanding the difference between a programming language and a library?


    White Rabbit +++ Divide by Cucumber Error ++

  • by beme ( 85862 ) on Tuesday April 17, 2001 @10:01AM (#286372)
    I don't think so. Different languages do the same things in different ways, and learning new languages can broaden the way you think about solving problems.
    As long as those unsung (and often sung) heroes go on developing new languages, I'll eagerly try to learn about at least some of them.

  • by Tom7 ( 102298 )
    Sorry, no time for the full rant.
    I just needed to let some steam out, and I can spare the karma.
  • As some-one who has recently discovered Ruby after a 5 years c++, a bit of java, and having taught myself the rudiments of Perl, I can only say that ruby does seem to do OO far better than any of the above, IMHO. Quite frankly, I have never come across a language that I have become as quickly productive in.

    The strength of Ruby is not only in its implementation of OO (which is very sweet - especially the iterators), but in that it lends itself to the writing of clean, easy of understand code. So when I go back to my code a few months later, it is *much* easier to understand -even with good comments in place.

    Quite frankly, Ruby is now my language of choice if there are no other important factors to consider. If I need speed, I will go to C or C++. But until I am convinced of that, my number one choice for a language will be Ruby.

    Best regards

  • by ( 114827 ) <> on Tuesday April 17, 2001 @06:44AM (#286396) Homepage
    do we really need to have a choice of almost a dozen languages to do just a small variety of tasks?

    I don't know about you, but I haven't had a "small variety" of programming tasks since the mid-80s.

    Programming Ruby has been on my book want list [] for a while, but based on this review I can tell I'm going to have to move it up in priority.

    I especially look forward to commentary from those /.ers who have used it.

  • by Animats ( 122034 ) on Tuesday April 17, 2001 @08:33AM (#286398) Homepage
    Modula-2 is a very different kind of language. It has two basic properties:
    • It's really hard to get your program to compile, because the language is so strict.
    • Once your program compiles, there's a good chance it will run the first time.

    Hackers hate that.

  • by djberg96 ( 133496 ) on Tuesday April 17, 2001 @06:59AM (#286410)

    There is the "ruby application archive" at

    Yes, CPAN is great and no other language comes close to the support found on CPAN. Of course, there's only one way to remedy that problem and that is to join the Ruby community and actually contribute.

  • I've checked out Ruby a bit, since it looks real clean, not as strict as Java, but more easily OO than Perl.

    Ruby seems like the classic great technology: better than most alternatives, but is likely to not reach critical mass.

    I'm mainly a Perl programmer, that does object-oriented stuff, influenced by my sometimes Java programming. I've found good ways to do clean Perl programming, but the main problem is that everyone has a different approach for doing OO-perl. You can create your own standards, but it's easy to be lax when there is no compliler enforcement.

    So i think a good alternative is to create a Perl pragma that enforces Ruby-style coding conventions, in terms of using built-in objects, exceptions, etc. Basic syntax would still be Perl ($%@;\), but there would be an option for a new dialect of Perl that doesn't require a whole new technology.

    It could be the next "use strict"! What do you think, Perl guys an gals? We could learn a few lessons without throwing the baby out with the bathwater.

  • It's already part of Perl, so why change it?

    If you know Perl, is makes sense. If you change it, it's not Perl anymore, then we're back to the issue of everyone using a new language.
  • by tomzyk ( 158497 ) on Tuesday April 17, 2001 @06:41AM (#286417) Journal
    Thanks for the review. I might have picked up this book by accident!

    I was expecting a book by the mafia and/or the CIA about brainwashing a Dallas stripclub owner named Jack.
  • What is needed is a scripting language-independent compiler/interpreter module for Apache. These scripting languages can be learned in a day or two.

    Then, you could combine languages and use the right scripting language where it made sense. For example, you could use Perl for regular expressions, Java for session management and connecting to the database, and Ruby for processing strings and arrays. Or something to that effect.

    ASP does this - it would be cool to see something like it on Linux/Apache.

  • No, no, no! Not another programming language! I don't care how cool it is.

    Look, I'm doing my best. I've studied Fortran II, Fortran IV, Waterloo Fortran, Ratfor, Fortran 77, Fortran 90, Basic, Basic Plus, GW Basic, WordBasic, Visual Basic, Visual Basic for Application, Visual Basic for Scripting, various Basics targeted at the Java VM, LotusScript, 360 Assember, MIX Assembler, PDP-11 Assembler, HP-3000 assembler, x86 assembler, JCL, Algol 60, Algol 68, Algol W, Pascal, Turbo Pascal, Object Pascal, Delphi Object Pascal, Vanilla Shell, C Shell, Bourne Shell, Z Shell, Sed, Awk, C, C++, Java, PL/I, PLZ/SYS, PLZ/ASM, YACC, Lex, Lisp, Common Lisp, Scheme, Emacs Lisp, Logo, Vim macro language, BRIEF macro language, Make, Gnu Make, SGI Make, SQL, PAL, INGRES query language, Postscript, TROFF, EQN, TBL, TeX, Maker Interchange Format, Rich Text Format, HTML, SGML, XML, and a few others I can't name off the top of my head.

    I'm sort of know Perl but need to brush up on some of the more arcane features. (Not my language of choice, but it's the bloody Duct Tape of the Internet []. Besides, it's the only RE-capable language for which I haven't misplaced the reference manual.) I'm learning Javascript to help out a friend who wants a whiz-bang web site. I desperately need to learn to write DTDs and style sheets. Ditto for those weird little languages they use to describe CORBA and COM data.

    I might learn Python, so I can play with Zope. I'm often tempted to get Lego Mindstorms, though I have no interest in building robots, so I can play with the weird visual programming language.

    I'd like to learn Icon (novel expression of coroutines), Prolog and some of the more AI-ish dialects of Lisp (used in various books I bought years ago and still haven't read), TCL (I don't quite understand why it didn't just die when Sun abandoned it in favor of Java, but lots of interesting Linux software uses it), Mathematica (fascinating use of non-imperative program structures) and Intercal [] (pure perversity) but probably never will.

    And the programmers at work are talking about doing a proprietary scripting language. Really simple and easy to use. Guess who gets to explain to the users why it's so easy to use?

    So forget it! No more languages! My input queue is full .

    Unless it offers something really new and different, of course!


  • This is tooo ironic.
    Allow me to use your sig:
    I love Java. I hate C++
    Why did someone make Java. C++ is object oriented and we have cross compilers. What's the deal?

    Yeah, I know there are huge differences, but for someone that knows C++ well, but just heard of Java, that is usually their reaction.
    I, personally, think that the more languages the better. Learning something new that is very similar to something else isn't a crime, nor a waste IMHO.
  • That's actually a bad thing, IMO. I'd prefer that the language not try to "save me from myself" by doing such conversions behind my back. Give me an overflow exception, please.

    Agreed, but with one caveat. If I want a completely type safe language I'll stick with C++. I'll also expect my variables to be initialized before use, my functions to be defined, etc. etc.. If I want to do a quick and dirty test with access to a nice OO methodology, I'll use a scripting language like Ruby.

    Also, I'm not really familiar with Perl or Python (dated both, but I'm afraid of commitment), but maybe Ruby, or other lessor-known language (what's Dylan like?), is a chance to get in closer to the ground floor and learn as the language is being developed instead of trying to wade through years of mythology, legends, and anecdotal experience. (It'll probably end up as another unopened .zip file in my downloads directory but it's there if I get motivated...)

  • by oingoboingo ( 179159 ) on Tuesday April 17, 2001 @06:50AM (#286431)
    For me the best thing about perl is the huge CPAN library...just about anything you could think of, all categorised and indexed...and the module makes everything really easy to download and install too. i don't see that newer scripting languages like Ruby can take off unless they have a similar centralised mass of ready to go modules...a clean object model can only get you so far when you have to code everything yourself 'cos there's no huge library of modules. does anyone know what the state of the supporting Ruby modules are like? anything approaching CPAN yet?
  • Ruby is sold on the basis that it's a correct language. Unlike say perl or PHP, Ruby has a 'correct' object implementation, with full polymorphism and other advanced features.

    Unlike perl, which is sold on the basis that it's expedient - quick and easy syntax, or PHP, which is sold on the basis that it's perl for morons, ruby makes no bones about doing things the right way.

    This is where it falls down. Ruby is, in effect, the esperanto of programming languages - all fine and correct in principle, but completely useless in practise. Just as esperanto serves no purpose because people already speak English, so too Ruby is useless because it's correct where correctness doesn't matter.

    Ruby stands to perl (quick and dirty programming) or PHP (perl for people to stupid to perl) as Objective C does to C++ or Lisp to a useful programming language. They are great in the laboratory, and for pointy-headed geeks to play with, but they are completely useless in practice.
  • by KevinMS ( 209602 ) on Tuesday April 17, 2001 @12:38PM (#286441)
    I looked into this, the threads arent native, they are implemented inside the ruby interpreter, so you do get the advantage of coding threads, but you wont get any of the advantages of executing threads, like you would want for tweaking performance on multi-cpu machines, or working around blocking calls in a server. Proof if this is that ruby threads work even in DOS
  • Years ago I bought into the hype around Modula-2, buying a compiler and some good books on it. It had it's pluses and minuses. Is this a dead language yet?


  • by Bob Abooey ( 224634 ) <> on Wednesday April 18, 2001 @09:33AM (#286447) Homepage Journal
    For me the best thing about perl is the huge CPAN library...just about anything you could think of, all categorised and indexed...and the module makes everything really easy to download and install too. i don't see that newer scripting languages like Ruby can take off unless they have a similar centralised mass of ready to go modules...a clean object model can only get you so far when you have to code everything yourself 'cos there's no huge library of modules. does anyone know what the state of the supporting Ruby modules are like? anything approaching CPAN yet?

  • Echoing the sentiment of others here, I feel Ruby doesn't offer any great benefits over other, more established languages (Perl, Python...). The list of differences between other languages is far from conclusive: 'Ruby scripts tend to be less cryptic [than Perl]'. Correct me if I'm wrong, but it is possible to write readable code in any language. Similarly it's also possible to write incomprehensible code.

    By the by, I think I've found the last remaining permutuation: I propose a new language: 'Polly'.
    Yes, this innovative language, incorporating the best features of Perl, Python, (Visual) BASIC, Assembler... is not only readable, but can also be easily started by shouting 'Wake up polly' and bashing your computer off a wooden bench.

  • "Ruby stands to perl (quick and dirty programming) or PHP (perl for people to stupid to perl) as Objective C does to C++ or Lisp to a useful programming language. They are great in the laboratory, and for pointy-headed geeks to play with, but they are completely useless in practice."
    Thanks. I might have considered your post seriously, until you wrote this. So perhaps I should take a quick look at Ruby.

In less than a century, computers will be making substantial progress on ... the overriding problem of war and peace. -- James Slagle