5 ms·
This is an annoying document. He goes into long, wrong explanations of different concepts, and then provides very minimal examples of how Ruby doesn't work like
by mattmcknight 9y ago
This is an annoying document. He goes into long, wrong explanations of different concepts, and then provides very minimal examples of how Ruby doesn'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.
Documentation: One criticism is that the documentation is somehow incomplete. I think https://www.ruby-lang.org/en/documentation/ https://www.ruby-lang.org/en/documentation/ and http://ruby-doc.org/ http://ruby-doc.org/ 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.
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.
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'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't he do it? But he can do it; he just doesn't like how it is done?
Multiplication of like things:
This is basically a weak criticism of TMTOWTDI, but using "orthogonal" 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.
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't like that there are two ways to include modules in Ruby, something is bad? No case made at all.
Tooling and reasoning:
This is just a disgusting set of lies. I think he's never heard of JRuby which has been an active project for 16 years. Try RubyMine if you want a smart IDE for Ruby.
"The criticisms above are not matters of taste. They are errors in language design."
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't easily be done by a single line of Ruby code, it hardly stands up as evidence of any error in language design.
Frankly, I find the preferences expressed here bizarre. The attempt to tie them to language design errors just seems stupid.
- hluska 9y agoI learned significantly more reading this comment than I did the article. It's concise, informative and well written. Wonderful work and thank you for sharing your perspective.
- philwelch 9y ago> Documentation: One criticism is that the documentation is somehow incomplete. I think https://www.ruby-lang.org/en/documentation/ https://www.ruby-lang.org/en/documentation/ and http://ruby-doc.org/ http://ruby-doc.org/ neatly dissolve that. The language itself is finally documented, but libraries are extremely hit-and-miss and the lack of features to support extracting documentation from code is a huge reason for this. Having used both Ruby and Python extensively (and Ruby for many more years), the difference is pretty staggering. > 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. But we do consult the source code of every library and framework we use. As for the advantages of having a well-defined grammar or the ability to inspect the AST, those are things I don't think you appreciate the value of until you have the opportunity to use them. Linting and optional static typing are two things I've come to appreciate. To name another example: I once worked on a Python project where we had to swap out database drivers across every Python codebase in the entire organization, and, as you point out, different libraries do things differently so we had to change the code around all our DB calls. One of our senior devs used astor--a Python library that supports loading Python code and transforming it at the AST level--to write a script to perform this transformation programmatically on our code repos. There was still lots of testing and review of the generated code changes, but it was a lot nicer than having to do it all by hand. > 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't work that way. Multiple files can contribute to a Module or a Class. I think you might have misunderstood the author here, because files are indeed "compilation units" in Ruby. If I have a running irb session where I've imported code from 20 different Ruby files, and I change the code in one of those files, I can just call load on that file again and it should fix anything up, even if that file is monkeypatching a class that's also defined in seven other files.