4 ms·

For me as a ruby user, the things that I can agree with (and maybe build upon) as criticisms here are: - Ruby's origin as a single implementation has led to a

For me as a ruby user, the things that I can agree with (and maybe build upon) as criticisms here are: - Ruby's origin as a single implementation has led to a few ongoing issues in documentation. This has been generally fixed considerably over time. Its lack of a '100%' AST still bugs me a little (ruby2ruby and ruby_parser only get you so far). As noted also, its not really built for some tasks like moving a method from one module to another. These are all really quite a niche issues however which wont affect 99.999% of programming. - There's a few 'gotchas' in learning Ruby's module, namespace, etc. systems (include/extend, raise-rescue/throw-catch, return from a block). However, most programmers learn these reasonably quickly and as a language Ruby is probably simpler in terms of these issues than others. - Ruby's TIMTWODI approach has caused a few areas where there are different libraries doing the same things in different ways (e.g. as noted unit testing - though RSpec is great) - a more mature language may just 'pick a winner'. TIMTWODI's got its advantages though. However, the author also mixes the above with some very oblique views on language design. Particularly where it goes down to paragraphs like 'Multiplication of like things', 'M+N' and 'Compilation units' etc. - there's not much discussion on ruby at all other than rather weak criticisms of ruby's module/namespace systems at the end, as they dont meet the writers preconceived ideas of how these should work. The final assertation that these 'errors in language design' mean you shouldn't use ruby because 'it is not the only language in its niche' is really ridiculous however. The author doesn't state what the better alternative is (or even define what ruby's niche is), and I'm sure any one which is picked would have its own issues - and these would have at the very least a different set of tradeoffs than those in ruby.

philwelch 9y ago
The obvious niche for Ruby is the niche shared by Perl and Python. Having used Ruby full-time for 4-5 years and Python full-time for the past year, I think Python is strictly better than Ruby in the particular areas mentioned by the author. I can think of a couple major reasons one would prefer Ruby to Python, but only a couple: * Ruby has a more flexible syntax, which means you can write "DSL's" in Ruby. Rake and RSpec are generally given as examples. Unlike actual DSL's, though, Ruby just lets you leave out parentheses so you can pretend that the handful of functions you just call a lot in a Rakefile or an RSpec test are keywords. I'm not sold, but some people may prefer this aesthetically, and there's really no way to argue against that. * Ruby is all-in on object orientation, in a "poor man's Smalltalk" kind of way. There are advantages to this, since you can just.call.methods.on.everything(like: this) or iterate by calling .each, which is simpler than Python's double-underscore protocols. There are surprisingly few disadvantages, because you don't have to actually write in an object-oriented style in Ruby. I personally don't find these arguments convincing.

philwelch 9y ago

The obvious niche for Ruby is the niche shared by Perl and Python. Having used Ruby full-time for 4-5 years and Python full-time for the past year, I think Python is strictly better than Ruby in the particular areas mentioned by the author. I can think of a couple major reasons one would prefer Ruby to Python, but only a couple: * Ruby has a more flexible syntax, which means you can write "DSL's" in Ruby. Rake and RSpec are generally given as examples. Unlike actual DSL's, though, Ruby just lets you leave out parentheses so you can pretend that the handful of functions you just call a lot in a Rakefile or an RSpec test are keywords. I'm not sold, but some people may prefer this aesthetically, and there's really no way to argue against that. * Ruby is all-in on object orientation, in a "poor man's Smalltalk" kind of way. There are advantages to this, since you can just.call.methods.on.everything(like: this) or iterate by calling .each, which is simpler than Python's double-underscore protocols. There are surprisingly few disadvantages, because you don't have to actually write in an object-oriented style in Ruby. I personally don't find these arguments convincing.