Friday, September 28, 2007

Rant on Ruby ambiguity and syntax woes

I've been part of the Ruby on Rails hype, as many others - I also wrote two small programs that are quite regularly used by me and Thomas, for whom I wrote a little helper to coordinate FAI development. Admittedly, neither of them ever made it being good enough to be published.

So, at the first glance, it looks very easy to do simple stuff with ruby/rails, and you can do some nice things very fast, without the hassles and complexities of setting up a Java project.

Still, the more I look at it, the more I wonder, if Ruby/Rails is a good way to go.
In developing a prototype for the new FAI GUI, I will check some interesting things:

  • What happens if you start writing an app that doesn't use a database to store it's data, but, say, the filesystem?
  • Will it be easy to use the model classes in an external lib, for creating other frontends than web-based ones? (most important: command line!)
And some other stuff...

But, I've come here to rant about some ruby stuff that starts to annoy me.

What about ambiguity?

I admit, it's saves some characters, but why do we have << class="blsp-spelling-corrected" id="SPELLING_ERROR_7">methods for the same functionality, and is it really necessary, to use special characters as method names? We learned from Perl that languages with too much ambiguity and shortcuts are likely to become "write only" - and not even the very authors of programs dare to touch them ever again, because they fail to understand them as soon as they stopped looking at them for more than 2 days. Don't get me wrong - I'm really impressed by the stuff Perl hackers can achieve with some lines of code - but the ambiguity and sometime cryptic syntax, implicit variables and stuff it provides stop me from learning it since ages. The more I get into Ruby, the more I fear Ruby will become the - fully object oriented - Perl of the next decade. Nothing to win here... In case you are tempted to tell me "this is just a single example" - yeah, right, what about:

File.open(path) do |file|
while line = file.gets
p line
end
end


Two things here:
  • What does the |file| syntax tell me as a human reader, exactly? (I searched, but never found a decent description of this
  • Why do I need two blocks for one parsing action?
I use this syntax myself to parse a file, but the more I look at it, the less natural it looks to me.


In Python, the same looks like this:
f = open(path)
for line in f:
print line


This is:
  • Two lines less code
  • only one loop block
  • no special chars that are never really well explained (assume the : be a part of normal written human language)

back alive... new plans

Finally, we have finished our Xen Book, and finally, I have a bit recovered from the stress it defintely imposed to me - working full time a Java devloper, and being Beta-Tester for the most hyped(and not always most promise-keeping and working-as-expected) virtualization software on the planet at the same time is quite some thing to do.

The Xen developers give us a great software for free, but they intentionally let the distribution vendors do the job to build and package ist nicely and make their users the well working features available - as Simon Cosby put it in some private mail - "We're providing the engine, not the car."
They build their own car on top of it, as XenEnterprise.

Still, it was a great experience, and the next book is in the plannings - watch out for announcements about this.

For now, I want to get deeper and back to FAI development. Most important things I have in mind:
  • Create a GUI to administer FAI
  • Introduce a better hierarchy of the configspace
  • Get more clean samples and docs of multi-distribution installs (e.g. Skolelinux, Windows, Fedora as the main candidates)
  • Make fai-cd work with non-debian distributions
I won't get bored, I guess...