Ruby frustration
Written on September 30 2011.
This blog post was written a long time ago and may not reflect my current opinion or might be technically out of date. Read with a grain of salt.
The more I code in Smalltalk, the more I find the flow of developing in Ruby annoying. What I really miss is a good way to navigate code, the debugging facilities and the runtime aspect of a Smalltalk dialect.
Code navigation
The browser is the standard way to browse code in Smalltalk. While it can be seen as cumbersome and ugly (in the look and the feel) compared to a native UI or a text editor, experienced smalltalkers have a love-hate relationship with their browser.
When using it, you do not need to have 45 tabs opened in your web browser. Almost all the documentation you need is right there in front of you. Browsing the senders and implementors of a method is so easy and convenient. When you come back to a text editor and Ruby code it’s just a pain in the ass to perform changes in your code.
As a developer you will spend (by far) much more time debugging and reading code than writing it, why not have a dedicated tool to browse it ?
Runtime
One of the most frustrating point when developing in Rails is how slow it becomes when your Gemfile grows. Running the test suite is so slow, it feels like the old ‘code-compile-run’ cycle is back again. It’s not the tests that are slow per se but loading the environment. Each time you run a test, you wait for Rails to start while the actual time spent in the test(s) is negligible. Very frustrating when doing TDD.
There are some tools to overcome this problem but it’s sometimes quite hard to get them working (more on this in a later post).
Debugging
Take the browsing tools and the always-runtime feature and you get easy debugging. The TDD flow get much better when you can create methods on the fly, navigate the stack and change the state of your object on the fly. In Rails, I’m used to run the test, see it fails, switch to my text editor and re-run the test. Tools like Pry makes things much more smooth but they are quite far from a live debugger.
Closing
This post is already far too long for and probably not very well illustrated but I hope you get the idea. I’m not saying that Smalltalk is better; all the goodness mentioned before have their drawbacks, mainly when it comes to deployment. As your code is always running, it can be quite cumbersome to deploy it on a server in a fresh state. There are tools to help but they are not as nice as what you get in the Ruby world. A lot of smalltalkers seem to have their own recipes to deploy. It can be quite disturbing for someone coming from Ruby.
Anyway, I gonna try to illustrate my arguments in the next posts. Thanks for reading !