Home > Messages from the Ether > Some thoughts on Ruby after finishing a week (minus one day) of training

Some thoughts on Ruby after finishing a week (minus one day) of training

Ruby's been my go-to language for any medium-trivial scripts that might need to be written. At work, I'd used it for some log file manipulation and for converting CSV files to SQL INSERT scripts, plus minor misc. one-offs. It's benefits are its portability and terse power. Being a Java developer, I'd honestly prefer to have used the almost-identical Groovy language, but it requires the JVM and who wants to always rely on that behemoth (useful as it is)? Passing around a few rb files plus an exe and a dll is just too simple.

This training (for the new job) is covering Ruby proper plus Rails. Much of the framework maps easily onto what is offered either in the JEE Web container and Servlet API or in the JPA/Hibernate API. There's a template library, request filters, URL mapping, and general data persistence and query support. Knowing one definitely helps in learning the other.

Monkey patching/duck punching is de rigueur, so classes are commonly rewritten at runtime as part of the standard framework. You just need to know that a class will look a certain way. Also, interestingly, any number of unintuitive methods will be dynamically added based on a callback named method_missing. This is called whenever a ... method is missing (doy). Frameworks will use it to allow loosely defined methods to be generated at runtime (e.g. by parsing intent from a method name, such as "find_by_name_and_age_and_zip"). All of this tacit interface generation adds to the general confusion when learning. Much is non-explicit in the code.

Readable, English language code is a goal. Ruby's functional roots make this easier to achieve this goal than, say, C++ or any C-derived language (although the Boost library's Spirit parser does an excellent job of using C++ operator overloading to replicate BNF). Because of the emphasis on readable code, Ruby library developers will talk about creating DSLs as opposed to simply APIs. This seems like an odd affectation.

The functional bits are familiar enough if you know C++'s function objects or Java's anonymous inner classes. Doing these tasks in Ruby is, however, much cleaner. (Notably, C++11's lambda functions offer promise, as does Java8's closures.)