Slashdot Mirror
Programming Ruby
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
The readability and maintainability of perl with the blazing speed of smalltalk! This is even better than Java! Count me in!
-- Erich
Slashdot reader since 1997
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.
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.
Topher
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
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.
Eternal vigilance only works if you look in every direction.
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).
Eternal vigilance only works if you look in every direction.
So would that be 'roobi', 'loobi' or 'ryubi'?
; )
**>>BELCH
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.
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".
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.
--
http://www.chat.net/~jeske/Projects/ScriptPerf/
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.
-Waldo
As in Moria and Angband. Now that cools (cool and rules).
What decent language can overload the comment symbol in this fashion?
defto_s
"Song:#{@name}--#{@artist}(#{@duration})"
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.
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.
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.
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.
--
Tweet, tweet.
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?
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 (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.
there's more to programming than web sites. really.
-c
I have discovered a truly remarkable proof which this margin is too small to contain.
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.
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.)
If it's for-profit but free, you're not the customer -- you're the product (e.g., the Slashdot Beta's "audience").
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.
If it's for-profit but free, you're not the customer -- you're the product (e.g., the Slashdot Beta's "audience").
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.
Slashdot - News for Herds. Stuff that Splatters.
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.
Slashdot - News for Herds. Stuff that Splatters.
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.
Slashdot - News for Herds. Stuff that Splatters.
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.
Slashdot - News for Herds. Stuff that Splatters.
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.
Slashdot - News for Herds. Stuff that Splatters.
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.
Slashdot - News for Herds. Stuff that Splatters.
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.
Slashdot - News for Herds. Stuff that Splatters.
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.
Slashdot - News for Herds. Stuff that Splatters.
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.
Slashdot - News for Herds. Stuff that Splatters.
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.
Slashdot - News for Herds. Stuff that Splatters.
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.
Slashdot - News for Herds. Stuff that Splatters.
And I drive a manual, because I have yet to find an automatic that shifts in a way I consider reasonable. ;-)
Slashdot - News for Herds. Stuff that Splatters.
yes, pretty much all modern languages are coming with huge libraries, java, python and ruby of course is doing the same.
------ Curiosity killed the cat. {satisfaction brought it back | it didn't die ignorant | lack of it is killing mankind
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.
------ Curiosity killed the cat. {satisfaction brought it back | it didn't die ignorant | lack of it is killing mankind
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.
and
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.
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?
perl -e 'fork||print for split//,"hahahaha"'
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.
perl -e 'fork||print for split//,"hahahaha"'
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.
Ñ'
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?
Ñ'
--
assert(expired(knowledge));
> 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.
My Karma: ran over your Dogma
StrawberryFrog
So is linux.
-- 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.
-- "Vote Democrat. Because the current crop of conservatives are just bugnut crazy."
Yes, but it is easier to read and type, but more importantly, it does *not* appear in the function declaration!
-- "Vote Democrat. Because the current crop of conservatives are just bugnut crazy."
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.
-- "Vote Democrat. Because the current crop of conservatives are just bugnut crazy."
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 ...
-- "Vote Democrat. Because the current crop of conservatives are just bugnut crazy."
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...
-- "Vote Democrat. Because the current crop of conservatives are just bugnut crazy."
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.
-- "Vote Democrat. Because the current crop of conservatives are just bugnut crazy."
Someone having a problem understanding the difference between a programming language and a library?
Pax,
White Rabbit +++ Divide by Cucumber Error ++
free experimental electronic music netlabel at www.viablehybrid.com
I'm sort of know Perl...
Yeah, but you should learn English instead.
"Naughty, naughty, naughty, you filthy old soomka !"
I agree that OO is not universally compelling. Especially when it comes to, say, having to integrate C++ code with existing C code. At work we have this huge telephony OS that is all MFC, C++, COM etc (written before I arrived), the point being it's OO'ed up to the gills, and the most hellish part is trying to hack around the OO barrier to work with the Dialogic (telephony hardware) APIs, which like many low-level APIs, is in C.
Now procedural programming in C isn't better just because I have the hapless task of working with APIs that are in C, but just look at the APIs themselves. Look at X Windows, UNIX, and Motif. These are large, mature programs with large APIs. They are written just fine in C, with minimal use of OO concepts--structs, unions at most--and they have stood the test of time (maintainability), proof that procedural programming from the ground up works and works well.
IMO multiple inheritance is a terrible thing. In complicated projects it can lead to unpredictable, unforseeable behaviour.
Have you used Ruby? I'd wager that you haven't. Don't knock something till you try it, as they say. Saying you won't use Ruby because it doesn't have multiple inheritance is like saying you won't use Linux cause it doesn't have the same looking menu bars as Windows. It has a perfectly useable alternative, but you're just stuck in a certain mindset. Rubys' mix-ins are supposed to be exceptionally flexible.
By the way, multiple inheritance is not a requirement for a full Object Oriented programming language. Objective-C doesn't support it, are you gonna argue that it's not OO?
-----
"Goose... Geese... Moose... MOOSE!?!?!"
Higher Logics: where programming meets science.
Too similar to everything else?
Just taking the header of your comment is enough explain why Ruby is good. It's supposed to be similar to other languages. It borrows from Perl, Python, C, Smalltalk, Sather, Java, you name it, and integrates it all into a clean package. It's supposed to be that way so you can just start working, and not have to fiddle with it to figure it out. It's simple enough that if you've programmed in ANY of those languages, you can pretty much sit down and read and code a ruby program without too much difficulty. The biggest deal are iterators(at least for me since I had never seen them before). Besides those, I understood everything right from the get go, and I'm no exceptional programmer.
-----
"Goose... Geese... Moose... MOOSE!?!?!"
Higher Logics: where programming meets science.
I highly recommend this page. The results aren't conclusive, but it's interesting nonetheless The Great Computer Language Shootout. They have ALOT of languages benchmarked.
-----
"Goose... Geese... Moose... MOOSE!?!?!"
Higher Logics: where programming meets science.
Do you always taker everything so literally? "Sold," in this case, means promoted or evangelized.
+4 Insightful? Gee, I wish I knew how to troll like that.
;-)
It's clear to me that you don't even know Ruby, or finer art of programming. "Correctness"? As if a language can write you correct programs. Have you ever tried meta-programming? I'd call most meta programming ugly hacks, but they MAY make things cleaner on-top. Just Maybe, if you can sort out all the hideous bugs in your call-stack.
I wouldn't recommend Ruby for correctness at all (whatever THAT is), not even for meta programming. I would recommend it if you'd like to 1) _try_ write beautifully clean object oriented programs, or 2) even messier and shorter code than Perl! (although with less special puke-symbols, Parrot almost looks like a good idea to me
- Steeltoe
http://www.debunkingskeptics.com/
True, but then again, all meta-programming (aka creating a language) are hacks. So what is "full-on OOP"? :-)
:( remove and dynamically add modules as I please in my classes. Very simply put: Elegant. Just remember that including modules is semi-horizontal as opposed to inheritance, so widely different modules shouldn't contain the same variable names and methods (but you can alias them if they start conflicting). And yes, I do use single inheritance and include in modules were appropriate. This technique works with deep classes and modules intuitively.
For me, mixins work the way multiple inheritance and OOP should have worked from the beginning. I no longer have to remember and overload functions for all my base classes to work. I cleanly separate different sets of functions in different modules, and no longer worry about different states in different parts of my class-hierarchy. There are no artificial boundaries between variables in my object(s). IMHO, objects were never meant to be separated vertically and statically into multiple classes, but horizontally and dynamically into multiple modules collaborating at the task. (Just remember to call _functions instead of using variables belonging to other modules).
In Ruby, the best you can do is always begin by creating a module you can mixin into later classes. Too bad this is not a common practice yet. Do you know what I do? If I have modules that usually, but doesn't have to "inherit" (include) from eachother, I instead include them all in my class that I'm defining. I make no code in my classes (except for my libraries, but I really shouldn't there either). Thanks to the order methods are called, super and all other methods are called in the correct order as long as I include them in the correct order (the order I want to for that particular class for instance). Thus, I have no static inheritance hierarchy that I depend on, and further split up my modules. I can statically
If you want multiple inheritance the C++ way, where every class must know about its parents, just forget about dynamic inheritance. Waaay too static and complicated.
Now, if you REALLY want it. Why don't you create something in Ruby to simulate multiple inheritance, and discover the joys of such programming. It may be done with a delegator, or you can extend Ruby with C code to do it. The language isn't cast in stone, however there are lots of features I thought weren't there, which I later find in a much better way. I really wish Ruby was a relational programming language though, with more concepts of reflectivity available (although it would probably kill the speed unless compiled with alot of constraints).
Heavily extending Ruby is best done in C though. It's not a language very well suited to extend itself in itself yet, although people are working on it I believe.
- Steeltoe
http://www.debunkingskeptics.com/
Ruby sounds like fun - but all we ever write these days are web back-ends, and CGI just isn't a fun way to do those. Is there anything like mod_ruby, Rubettes, Ruby Server Pages or even (Bill be merciful) RubyScript for ASP ?
There's no such thing as a programming language - what matters is the mindset, and the legacy baggage.
Ruby is new and shining, offering to solve all our problems, sleep in the wet spot and wash our socks for us afterwards. Yet already they've impaired it with this module that thinks it knows all now and future HTML DTDs.
What if I want to generate WML or cXHTML next week ? Why should I have to re-learn another module, or even have to write one from scratch ?
CGI isn't just about HTML. For the authors of a first-generation "CGI" module to have assumed it would only ever need to serve HTML is a big, big mistake.
The Ruby book has been open sourced and can be read online here. You can also access XML and HTML sources for your own dabbling pleasure.
Object-oriented programming is way, way overrated.
That's a pretty cool reference.
Check out: http://www.rubycentral.com/ or, more specifially: http://www.rubycentral.com/ref/index.html
Full OO makes Ruby far more intuitive than other scripting languages:
If you want the length of a string:
"Hello".length;
Or how about the length of an array:
[1, 2, 5, 9].length;
Of course, you can do this with variables too:
a = "Hello";
a.length;
There is great documentation available online at:
www.rubycentral.com
You can never get overflow, numbers are automatically converted to the Bignum class if they get too large.
OO fun with files:
f = File.new("out", "w");
f.chmod(0644);
For an online book on Ruby, check out the following:
http://www.rubycentral.com/book/index.html
Bruce Eckel is already writing "Thinking In Python" - I guess he knows the good stuff when he sees it.
I think this 'Ruby' has been around since (about) this time also - perhaps this other Ruby might beat it by a couple of years but it has been around for a while.
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
treefrog
Hackers hate that.
PHP is a full blown web application server.
:)
I have seen a lot of things done in PHP. What you did was grossly simplfy just about everything. I would trust PHP and a team of devleopers before I every let the word Perl roll off my tongue. Just me
P.S. Perl is okay as long as the project is well managed I just think PHP is designed from the ground up for a web app server whereas Perl has a Module (for anything as it tries to be EVERYTHING.) granted mod perl kicks butt.
Jeremy
I'm glad to see that Ruby is getting some attention here on Slashdot. It's a great scripting language IMO. No tabs required. :)
Dan
In the immortal words of Socrates, "I drank what?"
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.
In the immortal words of Socrates, "I drank what?"
Hmm, looks an awful lot like that felicitous union of Python and Perl I've been hearing so much about... what was that called again?
The language is very cool. I highly recommend this book. There are lots of interesting bits of information including how to extend ruby with C and whatnot.
However, it does become a tower of babble when there are more scripting interepters and compilers on your hard drive than there are programs.
Updating an OS is bad enough as it is without the need to update all the subordinate things associated with a language update.
DanH
Cav Pilot's Reference Page
Cav Pilot's Reference Page
UNIX - Not just for Vestal Virgins anymore
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.
eh. What can I do. It was at a "5 Funny" a while ago... now I see that it has been knocked down to "3 Offtopic".
Apparently some moderator(s) just didn't get the joke.
Karma: NaN
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.
Karma: NaN
do we really need nother scripting language???
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!
__
Ok, I was intrigued, but now I'm hopelessly non-impressed. What language uses '>>' as a comment, whilst using '> is a C++ construct.
I'll stick to LISP - Thanks :)
Winton
Can you purchase this book at ThinkGeek?
As usual, the answer is a resounding YES!!
When O'Reilly comes out with a book.
I'm too addicted to O'Reilly books that I can only learn programming languages with them (or maybe if Bruce Ekert wrote "Thinking in Ruby").
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
For god's sake, these scripting languages like Perl and Python are great, but why oh why much they all have their own special syntax? As a C/C++ programmer, it's hard for me to constantly context switch between different (but mostly equivalent) syntactical systems. I personally wish (and I know people are going to disagree with me) that Python and Perl looked a lot more like C++. Being different for the sake of being different (or because it's fun to be different) may make sense in some venues, but not with programming languages.
My 0.019$US
-elan
- Miva/HTMLScript
- ASP or Apache ASP
- TCL
- C#
- ect....
These are all good programing languages. Why not use them? What high perfromance site is using Ruby?You say things that offend me and I can deal with it. Can you?
This actually looks pretty cool. OO in Perl is certainly do-able, it just doesn't seem very instinctive. I use Perl a lot for scripting stuff cause its just so easy to get things done quickly. This would have that strength plus a solid OO vibe to it. Definitely neat. I really don't think this is going to catch on very stongly though cause people like to play it safe with languages they know. Especially Perl programmers. If it matured though, I would definitely give it a try. Needs some libraries written for it.
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 cpan.pm 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 an interpreted 'scripting' language for quit and easy object-oriented programming; it combines the pure object-orientation of Smalltalk with the power and convenience of Perl, and a simple, clean syntax inspired by Eiffel.
I would strongly recommend this book to anyone interested in Ruby. Its layout is clear and concise and it is well written. A great introduction to a fascinating language. In fact, I picked this book up about four months ago and haven't used Perl since:]
If you want a comprehensive online resource to all things Ruby, or are just curious, check out www.ruby-lang.org
- remove the primate to mail
All the o'reilly perl book are camel books.
Are you talking about "Lerning Perl"? Because that book sucks big time. It's horrible.
--
What a busy guy. When did he get time off from his job as CEO of Wendy's and doing all those tv commercials to write this book?
_ The bureaucracy is expanding to meet
_ The bureaucracy is expanding to meet
the needs of an expanding bureaucracy.
Yes!
It's a great book. Go Ruby Go!!!
There's already a language called Ruby; it's a circuit design language that's been around since at least as early as 1990.
More info here.
arnald
Mike
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.
If you want to broaden your thinking re. server-side web programming, try BRL.
Funny you mention JSP. It's only with recent JVMs that you can get good performance out of JSP or BRL, yet successful JSP sites have been around for some time. Similarly, PHP3 performance is terrible, yet people have used it to build many successful web sites. Just throw more hardware at the problem. The database is much more likely to be a bottleneck than the server-side language anyway.
Re. mod_ruby: I haven't looked at it myself, but it seems that even if there are implementation issues with it, people should be able to write web apps now that will still work after the implementation issues are corrected.
It may be a great language. It may be better than perl. I don't know. I've never used Ruby. But then I've never used Python, either.
Most of my scripting is still in (Bourne) sh, simply because most of the time I can't afford to worry about whether or not a particular language has been downloaded onto and compiled for the system I'm using. I need cross-machine compatibility, and I can't afford the time or worry of pushing out copies of some language onto dozens -- or more -- machines.
I use Perl for things that I need, and it is becoming more prevalent, but when that script is going out to production machines, I stick with the basics.
Great or not, it's worth nothing if it isn't there.
Sean.
This was effectively why I abandoned it. It seemed to require twice as much mental effort to write code in it as in, say, Pascal. Eventually I gave it all up for C, where I can pretty much do as I please. Worst that comes of it is Segmentation fault (core dumped) which is much happier than a reboot.
--
A feeling of having made the same mistake before: Deja Foobar
--
A feeling of having made the same mistake before: Deja Foobar
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 cpan.pm 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?
Yours,
Bob
All the best,
--Bob
O'Reilly does have a book on ruby. Too bad it's only in Japanese right now. O'Reilly even sponsored a Perl/Ruby conference recently in Japan. There is even a Larry Wall Interview from the event, on what he thinks about Ruby and what not.
Does anyone have any experience, numbers, or even just rumours pertaining to Ruby performance?
Perl is fast, and PHP has since 4.0 been close enough for the speed difference not to matter. I use them both, but I won't even consider taking a look at Ruby if the performance is significantly lower than Perl.
-- If no truths are spoken then no lies can hide --
Ruby puts the fun back into programming. When was the last time you had fun writing a program---a program that worked the first time; a program that you could read next week, next month, or next year and still understand exactly what it does?
Other reasons for why this is good for us is here.
There's always sufficient, but not always at the right place nor for the right folks.
...at http://www.rubycentral.com/book/index.html Or on a Debian box near you if you're able to type apt-get install rubybook Michael
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.
I wish Ruby all the best, but unless it becomes a lot more prevalent, I'm not going to bother learning it. Oh, anyone want to download my new, free software UNIX clone, Monux? It doesn't let you do anything more, but it has a slightly more modular kernel and simpler device interface than Linux does.
Even Slashdot wants to hide some things
I have to disagree with you. English is the international language of the Western world. Everyone may not speak it, but for anyone involved in foreign affairs you better learn it. Esperanto will never be the international language because there will never be one. Not in the next 400 years at least. The European Union has chosen English as the international language. English is also the defacto language of air traffic controllers.
You point out that English is not the most common language in the world. That's beside the point. One billion people may speak Mandarin among themselves, but the international language that they use when dealing with foreigners is not Mandarin.
English is not the universal language of course. There never will be one. Esperanto failed because no ones going to learn an artificial language and then speak to someone who knows that artificial language also. One will learn the others language before that happens. There is also the fact that real languages have evolved for millennia. They have quirks that esperanto and other artificial languages don't have. Their very disorder is an asset. They charm.
But Yogi, the RIAA won't like that.
I was busting to post something to this thread... but you summed it up nicely. Carry on, nothing to see.