It also really bothers me that in ruby you can invoke a function on a null value to see if its null (myvar.nil?). That's really messed up...
Well, given that repeating some piece of code N times involves only two "entities", the code to be repeated and the number of repetitions, i see it as a very natural OO design decision to put that looping logic on a method on one of those two entities. The other possibility would be to make the "code" object respond to a method that tells it how many times to execute:
{ puts "Hello, alternate Ruby" }.do_times(10)
> It also really bothers me that in ruby you can invoke a function on a null value to see if its null (myvar.nil?). That's really messed up...
Can you elaborate in this please? I personally think that making nil something else than an object on OO language wouldn't make much sense. It would be an unnecessary complexity to stipulate "the way we interact with objects is through message-passing, except with nil, on which you cannot pass any message, but instead you have to compare it by identity to a global value named nil". Nil being a regular object that responds to things like .to_s or .nil? is pretty handy.
Ruby has a lot of these special cases where there's a gimmicky way to do something which is not the general purpose way and is not the right way to think about that kind of logic. "== nil" is just as short as ".nil?" and isn't as wacky as intentionally calling methods of nil (and every other object needing to have this nil-specific interface).
In fact, everything in Ruby is an object. Languages that treat "nil" or "44" as not being instances of a class are the ones making special cases.
No, it's a brilliant use of polymorphism. "null" in Ruby is not a value, it's like everything else an object. So it have methods.
Just because you are not used to it doesn't make it messed up.
It's not a number's place to know how to do looping, it's not an object's place to know whether it's nil or not. Why would every single object have a "nil?" method?
You can make it work, but it's just not good style (and it doesn't serve the purpose of implementation efficiency or machine-sympathy, which I would give exception for).
(also, special characters in method names?! my complaints about ruby really don't end with these comments, these are just the most succinct ones)
This is not an objective statement, it is one of subjective preference, about which people (demonstrably, by the very existence of Ruby) disagree. The right way to think about organization of logic is not an objective fact, and...
> You can make it work, but it's just not good style
...neither is "style".
If we consider a number as "zero or 1 plus a number", then the "Number" class could very well be the one that knows how to execute a piece of code a number times given that representation. It's actually pretty similar to the Church encoding of numbers in the lambda calculus[1].
Why shouldn't every single object have a 'nil?' method? It can be very useful. Think about operating on a collection of objects with `map` or `collect` or whatever your favorite language calls it. No need to write code, just send the `:nil?` message to every object, which you can do with one line.
You're right that "everything is an object" is not the most performant way to build a runtime, but it suits the purposes for which Ruby was designed very well. Just because you don't value those priorities doesn't mean others do not.
How is it strange? Feels rather intuitive to me: "Do this 100 times".
> It also really bothers me that in ruby you can invoke a function on a null value to see if its null (myvar.nil?). That's really messed up...
Again: how so? `nil` is just another object, so why shouldn't it have a method telling us if it's nil?
Of course, if you don't like it, you could check to see if it equals `nil`, or you can check if its class is equal to or is a subclass of `NilClass`. Like Perl, There's More Than One Way To Do It (TM).