Slashdot Log In
Programming Ruby
from the ruby-who? dept.
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
- Roadmap
- Facets of Ruby
- Ruby.New
- Classes, Objects, and Variables
- Containers, Blocks, and Iterators
- Standard Types
- More About Methods
- Expressions
- Exceptions, Catch, and Throw
- Modules
- Basic Input and Output
- Threads and Processes
- When Trouble Starts
- Ruby in Its Setting
- Ruby and Its World
- Ruby and the Web
- Ruby Tk
- Ruby and Microsoft Windows
- Extending Ruby
- Ruby Crystallized
- The Ruby Language
- Classes and Objects
- Locking Ruby in the Safe
- Reflection, ObjectSpace, and Distributed Ruby
- Ruby Library Reference
- Built-in Classes
- Built-in Modules
- Standard Library
- Object-Oriented Design Libraries
- Network and Web Libraries
- Microsoft Windows Support
- Appendices
- Embedded Documentation
- Interactive Ruby Shell
- Support
- Bibliography
Besides reading online, you can purchase this book at ThinkGeek
Oooh! (Score:2)
Re:Interpreted languages must die. (Score:2)
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 [faqs.org] 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.
Having recently seen a major project... (Score:2)
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.
Re: CGI and Text::Template (Score:2)
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).
Made in Japan, eh? (Score:2)
; )
Re:too many tools? (Score:2)
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 [google.com].
--
Ruby Cookbook (Score:2)
-Waldo
Re:Where does ruby sparkle? (Score:2)
why Ruby hasn't broken out (Score:5)
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.
Re:Where does ruby sparkle? (languages are languag (Score:3)
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 [perl.com].
"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.
--
And history repeats itself (Score:2)
Re:Where does ruby sparkle? (Score:2)
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 (www.bluesnews.com) 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.
CPAN is no reason to ignore Ruby (Score:2)
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.
Re:why Ruby hasn't broken out (Score:2)
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.
Re:OOP (Score:2)
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.
Re:Where does ruby sparkle? (Score:2)
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.
Re:Ruby is really nice... (Score:2)
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".
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.
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.
Re:Cool things about Ruby.. (Score:2)
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.
Re:Cool things about Ruby.. (Score:2)
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.
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.
Re:Ruby is really nice... (Score:2)
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.
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.
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.
Re:Ruby is really nice... (Score:2)
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:
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:
To be fair, Ruby also has its strenghts:
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.
Re:Cool things about Ruby.. (Score:2)
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.
Re:Ruby is really nice... (Score:2)
Other than your personal (anonymous) opinion, what argument can you give for it being better?
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.
Untrue. It also has operator overloading, which is the most heinous kind.
While we're here, let's consider another of Ruby's warts:
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:
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.
Re:Cool things about Ruby.. (Score:2)
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:
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.
Re:Cool things about Ruby.. (Score:2)
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.
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.
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.
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.
Re:Cool things about Ruby.. (Score:2)
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.
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.
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:
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.
Re:Cool things about Ruby.. (Score:2)
And I drive a manual, because I have yet to find an automatic that shifts in a way I consider reasonable. ;-)
Re:why Ruby hasn't broken out (Score:2)
Re:..and there's CPAN (Score:2)
Re:Where does ruby sparkle? (Score:3)
Re:..and there's CPAN (Score:2)
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?
Re:use ruby; (Score:2)
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.
too many tools? (Score:2)
Re:Library docs are online (Score:2)
--
Re:OOP (Score:2)
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.
From #ruby-lang (Score:4)
-- David Thomas, in response to the comments in this article
Re:Library docs are online (Score:2)
Re:Ruby is really nice... (Score:2)
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...
Ruby is really nice... (Score:5)
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.
Re:Ruby CGI module's HTML generation methods (Score:2)
Someone having a problem understanding the difference between a programming language and a library?
Pax,
White Rabbit +++ Divide by Cucumber Error ++
Re:too many tools? (Score:3)
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.
-beme
Re:OOP (Score:2)
I just needed to let some steam out, and I can spare the karma.
why choose ruby (Score:2)
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
treefrog
Re:too many tools? (Score:3)
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 [petdance.com] 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.
--
Re:Which reminds me... Modula-2 (Score:4)
Hackers hate that.
Re:..and there's CPAN (Score:3)
There is the "ruby application archive" at http://www.ruby-lang.org/en/raa.html.
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.
Not what I expected (Score:3)
I was expecting a book by the mafia and/or the CIA about brainwashing a Dallas stripclub owner named Jack.
..and there's CPAN (Score:4)
Re:why Ruby hasn't broken out (Score:3)
don't forget about CPAN (Score:4)
Yours,
Bob