Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Programming Books Media Book Reviews Technology

Programming Ruby: The Pragmatic Programmers' Guide 231

Posted by timothy from the who-could-hang-a-name-on-you dept.
James Edward Gray II writes " Programming Ruby: The Pragmatic Programmers' Guide (Second Edition), known as the Pickaxe II to its fans, is an extremely current view of the Ruby programming language. Revised primarily by Dave Thomas, a founding father of the English Ruby community, Programming Ruby is distilled expertise from a reliable source. In the past, quality English documentation of Ruby has been in short supply, but if any one volume could solve that problem, this is it." Read on for the rest of Gray's review.
Programming Ruby: The Pragmatic Programmers' Guide
author Dave Thomas with Chad Fowler and Andy Hunt
pages 830
publisher Pragmatic Bookshelf
rating 9
reviewer James Edward Gray II
ISBN 0974514055
summary The definitive source for all things Ruby.

If you're not familiar with it, Ruby is a very fun and elegant scripting language that has been described as "more powerful than Perl and more object oriented than Python." I won't start a language war by defending that statement, but I will tell you what makes Ruby very attractive to me: Extremely object oriented, super clean syntax, and a smooth blending of iterators and code blocks for straightforward, concise solutions. If that sounds like a language you would like to know more about, Programming Ruby is the book for you.

At 830 pages, this edition is considerably larger than the first. It represents an expansion on many topics originally covered, in addition to all new coverage on topics like unit testing, RDoc documentation for Ruby source code, and more. Better still, "Duck Typing," a topic central to Ruby philosophy, receives its own enlightening chapter. This volume covers the very latest release of the language, often highlighting new features and even giving tips for things to watch for in future versions.

Programming Ruby is divided into four distinct sections. "Part I - Facets of Ruby" is a tutorial on the Ruby Programming Language. It's very effective, but I probably better give a warning here: This book teaches you how to program in Ruby, not how to program. You likely won't feel comfortable, even in this tutorial section, unless you have some experience with other programming languages. As an example, Ruby is object oriented on a scale with languages like Smalltalk, so you'll need to know object oriented programming. This book makes no attempt to teach such concepts, excepting how they apply to Ruby. As long as you come with the proper background, this section will get you on your feet with Ruby in under 200 pages. It's very well thought out.

"Part II - Ruby in its Setting" is a mixed-bag tour on the many places Ruby sees use. Web programming, command-line hacking, using TK to build GUIs, and Windows programming are just some of the covered topics. Other chapters in here focus on elements unique to Ruby, like the earlier mentioned RDoc or "irb," the interactive Ruby shell. There's even a chapter in here on package management with RubyGems.

When you're ready, "Part III - Ruby Crystallized" will take you deep into the core of Ruby syntax and functionality. This section tells you all the details about how Ruby reads your code, and how it runs. I think few people could soak in all the tidbits in here in one scan. I've read it twice now and learned about as much both times. There's a lot of great Ruby knowledge waiting to be mined out of here.

Finally, "Part IV - Ruby Library Reference" is the best Ruby reference I've yet run across. It covers every class, module, method and constant in core Ruby. The descriptions for these entities tell you exactly what you need to know, the examples, though short, are inspiring, and the comments sneak in subtle hints that are more than useful. Following this, the book gives an overview of all Standard Libraries included with Ruby. This section really opened my eyes to the tools I've been missing out on simply because I didn't know they were there. Be warned: These Standard Library summaries won't teach you every feature available. They just tell you what they're for so you'll know where to look for the information you need. The last great feature in this section is a terrific index. I care about the index and a book that has a bad one will really bother me. Luckily, that couldn't be further from the truth here.

Programming Ruby isn't perfect, of course. Some of the chapters are not as thorough as you wish they could be, simply because of the amount of information that needs to be covered. The chapter on threads is probably the biggest example of this, but remember that entire volumes have been written on threading. Another minor point is that some of the examples are quite contrived. This bothers some people, but I don't feel it's too much trouble for the book's target audience. As I've said, you're expected to know how to program going into this book, just not how to program in Ruby.

Programming Ruby at least touches on most things central to the Ruby Programming Language, and goes into considerable detail more often than not. There's something for all levels here. You can learn Ruby from the tutorial, as I did with the first edition, but you'll keep coming back to the wonderful reference and to go deeper into specific areas of interest. That's a lot of great mileage for one book. I'm willing to bet most Ruby Gurus keep it in arm's reach, because Ruby wouldn't be half as much fun without it.

You can purchase Programming Ruby from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
This discussion has been archived. No new comments can be posted.

Programming Ruby: The Pragmatic Programmers' Guide More

Programming Ruby: The Pragmatic Programmers' Guide

Comments Filter:

  • First edition is available online. (Score:5, Informative)

    by Kenja ( 541830 ) on Tuesday October 19, 2004 @02:39PM (#10568444)
    http://www.rubycentral.com/book/

    • Re:First edition is available online. (Score:4, Informative)

      by Anonymous Coward on Tuesday October 19, 2004 @05:48PM (#10570293)
      The 1st edition is very out-of-date. It's kinda like reading a Perl 4 book to learn Perl 5.8. But the author was generous to provide it for free and it is available in MANY formats online from PDF to Microsoft Help to HTML.

      I own the 2nd edition and am VERY happy with it except for the quality of paper. Reminds me of Java in a Nutshell because it quickly teaches the language and also provides a reference to keep on your desk. This is my first and only hardcopy Ruby book and I doubt I'll need another one for a few years.

      For those of you new to Ruby or just curious, here are some useful links:

      Ruby Home
      http://www.ruby-lang.org

      Ruby Forum (new! primarily for beginners)
      http://www.ruby-forum.org/bb/

      Ruby Online Docs
      http://www.ruby-doc.org

      Ruby Project Archives
      http://raa.ruby-lang.org
      http://rubyfor ge.org

      Ruby Package Manager (easy to install ruby apps)
      http://rubygems.rubyforge.org/wiki/wiki.pl

      Ruby IDE (free!)
      http://freeride.rubyforge.org/wiki/wiki.p l

      Ruby One-Click Installer for Windows
      http://rubyinstaller.rubyforge.org/wiki/w iki.pl

      Ruby IRC channel
      #ruby-lang at irc.openprojects.net

      Ruby Newsgroup
      news://comp.lang.ruby

      Ruby Links
      http://www.rubycentral.com/links/index.html
      http://dmoz.org/Computers/Programming/Languages/ Ru by/Software/

  • About the Ruby Gems chapter... (Score:5, Insightful)

    by tcopeland ( 32225 ) * <tom@NoSPaM.thomasleecopeland.com> on Tuesday October 19, 2004 @02:44PM (#10568492) Homepage
    ...it was written twice. Chad Fowler wrote it the first time while he was on vacation in Europe. Then he had to rewrite it after his Powerbook was stolen on his trip home. Argh!

    More on Ruby Gems here [rubyforge.org].

  • Ruby is great. (Score:4, Insightful)

    by nullvector ( 694435 ) on Tuesday October 19, 2004 @02:45PM (#10568510)
    Ruby is like the glue that holds alot of my programs together.

    The first edition of this book came in really handy in college, when I'd have to find creative ways to do something (especially text manip), where C++ or Java just seemed to get in the way.

    Ruby is quick to learn, and Dave Thomas from Pragmatic is a great teacher...he came to my school for a little lecture/speech one day, and talked on the merits of Ruby, which is how I got introduced to it.

    The network aspects of Ruby are great too. Small concise ruby programs can do a whole lot :)

    • Re:Ruby is great. (Score:5, Funny)

      by hoggoth ( 414195 ) on Tuesday October 19, 2004 @02:54PM (#10568612) Journal
      > The first edition of this book came in really handy in college

      Man, I feel old.
      For me, 'Programming Cyber 7600 Assembly' came in really handy in college.
    • I bought the first edition of the book, but was scared off from doing too much with Ruby because (a) it seemed like the language was still changing rapidly, and (b) Unicode support had to be bolted on.

      How are these issues now? Are there still changes being made to the language that will break code? I heard that Ruby was eventually going to have "something better than Unicode" for dealing with non-ASCII characters --- has that happened?

  • Given all the gem analogies... (Score:5, Funny)

    by grunt107 ( 739510 ) on Tuesday October 19, 2004 @02:45PM (#10568515)
    Why didn't reviewer say 'Brilliant, but slightly flawed'.

  • Goodbye Ruby Tuesday (Score:4, Funny)

    by Timesprout ( 579035 ) on Tuesday October 19, 2004 @02:45PM (#10568516)

    Who could hang a name on you

    Oh come on someone had to do it.

  • It's got to better than... (Score:3, Funny)

    by foistboinder ( 99286 ) on Tuesday October 19, 2004 @02:46PM (#10568521) Homepage Journal

    The non-Pragmatic Programmers' Guide

  • RubyConf 04 was held recently.... (Score:4, Informative)

    by tcopeland ( 32225 ) * <tom@NoSPaM.thomasleecopeland.com> on Tuesday October 19, 2004 @02:48PM (#10568536) Homepage
    ...thanks to Ruby Central [rubycentral.com] for sponsoring it.

    A BitTorrent of the presentations is available here [rubyforge.org].
  • where does the pickaxe name come from?

  • Eager to have this book (Score:4, Informative)

    by rolling_bits ( 754633 ) on Tuesday October 19, 2004 @02:52PM (#10568594)
    Many of us, Rubyists, have been introduced to Ruby by the very first version of this book. And the first version is online and is still handy for consulting:
    http://www.ruby-doc.org/find/pickaxe

    But this new version covers all the changes from Ruby 1.6 to Ruby 1.8; making this book a must have.

    As far as I know, it's available as PDF and as paper, and I'm gonna have both.

    Thanks Dave for helping the occident know Ruby and Matz for creating the must inspiring language for me.

    Cheers!

  • Too many new languages at once... (Score:3, Interesting)

    by Doesn't_Comment_Code ( 692510 ) on Tuesday October 19, 2004 @02:53PM (#10568603)
    I have to admit I've never tried Ruby. I use C++, Perl and PHP all the time. I just got started learning Python because of a book review I saw here on Slashdot. In fact, I also got interested in Python because someone suggested I use it to solve a problem that needs extensive parsing (Perl strength, nightmare in C++) and large, pointer-addressable arrays of objects(C++ strength, Perl weakness).

    Anyway, I was told Python was a good compromise. I've just started into it, but maybe Ruby is a better fit for this problem? I can only learn so many languages at once, and still have time for my projects.

    Can I get any advice? Is Ruby really "more powerful than Perl and more object oriented than Python" - is this what I'm looking for, or should I put it off and learn Python first?

    • Re:Too many new languages at once... (Score:5, Informative)

      by tcopeland ( 32225 ) * <tom@NoSPaM.thomasleecopeland.com> on Tuesday October 19, 2004 @02:56PM (#10568628) Homepage
      > Ruby is a better fit for this problem?

      There's a good C2 Wiki page on this - PythonVsRuby [c2.com].
    • I can't say I've delved too deeply into Python, but I know enough of it to read it. I'd recommend that you look at the web version of the 1st edition of this book (linked above in a few comments) and just browse through the first section on syntax.

      As far as I am aware, the guts are about comparable (though anecdotal evidence suggests faster runtime with python) but I much prefer Ruby's syntax. A few of the constructs are really really nice, such as code blocks. Plus, it's much more consistent in the OO

      • It is not true that Python is "half-OO", at least by the merit of your argument. Finding the length of an object is done by calling a method:

        >>>"bla".__len__()
        3

        >>>class Foo:
        ... def __len__(self): return 5
        >>> Foo().__len__()
        5

        You can also do len(Foo()) or len("bla"), and although I agree that the existence of this legacy function makes the language less consistent I fail to see how it makes it any less OO.

    • at the risk of being totally flamed by all the ruby followers out there:

      i have for quite some time now been programming in python and it just works like a CHARM!!
      i used to be so proud of my perl skills, but at some point i just felt dirty using perl and once i had started with python there DEFINITELY was no turning back! (well, maybe for a few-line regexp script...)

      from what i have gathered about ruby, the distinction between ruby and python is really slight! the syntax of ruby is VERY similar to that of

      • Re:Too many new languages at once... (Score:5, Interesting)

        by cmowire ( 254489 ) on Tuesday October 19, 2004 @03:18PM (#10568855) Homepage
        No, there is a difference. It's a mistaken notion that Ruby is like Python meets Perl.

        It's more like Smalltalk + Regular Expression + Incidental Other Goodies + Culture.

        I've tried both, and I like Ruby far more than Python. Ruby is an incredible language that tends to enable really simple, yet sophisticated code. When people talk about the Ruby Way, they aren't kidding. Ruby is endearing to me in ways that Python never was.

        Ruby and Python are both drinking from the smalltalk fountain, but they are still very different. Ruby plows head-on into more functional-programming types of paradigms while still using objects.
        • Ruby plows head-on into more functional-programming types of paradigms while still using objects.

          Err, like first class functions for example? Or list comprehensions?

          It's funny, Ruby programmers never seem to know what functional programming really means. It must be some widely spread misconception within the Ruby community...

          • Re:Too many new languages at once... (Score:4, Informative)

            by baka_boy ( 171146 ) <lennon@@@day-reynolds...com> on Tuesday October 19, 2004 @04:04PM (#10569325) Homepage
            Ruby has first-class functions; you just have to disambiguate them syntactically, since bare property access (like foo.bar) is actually calling method bar on the object foo. So, if you want to reference the method explicitly, you have to write foo.method(:foo), which returns a Method instance which can be invoked or used like any other scalar value.

            So, while in Python, you might write something like this:
            controller.set_handler('some_action', myObject.handle_some_action)
            ...the Ruby idiom would be one of the following:
            controller.set_handler('some_action', myObject.method(:handle_some_action))

            -or-
            controller.set_handler('some_action') { myObject.handle_some_action }

            The extra method(...) syntax is needed to ensure that all communication between objects is via method calls, rather than direct property access. Python allows you to directly assign to and read from object attributes, much like public members in C++ or Java classes. Ruby forces all attribute access to be wrapped in get/set methods, but provides a lot of support to make implementing those methods effectively automatic.

            The latter example also uses a code block, cover many cases where first-class functions would be otherwise -- they're basically a compact syntax for lambda expressions, and prevent you from needed sugar like list comprehensions in most situations.

            For example, instead of the following Python list comprehension:
            [x*2 for x in myArrayOfValues if x % 3 == 0]

            ...you would use this:
            myArrayOfValues.map {|x| x*2}.find_all {|x| x % 3 == 0}

            Blocks are also a general idiom used throughout the standard library and most Ruby code in the wild. You can use them to write callbacks, query databases, and even to build domain-specific languages (another traditional stronghold of functional languages).

            Really, though, neither Ruby or Python is a truly functional language; both borrow from the more "academic" languages those features and concepts they find useful, and leave behind those that the maintainers and users don't want, need, or understand. (Except for continuations, of course -- Ruby has those, and I would guess that only a very small percentage of Ruby coders ever grok them.)
          • You don't have list comprehensions in SML. Last time I checked, this was still a functional language.
            The comp.lang.functional FAQ says

            Functional programming is a style of programming that emphasizes the evaluation of expressions, rather than execution of commands. The expressions in these language are formed by using functions to combine basic values. A functional language is a language that supports and encourages programming in a functional style.

            Actually Ruby only has expressions, so it seems to

          • Notice I said "functional-programming types of paradigms", not functional programming.

            It does have first-class functions (the Proc class) it's just that the syntax is driven towards making closures accessible instead of functions and creating Procs is a lot more involved.

            On the other hand, what they do with the closures (a.k.a. Code Blocks) is quite amazing on its own merits. The concept of being able to iterate over arbitrary stuff in a variety of ways with them comes in quite handy, plus all of the oth

    • Ruby + C == World Domination (Score:2, Insightful)

      by Anonymous Coward
      Well not exaclty, but the combination of Ruby and C is unbelievably powerful.
      A graceful and dynamic OO language coupled with, well C - fast, portable (more or less) and used everywhere.
      Because it is so easy to go back and forth between Ruby and C you get the strengths of both languages (also all those C libraries out there).

      If you haven't used Ruby, your missing out to say the least - and this book is an excelent way to get started.
      • mod the parent up!

        Ruby isn't the fastest language on the block, but it's so easy to write C extensions for a Ruby program. Usually only about 10 to 20% of your code is speed critical, so this allows you to write that small part of your code which is speed critical in C while writing the rest of your code more quickly in Ruby. Oh and there's a profiling module that comes with Ruby that will help you figure out where your code is spending it's time.

        I would also add that if you use Swig [swig.org], it's quite easy to
    • I'd suggest downloading some C or C++ libraries for string parsing. Rolling your own is a pain, but there's regular expression libraries that will give you all the strength of perl's. In fact, its a little known secret but glibc has C regular expression functions built in. Here's some documentation [utah.edu].

      Really, unless a language brings in a completely new way of programming (functional vs procedural, for example), the time spent learning a new language is usually a waste. Odds are 90%+ that you can either b
      • Yes, you could keep punching cards or writing asssembler. Or maybe, write C or Java. Or... You could use Ruby and build your programs and libraries in a special way, that makes them concise and much more maintenable. That way instead of creating one program per year, you could create one per week, and keep improving them as needed. You are not free from creating your own libraries, though. You are even encouraged to. And it's much easier to create a library in Ruby than in other languages. The payoff is
        • A new language gives no additional power, at a large cost of time to learn the language. The limiting factor of programming isn't what the language can express- every Turing complete language has the same expressivity. The limit is the amount of work you can reuse- the amount of library code that already exists. And there's more library- and equally important, those libraries are better tested from real world use- in older languages.

          Changing languages might earn you geek points on /., but it doesn't s
          • Following this logic and given there were enough libraries for brainfuck available, we could program everything in brainfuck as well?
            • I don't know too much about Brainfuck, is it Turing complete? If so, yes. But I don't think it has the necessary mass of existing libraries and users. But if someone who mainly used Brainfuck had a problem, I'd point him to look twoards solving it in Brainfuck rather than switching languages as a solution.

    • Re:Too many new languages at once... (Score:5, Insightful)

      by CatGrep ( 707480 ) on Tuesday October 19, 2004 @03:44PM (#10569107)
      Can I get any advice? Is Ruby really "more powerful than Perl

      That's really difficult to quantify. How do you define 'more powerful'?

      Personally, I prefer Ruby's clean syntax to Perl's (especially when compared to OO programming in Perl, which is just a disaster from an aesthetic viewpoint, as well as the amount of work that is required from the Perl programmer to do OO). There are a few features that Ruby has that Perl doesn't: continuations, code blocks and exceptions.

      and more object oriented than Python" - is this what I'm looking for, or should I put it off and learn Python first?

      This tends to be an area where there is a lot of dispute between the two camps. I've already revealed my bias toward Ruby, so take that into consideration regarding the following comments: In Python I get the feeling that object orientation was tacked on. Granted it was tacked on much earlier in the language's development than it was in Perl where OO programming is essentially a do-it-yourself project. There are a couple of nagging issues in Python which give me this idea:
      1) why do I need to include 'self' as the first parameter of each method definition?
      2) In Python people tend to prefer, for example, to find the length of an array by saying:
      length( array ) instead of array.length (the latter being the way you would do it in Ruby). Of course Pythonistas are now screaming that you can also say: array.__length__ (or something similar) in Python as well.

      Python now also has something similar to Ruby's iterators (though they're a bit different), but something to keep in mind is that Ruby's standard libraries and built-in classes were built from the ground up with iterators in mind - I think that's a big advantage that Ruby has over Python.

      I suggest that you try to write a smallish program in each language (pick a project that might take an hour or two) and see how each language 'fits' with the way you think. I find Ruby fits my way of thinking much better than Python does, but as they say, YMMV.

      • 1) why do I need to include 'self' as the first parameter of each method definition?

        It's nicer for unbound methods, and makes calls to superclass methods clearer. This is also answered in the Python FAQ [python.org].

        2) In Python people tend to prefer, for example, to find the length of an array by saying:

        length( array ) instead of array.length (the latter being the way you would do it in Ruby). Of course Pythonistas are now screaming that you can also say: array.__length__ (or something similar) in Python as well.

        See

      • There are a couple of nagging issues in Python which give me this idea:

        Here's how I think people should evaluate Python vs. Ruby:
        1. Run Python, downloading it if necessary.
        2. Run a Python shell (OS-dependent).
        3. Type "import this", and read it.

        If everything speaks to you, as it does me, than try Python first. Otherwise, try Ruby. I'll leave a Ruby-ist to explain the exact differences.

        I can give a couple of the differences, though; mostly, the differences between the languages and capabilities are philosophica

        • , but the Python one will look more like pseudo-code with real English words

          None of my pseudo-code has "self" everywhere, nor frequent use of underbar characters.

          I tried Python, and it felt forced, not practical, as if purity were indeed the main point.

          Even with the compulsary indentation I find Python hard to read, as there is a lot of syntax one has to read past. Persoanl preference, I guess, but Ruby is easier to read and write.

      • 1) why do I need to include 'self' as the first parameter of each method definition?

        Several reasons: requiring the explicit parameter fits a Python Zen concept (explicit is better than implicit), it avoids adding a new keyword to the language (you can call self whatever you want) and it supports these features when you you have things like class methods.

        2) In Python people tend to prefer, for example, to find the length of an array by saying: length( array ) instead of array.length (the latter being the

      • > 1) why do I need to include 'self' as the first parameter of each method definition?

        I was *just* discussing this a few weeks ago with a friend. I *like* that python enforces the 'self' syntax. Where in other languages, like C++, 'this' is just there. For someone *reading* python code, you *see* where 'self' is given, not having to guess where it came from.

        Not sure if Ruby allows this, but using that syntax then allows me to also call the Class directly, using my Instance as an argument *if* I need
      • why do I need to include 'self' as the first parameter of each method definition?

        So that you can import a generic function that goes, for example, parse_stuff(some_string, flags) and then tack it onto a local class:

        MyAdvancedStringClass.parse = parse_stuff

        And instances of that class can now call mystring.parse(self, someflags) and it just works, magically.

        This is especially godsent for writing decent wrappers for C libraries.

        But I agree that it remains an idiosyncrasy of the language, even if it h

      • Do Real Programmers write in Ruby? Or in Python? (Score:2, Interesting)

        by Anonymous Coward

        Sorry for an off-topic rant by an old man, but this pointless duscussion has just reminded me a recent story [slashdot.org] comparing Java to C# when someone [slashdot.org] apparently devoted to the macho side of programming made the bald and unvarnished statement: Real Programmers write in Perl.

        Maybe they do now in the 21st century, in this postmodern era of blogs, smartphones, and "user-friendly" software, but back in the Good Old Days, when the term "software" sounded funny and Real Computers were made out of drums and vacuum tub

    • I know both languages, although I know Python better. I first learned Ruby and then switched to Python. In many ways I think both languages fit the same niche. They both make many tasks easier and you really can't go wrong with either. If you started with Python I would stick with it. You'll never regret knowing Python well. For me, Python offered 1) more bindings to existing "C" libraries. 2) a bigger community with more support. Ruby is pretty decent in both 1) and 2) also, just not as far along (I'

    • Is Ruby really "more powerful than Perl and more object oriented than Python" - is this what I'm looking for, or should I put it off and learn Python first?

      I've never bothered to learn Perl, although from what I understand you're likely to miss being able to do some things in one line that might take a few extra lines in either Python or Ruby.

      Python has been by far my favourite scripting language for several years now. It's structured, it forces relatively consistent syntax, and it has a huge am

      • For instance, one thing I'd really like to do in Python is to modify a few things about the built-in string class. I'd like to just be able to import a module into my program, and have the string class work differently from then on.
        So whats wrong with this:

        class mystr(str):
        .def __eq__(self, other):
        ..print "I am unique!"
        ..return False

        a=mystr("bla")
        print a==a

        resulting in:

        bjoern@lord:~/ > python pytest.py
        I am unique!
        False

        Yes, you have to init the strings explicitly as mystr, but so what - anything el

    • The two big reason I'm not using ruby much is:
      * No CPAN (RAA and Rubyforge does not compare)
      * No community even close to the one Perl has

      Really, ruby is super sweet, but for productivity and getting things done, those above things are really, really important. And since Perl is a great language too, it wins out every time.

      Python... I never got what was so great about it. It feels limited and limiting in so many ways, although I suppose it is easy in a "one way only" kind of way. This is one of the things

    • Can I get any advice? Is Ruby really "more powerful than Perl and more object oriented than Python" - is this what I'm looking for, or should I put it off and learn Python first?

      No, it is not more powerful than Perl. But than again, nothing is. The points is not what is more powerful per se, but rather which is more powerful in your hands and which one best fits your own brain. At this point it is extremely important to mention Parrot [slashdot.org]: "The amazing project [...] to really unite Perl [perl.org] and Python [python.org] one d

  • ...are also available on ruby-doc.org here [ruby-doc.org].

  • Poignant vs Pragmatic (Score:5, Informative)

    by weston ( 16146 ) <<westonsd> <at> <canncentral.org>> on Tuesday October 19, 2004 @03:02PM (#10568691) Homepage
    Why's Poignant Guide to Ruby [poignantguide.net] has got to be the most entertaining Ruby read out there....

  • Dave Thomas (Score:3, Funny)

    by dfn5 ( 524972 ) on Tuesday October 19, 2004 @03:14PM (#10568821) Journal
    a founding father of the English Ruby community...

    ... and hamburgers

  • Ruby and Perl over Python for cross-platform dev (Score:5, Insightful)

    by Dystopian Rebel ( 714995 ) on Tuesday October 19, 2004 @03:16PM (#10568835) Journal
    I can live with Python's having no statement terminator (";" in C, C++, Perl, Java).

    What I find unacceptable in Python is that whitespace (tabs) determine the logical flow. I once wrote a script on Windows and moved it to UNIX; the UNIX editor handled tabs differently, and my script wouldn't work without a few hours of attention just to set the spacing right.

    Ruby has Pascal-like blocking. That alone makes it superior to Python. And for all other situations that do not require a good OO implementation, there is Perl.

    • my script wouldn't work without a few hours of attention just to set the spacing right.

      Python distribution has reindent.py that does this for your file(s) automatically.

      Using tabs for indenting is recommended against in Python. It's a Python newbie mistake that is usually only done once.

      Ruby has Pascal-like blocking. That alone makes it superior to Python. And for all other situations that do not require a good OO implementation, there is Perl.

      I guess that paragraph kinda speaks for itself and makes

    • Re:Syntactically significant whitespace (Score:5, Interesting)

      by dozer ( 30790 ) on Tuesday October 19, 2004 @05:10PM (#10569999)
      Ever notice that there's tons of Perl, PHP, and Ruby snippents all over the web but very few Python snippets? It's because you really can't copy Python from the browser and paste it into a text editor! The whitespace gets changed and the program breaks in very hard-to-diagnose ways. It's rather funny.

      There are many features of Python that will be adopted by future languages, but I doubt that significant whitespace is among them.
    • What I find unacceptable in Python is that whitespace (tabs) determine the logical flow.

      It also means you cannot take advantage of the auto-indenting feature of editors.

      If I need to go back and wrap a chunk of code in an "if" statement, I can put a { at the beginning and a } at the end and the editor will correct the indenting.

      Python will require me to go line by line and insert spaces or tabs.
      • Python will require me to go line by line and insert spaces or tabs.

        No offense, but that's a load of crap and evidence that you've never actually coded anything in Python. If you had, you'd know that Python comes with a fully functional editor called IDLE, which includes auto-indentation. You can also select whole chunks of code and press ctrl+] to indent or ctrl+[ to unindent. Explicit scope declarators serve no purpose but to frustrate the programmer who forgets to declare that last '}' of 'end' statem

  • Great book, great language (Score:3, Insightful)

    by CatGrep ( 707480 ) on Tuesday October 19, 2004 @03:52PM (#10569193)
    I got my copy a couple of weeks ago. It's a great followup to the first edition - much more information. I've already learned new things from it even though I've been programming in Ruby over 3 years now.

    I also think that the philosophy espoused in the chapter on 'Duck Typing' could apply to other agile languages like Smalltalk and Python. I haven't really seen these ideas come out as strongly in other language communities as they have in the Ruby community.

    I don't think there is any one thing about Ruby that's truly revolutionary, but the combination of features (code blocks, very consistent and complete standard libraries, OO'ness, etc.) make it very compelling. Do yourself a favor and buy the book - learning Ruby can help you think differently about how you approach problem solving in your day-to-day programming work (even if you don't program in Ruby for pay).

  • Language selection parameters (Score:5, Insightful)

    by Mr_Icon ( 124425 ) on Tuesday October 19, 2004 @04:32PM (#10569590) Homepage

    There are several kinds of programmers, at least when it comes to the language selection:

    • The Hardcore Kind: Everything must be written in something as low-level as possible, meaning C, but only if you absolutely cannot do ASM.
    • The I'm Special Kind: I am going to pick a language that is not commonly used, because having an obscure preference in programming languages makes me feel special. To justify my preference, I am going to learn a few facts that make this language marginally better than a similar language $FOO, ignoring all other advantages of $FOO.
    • The Hammer-Happy Kind: I know one language and I will use it whether it makes sense or not

    The first kind gives us applications that cannot be easily ported to other OSes or platforms, because everything is so low-level that it is tied to the underlying architecture. The second kind gives us duplicated effort and software that becomes unmantained whenever the main developer quits, since few other programmers know the language in which the project is written. The third kind gives us solutions that make sane people scream, like shell scripts that start with #!/usr/bin/php -q.

    It's fun to learn other programming languages, and contribute to the development of new ones, but in the open-source environment it is also very important to remember that you a) do not and should not work in a vacuum, b) that there are freaks who will probably try to run your software on bizarre setups, and c) that there is always a chance that circumstances will require that you quit working on that project.

    This is the reason why when picking a development environment for a project it is important to consider things like portability, maintainability, and suitability for the purpose. I'm not sure I can justify writing something in Ruby at this point, seeing as its adoption is far below Python, while its advantages over Python are slim to questionable.

    • I use language zealotry as a clue-factor. Anybody who says "A" is better than "B" with strong conviction and no caveats, tells me how much they know about programming.

      Great developers know two rules that keep them happy:

      1. Choose the best tool for the job

      2. Given that, know that the best tool is not always the best choice (e.g. everybody in your company knows Java but you want to write in PHP)

      And I suppose even before all of this is, learn at least a few languages. It will give you the clue factor that
    • > This is the reason why when picking a development environment for a project it is
      > important to consider things like portability, maintainability, and suitability for the purpose.

      Oh. So that would mean COBOL [thekompany.com] would be your first choice for languages.

      Seriouslly, that wouldn't be as far fetched as you might think. COBOL is on every platform you'd probably ever need to run on and now has OO capabilities that are better than C++. No, I wouldn't use it for the Next Great OS®, but if you're p

    • Re:Language selection parameters (Score:2, Insightful)

      by Anonymous Coward
      You know, there are some people who actually enjoy programming, and enjoy the aesthetics of different languages. Some of us are interested in obscure languages because they represent a different way of thinking about programming, algorithms, and other such issues. It's not about "feeling special", it's about enjoying a particular language on its own merits.

      If everyone adopted the perspective you seem to present, people would only be interested in math because of what it can do, not what it is.
    • Adoption seems healthy here. Should I stop using FreeBSD too because it's not as popular as Linux, or Windows perhaps?

      Ruby's mature, portable (do Python's threads work in DOS?), easily popular enough for general use, has excellent support, and I find it a hell of a lot nicer than Python. Why shouldn't I use it, especially when I see so much more interesting development there?
    • I'm not sure I can justify writing something in Ruby at this point, seeing as its adoption is far below Python, while its advantages over Python are slim to questionable.

      Do you have a reference for that? I was under the impression that while Python adoption was slightly ahead of Ruby in the US, Ruby was more widely-adopted in Japan, and (on the whole) they were roughly on par.

  • awesome book, awesome language (Score:5, Informative)

    by Anonymous Coward on Tuesday October 19, 2004 @04:57PM (#10569867)
    I've been using Ruby since I read about it in DDJ a while back.

    What really struck me about Ruby is how it "solved" many of the issues that had been bugging me about other languages (and I've used a bunch). Such as:

    * In many languages, a built-in method will either mutate an object "in-place", or it will work on a copy of the object and return that, leaving the original untouched. Sometimes pretty arbitrarily. But in Ruby, there's a convention like in Scheme (and maybe others): methods ending in "!", like "array.sort!" will sort the array in-place, and the other methods return a new sorted copy. Nice! One annoying issue solved.

    And booleans end in "?" which is nice too. instead of "is_foo" you write "foo?".

    * In many languages, you can have fields on objects, and you can have methods. So when you have "attributes" (like "first_name", "last_name" on a customer object), do you use fields which are simple and straightforward with natural syntax:

    object.first_name = "Joe"

    or do you use methods, which can be refactored:

    object.setFirstName("Joe")

    So, do you go for the awkward syntax, keep the fields private, and allow refactoring? Or do you expose the field, and rewrite all the code later when the requirements say "name must default to 'Anonymous Coward' when no name set"? Or do you convolute your code around the issue?

    Ruby solves this elegantly. There are NO PUBLIC FIELDS! Instead, you always use methods:
    # setter
    def first_name=(f)
    @first_name = f
    end

    # getter
    def first_name
    @first_name
    end

    object.first_name = "Joe"
    And no goofy "set_first_name" .. it's UNIFORM ACCESS. Beautiful! Now when the anonymous coward requirement comes in, just rewrite:
    def first_name
    @first_name || "Anonymous"
    end
    No client code has to be changed. And "first_name = 'joe'" still works.

    AND you don't even have to create the basic getter/setters! Ruby classes have a built-in class method that creates them dynamically:
    class Customer
    attr_accessor :first_name, :last_name
    end
    Very elegant! Well-written programs are very clean and light.

    * No need to use exceptions for non-local flow control.

    Ruby has exceptions, but sometimes you want to jump out of a deep tree search (for instance), and an exception is what you need: "raise SearchFinishedException" or something like that.

    But is that a good idea? Using "exceptions" for flow control? No because exceptions are, well, *exceptional*, they don't occur normally.

    Ruby helps me here too. It has catch()/throw() which is a simple alternative to exceptions, designed for nonlocal flow control. And of course you can write your *OWN* flow control because it has continuations (encapsulate program flow into an object for later return).

    Anyway Ruby is such an amazingly elegant language, and the pickaxe book is the appropriate companion! Buy a copy now, even if you don't use Ruby, it's very clear and easy to read (not just because of the language, but because of the enthusiastic and talented authors).

    • But in Ruby, there's a convention like in Scheme (and maybe others): methods ending in "!", like "array.sort!" will sort the array in-place, and the other methods return a new sorted copy.Nice!

      Nice what?, the previous phrase or his copy? Excuse me, silly question, it's the previous phrase!

    • AND you don't even have to create the basic getter/setters! Ruby classes have a built-in class method that creates them dynamically:

      class Customer
      attr_accessor :first_name, :last_name
      end

      What's also handy is you can write your own methods which work like this to dynamically generate repetetive blocks of code for a class or object. ActiveRecord [rubyonrails.org] makes great use of this with things like:

      class Author < ActiveRecord::Base
      has_many :articles
      has_one :account
      end

      class Article < ActiveRecord::Base

    • one of my favorite featuers of ruby is the ability to dynamically modify built in data types at runtime. say, for example, i want to add a pretty format method to hashes. i just type:

      class Hash
      def format
      data = self.keys.collect do |key| key = "#{key} => #{self[key]}" end
      "{ #{data.join( ', ' )} }"
      end
      end

      now i can make a hash and print it just by saying:

      hash1 = { 1 => "one", 2 => "two", 3 => "three" }
      puts hash1.format

      which outputs

      { 1 => "one", 2 => "two", 3 => "three"

  • ruby documentation (Score:5, Informative)

    by pizza_milkshake ( 580452 ) on Tuesday October 19, 2004 @05:05PM (#10569953)
    one thing that really hurts ruby is that it's documentation is sparse. i used to be a big ruby fan, but documentation has not kept up with its releases. whereas i think ruby is a very nice language, languages like perl, php and python have much more complete docs, and it makes the difference between 30 seconds to figure out the right function/method and digging around 15 minutes through out-of-date docs and finally going in and reading the source code.

    i own the first edition, it's a good tutorial-type ruby book

  • I downloaded both python and ruby when I started thinking about learning how to program. I cd download and install correctly both languages on my Win2K OS laptop, but ruby had two things python did not: a really neat intro tutorial out of berkeley, and some sample progams (like abouncing red ball in a box) to play with. For kids learning to progam, this sort of basic hold your hand stuff is invaluable
    Based on this, ruby is better thought out. ON the other hand, I started to puke at all the ruby way stuff.

Slashdot Top Deals

Solutions are obvious if one only has the optical power to observe them over the horizon. -- K.A. Arsdall

Close