Programming Ruby 169
| 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
- 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
Re:ruby? (Score:1)
Oooh! (Score:2)
Re:..and there's CPAN (Score:1)
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.
Re:use ruby; (Score:1)
Programming Ruby is Free Documentation (Score:1)
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.
Re:Where does ruby sparkle? (Score:1)
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
hmmm (Score:1)
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.
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)
; )
Low Cognitive Overhead (Score:1)
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.
Re:Low Cognitive Overhead (Score:1)
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? =)
Re:OOP (Score:1)
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.
Re:Take a look at this Ruby Tutorial (Score:1)
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].
--
Python/Ruby/Lua performance comparisons (Score:1)
http://www.chat.net/~jeske/Projects/ScriptPerf/ [chat.net]
Ruby Cookbook (Score:2)
-Waldo
Re:Ruby is really nice... (Score:1)
As in Moria and Angband. Now that cools (cool and rules).
Re:Take a look at this Ruby Tutorial (Score:1)
What decent language can overload the comment symbol in this fashion?
defto_s
"Song:#{@name}--#{@artist}(#{@duration})"
ASP (Score:1)
Re:Take a look at this Ruby Tutorial (Score:1)
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.
Re:hmmm (Score:1)
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.)
--
Re:Performance? (Score:1)
I use ruby today everywhere that I used to use perl.
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.
--
Re:why Ruby hasn't broken out (Score:1)
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.
And history repeats itself (Score:2)
Re:Ruby is really nice... (Score:1)
Well, Dave Thomas (yes, one of the book authors) recently released a program called ri [pragmaticprogrammer.com] (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 [pragmaticprogrammer.com].
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.
Re:What about... (Score:1)
there's more to programming than web sites. really.
-c
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:And history repeats itself (Score:1)
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.
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:Who wants to write CGI anyway ? (Score:1)
mod_ruby [ruby-lang.org].
Re:OOP (Score:1)
(I didn't know Java could do PS generation as a builtin feature. That's kind of cool.)
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:Who wants to write CGI anyway ? (Score:1)
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!
The most innane Slashdot comment in a long while. (Score:1)
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.
Re:Where does ruby sparkle? (Score:1)
You should really check it out. 9 out of 10 ex-Perl/Python junkies agree that mixins are super-way-cool!
Re:Where does ruby sparkle? (Score:1)
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.
Re:Ruby CGI module's HTML generation methods (Score:1)
very similar to Python's and Perl's, bit so similar to LISP's.
and
totally user extendable.
so, what is the problem? Oh, you wanted to sound like you knew it all.... That _can_ be a problem.
Re:And history repeats itself (Score:1)
You have obviously never maintained other's Perl. (Score:1)
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.
Re:Who wants to write CGI anyway ? (Score:1)
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.
Re:the camel book? (Score:1)
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.
Re:too many tools? (Score:1)
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.
Re:too many tools? (Score:1)
Re:too many tools? (Score:1)
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.
too many tools? (Score:2)
Re:CPAN is no reason to ignore Ruby (Score:1)
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".
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.
Re:OOP (Score:1)
From #ruby-lang (Score:4)
-- David Thomas, in response to the comments in this article
Re:OOP (Score:1)
Re:Ruby is really nice... (Score:1)
Re:Ruby is really nice... (Score:1)
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.
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.
use ruby; (Score:2)
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.
Re:use ruby; (Score:2)
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.
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.
Re:ruby? (Score:2)
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.
Goddamnit! (Score:2)
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 [webpres.com.my]. 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 [tuxedo.org] (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!
__
Re:too many tools? (Score:2)
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.
Re:Cool things about Ruby.. (Score:2)
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...)
..and there's CPAN (Score:4)
Where does ruby sparkle? (Score:2)
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.
Re:why Ruby hasn't broken out (Score:3)
Which reminds me... Modula-2 (Score:2)
--
don't forget about CPAN (Score:4)
Yours,
Bob
Too similar to everything else? (Score:2)
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.
Re:Where does ruby sparkle? (Score:2)