Why Ruby?

[Ary Borenszweig]

Well, about a year ago I started programming in dynamic languages like python and
Ruby. I did very little of python and a lot in Ruby. At first I thought "Hm, it
must be really hard to program without autocompletion, static type verification,
etc.". Soon I found out I was wrong.

First, in Ruby it's very easy to test the code. And you can do crazy things like
what I mention in here (
http://weblogs.manas.com.ar/ary/2010/04/15/quick-way-to-test-many-values-in-ruby/ )

[[1, 1], [4, 2], [9, 3]].each do |input, output|
  test "sqrt #{input}"
    assert_equal output, sqrt(input)
  end
end

and the good thing is that if it fails for a specific input/output pair it is
treated as a different test, so you can clearly see which input/output pair
failed. I can see you can do the same in D with string mixins, probably putting
all the code between do/end in a string... :-(

Second, I found out I have to type a lot less. And names are very consistent and
intuitive in Ruby and specially in Ruby on Rails, so I don't need that
autocompletion anymore, I can just type what my mind think is correct and it
works. And I do use some autocompletion, I switched to use gedit first, then vim,
and it seems to be enough to autocomplete things based on the words on the open
documents.

And autocompletion might show you the list of methods of a class, but that's not
useful if you don't know how to use those methods in combination. For that, you
need to read the class' documentation about it's usage. And that, you can find it
*a lot* in Ruby libraries. After all, what's important is how to use a class for
what you want to do, not what methods it provides. This concept is so strong in
Ruby that sometimes you just see things documented like "To use this, do
'basic_auth :user => x, :pass => b' without even caring about the signature of the
method".

Third, go to declaration, I can do that in vim with ctrl+], using ctags.

Fourth, rename refactoring. That is the thing that is likely less to happen in a
project. The most common refactoring are logical, not just names. And after
refactoring by hand I just run the tests and fix whatever is there to fix. It
completely changed my mind about how to develop software (previously I also did
tests, but in Ruby I can test more things and much more easily... for instance, I
can mock a static method or even a top level function, which I cannot do in D or
Java... so in those languages I have to do dependency injection and change a lot
the way I should be programming... making my code harder to understand and to
follow. In Ruby I can program directly what I want and still test it, always).

What do you mean by "compiler checked documentation"?

And Ruby might be slow(er than X), but when you program a website or something
where the database time or http request time is orders of magnitude higher, you
don't care the language to be a little slower. In the end you can never blame the
language for your app being slow, you might to do load balancing, optimize your
queries, etc.

BUT. D is a systems programming language, so the above paragraph doesn't apply.
But I still think some things in D could be improved.