Slashdot Mirror
Programming Ruby: The Pragmatic Programmers' Guide
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.
http://www.rubycentral.com/book/
"Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"
The review mentioned web programming, does one need a specific platform installed or it "just runs"?
Rock that crushes, Paper & Scissors that don't matter.
...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.
The Army reading list
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
Why didn't reviewer say 'Brilliant, but slightly flawed'.
Who could hang a name on you
Oh come on someone had to do it.
Do not try to read the dupe, thats impossible. Instead, only try to realize the truth
What truth?
There is no dupe
Is it a desirable function that employers are looking for? Can you make money or is it just like other jobs, non existant and low paying.
The non-Pragmatic Programmers' Guide
Yet Another Web Site
...thanks to Ruby Central for sponsoring it.
A BitTorrent of the presentations is available here.
The Army reading list
where does the pickaxe name come from?
I liked this book a lot but there are a lot of typos.
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!
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?
Slashdot Syndrome: the sudden, extreme urge to correct someone in order to validate one's self.
...are also available on ruby-doc.org here.
The Army reading list
Why's Poignant Guide to Ruby has got to be the most entertaining Ruby read out there....
Tweet, tweet.
Way to keep those eyes peeled, mods!
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.
-- Thou hast strayed far from the path of the Avatar.
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.
Rich And Stupid is not so bad as Working For Rich And Stupid.
Waiting was the hard part. Hopefully I can get a copy of the book soon. Great work.
;)
Ruby is a great language to program in and embed. Ruby and SOAP is a decent combination and anyone looking for a newlanguage, this is the language for you to try out. You'll get hooked on the great syntax, community, and Matz!
Remember to check out your local copy of ruby stable-snapshot today!
The online community has a mailing list and various channels on Freenode.
#ruby-lang, #rpa, #rubymine, #rubyonrails, and more!
Thank Matz and the other core devels.
Ruby Power!
David Ross
------------------
Hassle-free packages and package system
http://rubyarchive.org/
Comment removed based on user account deletion
Funny you mention that. I'm a Ruby coder, but with a bent toward exploring languages. I've been thinking about learning a little REXX myself.
;-) Ironic isn't it?
s e
;-)
Also I'm exploring K and R. But not C
For general programming language discussion try:
https://lists.berlios.de/mailman/listinfo/suby-mu
Signed,
Amiga Owner #51
:T:R:A:N:S:
I've written code in many, many different languages. I got interested in Ruby a long while ago but never bothered doing anything about it, then a few weeks ago I started looking into it seriously. After doing quite a lot of speed testing (in particular various mathematic statements) against PERL I found that Ruby usually took twice as long to complete an operation than PERL did, which was rather disappointing. However, IIRC Parrot is going to support Ruby so any speed concerns should be eliminated - maybe I'll dive in properly sometime :)
Dave Thomas? Wendy's? Chicken Nuggets? Come on; it's funny!
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 it obvious where you are coming from in the, uh, Computer Science landscape.
Save your wrists today - switch to Dvorak
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).
The Pickaxe book, named for the tool on the cover, is the definitive reference to this highly-regarded language.
Juat as PerlFans refer to The Camel or The Panther.
You sly dog: you got me monologuing! - Syndrome
Using tabs for indenting is recommended against in Python. It's a Python newbie mistake that is usually only done once.
Exactly. Set your editor to insert n spaces (instead of a tab) when you hit the tab key. If your editor won't do this, you need a different one.
Cool link, wrong book :)
Ah, nothing like a classic troll...
Comment removed based on user account deletion
There are several kinds of programmers, at least when it comes to the language selection:
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.
If you open yourself to the foo, You and foo become one.
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 amount of support. The (online) documentation has room for improvement, although I might have been spoiled somewhat by the online Java documentation. (That said, I've hardly used Java at all for three or four years.)
About a year ago I took my first proper look at Ruby. Ruby is a nicer language. It's more consistent and feels a bit more natural once you get to more in-depth language-related things.
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.
Python simply doesn't let you do this, short of something drastic like hacking the interpreter. Although a large part of the standard libraries are very flexible, the string class is something that's just built in. It can't be touched, because the string implementation is built into the interpreter. I spent a month trying to get my idea to work before I was able to find out that the string class is inconsistent with other classes, and what I wanted really wasn't possible.
Python's a great language and it's wonderful for prototyping and scripting, but it's this type of thing, where the occasional part of the language is still inconsistent that still lets it down on occasion. For me, at least. My experience with Ruby so far has been that everything just acts the way that you'd expect it to act based on how everything else acts. I'm still not an expert Ruby programmer and there are parts of the language that I'm still working to get my head around, but I haven't yet encountered anything that seems painfully inconsistent.
Putting all of that aside, I'd recommend definitely learning Python if you want to be productive, and learning Ruby as a side project for the future. The reason I say this is that Python just has so much more support and more depth. eg. Ruby doesn't yet have great support for a lot of often-needed things like Unicode, and you're likely to find a lot more Python support for parsing routines, too.
Ruby is certainly likely to be useful in a production environment and on a later day may be superior to many other scripting languages. It's worth becoming familiar with it just for that, but I wouldn't want to base everything on Ruby (yet) without backup plans.
When I go to Amazon.com it tells me the book is not yet released, but according to Oreilly it is.
Hmmm.
Anyone know why?
Ah but the advantage of a tab over n spaces is that it can be removed with a single backspace, whereas n spaces can't. Unless you bind backspace to un-indent, but then it wouldn't delete normal characters...
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:And no goofy "set_first_name"
AND you don't even have to create the basic getter/setters! Ruby classes have a built-in class method that creates them dynamically: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).
i own the first edition, it's a good tutorial-type ruby book
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.
Had to make the same choice a bit earlier as well (what scripting language to learn: perl, python, ruby) (briefly looked at scheme / lisp too).
Finally picked ruby over python, mainly cause I liked the founder of ruby more. Been scripting the last few months in ruby, and I'm managing fine with the available documentation on the web.
I come from that part of the, uh, Computer Landscape where folks believe in crop-circles, George Lucas's genius, and the arguments proving that the lunar landings never happened. Oh yeah, and where programmers don't want white-space to have the significance that it does in Python.
It's a real mixed bag in my neighbourhood. But however crazy it gets, we always agree that Aquaman should have found a wife with gills.
Rich And Stupid is not so bad as Working For Rich And Stupid.
I don't know of any editors that work that way. Most will gladly allow you to configure them to use emulated tabs: any line beginning only with whitespaces acts as though that whitespace consisted only of tabs.
:-).
It's a pretty fundamental feature, thanks to all the disputes about the One True Indentation
-Billy
Your sig is my favorite Philip K. Dick quote.
"I think this line is mostly filler"
Tabs are superior because they are easy to adjust to whatever the reader's preference is, just by changing the tab stop setting. Tabs also save 3 bytes per line if you are using 4 space indentation. They are also backwards compatible with text editors that are unable to substitute keys. It is important to realise that people besides yourself may want to read your code.
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.
Of course, there is already a Data Description Language with whitespace significance, vying to replace XML: YAML. And, interestingly enough, this particular instance of style-as-substance seems to be quite popular with the Ruby crowd.
So you use spaces instead of tabs. Big fucking deal.
YAML differs somewhat from Python in this regard. When a Ruby programmer deals with YAML, it's largely by reading in the YAML code, which creates a Ruby object, dealing with that object, then calling another method to reserialize that object to YAML.
Python code requires more direct editing.
You must be new here. It's due to their 1-click business-practice patent, some years ago.
/new/ books there.
I'm not infinitely serious but, that's why the slashdot links use bn.com instead of amazon.
And I for one don't buy
Someday we'll all be negroes
When will it appear on Safari?
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: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 happens to be a powerful one.
-- B.
This sig does in fact not have the property it claims not to have.
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.
Having been a rapid C++ programmer, this was my largest complaint against Python when I was first introduced to the language, but now I consider it one of Python's strengths. Most languages that ignore whitespace invariably have cultures or conventions for defining "proper code indentation". This leads to a redundant mess where you (the programmer) still respect whitespace, often with conflicting "styles", but also respect the language's syntax for doing the exact same task. Python cuts through that crap by throwing out explicit scope declarations ('{', '}', 'begin', 'end', etc), as every language rightly should. This results in shorter, cleaner, more easily readable code. Btw, you can still use ';' in Python, it's just not mandatory.
As for your "complaint" about crossplatform whitespace, that's the fault of your editor, not Python (I've yet to find a decent editor that doesn't allow you to view whitespace). The recommended Python indentation is four spaces, which is interpreted the same on all platforms.
Overall, I have to admit Ruby is at least Python's equal in most regards, but it's lack of whitespace is one of the main reasons I haven't considered seriously adoption.
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' statement. All Python forces you to do is write clean, readable code.
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.
I wonder why there has not been any "In Japan" jokes here!
Sorry for an off-topic rant by an old man, but this pointless duscussion has just reminded me a recent story comparing Java to C# when someone 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 tubes, Real Programmers wrote in machine code. Not Perl. Not C. Not, even, assembly language. Machine Code. Raw, unadorned, inscrutable hexadecimal numbers. Directly.
Lest a whole new generation of programmers grow up in ignorance of this glorious past, I feel duty-bound to describe, as best I can through the generation gap, how a Real Programmer wrote code. I'll call him Mel, because that was his name.
I first met Mel when I went to work for Royal McBee Computer Corp., a now-defunct subsidiary of the typewriter company. The firm manufactured the LGP-30, a small, cheap (by the standards of the day) drum-memory computer, and had just started to manufacture the RPC-4000, a much-improved, bigger, better, faster -- drum-memory computer. Cores cost too much, and weren't here to stay, anyway. (That's why you haven't heard of the company, or the computer.)
I had been hired to write a FORTRAN compiler for this new marvel and Mel was my guide to its wonders. Mel didn't approve of compilers. "If a program can't rewrite its own code," he asked, "what good is it?"
Mel had written, in hexadecimal, the most popular computer program the company owned. It ran on the LGP-30 and played blackjack with potential customers at computer shows. Its effect was always dramatic. The LGP-30 booth was packed at every show, and the IBM salesmen stood around talking to each other. Whether or not this actually sold computers was a question we never discussed.
Mel's job was to re-write the blackjack program for the RPC-4000. (Port? What does that mean?) The new computer had a one-plus-one addressing scheme, in which each machine instruction, in addition to the operation code and the address of the needed operand, had a second address that indicated where, on the revolving drum, the next instruction was located. In modern parlance, every single instruction was followed by a GOTO! Put that in Pascal's pipe and smoke it.
Mel loved the RPC-4000 because he could optimize his code: that is, locate instructions on the drum so that just as one finished its job, the next would be just arriving at the read head and available for immediate execution. There was a program to do that job, an "optimizing assembler," but Mel refused to use it. "You never know where it's going to put things," he explained, "so you'd have to use separate constants." It was a long time before I understood that remark.
Since Mel knew the numerical value of every operation code, and assigned his own drum addresses, every instruction he wrote could also be considered a numerical constant. He could pick up an earlier "add" instruction, say, and multiply by it, if it had the right numeric value. His code was not easy for someone else to modify.
I compared Mel's hand-optimized programs with the same code massaged by the optimizing assembler program, and Mel's always ran faster. That was because the "top-down" method of program design hadn't been invented yet, and Mel wouldn't have used it anyway. He wrote the innermost parts of his program loops first, so they would get first choice of the optimum address locations on the drum. The optimizing assembler wasn't smart enough to do it that way.
Mel never wrote time-delay loops, either, even when the balky Flexowriter required a delay between output characters
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: "The amazing project [...] to really unite Perl and Python one day (not to mention Tcl, Scheme, Forth and Ruby, to name just a few)."
Perl, Python and Ruby, while not the only ones, are certainly the most important languages for the Parrot development. Parrot will not be considered ready until all of them are fully supported, and at this point Parrot will be their main target Virtual Machine, running each of them and allowing them to interoperate. At this point it won't matter which of those languages you personally use, because whatever you choose you will still have access to all of the libraries and module, class and object, of each of them.
Few years ago I will tell you: "go for Perl because of CPAN." Now my advice woule be: "go for whatever you please, for in few years it won't really matter. We will be able to work on the same project, write the same application. I will write my part in Perl 6, you will write yours in Ruby, someone will write in Python and another one in Scheme. We will all subclass our classes, invoke our methods, use our objects, and we will produce a single, monolithic Parrot application anyway."
Just imagine picking up some fresh, young and cutting-edge language designed weeks ago--or even designing your own language--and having every module from CPAN available at once, working just fine using your new language syntax. This is the future Perl, Python and Ruby. Interoperation instead of competition.
Sincerely,
Pan Tarhei Hosé, PhD.
"Homo sum et cogito ergo odi profanum vulgus et libido."
You must be confusing it with a different book by O'Reilly. "Programming Ruby: The Pragmatic Programmer's Guide" is published by Addison-Wesley.
Oops... you're right, O'Reilly isnt the publisher, but neither is Addison-Wesley for the 2nd edition. It is published by the Pragmatic Bookshelf publishers
Ruby combines a lot of goodies from different programming paradigms which results in an incredibly powerful yet simple language.
Ever awed at Perl hacks producing things you never thought to be able to do in a few lines? The same done in Ruby, and you might actually understand the few lines of code at first glance...
Ever awed at consistent object oriented design in Smalltalk or (well done) C++? Try Ruby and you wouldn't believe that there's languages that try to do it another way....
Ever awed at LISP programs passing code chunks around and evaluating as if there's never been a difference between code/data? In Ruby you are allowed to do that and other dynamic magic and you are still given a beautiful, clear syntax beyond ((braces) (which ought to be enough anyway))...
Ruby is a gift to us developers. It is the future of language design, brought to us now...
Learn the Ruby way and you will learn to develop software.
moron trap. Learning a language is a one time thing. If you spend 1 week learning a language which lets you write programs 7 times faster vs. your "already known" language, which do you think will come out on top in the end? (Hint: If you write more than 7 programs it will be the new language). Sure, libraries *are* a factor, but please don't tell me that C doesn't let you write programs faster than symbolic assembler (yet giving you the exact same libraries to work with).
HAND.
I think Haskell had the right idea with the whole whitespace-denotes-flow thing - it used the offside rule, but if I remember right, you could throw in braces and semi-colons and have any old formatting.
Propaganda. What would motivate someone to spread idiocy like this against a programming language? I'm genuinely curious.
if you
s/Python/Perl/g
s/Ruby/Python/g
You would be making a statement I heard many many times in 1999.
Yet Python use has been growing. I just recently started looking at Ruby (I bought "Programming Ruby" 1st Edition from the overstock rack for $5 the other day) and I see it has a lot of the 'just makes sense' things that drew me to Python over Perl and drew me to Perl over Java.
Picking a development environment for a project is important if you're spending someone else's money. If you're hacking around at home, you deserve to use what you like.
Much of the reason why Python has grown so successful (besides Guido Van Rossum, BDFL) is that lots of 'regular folk' liked it better than Perl.
Also, from what I've seen so far, the surface differences between Ruby and Python can probably be learned in a day or two. If you know one, you probably should learn the other just to put it on the resume.
My father is a blogger.
That's a very legitimate concern - if you're using Notepad. If you use something more reasonable like Vim, Emacs, Kate, Eclipse, or any other modern programming editor, then you need to spend two minutes learning how to enable Python indenting rules.
For example, in Kate you can highlight the block and hit <tab> to indent the block or <shift-tab> to unindent. If your editor doesn't offer similar facilities, then it's time to upgrade.
Dewey, what part of this looks like authorities should be involved?
That's absolutely ludicrous. You should be using <pre> tags around your code anyway, and those preserve Python indenting every bit as well as Perl, PHP, and Ruby formatting.
If you haven't found Python on the web, then you're simply not looking in the right places.
Dewey, what part of this looks like authorities should be involved?
So in order to paste in bits of code from elsewhere, I have to open my source file in Another Editor that Isn't Emacs or Vi, use it's mysterious indentation features, save, then reopen the edited file in my editor of choice? Sounds fun...
Right, but not all bulletin boards / forums / etc. let you use <pre> tags. Take slashdot, it lets you use 'ecode' but that isn't quite the same thing. In addition, copying and pasting text from a table is always troublesome, it's really hard to make sure you get all the indentation right.
When the language has start and end delimiters for a block of code, a good editor can re-indent it without having to "understand" the code. Python doesn't work that way. The lack of "reindentibility" of Python code is a huge drawback for Me.__init__(self).
Python:
Can Idle truly indent that python code properly? Without an end token, how does it know whether 'print "world"' is part of the conditional block, or is simply a statement following the conditional block?
Ruby:
Because the conditional block contains an end token, the indentation system can figure out how far to indent things.
I don't know of any programmers who are frustrated by having to end their code blocks, and those few extra keystrokes are worth it if it means that my editor can fix indentation across the entire file if I choose.
Learn Japanese, ya lazy bum!
Just kidding. You're right, documentation has been a major weakness of Ruby in the past. With 'ri' and 'rdoc', and the new wonderful book this review is all about, modern versions of Ruby are becoming better and better documented. There's still a long way to go, especially in 3rd-party libraries, but they're coming along too.
They're both really easy to learn, at least the basics. With the interactive interpreter ('python' for Python, and 'irb' for Ruby) you can just poke at it, and try random things. Honestly, Ruby and Python are two of the most beginner friendly languages out there.
As for that page, my experience is that if you like Perl at all, you'll like Ruby more than Python. I know plenty of Ruby users who like both C and Perl, but in my experience it is rare to find a Python person who likes Perl. But don't take my word for it, try them both. They're really easy to play with.
If I want to define something that acts like an array/hash in Ruby, I define the operator like:
The dichotomy between the name for the internal implementation of the method and the use is yet another thing that bothers me about Python.
Can Idle truly indent that python code properly? Without an end token, how does it know whether 'print "world"' is part of the conditional block, or is simply a statement following the conditional block?
Because the conditional block contains an end token, the indentation system can figure out how far to indent things.
If you write Python code in IDLE, the indentation will be taken care of as you write it. Not after the fact. But you're misunderstanding Python. Unlike C or Java, the whitespace is part of the syntax. Forgetting to indent in Python is the same as forgetting to use a curly brace in C/C++. Can your system figure out where to add a missing brace? Both compilers will complain. The only difference is with Python, the whitespace and scope declarators are the same, so your work is less.
I don't know of any programmers who are frustrated by having to end their code blocks, and those few extra keystrokes are worth it if it means that my editor can fix indentation across the entire file if I choose.
Why would your indentation be broken? I understand your argument. It's a common one among programmers unfamiliar with significant whitespace. You've never known order to whitespace. To you, whitespace is a variable, to be substituted and interpreted by the programmer, and to be "fixed" if it doesn't fit your "style". What you fail to realize is that this is all meaningless and is irrelavant to the true purpose of your code, which is to DO something. With significant whitespace, there are no style wars, no "broken" indentation to be "fixed", no redundent syntax. Just clean, readable code.
I have no idea why has your post been moderated as Troll. Those are very good questions. There will be many ways to interoperate on many levels. I'll start from the things you are asking about, i.e. mixing languages in the same file, and then I'll talk about what I think will be even more important. First of all, in Perl 6, eval() will take an optional argument which will be the name of the language used to compile the string:
This is the most verbose syntax and something similar will probably be added to other languages, even those with no built-in eval(), by using some simple module or library in the worst case. Every language compiler will be available on the Parrot level, so it won't be an issue.
Actually, inlining other languages code is already possible today in Perl 5, using the Inline modules:
For example I just ran this Perl program:
It printed: "9 + 16 = 25" and "9 - 16 = -7" but 25 and -7 were computed by C functions. The first time I ran it, it took longer because the C code had to be compiled, but every next time the already compiled shared object is used and it starts instantly. When the C code changes, the module recompiles the shared object automatically and saves the new version. This is a simple example which may seem useless, but you might for example write the speed critical parts of your Perl program in C to speed it up, etc. without the need to learn the XS language normally used to create an extension interface between Perl and C.
Using other languages in Perl 5, though, especially other than C, is probably not very elegant under the hood. Also, you cannot pass live objects back and forth and axpect them to behave normally, as far as I know. Perl 5 and Python both use their own virtual machines, with different bytecode and different behaviour, like garbage collection, threading etc. When Perl 6, Perl 5, Python and Ruby are running on Parrot, they will all get compiled to the same bytecode, with the same function calling conventions, the same exception handling, they will run on the same VM, with the same threading, garbage collection, etc. only with different data semantics, because for example Perl strings in numeric context are converted to numbers, Perl 6 will have things like 0 with true boolean value, etc.
Going back to inlining other languages in Perl 6 programs, in addition to eval(), thanks to powerful macros, someone will easily write one which would let you write:
or POD-style:
or an XML-style, or some fancy bracketing, or indeed whatever syntax you'd like. But probably more important than mixing languages in the same file, would be the ability to use classes and objects from other languages. For example, you will be able to use Perl DBI module from CPAN in a Python program, using probably something like this:
Sincerely,
Pan Tarhei Hosé, PhD.
"Homo sum et cogito ergo odi profanum vulgus et libido."
//Information does not want to be free; it wants to breed.
HTML says whitespace is not significant. Python says it is. Nuff said.
It's not just HTML either. Whitespace isn't significant in any natural language, nor in any other computer language I'm aware of. The computer world simply isn't well equipped to deal with signficant whitespace. Any time you copy/paste code around, you run the risk of messing up indentation / whitespace. it's much harder to accidentally miss a } or 'end'
Don't get me wrong. If python required signficant whitespace *and* closing tokens, that would be better. That way you'd have the best of both worlds. An editor could fix bad indentation because of the tokens, and you'd be guaranteed to have properly indented code for all working code.
And, the truth is, Python does have redundancies. In this very discussion we've had people complaining about how you get the length of things in python using len(foo), but others explaining that you can actually use foo.__len__(). Significant whitespace doesn't eliminate style wars, nor does Python eliminate redundancies. Python code is clean and readable, just like Ruby code. Ruby code, by not being whitespace-dependent is much more copy-and-paste-and-share-with-the-world-friendly.
HTML says whitespace is not significant. Python says it is. Nuff said.
In other news, apples are red, so oranges must suck? Do I really have to point out the fact that HTML and Python are two completely different creatures designed to do completely different tasks?
It's not just HTML either. Whitespace isn't significant in any natural language, nor in any other computer language I'm aware of.
You're missing my point. Most languages, including Ruby, essentially still have significant whitespace, it's just not enforced. Try replacing all whitespace tokens with a single space in your language of choice and you'll quickly see how whitespace plays a very important role in programming languages. And btw, significant whitespace is also featured in Haskell, Occam, and YAML.
The computer world simply isn't well equipped to deal with significant whitespace. Any time you copy/paste code around, you run the risk of messing up indentation / whitespace. it's much harder to accidentally miss a } or 'end'
I guess all those Python programmers must be tripping over themselves on a regular basis. Hell, I don't even know how I manage to code my Python programs in a few days what would have taken me a few weeks to do in Java or C++. Yeah, significant whitespace is horrible. That's why Python's popularity has only risen in the last decade since its inception. I'm not sure what browser you're using, but I suggest you upgrade (Firefox is especially nice). I've never had trouble copy/pasting Python code around. Granted, this is still a poor measure of a language since most code is shared in files.
Don't get me wrong. If python required significant whitespace *and* closing tokens, that would be better. That way you'd have the best of both worlds. An editor could fix bad indentation because of the tokens, and you'd be guaranteed to have properly indented code for all working code.
With significant whitespace, there'd never be a need to "fix" indentation, so any tokens would be meaningless. I think you're associating Python's whitespace with the use of tabs. Standard Python whitespace is four spaces per level of indentation, which is quite explicit.
And, the truth is, Python does have redundancies. In this very discussion we've had people complaining about how you get the length of things in python using len(foo), but others explaining that you can actually use foo.__len__().
Wrong again. __len__ is a utility function meant to be overridden in the class definition by programmers who know what they're doing. It's not meant to be called outright. The reason for this is, the underscores represent a reserved namespace that allows the Python developers to introduce new functionality without breaking backwards compatibility. You shouldn't be so quick to criticize a language you seem to know little about.
Significant whitespace doesn't eliminate style wars, nor does Python eliminate redundancies. Python code is clean and readable, just like Ruby code. Ruby code, by not being whitespace-dependent is much more copy-and-paste-and-share-with-the-world-friendly.
Yet ironically, the Python community dwarfs that of Ruby. Actually, I suppose that's not really ironic after all.