Why are there so many kinds of things that can be passed to a Ruby function?
You can pass positional and keyword args together in a way which is rigidly formalized since Ruby 3.0 because, at one point in history, you could pass a hash, you could pass positional arguments, and you could pass keyword arguments, and nobody was ever able to tell reliably what you were doing:
https://www.ruby-lang.org/en/news/2019/12/12/separation-of-p...
You can pass a block because in Ruby, a block is an object like anything else. And you can pass an anonymous block because in Ruby, the "yield" keyword is an idiom that's commonly used with anonymous blocks. The curly braces and the "do" keyword that are both common idioms in Ruby are nearly identical forms of anonymous block.
The throwaway answer to your question is that you can pass anything that is an object, and in Ruby since anything is an object, you can just pass anything! I haven't read the whole article, but I get the sense that I shouldn't read much into the clickbait headline, since it looks like this is a really thoughtful show or treatment of all the neat handy things that Ruby lets you do with various types of arguments, and not a hit piece! whew relieved
That's simpler to understand because there is less to understand, with these capabilities composed from extant syntax rather than having been invented as one-offs that require being learned and understood as such, each hedged around with its own special cases and failures to generalize - if that were not the case, the article here under discussion and all others like it would never have needed writing in the first place.
I realize describing Javascript as "well designed" will be controversial, and certainly it has not been without its share of flaws: loose equality and IEEE 754 float behavior come most quickly to mind, along with the lack of a general conditional expression. I am comfortable with describing Javascript as better designed than Ruby, though. Certainly it is far more ergonomic.
Good engineering above all else is, as much as possible, simple: it can't help being about as complex as the domain it addresses, but any complication beyond that represents an error of design. Programming a general-purpose computer is an arbitrarily complex domain, which gives all the more point to the need for simplicity in design: the user of the tool has enough to think about already, and should insofar as possible not also be forced to manage unnecessary complexity in tooling. Under such a metric, that Ruby needs three kinds of calling conventions to accomplish what Javascript does with one is already enough to demonstrate that Ruby's design is lacking.
A language that is self-evidently superior due to simplicity and ergonomics would not inspire the publication of a hugely successful book that promises to show people the "good parts" of the language. The superior language you're describing should only _have_ "good parts".
I'm glad you mentioned "The Good Parts"! Crockford published in 2008 and the state of the art in JS has so evolved as to make further such work mostly unnecessary, or so I infer from its more-or-less absence over the last decade or so at least. That Ruby still requires such explainers be published in 2023 seems more an argument to my point than to yours.
You're also very anxious to make the perfect the enemy of the good here, which is a surprise after the explicit disclaimer in my prior comment. Why are you asking me to defend an argument I've been at such pains to make clear I'm not advancing?
async/await was introduced in 2017. If you're suggesting that this required fewer "explainers" than a set of gradual changes to Ruby method call syntax, I'm afraid we're not operating under a common understanding of reality.
(Which I don't understand very well because I was a ruby programmer for 12 years, so missed all the async/await/callback-hell nonsense entirely that everyone is so obsessive about these days)
One thing to consider: Ruby is old. Ruby stems from a time when "Everything is an object" and "You can pass a code block to a function" are borderline revolutionary. Ruby comes from a time of very imperative PHP, C and such. Python was another language during these early days, as was perl.
And ruby has strayed into a few paths of ambiguities. Like, hash as an arg vs kw-args, blocks, references to blocks. Quite a few things are weird there. Tolerable, moving into better spaces, but certainly weird.
But at the same time, have you looked closely at Java Generics? Or, Pythons multiple inheritance? Or, Perls Object Orientation. Or, PHPs types, until recent versions. If three of us get together, we can start making fun of every language for taking a wrong step, I'm sure.
I didn't work with Ruby for nearly as long as that, not least because I found it to share too many of the same problems. I understand why the few people who deeply appreciate it do so, and I don't really judge them for that, but a wider and less partial perspective is also needed.
Then, too, nothing here actually defends Ruby's design per se. That nothing better could be expected at the time is really as close as we get, but as I discussed in more detail on another branch of the thread, contemporaneous Javascript suffices to dispose of that claim. That there are less well designed languages than Ruby I freely grant, but that's also not much of a defense.
However, with the brevity of original comment, it feels like Ruby is getting a lot of flak for shaky design decisions.
While in reality, a lot of languages from that period had very shaky design decisions. Newer generations of languages or better versions of these languages - built upon the lessons of that period - avoid these mistakes and put the spotlight on these "obvious" design issues.
That I routinely can convert code from other languages and end up with something far smaller and more readable is another major plus.
That is all I need to defend its design.
Why so?
Keyword arguments remove the depedency on the position.
And arguments may be passed either positionally or by name.
Blocks are the weird part, they have special support because they're a bunch of syntactic sugar / magic, which doesn't even have to be part of the function's prototype e.g
def foo
yield if block_given?
end
I haven't kept up to date with Ruby so I don't know if that style is still en vogue. The equivalent "explicit" version is
def foo &block
block.call if block
end
Fun fact: Both yield and block.call may never return. The block is free to return from its enclosing method, which effectively pops multiple frames, including foo and possibly more, off the stack.
As an aside, this is one of the key differences between a lambda and a proc. Last I checked, you can pass a lambda as a block, but it is implicitly converted to a proc.
It’s more the opposite, arrow functions treat `this` as a regular lexical variable, it’s normal functions which special-case `this`.
The distinction between a block and a Proc is an implementation detail - an implementation can choose to always make blocks Procs (my experimental Ruby compiler does just that) and a program shouldn't be able to tell the difference.
The distinction between proc and lambda with respect to how returns are handled provides significant utility with very low added implementation complexity that for the most part work together to do what people will expect of them.
That is, the most logical reading of the block syntax is that a return will return from the function it is lexically in, so it does, while a lambda looks like a function, and acts accordingly.
If anything, to me these are prime examples of what makes Ruby a great language that values developer happiness over pointless exercises in purity.
Named args, unnamed (positional) args, and a special block. Because Ruby was basically "let's make Python but without Guido's hatred of metaprogramming", so it copied Python's *args and **kwargs and then added the block so you could make functions that look like control blocks.
To me the problem is that they're handled as 3 vars instead of 1 object that has 3 public properties.*