Why Ruby?

[Don]

Andrei Alexandrescu wrote:
> On 12/10/10 10:16 PM, Christopher Nicholson-Sauls wrote:
>> On 12/10/10 19:26, Ary Borenszweig wrote:
>>> http://vimeo.com/17420638
>>>
>>> A very interesting talk.
>>>
>>> I used to like D. To write code in a high level while at the same
>>> time being very close to the machine, with class invariants, unit
>>> tests and many other features seemed very appealing. But I always
>>> felt there was something wrong.
>>>
>>> About a year ago I met Ruby. Now I find languages like Java, C#,
>>> Python and D kind of ugly and uncomfortable. Why? Exactly because of
>>> what it is said in that video.
>>>
>>> This is not to start a flame war or trolling, it's just to show you
>>> why I changed my mind so much about D, and why I think (IMHO) you
>>> should care about naming conventions (like bearophile says), more
>>> powerful unittests (and not having unittests integrated into the
>>> language but rather being able to build your own test frameworks
>>> with ease) and stop caring about being C-syntax friendly. The world
>>> doesn't need that many semicolons and parenthesis. :-)
>>
>> I'm a strange one.  I use Ruby, and D.  (And a couple of others...)  I
>> use the tool that feels best for the job, whatever that may be at a
>> given time.  Sitting on a disc somewhere are some personal tools I used
>> to use when working with D... which are themselves written in Ruby (and
>> bash script, but hey).
>>
>> Then again, I'm the same one who really really likes Ruby on Rails...
>> and yet still does most things with PHP.  Why?  Well for one, because
>> for plenty of projects, Rails is less an aid and more a hindrance.  (And
>> yes, before someone brings it up, I'm well aware of CakePHP... and don't
>> care for it much.)
>>
>> There are times in D when I find myself wishing, momentarily, for the
>> loose typing of Ruby... but then there are times in Ruby when I find
>> myself wishing for stricter typing.
>>
>> There are times when I wish D had open classes... but then there are
>> times when Ruby's open classes give me headaches.
>>
>> I could go on like this... but the point was really just: use the right
>> tool for the job.  Keep several tools in your toolbox.  There is no "THE
>> BEST LANGUAGE OMG!!!"  There is just the best one for a given programmer
>> in a given scenario.  Some of the things I've done could probably have
>> been better written in, say, Pike!  But I don't really know Pike (very
>> well), and don't feel the need to learn it just for those few things
>> that might have benefited.
>>
>> -- Chris N-S
> 
> Agreed. One issue with the talk is non-acceptance of "the right tool for 
> the job" (the speaker literally says he's tired of that phrase). There 
> is one best tool - and that's Ruby. Ahem.
> 
> Andrei

I find this issue interesting. I think the "the right tool for the job"
is justification for the existence of multiple languages, but on the 
other hand, I'd agree with him that it's overused.

If you consider all problem domains, and then ask: what is the minimum 
number of languages required to be "the best tool" or "close enough to 
the best tool" for all those jobs? For sure the minimum number is > 1.
But I suspect the minimum isn't very high, essentially because most real 
world tasks involve a combination of several problem domains.
I think the minimum might be as small as five, and I seriously doubt 
it's more than a dozen.