Comment by kace91

Because it leaves it up to the object being called what to actually do with the message. The object you're talking to might be forwarding its messages to another object in another ruby instance on another machine (if the current machine is getting fully loaded, etc), and the caller would be none the wiser. And crucially, the caller wouldn't have to be modified to enable this. The logic for this would be entirely within the object being called.

So the difference isn't just with method_missing.

With "method calling" as you put it, the program blows up if that object doesn't have that method, WHEN YOU CALL IT.

Basically, this smalltalk oo paradigm is about shifting where you put more of your logic. At & around the "call" site, or within the object whom you're calling & entrusting to do something useful with it.

All hearkening back to Alan Kay's original ideas about biology influencing how we organise code, and having a program be 1000's of "little black boxes" where work gets done by all these boxes talking to each other.

Which is why smalltalk (& ruby implements the Smalltalk object model to its entirety) actually has an awful lot in common with Erlang & other BEAM runtimes, even though those are functional languages. Because once you get beyond the techy buzzwords, the main ethos behind them is actually quite similar.

I think I feel you. However, I think you have conceptually loaded "method" with more meaning. I think a less loaded way to think of the object/method is that the object is the first argument to the method that is called on it. So

    5.times { puts 'hi' }

    times(5) { puts 'hi' }

    my_function = -> { puts 'hi' } 
    repeat_times(5, &my_function)

After my foray into functional programming, I actually ended up appreciating Ruby more, because it lets you have it both ways: program your computer directly, and harness functional concepts. Since computer hardware is not functional I don't want the extra ceremony and abstraction over it for the sake of purity.

All that said, going back and forth between Ruby and Elixir really conceptually crystallized for me that the method call receiver is basically just the first argument to the method, accessible with the keyword `self` (which in Python is made explicit for example).

There is a bit of personal preference in what "applies to a number", but I see what you mean.

As a slight correction, a block is indeed an object! They are received by methods as an instance of the Proc class:

  def inspects_block(&block)
    puts block
    puts block.class
  end
  inspects_block { "foo" }
  # => #<Proc:0x0000000000000000>
  # => Proc

  class Proc
    def repeat(n)
      n.times { self.call }
    end
  end
  ->{ puts("foo") }.repeat(3)
  # => foo
  # => foo
  # => foo

Blocks are actually instances of the Proc class. There are helper methods to handle blocks passed to methods in a lightweight manner but you can also accept the block as a method argument, e.g.,

  class Integer
    def times(&blk)
      i = 0
      while i < self
        blk.call(i)
        i += 1
      end
    end
  end

Fun fact - there's no Boolean class in Ruby. True is an instance of TrueClass and false is an instance of FalseClass

Hmm, but that's not really a "breakage" in ruby, it's more an aesthetic argument over which objects should have which logic. It's like naming things. Smalltalk (& ruby) has 'select'. Everyone else uses 'filter'.

To some, 5.times seems very readable & logical. It's like arguing over the "right" colour scheme to use while coding (BTW, the correct answer is solarised light, but with black foreground text!!)