A criticism of Ruby (2013)
This is an annoying document. He goes into long, wrong explanations of different concepts, and then provides very minimal examples of how Ruby doesn&#x27;t work like Java or some other imagined ideal language does in his conception of the world. A person that has a particular way of programming often will struggle trying to impose that way on another language.<p>Documentation: One criticism is that the documentation is somehow incomplete. I think <a href="https:&#x2F;&#x2F;www.ruby-lang.org&#x2F;en&#x2F;documentation&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.ruby-lang.org&#x2F;en&#x2F;documentation&#x2F;</a> and <a href="http:&#x2F;&#x2F;ruby-doc.org&#x2F;" rel="nofollow">http:&#x2F;&#x2F;ruby-doc.org&#x2F;</a> neatly dissolve that. The other criticisms appear to be things that would largely apply if one were trying to implement a Ruby interpreter, which is not the normal task of a Ruby programmer and are irrelevant, but also largely wrong. Most Ruby developers are not consulting the source code of the interpreter to determine what functions do on a regular basis.<p>Interfaces: This is largely a meaningless complaint about the lack of specific thing called an interface in Ruby, when it is largely not needed as they are a mechanism to work around strict typing. The long example of streams is something that is easy to do in Ruby. The examples are then one case where the OpenSSL library has a different name for a method than the standard library for sockets, that the rexml SAX2 parser and Nokogiri are slightly different, and then some odd complaint about streams again. This is a ridiculous complaint about different libraries doing things differently, not related to interfaces at all, and Ruby would let you easily work around this situation if you ever needed to.<p>Namespaces, compilation units, and modules:
The explanation for this is tortured and simplistic. You can see confusion shining through when he calls a Ruby file a compilation unit. It just doesn&#x27;t work that way. Multiple files can contribute to a Module or a Class. The supposed criticism here is incoherent and seems to be incomplete. What is he trying to do? Why can&#x27;t he do it? But he can do it; he just doesn&#x27;t like how it is done?<p>Multiplication of like things:
This is basically a weak criticism of TMTOWTDI, but using &quot;orthogonal&quot; in an incorrect way that makes the whole thing nonsensical.  It complains that Ruby has too many functional constructs, which is not the typical complaint one sees.<p>MN vs. M+N and what it did to the language:
Nonsense again, suggesting that one must use multiple inheritance to write a polymorphic max(a,b) function, and since he doesn&#x27;t like that there are two ways to include modules in Ruby, something is bad? No case made at all.<p>Tooling and reasoning:
This is just a disgusting set of lies. I think he&#x27;s never heard of JRuby which has been an active project for 16 years. Try RubyMine if you want a smart IDE for Ruby.<p>&quot;The criticisms above are not matters of taste. They are errors in language design.&quot;
Absolutely incorrect on two counts, they are almost all taste, and many of them have zero to do with language design. How about this- if they were errors, that would suggest that there is a right way to X, Y, and Z.  Instead, we are given examples of how language A does something, and a statement that Ruby does it differently.  Given that we are dealing with humans here, there are clearly large numbers of humans that prefer the Ruby way. Given that there is nothing listed here that can&#x27;t easily be done by a single line of Ruby code, it hardly stands up as evidence of any error in language design.<p>Frankly, I find the preferences expressed here bizarre. The attempt to tie them to language design errors just seems stupid.