Your skill will accomplish
what the force of many cannot
One more perl programmer's take on Ruby (discussion)by deprecated (Priest)
|on Nov 18, 2001 at 02:04 UTC||Need Help??|
I've been talking to a lot of people about our trade, as programmers lately. Well, let me back up. Some people here arent trade-programmers, but program for fun. So maybe some of you guys haven't gotten the ruby "buzz" thats going around.
At work, we seem to have two different kinds of programmers. Programmers who do what they do because they went to school, learned it, and they make a living doing it -- and the other kind. The programmer who seems to code because he or she actually likes to do it. I'd even call these people 'code junkies' some times.
So, like memes, sometimes programming languages go around and embed themselves in new communities. I think that perl is such a language. It caught unix admins, C programmers, and shell programmers (and my apologies, but I'm going to include awk programmers in that bunch) sort of by surprise. Lo, there was a new language, and it was pretty cool. It had new syntax and new features and made the hard tasks less hard and the impossible tasks possible (Napster clients in awk, anyone?).
Lately, I've been hearing a lot about Ruby. My friend Dan referred to it as "Perl's younger, prettier sister." A prospective employer looked at a code sample of mine (perl) and asked me if I had looked at ruby; not because it was a skill for the job, but when somebody uses perl like I do, they might be interested in Ruby.
I had heard about it, but had no idea what it was about, and the very few samples I had seen reminded me of Python, which, frankly, makes me sick.
Well, after enough people had told me to check it out, I decided to buy the book. I had just finished my new Tom Robbins Book, and had some time to kill. So I picked up Programming Ruby, The Pragmatic Programmer's Guide.
After about 20-25 pages into the book, I had Ruby pretty much understood. Many of the stuff is totally intuitive for perl programmers.
My impressions of the language are pretty much as Dan expressed it to me: it's a younger, fresher, prettier language. This isnt to say that I dont still love and won't continue programming in it. I've got a lot of time and a lot of effort invested in being a good perl programmer (despite what some of our 'bretheren' may think). Furthermore, perl has a lot more functionality in terms of modules and support. From what I can tell there is no 'rubydoc', there is no 'cran', and there is precious little literature. DBI seems to be mostly ported, including DBD::Pg, without which I could not exist.
The object creation syntax of ruby is pure ecstasy when compared to perl's. I've always been turned off by the syntactic ugliness and hoops I had to jump through to make modules in perl. In Ruby, such things not only are easy and clear, but come naturally.
Where ruby is lacking, in my opinion, is flexibility. One of the things I treasure about perl is TIMTOWTDI. A friend of mine on IRC was bitching that what perl is sorely missing is an 'elsunless'. A cute joke, but indeed, perl seems to be missing very few syntactic niceties. Ruby requires you to code in a more rigid way, and be more verbose about things. However, the things you do in Ruby are more clear and easier to code. I think in many cases, Ruby excels at being all the things Perl strives to be. Perl, however, has just hyperfocused on a few of those facets. This is where Ruby's youth shows. It is a very general language and isnt really good at doing a few specific things, it seems to be pretty good at doing a lot of different things.
Its almost like you can see where Ruby is going, but it hasn't gotten there yet. I suppose that's part of the fun of using it.
I'm not going to post contrasting code samples, as that has already been done here, and it doesnt really do the language justice.
My take on the abovementioned book is it was just not written very well. The ages-old example of the "Song" class is overused and unclear in this book. The authors neglected, very early on, to explain that Object.id returns an "id" of that object. It was never mentioned, and its output was just shown as "normal" with no explanations. I understand there is an HTML version of the book online. Read the first 20-30 pages of it, and then start coding your own Ruby. It's not hard, and you'll pick up more that way since you know Perl already.
Cheers, and happy coding.