Orange: A great little blog entry about creating your own language using the grammar description gem TreeTop and llvmruby, a gem that gives you access to all that llvm goodness (JIT or compile to bytecode).
ArrayFields: Tired of indexing with numbers? Index your arrays in a better way.
Main: Quit re-writing your main program structure for all those flags and options. Use this gem to do the heavy lifting.
rq: rq is a great little gem for clustering Linux boxes via a job system running on an sqlite database on an NFS. Check out a nice little article on it here.
I have always subscribed to the Sapir-Whorf hypothesis (a.k.a. Linguistic Relativity), especially in its applications to programming. It is my firm belief that programming languages directly influence how programmers solve problems. The verbosity and robustness of any solution are often directly dependent of the paradigms that the language attempts to empower.
As a simple example, one can examine the solutions that Ruby programmers come up with when given the power of meta-programming. Some are clean and extremely beneficial to the end user. If we look at ActiveRecord, we find that all sorts of instance and class level methods and values are inherited dynamically, by looking up values of columns in a database table! All transparent to the user.
While some solutions provided by Ruby’s dynamic and meta-programming ways are extremely elegant, other times it just leads to a heap of spaghetti code. Speaking from experience, with the lack of type constraints built in, open classes, and meta-programming abilities, I often find that I get objects in some places that I don’t expect. Twitter had the same problem. They blamed Ruby. Others blamed bad programmers.
I blame both. Personally, I know that my ‘programming hygiene’ has greatly suffered in my ‘Time of Ruby.’ While it has allowed me to code with blazing speed and agility, I find that my code smells quite a bit worse than it used to. It was great for writing one-off programs, but my code readability and reusability has faltered greatly. Quite simply, in the absence of static languages, or even functional languages, I failed to shoulder the responsibility of ensuring that my programs were well constructed and well tested.
Having picked up Scala lately, I have found the switch back to a static, semi-functional language refreshing. In fact, I feel almost the same way I did when I switched to Ruby. Now, writing simple one-off programs has taken me more time — but it also tends to lead me to writing reusable libraries. I tend to break up my code more naturally, instead of hacking together solutions that work at the time. Instead of just restarting a project, I find myself refactoring.
So that brings us back to the Twitter case. I know it is old news, but I think it is a good case study. Twitter chose Ruby because it allowed them to rapidly develop their product. But when it came to scalability, they found that it just didn’t suit their needs. That isn’t to say that Ruby couldn’t suit their needs — they just didn’t find it to be the appropriate solution. Certainly, I know I have trouble maintaining a large Ruby code base (except for maybe a well constructed Rails project). On the other hand, most of the larger Scala projects I have written have naturally fallen into proper software engineering constructs on their own. I put that on the language.
You see, I know I am a bad programmer. Not in the sense that I can’t write efficient algorithms, or design systems well. I can. But under the time constraints of business projects, I don’t. And Ruby let me do that better than any other language I have used. So I guess I will use Scala for now, not just for my own sake, but for the sake of everyone who has to read me code one day.