Archive for Ruby

Top 10 Rails Blogs, Revisited

July 9th, 2007 • 2 comments Ruby

Following my quest to learn Ruby, I eventually stumbled upon some Rails sites. Here’s a quick look on the top 10 that are supposed to be worth reading:

* make sure you subscribe

Although PHP Eats Rails For Breakfast

June 23rd, 2007 • 2 comments PHP, Ruby

Ohloh is a stalker for open source projects. These guys can discern tremendous amounts of data about any code that has public version control. Pretty nifty.

Now according to Robin Luckey’s report, PHP has seen 20% growth in terms of LoC; code written in Ruby simply dwarfs in comparison. Though I have a strange feeling about this.

I believe that this year, and the one to follow will put Ruby (and especially Rails) where PHP was back in 2002-03; in a sense Ruby will enjoy the growth in popularity and adoption the same way PHP did. But putting aside technological merits, I think that there’s a categorical difference between most code written in PHP and that in Ruby… in a Apple vs. Microsoft kind of way.

For starters, Ruby (and especially Rails) tend to spoil developers. The minimalistic approach of both the language and the framework affects the developers’ mindset, and makes them, even forces them to write more concise code. PHP has a history of ugly code, amateur software and “failed” frameworks. So the code produced by most PHP’ers would have a much larger LoC value than similar code produced by Ruby’ists.

In addition to that, most projects written in Rails are service-oriented: not open source, no public code repository, and no way Ohloh can analyze them. Most of the Ruby code that Ohloh can analyze comes from RubyForge, which accounts for most projects written in Ruby, and none of those, relatively speaking, have a large code base.

I neglect the effect of 37signals’ product design and marketing approach, though I know it’s in the back of every Rails developer’s mind. Most sites built with Rails are usually simplistic, and don’t require much code in the first place. And even if Ohloh had access to these sites’ code, they wouldn’t see much growth anyway, because once a service-oriented site is complete, feature-additions will only account for a thin slice of its growth.

Remember, the numbers on Robin’s report are those of growth not of total LoC. That is, PHP has grown by 20% even with Rails’ influence over web developers. I can only find two reasons for that:

  • PHP code is inherently more verbose, thus generates more lines of code.
  • Developers prefer switching frameworks than switching languages.

Ruby Scares Me More Than Perl

June 9th, 2007 • 2 comments Ruby

It seems that every time someone writes a Ruby library that uses class methods, symbols and hashes reasonably sensibly they get delusions of grandeur and call the result a Domain Specific Language (or maybe an ‘embedded’ DSL).

— Piers Cawley’s Just A Summary

What scares me most about Ruby is that its seemingly clean syntax can hide very ugly design artifacts, just as Perl’s seemingly ugly syntax makes it easy to cipher code. In reality, I think both languages can be equally unreadable.

Both Ruby and Perl expose their internals. In fact, they expose their internals so much that you can twist them, bend them, and practically create new languages without so much as a grunt; only each accomplishes this differently.

Ruby depends heavily on how its built-in objects behave. Like I said before, the language itself is very minimalistic, it defines a few rules to enhance (or modify) language capabilities1 and leaves the work to someone else. This means that if you override core object classes2 and mess up, your changes will proliferate through other people’s code, and end up biting back.

Maybe all DSLs are equal, but some DSLs–the ones that look exactly like Ruby code–are more equal than others.

— use Perl;

From what I understand, the Ruby community likes making new APIs and DSLs, but they love modifying Ruby’s internals in the making. That’s not necessarily a bad thing, if it’s done by very disciplined developers (who should probably read Martin Fowler’s Internal DSL Style); though that’s not true in most cases.

Here’s what scares me most: Everyone’s still hyped about Rails. forgetting that Rails is following Perl’s path of failure. You heard me, Path of Failure.

Now don’t get me wrong, I have deep respect for 37signals, and their brilliant marketing. I believe that Rails’ success has little to do with its technical merits. But I’m not going to get apologetic on this one.

Perl failed on the Web not because it had a tough competitor, but because it was so damn difficult to be up and running in a relatively short time. It took an expert on FTP, CGI and Unix permissions to install programs like MoveableType, not to mention write programs like it. Every single application reinvented the wheel, be it session management, authentication, or simple things like templates. And that’s the path I feel Rails is following.

Ruby scares me more than Perl because its syntax hides the underlying mess, as opposed to simply uglify it. What’s more, Rails’ syntax wraps around the very same mess that Ruby hides. Without rigid documentation, you’re stuck with code that would look like fluid.

Unfortunately, even Ruby and Python (which “feel” simpler, syntactically) both also have very complicated grammars…

— Stevey’s Blog Rants, The Next Big Language

Though things like Markaby make me think twice.

  1. Take for example garbage collection, introspecting, behavior of operators (e.g. comparison), importing objects from other languages, etc. ↑

  2. Say like RubyLex, Kernel, or Object? ↑

How I Stopped Worrying and Learned to Love Ruby

April 30th, 2007 • 2 comments Ruby

The past week was very enlightening. Reading the PickAxe books, I felt like I was going back to my Perl-learning days, with all their headaches and all their joy. I can’t believe I haven’t learned Ruby before.

In Ruby, where everything’s an Object, life is very simple: Everything descends from an Object class, and you can easily manipulate each and every object’s properties during runtime (that’s where Rails gets its magic from). This approach gives Ruby flexibility similar to Perl.

I keep bringing Perl up because it’s the first language that I learned, the first language that I “mastered”, and the language I enjoying coding in the most. The problem is my poor brain is built to compare and contrast, so I can’t help but get myself into a Perl vs. Ruby argument, especially that I’ve already done my Perl vs. PHP homework.

I admit I was turned off a little by the hype that is Rails. Granted, Rails is amazing, and 37signals’ marketing brilliantly associated Rails with Ruby. But if Rails turns out to be a fad, or it gets smeared by FUD campaigns, Ruby will be affected just the same.

However, putting popularity contests aside, Ruby’s zen-like sensation left me wondering whether I should use it for any serious projects.

My first (and most important) gripe was that Ruby’s performance suffers at least double as much as the next scripting language. The language shootout page clearly shows that Ruby sucks in most benchmarks. I’m not even going to mention Ruby vs. C or vs. Java because the score difference is so huge that Ruby doesn’t stand a chance. It could be because nobody paid attention to Ruby’s implementation, or because Matz wanted to keep the source code clean, or because Ruby doesn’t use a VM (like Python) and doesn’t have a 20-year-old hacker community (like Perl).

After much thought, I could only come to a single conclusion: It doesn’t matter! And the reason it doesn’t is because Ruby suffers not by design, but by implementation. But then again, every single language I know went through that path: Java was slow until 1.4, Python was slow until 2.3 (or so I believe), Perl was slow until 5.6, PHP was slow until 4.x, but they eventually solved those problems; after all, the rule is: Make it work, then make it fast. But In all honesty, if my problems can be solved by buying a few more server boxes, then the hell with it, I’ll use Ruby.

Second gripe was the availability of libraries. Ruby’s Gems are no where near CPAN nor JDK. There exists some very interesting stuff, but the vast majority of libraries pale in comparison to what’s available with more mature languages. Funny thing is, it doesn’t matter either. Nothing in software engineering says you can’t use other people’s work, in fact that’s why things like pipes exist: to bridge different tools together. Plus, Ruby’s mkmf utilities make it a lot easier to bind C libraries to Ruby. Now guess what, Perl, Python and PHP are all “libraries”, in a sense that the executable itself is just a wrapper around the shared object that is the language interpreter. This means we can implement Inline::Perl and Inline::Python, just like Perl’s Inline::Ruby and Inline::C.

The last gripe was Web server support. It’s not enough that Ruby is slow, its server support at the moment seems more like an experiment than a serious project. mod_ruby cracks under pressure, and it’s not nearly as flexible as mod_perl. Now now, there’s nothing to worry about, Ruby’s FastCGI performance can hold your business logic together. It’s still not the fastest, but FastCGI eliminates start up cost, and that is one expensive operation.

And that was only the surface of my internal monologue. It’s relatively easy to learn a new language, but it’s damn hard to forget about your emotional attachment to another. Programmers know this, and that’s part of why the Java community went crazy when Rails (and inherently Ruby) got all the attention.

So here’s my advice: Learn Ruby anyway, because it’s worth having a mini epiphany. But most importantly, learn to program, because at the end of the day, it’s not the language that matters, it’s those who know how to use it.

5 Reasons to Hate Ruby

April 18th, 2007 • 18 comments Ruby

5. Ruby Is Japanese For Perl

Originally created in Japan, Ruby is just a washed out Perl, an ill translation of a language if you will. There’s no $_, $`, $@, $$. There’s no m///, s###, y!!!, tr^^^, no qq, qw, qx, qr. Ruby doesn’t even have $scalars, @arrays or %hashes. How does it expect me to speak a language with nothing but, um, words?!

Though I excuse Ruby, I completely understand its reasons for being weird. It’s Japanese, it can’t use English.

4. Ruby Only Has 38 Keywords

According to Learning Ruby, there’s around 38 of them. Just 38! Even perlfunc documents more, somewhat around 270 functions, and I consider Perl to be a little on the cheap side.

Here’s how a real language’s quick reference should look like. A staggering 4942 functions, not counting class functions, and if you do, you’ll end up with 5312 functions. I don’t even want to know which are built-in, and which are extensions; with 5K functions, I couldn’t care less.

3. Ruby Has No Sense of Humor

Watch:

`$=`;$_=\%!;($_)=/(.)/;$==++$|;($.,$/,$,,$\,$",$;,$^,$#,$~,$*,$:,@%)=(
$!=~/(.)(.).(.)(.)(.)(.)..(.)(.)(.)..(.)......(.)/,$"),$=++;$.++;$.++;
$_++;$_++;($_,$\,$,)=($~.$"."$;$/$%[$?]$_$\$,$:$%[$?]",$"&$~,$#,);$,++
;$,++;$^|=$";`$_$\$,$/$:$;$~$*$%[$?]$.$~$*${#}$%[$?]$;$\$"$^$~$*.>&$=`

Now watch:

print map chr$_[0]-ord$_,@_='200ocT¨gZYT`cV¨xcV\¨`ge]cV'=~m;(\d+|.);g;

Can Ruby do this?

2. Ruby Has No Class

“Class in an object, Object is a class.” Ruby people just love to philosophize.

A Class in Ruby is just an object that can spawn new Objects. Classes can have methods attached to them, but not give these methods to their spawned ones. Objects on the other hand are instances of Class, and have their own methods that Class gave to them.

Not only that, but objects are open and can be overridden. This means that a method can be turned into an object, which then can be used as a block passed to another object, glued to a class, split across more objects, called simultaneously from difference threads, on different servers, redefined, then redefined again, twisted into obedience, bond to a master, and then beaten to death.

I’m not expecting you to understand, I couldn’t either. And Just so you know, capitalization in the quote above does matter.

1. Ruby Makes You Think

With Ruby, you have more than enough rope to shoot yourself in the foot. Good luck trying figuring out Ruby’s dynamicism (or the couple of paragraphs above). Ruby’s flexibility makes it very easy to write code than only you (and God) can understand.

If you want to write proper Ruby, you better understand classes and objects, lambdas, design patterns, mixins, threading, messages, and tons of other funny words, otherwise you’ll end up where you started: writing CMS software in PHP.

Tweets from