10 Things I Hate About Ruby

1. initialize

To create a new object in Ruby you invoke the new class method like so:

c = Car.new("Toyota")

Naturally you think the constructor would be defined in a method called new, right? Or just maybe a method called Car like in Java? But no, instead it has to be called initialize like this:

class Car
  def initialize(make)
    @make = make
  end
end

Would this have been so hard?

class Car
  def new(make)
    @make = make
  end
end

2. Weak typing

As a library vendor, it scares the bejeezus out of me that anyone can pass anything to my methods and I’m expected to handle it. It’s like walking into McDonalds and ordering a Big Mac, and instead getting a Tofu burger; not very appetizing. Ruby’s thrown out the one piece of precondition checking most languages give you for free.

3. Automatic returns

Didn’t C teach us that unexpected results were confusing? This is Ruby’s equivalent of C’s a = b + a = c;. Returns should be explicit. An explicit return is not hard to write, and it’s a lot easier to read and understand. Reducing finger typing and at the expense of increasing brain confusion is not a wise tradeoff. Languages should be concise only in so far as that improves clarity. When compactness comes at the expense of clarity, it’s a bad thing.

4. Global variables

Didn’t somebody tell me Ruby was an object-oriented language?

5. puts

Do we have to copy C’s most ungrammatical, pointless method names?

6. Zero-based arrays

C arrays began at zero to match memory addressing. In a weakly typed scripting language, there’s exactly no reason to do this. There hasn’t been for decades. Can’t we please start the arrays at 1 where God intended? Hasn’t anyone read Numerical Recipes? Aren’t we tired of fencepost errors yet?

7. elsif

Sorry. “elsif” is not a word in the English language, and it shouldn’t have been one in Ruby. Would typing one extra letter have been so onerous?

8. $_

Global variables suck. Did I say that already? Global variables you didn’t actually create and that pop up out of nowhere suck even worse. And global variables whose names are indistinguishable from line noise suck still more. Java’s verbose, but that verbosity is in the service of legibility. Ruby’s compactness all too often serves only to obfuscate.

9. Methods are public by default

Minimal interfaces to classes are important. The less a class promises, the easier it is to change, optimize, fix, and otherwise improve. Furthermore, the easier it is to learn and understand. Everything that can be private should be private.

Now of course you do need public methods. Not everything can be private. However this shouldn’t be the default. Marking a method public decreases the flexibility and increases the learning curve of the class. It should require an explicit decision from the programmer to do this. Ruby gets this exactly backwards. A programmer just banging out Ruby code is likely to create a class with nothing-but-public-members, without even thinking about it. That’s a bad thing.

10. No package access or friend functions.

There’s no access in-between public and private. All too often different classes in the same library/application/codebase need more detailed access to their other parts than the general public should have. Ruby provides no way to manage this.

In conclusion

I could go on (and I probably will) but that’s a nice round number of hates for now. I’m also keeping a list of things I love about Ruby as I learn the language. However, the things I hate hit 10 before the things I love. That’s not a good sign.

95 Responses to “10 Things I Hate About Ruby”

  1. John Cowan Says:

    A partial rebuttal:

    #1: No, it wouldn’t be hard…. but it would be wrong. new is a class method in Ruby, and you’re invoking it from one of Car’s superclasses. new creates the new instance and then invokes the instance method initialize.

    #2: If you want Java, you know where to find it.

    #4: Java public static variables are just global variables under another name. Anyhow, class names in Java behave like final global variables holding the class object — for some purposes. For other purposes, you have to say Foo.class. What makes that a good idea?

    #6: Zero-based arrays are IMHO a good idea in any language, precisely because they avoid certain kinds of fencepost errors. Java has them, and it’s not to match memory layout; ditto Perl; ditto Scheme, which is a very high-level language. Classic Basics had it both ways: DIM A(10) actually allocated 11 elements; you could ignore the 0th or 10th element if you wanted.

    #7: A matter of taste. Me, I like elif.

  2. Trent Steele Says:

    1. Agree. It’s spelt initialise.
    2. Chill. Don’t worry so much.
    3. The implicit returns are a part of “everything is an expression” in Ruby.
    4. Sometimes you do need them. Really.
    5. I’ll puts you, you little..!!!
    6. Everyone’s used to it. Everyone expects it. It’s POLS.
    7. Yeah, that is kind of stupid :P It’s like when PHP h4x0rz use hard to read names to feel like they really know what they’re doing, when they really don’t. But that’s the way, ahah ahah, I like it.
    8. Do you actually use those? Me neither.
    9. Encapsulation is so overrated. You know that. It’s like those stupid laws that are meant to protect us from our own stupidity.
    10. 9.clone

    A grain of salt? How much is that in grams?

  3. mike Says:

    2. John Cowan is right.

    5. POLS.

    Here, I have a fix for you:

    def system_out_println(*s)
    puts *s
    end

    6. POLS again. Also, you can get rid of fence-post errors (usually) by using methods from the Enumerable module.

    Depending on what you’re doing , Java might be better. Also, Ruby kills at lots of other stuff. You gotta use the tools best suited to solve the problem.

  4. henning Says:

    What does POLS mean? (maybe my english is just too bad, but I never heard that, and have no idea where to look it up)

    BTW: abbreviations suck… (like one letter variable names in programming)

  5. Wouter Says:

    POLS is an abbreviation for “Principle of Least Surprise”. It seems to be used in the Ruby community a lot.

  6. Michael Daines Says:

    #10: What about “protected”?

  7. Masklinn Says:

    1. Wrong, the constructor is called new, it’s a classmethod, and it exists in every Ruby object. Initialize is an initializer, not a constructor, by the time initialize is reached the class instance has already been built. Python works the same way BTW, __new__ is the constructor and a classmethod and __init__ is the initializer and an instance method.

    Oh, and you can override ::new btw.

    2. It’s dynamic typing, not weak typing, and if by “most languages” you mean “algol derivatives and a few others” you’re right, otherwise you’re completely wrong, most languages actually use either strong dynamic or weak (be it static or dynamic) typing: Lisps (especially Common Lisp), Python, Smalltalk are exemples of the first, assemblys, Fortran, or C of the second, Perl, ECMAScript, or PHP of the third.

    Now if you really want static typing you don’t even want Java (as Java’s type system is an unsafe and incomplete piece of crap) you want MLs or Haskell. And if you want static explicit typing then you want Ada. As in Ada87 by the way, not those fancy Ada95 or Ada2005.

    3. There is no unexpected return in Ruby, everything returns a value period, this makes for much simpler expressions. “Strangely enough” (from your point of view I guess), i’m pretty sure that every single modern functional language (which does include Lisp) behaves this way.

    4. Java allows the creation of singletons, singletons are usually stupidified constants ergo Java isn’t an object oriented language.

    Stupid? yeah, pot, meet the kettle

    5. Yeah, because System.out.println is so much better.

    6. Use Fortran, it has 1-indexed arrays.

    Ruby is not Java or C, it has built-in iterators for every native type and then some, use them.

    7. Who gives a fuck?

    8. Ruby’s $ constants come from it’s Perl heritage, and every single one of them has a plain english equivalent ergo you don’t have to use them, and you don’t even have to know they exist.

    You don’t like the fact that Ruby is the love child of Perl and Smalltalk? Don’t use ruby.

    9. Stop “banging out ruby code”, problem solved.

    10. Yep, there is no “protected” access modified in Ruby… oh wait, there is…

  8. Paul Clapham Says:

    There’s an attitude in some of those responses that I don’t care for. It looks like this…

    Me: The right windshield-wiper on my car makes streaks on the window instead of cleaning it properly.

    Mechanic: Don’t like Volvos? Then take the bus.

    Seriously, if you don’t have a valid response to a criticism then don’t get all defensive.

  9. Masklinn Says:

    Except in this case your problem is that your right windshield wiper doesn’t wipe the window the way you’d want it to be wiped (oscillates from left to right when you’d want it to oscillate from right to left).

    No one argues with the fact that Ruby isn’t perfect (hell, Matz even compiled a list of Ruby’s shortcomings in his own eyes), but your “10 things i hate about ruby” range from “I don’t know Ruby but that doesn’t stop me from talking about things I don’t know” to “I wish Ruby was really Java”

  10. Elliotte Rusty Harold Says:

    A couple of generic responses:

    1. Just because Java has problems too does not let Ruby off the hook. This is a list of flaws in Ruby, not things that are great about Java. (I don’t think I even mentioned Java in the original article, and FWIW I’ve also written a similar article about Java.) There are more than two choices of programming language. Nor do we have to settle for the best current existing language. We can improve the state of the art in the next language by learning from the mistakes of today’s languages.

    2. “If you don’t like feature X, you can ignore feature X” is false. Once the feature is in the language other people will use it, and thus I have to recognize it, understand it, and be able to work with it in their code, even if I don’t use it in my own. I found these problems precisely because In was dealing with other people’s code and they used all of these things. I can’t just ignore them.

    P.S. protected != package access or friend function.

  11. Joshua Volz Says:

    I would have said weak typing (#2) and automatic returns (#3) were some of the features I liked in Ruby. It’s not really weakly typed, it is actually “duck” typed. It’s just that you aren’t required to explicity state the type. That saves time, both in original construction, and later if the type of something has to be changed (in refactoring). Automatic returns are part of the removal of method level keywords (public, private, static, return, virtual, override, etc.). They make programs easier and faster to write. Coming from C#, Ruby is a refreshing look at how easy things can be, and how quickly you can mock something together.

  12. Dave Says:

    Having global variables has nothing to do with a language being object-oriented or not. Feel free to not use them; nobody says you have to. You lost me on this one.

  13. Christopher Says:

    I have to agree with some of the comments I have seen in the list. It seems to me that the person who posted this blog has very little experience with anything outside of the most common programming languages. And in addition, probably has no experience with the art and science of compiler design, since a lack of understanding of what’s going on under the hood seems to be absent in this list as well. Many of the so called problems of the language are not really problems at all if you really understand how the language works. As was pointed out earlier, methods such as initialize, do resemble exactly what is happening “under the hood”. Since Ruby is totally OO, even classes are considered objects and thus inherit methods from their parents as well, as is the case with the new method that invokes the initialize method on the newly created instance. Also, the fact that Ruby automatically returns a value is not a problem for anyone used to the functional programming paradigm. It merely shows Ruby’s lisp heritage. The author of this blog probably doesn’t even realize that the beauty behind Ruby’s closures–oops, sorry I should probably use the word blocks here, since closures is more of a CS term–is that they allow the programmer to follow a functional programming regimen, cutting down on the number of side effects and thus the number of logic errors in the program. Bottom line, it’s not that I don’t think that Ruby has problems (in fact, my pet peave is that “foo”[0] returns an int rather than a character, how’s that for POLS–and yes, I understand the reasoning behind it, in Ruby strings aren’t character arrays, but it still bugs me), I do, but the list here shows a lack of knowledge, and not a useful criticism of what needs to be changed to make the language better.

  14. efr. Luk Says:

    Just one quote: “Can’t we please start the arrays at 1 where God intended? ”

    God intended to have 1 based arrays? Did you red this in the bible?

    Are you an idiot?

  15. Mark Says:

    Genesis 1:5 And God called the light Day, and the darkness he called Night. And the evening and the morning were the first day.

    Had God used 0-based arrays, it would have been the 0th day.

  16. Ed Says:

    Just one quote:

    “God intended to have 1 based arrays? Did you red this in the bible?
    Are you an idiot?”

    Ever heard of this concept called “humor”?

  17. Slava Pestov Says:

    While global variables and dynamic typing are simply a matter of taste, I think Ruby has some more serious _implementation_ issues:

    - no Unicode support
    - very slow interpreter, no native compiler
    - the garbage collector always scans the entire heap at once, and so interactive programs can be prone to pauses
    - the AST is not as straightforward as Smalltalk or Lisp without offering any added expressiveness, thus making meta-programming more difficult
    - Ruby seems to miss the most important advantage of dynamic typing, and that is having an interactive development environment where anything can be inspected and changed running in the same image as your application. ‘irb’ is not enough.

  18. Daniel Says:

    1: Personally the only thing I don’t like about initialize is that it’s hard to type. I would have used init.

    2: Ruby doesn’t have weak typing. It it a strongly, dynamically typed language. Weak typing is where you can coerce any object to another type.

    3: Tard. In Ruby everything is an expression; there are no statements. Therefore there is no need for a return statement. The “everything is an expression” paradigm actually gives a whole lot of power to a language, but if you can only think in terms of long thin columns of statements then hey.

    4: Object orientation and global variables are orthogonal concepts.

    5: Who cares.

    6: Go back to Pascal.

    7: I have to agree here. Given the amount of influence Smalltalk has had on Ruby I’m surprised Ruby doesn’t use ifTrue and ifFalse methods of TrueClass and FalseClass to implement the if/else construct. Maybe Matz thought that would make it too scary.

    8: I guess that’s just Perl-related insanity. I’d have to say that if I were making a list of things I hate about Ruby it would consist of one item: Perl.

    9: Wrong.

    10: Not even wrong. Friend/protected/whatever is a crutch for both the programmer who is a shitty architect and a language that doesn’t offer truly powerful features. It’s also confusing and prone to misuse.

  19. Matt Says:

    99.9% of the people on Earth start counting from 1, not 0. How is that not least surprise? Or does Ruby only belong to the insider club with the right technical background?

  20. don Says:

    1. initialize

    new is a class method, initialize is an instance method. Not sure this is worth getting worked up about. Yes, its less than obvious, but not confusing or hard to remember. I guess there is no reason that both couldn’t be called new, but that is potentialy more confusing.

    2. Weak typing

    Nothing is forcing you to use week typing in your library. Just check the parameters with ‘class’ or ‘kind_of’ instead of ‘responds_to?’.

    When strict type checking isn’t required, duck typing is handy. For instance, strings, file handles, and arrays all have an ‘each’ method. If you are writing a parser and use ‘each’ then it is much more flexible.

    3. Automatic returns

    I agree, and in fact I always explicitly declare my returns.

    4. Global variables

    Global variables sometimes have their place, but I agree such instances are rare. The good news is that support for global variables is only bad if people actually use them, and I think the ruby community effectively discourages it.

    5. puts

    Not sure whats wrong with puts, but ok.

    6. Zero-based arrays

    I actually prefer zero based arrays for a number of reasons, but the use of code blocks and itterators in Ruby eliminates all but the most obscure fencepost errors.

    7. elsif

    Agreed, but so what?

    8. $_

    The use of $_ is depreciated, and I don’t think I have ever actually seen someone use it. It’s an unfortunate nod to perl, but if its never used whats the problem?

    9. Methods are public by default

    Agreed

    10. No package access or friend functions.

    protected methods are accessible from within the same class or subclasses. Any other access to the internals of a class breaks the whole point of encapsulation.

  21. We Are Here And It Is Now » Blog Archive » Ruby Imperfections Says:

    [...] Elliotte Harold raises some good points about some of Ruby standards. You can read his list of 10 things he hates about ruby here . [...]

  22. Eric the .5b Says:

    “99.9% of the people on Earth start counting from 1, not 0. How is that not least surprise? Or does Ruby only belong to the insider club with the right technical background?”

    Would that be the club of “computer programmers”? Vanishingly few languages use 1 as the first offset. If Ruby did, far more people would complain about that weirdness.

  23. Masklinn Says:

    > 99.9% of the people on Earth start counting from 1, not 0.
    > How is that not least surprise? Or does Ruby only belong to the insider club
    > with the right technical background?

    The vast majority of computing languages use 0-indexed arrays (and the ones that don’t usually suck, see Fortran). Plus as it’s already been said many times, Ruby’s emphasis on iterators makes this point a non-issue in the first place.

  24. Masklinn Says:

    > new is a class method, initialize is an instance method.
    > Not sure this is worth getting worked up about.
    > Yes, its less than obvious, but not confusing or hard to remember.
    > I guess there is no reason that both couldn’t be called new, but that is potentialy more confusing.

    Initialize is not a constructor, it’s an instance initializer, the constructor is the class method `new` (which you can overload if you with to and have a deep love for pain and suffering).

    Initialize is called in the phase that follows constructing to actually… well… initialize the base state of your instance.

    If anything’s confusing here, it’s Java’s and C++’ behaviour of mixing the creation and initialization in a way that makes some people unable to realize that they’re fully separate.

  25. Paulo Silveira Says:

    he does not know the difference between dynamic and weak typing!

  26. John Cowan Says:

    Dijkstra on why numbering should start from zero.

  27. Tomasz Wegrzanowski Says:

    Ruby is not Java. It also uses good ideas from Smalltalk, Lisp, Perl and other languages. In detail …

    1. Decoupling object creation and object initialization is useful sometimes. Here’s one nice trick: http://t-a-w.blogspot.com/2006/07/new-kind-of-hacking.html Basically if you have magical constructors like in Java, new simply has to create new object, with decoupled construction and initialization you can reuse objects and do other nice stuff.

    3. Everything is an expression rule (aka “implicit returns”) is standard of functional programming. lst.map{|x| x.to_s}.join(“, “) is great, on the other hand lst.map{|x| return x.to_s}.join(“, “) is absolutely awful. If you come from Java you may not see that, but it’s really useful.

    8. Magical variables are used mostly for regular expressions, and they were copied directly from Perl. Now they may not be cute, but they make something very common (string parsing) a lot more concise and less error-prone. The only idiom in which they’re commonly used is:
    foo =~ /expression/
    a,b,c = $1.to_i, $2, $3.to_f
    and as there are no obvious ways of making it more expressive, the Perl method stays.

  28. Ian Scott Says:

    That Numerical Recipes has 1-indexed arrays is simply because the first edition was Numerical Recpes in Fortran, which, as stated above, has 1-indexed arrays.

  29. Avdi Says:

    Generally I don’t agree with “if you don’t like it, then go away” comments; but there’s a case where I think they are called for, and that’s when someone complains to the effect of “this bulldozer is not nearly as fast as my Ferrari”. The relative advantages of dynamic vs. static typing (as others have noted, it is not “weakly” typed) have been debated to death in the literature and on WikiWiki and LambdaTheUltimate for years. if you really are someone who, in the final analysis, prefers one over the other, it seems a bit pointless to learn a language like Ruby which, like SmallTalk, bases much of it’s philosophy, identity, and power on dynamic typing. Personally, I’m as at home with either. I write C++ code for aerospace projects for a living, the classic case for strong, static typing; but in my experience dynamic languages are no more defect-prone provided you work WITH THE GRAIN of the language, and not against it.

    On the subject of Perlisms like “$_”: with very few exceptions, almost no one uses them in production code. Just because they are there doesn’t mean they are habitually abused. On the other hand, I’d be sad to see them go, because they give Ruby a unique strength: I can whip up a quick three-line Perl-style script to get something done, without it being ANY longer than the equivalent Perl script – and then, when I decide I need something better, I can incrementally refine it IN THE SAME LANGUAGE until it is an elegant, well-factored, object-oriented, unit-tested program. No other language so adoitly spans the whole gap between hackish expressiveness and robust structure.

  30. Dale Says:
  31. ian Says:

    I think you’re all missing the point. All the problems outlined stem from the oop pardigm, in whatever language. The whole software design, encapsulation, private, public protected, polymorphism debate is entirely caused by the oop paradigm. It’s basically a software mirror of that favourite of snake oil salemen the world over, the holistic approach. While all human progress has been attained up to now by breaking problems down into their smallest possible units (functions) and then solving those problems one by one, oop programming is like trying to predict the weather by looking at the whole world’s weather systems, or a genetic disease by looking at the symptoms rather than the dna.
    The claims, the reuse, the dodgy examples, it’s a crock. Have software disasters stopped happening despite all those supposed benefits? Why do books on oop never say, this example is completely irrelevant to the Object approach(as are most real world problems), but imagine you’ve got a shape, bike, employee hierarchy etc.
    It’s not that its not useful for a very small set of problem domains, it is, but why have a whole software methodology devoted to a problem almost no-one will come across. If that’s not true, why do all the tutorials and books use these “real world” examples.
    So, it’s not ruby, python, java, etc etc, it’s the paradigm that’s the problem, the reason these wars exist is because the advocates miss the point, the house is built on sand, and shifting sand at that.

  32. Jim Says:

    I don’t particularly agree with the list, but Paul has it spot on. A lot of these responses are immature and give an extremely poor impression of the Ruby community. Until now, I thought Ruby was used by people at the forefront of the industry, not a bunch of children who call people names when somebody doesn’t like their pet language. Grow up.

  33. Paul Downey Says:

    Great post, even though I mostly disagree! I love weak typing, ’0′ arrays are cool, the Perlisms are mostly ignored and you missed my pet peeve – the “end” keyword, {}, punctuation or indentation to mark a block is clearer and easier to manage in an editor. Looking forward to the follow-up!

  34. thoran Says:

    I think the churlish (but funny) reactions are an expression of the astonishment at the presumptuousness to comment so quickly on a language with which one is patently so unfamiliar, and is directed particularly at the lack of understanding of some basic principles, which are coming from someone who presumably considers himself knowledgeable enough about our craft to author a book anywhere near the subject. I myself am safe from such accusation as I presume to be capable of nothing, or nothing but wild unsubstantiated assertions. Take your pick. Nevertheless, my take on Ruby is that Matz agrees with me just about everything so far! Everything I’ve ever thought might be a misfeature, an annoyance, or could be improved has ultimately and in time been proven false. Either that or I just dived in and didn’t judge it too much—at first.

  35. Karel Vlcek Says:

    #6: I also think, that zero based arrays are good idea. Definitely better than starting them by 1. I think, that God intended arrays to start with 0 ;-)

  36. PaulE Says:

    No silver bullet.
    Lets face it, different languages for different problems.
    Trying to make Ruby more like Java is pointless. Just use Java. Making Java like Ruby is equally flawed.
    Personally, I tend to like strongly typed languages because the compiler becomes a tool to help prevent bugs. Then again, I tend to work on extremely large projects where this can help in innuerable ways.
    An argument for dynamically typed languages tends toward faster development. They are right.
    Arguing about which language is best doesn’t make sense. Its always going to be apples and oranges. Lets understand that each has a strength in certain domains. Lets use the best for each domain. Besides *real* programmers should know at least half a dozen languages well, and be familiar with at least a dozen.
    For example, a J2EE developer should know Java, SQL, ECMAscript, XML, XSL, HTML, (Perl, Ruby, or Python), and ANT at a minimum, plus a whole bunch of API’s and frameworks.
    Learning new programming languages gives new ways of approaching problems and makes for a more well rounded developer. So, lets stop fighting and see what we can learn from each other.

  37. PaulE Says:

    Slava Pestov
    “very slow interpreter, no native compiler”
    Just use JRuby, to compile your Ruby to Java byte code, and the GCJ to compile that to native.
    ;-)

  38. Dave C. Says:

    Zero-based arrays:
    I think the idea that counting starts at one is cultural, not natural. As a child, I had a hard time with the idea that I didn’t have a starting position before one. I recently observed the same thing in my friend’s three-year-old. He kept having one-off errors while counting spaces on a board game. Once his parents explained zero to him, he was able to count spaces correctly.

    Maybe we’re born to count starting at zero, but are taught to do it starting at one.

  39. Ben George Says:

    Some commenters are a bit harsh – Elliotte is entitled to publish his concerns and receive a warmer welcome from the Ruby community. They are mostly legitimate initial reactions for someone coming from a Java background.

    1,5,7: initialize, puts & elsif
    yes, I’d prefer “init”, “println”, and “else if” (but it’s no big deal)

    6 : 1-based indexing
    was this a joke Elliotte?

    8 : $_
    Actually I like this. But then I love Perl. Unlike most people these days it seems.

    2,3,4,9,10
    These simply wont bother you once you get into Ruby a bit more.

    Ruby is awesome for having fun and beating deadlines.
    Java is awesome for easy threading, systems programming, and the world class hibernate O/R solution.

    The things that bother me about Ruby are more pragmatic and due to its relative immaturity. The quality and depth of certain support libraries does not compare to Java (but that’s understandable at the moment), the lack of a hibernate competitor (activerecord is very cool but it’s a long way off Hibernate’s featureset at the moment). I’m sure these will all be improved given time as the Ruby community grows.

    Performance is my main worry at the moment, but again I’m sure clever techniques will evolve here too.

    Crucially though (and unusually for me), I don’t have many core gripes about the language itself. For me, Ruby was a Python killer rather than a Java killer.

  40. SMILER Says:

    WOW. => Just use JRuby, to compile your Ruby to Java byte code, and the GCJ to compile that to native.

    Just throw away Ruby and start from the Java stuff ;)

  41. Absolutely No Machete Juggling » Globals In Java? Says:

    [...] Elliotte Rusty Harold, author of Java I/O, has a few very nice blogs that I read often. He’s a smart guy with a lot of experience in software development. In a recent post, however, I think he made an interesting point that I wanted to address. [...]

  42. Christopher Burkey Says:

    These posts show that Ruby is so nerdy.

    Why was Ruby created? It seems to have no purpose other than as an esoteric platform for creating cute code. I have built numerous software products under tight deadlines. My feeling is that even if the programming language helped me write source code 50% faster then the we would have be shipped in 99 days instead of 100 days. In other words Ruby and Python and all the rest are not solving any actual problems other than syntax sugar.

    The real problem is how do we keep from writing the same libraries more than once? We should have a single repository of objects to build on top of and it should not depend on platform or native code. How is Ruby helping to streamline the number of redundant libraries out there? It actually looks to make everything worse by forking everything.

  43. Malcalypse Says:

    “a lack of understanding of what’s going on under the hood seems to be absent”

    Isn’t that what we want?

  44. pamthree Says:

    did u really wrote that book??
    your lack of understanding of ruby makes me wonder how much you know about java.

  45. rhubarb Says:

    Great, comments are still open so I can play too. Hmm.

    1. (Initialize (reading the comments has been as interesting as reading the original post, but I had to keep scrolling back up to remember what each number dealt with so Im putting reminders in parentheses (and longwinded explanations of reminders in (get this!) nested parentheses)) umm, let me count… right two more), shit too messy now, let me just start again)

    1. (Initialize) Glad you brougth it up, it annoyed me too but the comments have set me straight so now Im a lot happier.

    2. (scroll scroll scroll… Weak Typing) I hear you, but its the price of doing business in the dynamic language world. The benefits make up for the inevitable costs. I actually miss the readability of static typing more than the the security.

    3. (returns) Amen amen. Hear hear. Ruby _has_ the return keyword, but noone uses it. It’s bad enough that it’s not mandatory (why have it!) But the actual coding convetion – or idiom – is to not use it. Argh. This goes straight to readability. I want to see what the purpose of a method is, and I’m already handicapped because there’s no neat return-type in the declaration to give me a big clue. Without an explicit return statement I have to parse the damn code just to work out if its even _meant_ to return something.
    Please someone explain why
    def get_foo
    foo
    end

    is better than
    def get_foo
    return foo
    end

    4. (Globals) Unavoidable, I’m cool with globals. Though I’m not going to use them if I can avoid it (just as in global-substitues in Java)

    5. (puts) Only slightly agree. I would have liked to see good old “print” from way back in my BASIC days. But I am just so damn pleased everytime I dont have to type System.out.whenwillitfreakingend.ijustwanttofreakingwellprint.prinln that I’ll never complain about puts or p or pp.

    6. (zero based arrays) I’m fine with these. Agree with the argument that they’re not necessary, though I liked them in C coming from assembly language after starting in BASIC. However I agree with the POLS comments totally on this one. Starting arrays at 1 would just cause way too many headaches including an order of magnitude more fencepost bugs irrespective of how “right it is”

    BTW: To other commenters, 5 is clear evidence that Rusty is not comparing Ruby to Java.

    7. (elsif) Amen. “else if” is more readable, simple, elegant: it doesn’t require an extra keyword.

    8. ($_) Absolutely. And spare me the “theres an english alternative if you want to use it” BS, because I don’t want to use it, I want everyone else to use it so I can read _their_ damn code. And I want it to be mandatory so they _have_ to write code I can read. Therefore $_ and it’s ilk should simply be banished. QED.

    9. (public by default) don’t care.

    10. (nothing between private and public) I believe there is, though the distinction is different than Java and I don’t care.

    11. (my own) the whole statment~expression thing bugs me. It leads to code that does non-obvious things. I liked it in C, but learnt to love the lack of it in Java.
    I want to get a syntax error when I accidentally type

    if ( account.balance = 0)

    not a logic error that takes a month to find. I praise the Sun gods every time I get that compile-time error in Java because I’ve been bitten by that C-serpent so often in the past

  46. rhubarb Says:

    (sorry meant to say 6 proves he’s not comparing with Java, not 5)
    Oh yeah and let me add one last pet hate and end at the …

    12. end.
    The blithering language has curly brackets. So use them! I’m sick of reading “end” everywhere.

    The community is so spoilt for choice in this that the idom’t been adopted of using {} on one liners, and … end (note the lack of even a clear begin for the end, it’s “do..end” or “if..end”) for the multi-line blocks.
    Lets all start a new idiom. Lets all forget end in favour of {} and use explicit return statements from here on until the alternatives are deprecated for lack of use.
    (Oh and if you’re about to tell me the subtle difference between } and “end”, to show how clever you are, just be aware that this kind of subtle difference only makes it a LOT worse)

  47. Harry Kalogirou Says:

    This is why I don’t like Ruby : The “don’t speak of the devil” culture

  48. David Koontz Says:

    2. It’s not weak, it’s dynamic. Try doing “hello number ” + 7. You get a type error because you can’t add strings and numbers (unlike a weak static system ala C/C++/Java where it’s coerced for you by the compiler). Further, static typing is a very small amount of “correctness” and is more than made up for, plus a whole lot more, by unit tests which are strongly encouraged by the Ruby community.

    3. As stated this is common faire for functional languages. As for the poster who said why even have return, it’s to signal that you’re doing a non-standard return by ending the method right there and returning to the caller. Otherwise you’d have to structure your code so that the thing you want to return is the last evaluated statement, not easy in some situations.

    6. You have print, it works just like System.out.println. puts gets used almost exclusively because it automatically tacks on that “\n” for you. As stated by someone else, this stops bugging you pretty fast.

    7. “Sorry. “elsif” is not a word in the English language”. And Ruby was created by a Japanese man. Is def an english word? Is != an english word? Programmers make up new symbols and names for things all the time. Personally I would have preferred elseif but like #6 this stops bugging you pretty fast when you’re using it.

    9. I find that 95% of my methods are public. Having to put private in front of the few that aren’t is sure more convenient than putting public in front of each one that is.

    10. So have your class that probably is tightly coupled to the other just call some private methods on it. obj1.call(:private_method_here) If your class REALLY needs to know things that other classes shouldn’t then this won’t be a problem as the class already has intimate knowledge of the target.

    (Since they were brought up)

    11. Everything is an expression so you know what to expect. If you don’t return anything yourself you get back nil. Besides, good programmers know you should always write that “if ( 0 == account.balance)”.

    12. Curly brackets are only used for blocks, and then usually only for one line blocks. Blah / end is by far the norm and curly braces are the exception. You get used to end pretty fast.

    So, in conclusion: stop trying to make Ruby into Algol and enjoy what Ruby is, otherwise you’re going to have a terrible time fighting the language and libraries (same can be said of ANY language).

  49. Geoff Longo Says:

    Man, some people get so defensive over Ruby. Settle down, you are giving Ruby a bad name.

  50. galo Says:

    every language has its fair share of stupid quirks. Every one you cited can be refuted.

    And you lost all credibility on 1-based arrays…just…stupid.

  51. Dan Hayward Says:

    You’re all fucktards. Ruby suck the poo from your asses.

  52. MilesZS Says:

    If anyone has made it this far in the comments, wow.
    Someone up there had problems with implementation in Ruby. You should check out the future of Ruby, including YARV (to be included in Ruby 1.9 in November-ish), JRuby, Rubinius, Cardinal, etc. etc. etc. I won’t claim to know that much about them, except that, if I understand correctly, they will fix some of those implementation issues that have been discussed.

    Also, I have heard/read a ‘rumor’ that, in the future, if you have a string foo[0], it will no longer print the ASCII character code, but rather a character. (See page 79 in “The Ruby Way” by Hal Fulton.)

  53. Mystilleef Says:

    Try Python. I can’t stand Ruby’s syntax and semantics either.

  54. monowheel Says:

    1. init would better, less typing, especially the pesky z key.
    2. Swings and roundabouts here. Nice to have dynamic typing but there’s a cost in terms of testing. Pet peeve is the lack of syntax for declaration of variables.
    3. Like the consistency of expressions returning values. Explicit returns are much more readable though.
    4. Necessary evil.
    5. Like puts – short and obvious.
    6. C has a lot to answer for here. A whole generation of programmers have been brought up with the assembly level indexing of C and don’t know better. I’ve seen several severe system bugs over the years due to fencepost errors in 0-indexed languages. I can’t recall a single similar error in 1-indexed languages. Lost battle I fear.
    Note: Lists in human languages always start at 1, including this article! Zero is described as a state or condition.
    7. Agree about elsif in a pedantic fashion. Is it so hard to have elseif.
    8. Agree about the awfulness of $_ et al. What’s wrong with names?
    9. Private should be default. Outside access should require explicit syntax/permission.
    10. friend accessors are just bad design.

  55. Dean Says:

    I agree with rhubarb response 100%. No one ever thinks about maintainability. That’s the bottom line.

  56. Forstis Bonitas Says:

    “I don’t particularly agree with the list, but Paul has it spot on. A lot of these responses are immature and give an extremely poor impression of the Ruby community…”

    “Man, some people get so defensive over Ruby. Settle down, you are giving Ruby a bad name….”

    I find these kind of comments amusing, as if this only happens in the “childish” ruby community. I’m sure a blog post with the title “10 things I HATE about c++” would only elicit “let’s agree to disagree” and “you’re right, our language of choice does suck”.

    When one writes a post that has “hate” in the title, then you get basic things wrong (like not understanding the difference between weak typing and dynamic typing), you are going to get annoyed responses; as the author intended I’m sure.

  57. Forstis Bonitas Says:

    “I don’t particularly agree with the list, but Paul has it spot on. A lot of these responses are immature and give an extremely poor impression of the Ruby community…”

    “Man, some people get so defensive over Ruby. Settle down, you are giving Ruby a bad name….”

    I find these kind of comments amusing, as if this only happens in the “childish” ruby community. I’m sure a blog post with the title “10 things I HATE about c++” would only elicit “let’s agree to disagree” and “you’re right, our language of choice does suck”.

    When one writes a post that has “hate” in the title, then gets basic things wrong (like not understanding the difference between weak typing and dynamic typing), you are going to get annoyed responses; as the author, I’m sure, intended.

  58. Jaehyun Yeom Says:

    1. I think that’s because Ruby has class Object. “new” creates instance of self prototype and “initialize” initializes self. That’s different.
    2. Disagree, Tofu is my favorite, indeed. I can’t live without it.
    3. This can be confusing. You may want nil returned if no explicit return statement was written.
    4. Did OOP say “No global variable allowd?”
    5. It’s short and easy vocabulary. I like it.
    6. Oh… I once used indexed from 1. Now I realized why I should count from 0. I think counting from 0 is the god’s will.
    7. I’m non-English user. If “elsif” is a problem, so is “def”, “int”, and so on.
    8. No comment. I’m pretty busy now sorry.
    9. For agile development, I like this stuff. What if I have to put “public” everytime when I just like to test class?
    10. No comment.
    Not to be late for school. Have a good day.

    Tofu is my favorite.

  59. ob1 Says:

    None of these have EVER been a problem for me, and the fact that they are for you says that you haven’t been using Ruby very long. Are they problems in practice, or just in theory. Use Ruby to make something cool and you will understand why things are the way the are. (and the 2 character globals, like $! and $_, all have long named brethren. They come in very handy though for one liners and such. Don’t forget, Ruby is a SCRIPTING language. )

  60. zem Says:

    I had few frustrations with ruby before, but now….
    Check this out:

    arr = []
    arr.concat [3,4] # Following syntax logic, it should be: concat!
    # But its ok I suppose, lets see the result
    #>>> [] # What! It is supose to be [1, 2] you stupid!

    # Lets try again
    arr = [1,2]
    arr.concat [3,4]
    #>>> [1,2,3,4] # Aaah, I see! Stil stupid!

    # ok
    arr = []
    # arr += [3,4] # You cannot do that! Sucks!
    arr = arr + [3,4] # What about that?
    #>>> [] # What the f***!!! That is just disgusting!

    So how I’m supose to add to one array(posibly empty) another
    I wanna do it in ONE call please!

    And for the record ELSIF – sucks as!

    Anyway, I’m just started to learn smalltalk, Its pretty amaizing!
    Ruby is a crippled SMALLTALK!

  61. zem Says:

    Hey, its magic!!!
    concat is working!
    Yuppe!
    Maybe ruby or rails have changed their minds.
    I didn’t change a single bit of code by the way.
    Maybe when I was writing previous comment, the GC….
    Ah, what a heck! It doesn’t matter, it happens not the first time!
    I’m starting to understand what ruby magic means:)

  62. zem Says:

    By the way I love ruby;)
    It would be nice to see access modifiers for instance variables though!
    Another thing is the difference between class and def. I believe it should be the same as in JavaScript. Just def would do:)
    Next ofcourse, arrays should start from 1!

    Methods/classes names are poorly designed at the moment! Documentation is fragmented and hard to find.
    Not mention the slooooooow interpriter.

    But as I said, RUBY is the best language I used so far!
    SMALLTALK looks better but I’m just started learning it.
    Could someone point me why RUBY better than SMALLTALK, or otherwise?

  63. yeago Says:

    301 -> 10-nags-about-perl

  64. Me Says:

    Somebody finally put there money where there mouth is.

    I hate ruby and I have been using it for 8 months.

    It is ridiculous.
    I personally do not recommend it.

    Now I am back in Java and loving the simple things.

    Ruby has this weird following of kids.
    Congratulations to Ruby on Rails for reinventing the wheel.

  65. BusinessRx Reading List : The Way The Wind Blows Says:

    [...] Of course, your approach won’t make every user happy. You’ll still need to make trade offs. In “10 Things I Hate About Ruby”, Elliote Rusty Harold (author of Java I/O) is surprised by some of the conventions in the king of [...]

  66. Steven Says:

    Wow, a full year of comments. In spite of multiple comments correcting the author’s failure to understand the difference between new and initialize, the incorrect point remains posted. In spite of multiple comments contradicting the claim that “[t]here’s no access in-between public and private”, the incorrect sentence stands. These things are not matters of preference or opinion. The fact that these misconceptions continue to be referenced by others is what’s really Not A Good Sign.

  67. Pedro Penduko Says:

    Ruby would have been perfect if it followed the C style syntax the way Java did. I realy miss { }

  68. 5 Things I Hate About Ruby « Devi Web Development Says:

    [...] 3rd, 2007 at 5:19 am (language theory, syntax, ruby) I read an article at The Cafes about all the things he hates about Ruby. I love Ruby, but there are a few things I would do [...]

  69. Bian Xi Says:

    #6: Disagree. Can not imagine a ruler starts at one.

  70. DUDE Says:

    RUBY SYNAX IS THE WIN. NOT… It should have followed C’s. Ruby has some usefulness, but… PEOPLE USE JAVA INSTED!

  71. Sudipta Mukherjee Says:

    I completely agree with Christopher Burkey.
    At this point of time, We don’t need any more new languages. We have enough already. All new languages popping up can actually be replaced by ideally designed APIs.

  72. anon Says:

    Then write your own ‘PERFECT’ language.

  73. Ruby Says:

    why do you hate me?

  74. Merlion Says:

    Great, great post. I have been stuck in Ruby hell (RoR, real suffering) and I agree with most of your top ten. There are some good things, but be dammed their are too many hates.

  75. qwerty Says:

    “Great, great post. I have been stuck in Ruby hell (RoR, real suffering) and I agree with most of your top ten. There are some good things, but be dammed their are too many hates.”

    Nearly everything in his top 10 list is incorrect.

    If you do not understand weak vs strongly typed and static and dynamic typing, then you have no business commenting, just like the original author.

  76. rgz Says:

    1. “constructor is named like class” is a bad idea to begin with.
    2. You are missing the point of dynamic languages…
    3. SORT OF agree, methods should automatically return self unless there are explicit returns. But you will probably hate that too.
    4. There will always be something in the global namespace.
    5. Please tell me you are suggesting “print” or “println” else fail.
    6. Fail, go back to school, take a CS course.
    7. Please tell me you are suggesting “elif” else fail, er… just fail.
    8. First sane complain, that few people use it just makes it more likely to bite you by surprise.
    9. Fail and privateness is a bad idea to begin with, too, just embrace dynamic programming.
    10. No idea what you talking about.

  77. Rusty Shackleford Says:

    1. Car in java is a constructor for the class Car, not a method. new is a class method, initialize is exactly what it implies. When you call Array.new, initialize is NOT what gets called.

    2. Ruby is strongly typed. Every object has a type and that is all it will ever be.

    3. Unexpected returns? What? Every statement and method return something. If it is always the case, how can it be expected?

    4. What does OOP and globals have to do with each other? Answer: nothing! If you don’t line them, don’t use them.

    5. Then use print, or just alias puts.

    6. This is just stupid it defies belief. Computers start counting at 0. How many languages use 1? Very, very few.

    7. This is nonsense as each language uses something different.

    8. No one uses those in ruby, those are simply a by product of its heritage(Perl).

    9. This is retarded, it is like you don’t know that ruby has private methods. Hint, type private and every method below it is now private.

    10. You mean like observers? You can do this in Ruby.

    10 points of complete, utter and epic fail.

    All you have shown is that you have no clue about Ruby.

    Back to school for you.

  78. Rusty Shackleford Says:

    “There’s an attitude in some of those responses that I don’t care for. It looks like this…

    Me: The right windshield-wiper on my car makes streaks on the window instead of cleaning it properly.

    Mechanic: Don’t like Volvos? Then take the bus.

    Seriously, if you don’t have a valid response to a criticism then don’t get all defensive.”

    Post 10 legitimate and correct reasons and you will get reasoned responses. This article show that the writer knows absolutely nothing about Ruby.

  79. Rusty Shackleford Says:

    “Why was Ruby created? It seems to have no purpose other than as an esoteric platform for creating cute code.”

    Why was Java and C# created? They are both younger than Ruby.

    In fact we should all be using Algol or 1950′s Fortran right?

  80. Rusty Shackleford Says:

    ““a lack of understanding of what’s going on under the hood seems to be absent”

    Isn’t that what we want?”

    No, we want programmers who understand what is going on from the processor on up. If you don’t understand what is going on under the hood, you are an API monkey, not a programmer.

    Most Java and .net programmers do not, and thus suck.

  81. Rusty Shackleford Says:

    “It’s bad enough that it’s not mandatory (why have it!) But the actual coding convetion – or idiom – is to not use it. ”

    The results of the last line of a method automatically gets returned, explicitly putting a return is redundant.

    Why does it exist?

    def meth state
    return “hi” if state.nil?
    “bye”
    end

    It is that much to ask for people who complain to understand what they are complaining about?

  82. Craig Says:

    Why are some people so zealous about defending their language? I don’t go to France and tell everyone English is a better language than French. Why not just shut the hell up and use whatever suits your individual tastes? They all get the job done in the end.

    Personally I would love to be able to speak to my computer in plain English and have it construct some software for me in 10 seconds flat but that isn’t gonna happen any time soon. Until then, all languages are flawed.

    The most retarded thing about this discussion is that there are people saying some things are down-right wrong. How the fuck can a language be “wrong”?

  83. Jim Says:

    Try this on for size…..

    —-

    Class Player
    def initialise()
    end
    end

    puts “Welcome to a retarded example”
    puts “As you can see
    player = Player.new
    puts “The results of this example are fucking retarded.”
    ——-

    Returns “unexpected keyword_end, expecting $end” in Ruby 1.9.1 and 1.9.2
    Have yet to try it on the older versions.
    Shitty languages produce shitty useless errors. I’ll be taking up python TYVM.
    Also tried spelling it initialize()

  84. Cameron Says:

    Jim, I don’t know what environment you’re running in, but your code didn’t produce any errors on my system with Ruby 1.9.2. You mistakenly used a capital “C” for “Class”, which I fixed, so that might be your problem. Make sure you’re using the right syntax before you call a language shitty – the problem here between the keyboard and the chair.

  85. Javitzso Says:

    In the future there will be two types of computers. One that can process only mundane things like browsing the internet and updating a Twitter account. The other type of computer will have the added ability to compile code for making things. This compiler will be standardized and you will not be able to purchase or own one of these (legally) without a doctorate and certification.

    It will be illegal and abhorrent to experiment in programming languages just as much as performing science experiments on human bodies without the proper credentials and permission. Computers hold people’s lives now! It’s a serious business. It’s not a game anymore. Get these insecure “easy button” languages out of here before some idiot uses them to code a government website somewhere!

  86. Battletron Says:

    Jim, your code returns “____.rb:4: syntax error, unexpected keyword_end, expecting $end” because on line 4 there’s an unexpected “end,” that is, it’s not closing anything. That’s because “Class” should be class. Also, “initialise()” should be “initialize()”. Also, you need to close your quotes. These issues a) are programming 101, and b) shouldn’t need a compiler, as in any decent text editor the errors should literally be color-coded.

    As for the main argument, there are some legitimate complaints about Ruby, and there were more back when it was written (documentation, XML, speed) that have since seen at least partial progress toward resolving. Syntax peculiarities are not among them.

    1. new creates a new instance of a class, and it calls initialize to set it up for you. Think of it more as self.new(*args, &block), which allocates memory, sends the args and block to initialize, then returns the object. It can also be overridden, but generally people use initialize because they don’t want to alter the allocation and return parts.

    2. Already been addressed. Dynamic typing (and Ruby’s focus on duck typing) has its benefits and drawbacks, but given the amount of work some verbose languages like C# require just to maintain the type system, Ruby does eliminate some mindless work. There are speed consequences and type safety consequences, but no programming language is perfect in all cases, and Ruby fits its niche quite well.

    3. Everything returns something. Why is implicitly returning a null or undefined value better than implicitly returning the last line? And given Ruby’s emphasis on closures and chaining, it works: I’d rather see arr.map { |n| “a” * n } than return arr.map { |n| return “a” * n }. Plus, is there a reason and object-oriented language should default to a nil object (or, God forbid, a special literal like null)?

    4. Global vars are generally used sparingly. It’s better that they exist than not. Even if they’re usually a bad idea, in some cases they’re indispensable.

    5. puts can be abbreviated as p. You can use print and end it with a newline. You can alias it in one line with put or say or println or cout or whatever.

    6. Zero-based arrays are what most programmers expect. An array of length l has indices 0 ? i < l. l – 0 = l, so this interval also describes the length of the array. When extended by m places, the added elements have indices l ? i < l + m. They just make the math easy. Plus, there's an ary.first method.

    7. Is there any reason it's worse than else if or elseif or elif or nested ifs? It's just a control keyword, and it's really a fairly uncommon one (roughly 1/10 as common as else and 1/5 as common as case in Rails source, for example).

    8. Are these really being abused?

    9. It takes a second to type private and begin typing private methods after it. Any half-decent code will do this.

    10. Friend accessors? In general, when I see these used it's to break encapsulation. Its legitimate use cases exist, and probably the biggest one missing from Ruby regards testing, but it's hardly something worth hating. Furthermore, despite the limitations imposed by "mere" public/protected/private visibility, they generally allow for terse, legible, fully functional code.

  87. a Says:

    1. I agree… it would be more intuitive if ruby behaved like many other languages and made new and initialize the same method. it would also lead to much more elegant method overloading with multiple constructors rather than a single constructor and a giant case statement for determining how to process the completely arbitrary arg list.

    2. this is pretty standard for dynamically-typed languages

    3,4,5. agree

    6. disagree as this would make ruby unintuitive if you’ve used java, perl, python, php, c#, etc.

    7. no opinion

    8. agree

    9. no opinion

    10. there is the protected keyword

    my biggest gripe with ruby is that one can redefine a class arbitrarily. that wreaks all kinds of disastrous havoc in the wrong hands, esp in a relatively complicated system. this behavior should be modified or at least there should be a warning that a class is defined across N files and what those files are.

  88. feifei Says:

    “#7: A matter of taste. Me, I like elif.”

    man I can not tell you how much I loved this kind of nonsense. when you make public facing product — it better be the taste of public, not “a matter of taste”.

    this is just purely ego, arrogant and stupid to make things unnecessarily different. Unfortunately there are a bunch of smart *ss in this world which
    enjoy to make the world a worse place…and they are clever indeed, that is why we end up where we are.

  89. airtonix Says:

    eh While I’m not a computer scientist, I’m not a fan of the Ruby syntax. I would much rather use Python.

    1) end statements? really? what’s the point?
    2) pipe symbol not being used as a pipe ?
    3) just too many damn weird ass characters in non nonsensical places.

    Python is far more elegant.

  90. Tim Rowe Says:

    Arrays based at 0 or 1? Real programming languages let you *define* the base of the array, to match the problem it’s being used for. Gotta love Ada! :)

  91. Isaac Zepeda Says:

    The title should be: “10 things I hate about ruby based on my ignorance” or “10 things I hate about ruby because it’s not like Java”, I agree with the Masklinn arguments u.u, maybe my comment is useless but I want to say it :P

  92. Seo Says:

    1. Agreed. This has always annoyed the shit out of me; From a design standpoint, initialize is not an easy word to type, it’s a lot of letters, and it’s an ugly word for such a pretty language.
    2. Agreed. As long as the strict-typing system was elegant and faster than the regular type system in clarity and compactness. It would be convenient to have a short, one-line like “foo, bar are String” that auto-throws, or a way to discriminate between a function that could except say a space seperated string or an equivalent parameter array of strings. If an elagent, out of sight solution existed for these problems, I think you could improve (A) readability for functions that are not particularly descriptive in what they accept and (B) potentially even create non-order-dependent functions i.e. “def foo Integer String { puts “#{the Integer}” where a pro-noun architecture could be used to reference a variable.
    3. “When compactness comes at the expense of clarity, it’s a bad thing.”, “Languages should be concise only in so far as that improves clarity.” You would be forced to assume the same argument when people wanted to say 3 + 4 instead of 3.plus(4). You would have to prove your argument on the grounds that leaving “return” off the end of a statement, is grounds for ambiguity. Using less words to convey the same message is an improvement on clarity, not a counter to it. Again, you need to argue that the message is not as easily interpreted by a human as the “same message”. I don’t have a strong opinion on this matter.
    4. There are never times you need a global variable, and there are many times when global variables will fuck you over (Fork will fuck you). With that being said, I personally like using them in temporary scripts because they are immune to object-context and ruby has peculiar scoping mechanisms when dealing with variables and scopes. We will have to agree to disagree here. I prefer languages to have an air of freedom because I think expressibility improves clarity, creativity, and productivity. P.S. To everyone ripping
    5. I think puts is a nice, friendly, word. It’s like “put it here pal” :).
    6. You could say ruby supports this, e.g. “my_arry.first”, but I don’t think that’s to the degree you were considering. I don’t know enough to testify for the fencepost fix argument, but if that works, i’m all for trying it out! (I tried it in matlab, and hated it, but that’s probably because I hated matlab, or because matlab is a pile of shit for uncreative fucks).
    7. Yea.
    8. Yea.
    9. “Minimal interfaces to classes are important. The less a class promises, the easier it is to change, optimize, fix, and otherwise improve.” Disagree. Ruby has always had a strong tradition of having interfaces declared in human friendly “example” documentation and it is often useful to have private functions exposed by default for debugging purposes. The era of “privatize everything” will hopefully die alongside C++, along with Java interfaces. Interfaces are an unnecessary overhead and are nightmares to manage; talk about a waste of time. That is, interfaces, whether they be implied through private/public keywords like ruby/C++, or defined in java/C#; interfaces push programmers to spend their time over-engineering how they are going to cooperate with another department so they can fail horrifically at integration stage because corner cases were not evaluated. This is more a critique on engineering practices in general, however.

    10. “No package access or friend functions.” Similar to answer 9, you will fall victim to over-engineering. KISS

    ~Electrical Computer Engineer for 16 years. :) peace.

  93. Seo Says:

    @airtonix

    “eh While I’m not a computer scientist, I’m not a fan of the Ruby syntax. I would much rather use Python.

    1) end statements? really? what’s the point?
    2) pipe symbol not being used as a pipe ?
    3) just too many damn weird ass characters in non nonsensical places.

    Python is far more elegant.”

    Good thing you’re not a computer scientist.

    (1) end statements are good visual cues for your eyes, and prevent silly things like … say, a misplaced space from catastrophically fucking up your program and preventing the if statements from actually executing the correct lines because it think’s the indention level is off. end is necessary because ruby is not a white-space delineated language (beyond specific instances of newlines).

    (2) Dorthy says, “We’re not in *nix sh anymore”
    (3) Yea, probably. An example is hash syntax, {:this => “sucks”}, when the coffescript equivalent this: “sucks less” is much more succinct. I imagine it has something to do with tokenization because of the ambiguous nature of the coffescript version in comparison with other ocmmon operations. If i’m not mistaken though, ruby has been adding support for these kinds of shenanigans lately. :)

  94. Wow Says:

    Anyone who doesn’t understand that Ruby is strongly typed doesn’t know enough to have an opinion.

    “Java is number” + 999999999;

    That will compile and run just run.

    Ruby will spit an error message because it doesn’t coerce types and you morons think Java is strongly typed?

    Whiskey Tango Foxtrot?

  95. Newton Says:

    I see a lot of interesting posts on your blog. You have to
    spend a lot of time writing, i know how to save
    you a lot of time, there is a tool that creates unique, SEO friendly articles in couple of seconds,
    just type in google – k2 unlimited content

Leave a Reply