[endorphine]

I intuitively expected this to get downvoted but I'd like to hear opinions of the people who downvoted this, wrt how much of this flexibility is a design flaw (or accidental complexity?) and how much it is expected given the history and evolution of the language.

[tetha]

I didn't downvote it, but I don't like the swipe of ruby not being a well-designed language.

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.

[throwanem]

If I found myself defending a language by comparison with Perl, I'd be nervous. I worked in that language for most of a decade, and there are many reasons why I refuse ever to touch it again for longer than required to write a shell oneliner.

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.

[vidarh]

In 43 years of programming, it's by far the most readable of the several dozen languages I've used.

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.

[tetha]

I'm not even defending ruby too much. I used ruby for many years and it always felt somewhat off.

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.

[lamontcg]

They didn't comment on what they think good design was so its just pretty uselessly taking a swipe at Ruby. They may be correct that languages made more recently are better designed from the start because they can work around issues that ruby hit because people largely didn't know any better (some contemporaries may have claimed to know better, but there's always people after the horse race who really did bet on the right horse). They may be starting a religious war, believing that something that ruby supports is just so clearly wrong that ruby shouldn't exist. We can't really say, but it doesn't offer any useful comment. And its really easy to say that a 28 year old language shouldn't have been developed exactly the same way, given what we know now.

[throwanem]

Javascript and Ruby are of an age, both first released in 1995. Javascript has always supported all of the use cases described here for Ruby, until very recently with exactly one syntactic convention for argument passing. If you want keyword arguments, pass an object; if you want to pass a function, pass a function.

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.

[djur]

The ergonomics of passing anonymous functions in JavaScript as originally released was awful, as was passing "keyword arguments" as objects. That's why arrow functions, async/await, and object destructuring were added to the language years later. 1995 JavaScript didn't even enforce function arity!

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".

[throwanem]

This gets us a bit into the definition of "sugar", I think. Specifically, all the constructs you mention are syntactic shorthands for the same underlying concepts, and the original syntax also remains available - which is to say, those constructs actually are syntactic sugar. Ruby having three ways, in two cases, to do one thing, is not.

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?

[djur]

> 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

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.

[lamontcg]

Kind of funny -- if I understand this correctly -- that Javascript was descended from Scheme which has delimited continuations and yet Javascript has async/await and function coloring nonsense, while ruby has continuations and fibers and doesn't need to worry about "function coloring" or "callback hell".

(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)

[vidarh]

Simplicity is why I detest the Javascript syntax and love the Ruby syntax. I spend far more time reading code than worrying about very simple rules for how to write the arguments, and so readability matters far more.

[djur]

The language didn't have keyword arguments at the time it was originally created (nor did many other languages). The use of hashes as a way of simulating them was popular at the time (I've seen the same in Perl) but it was a good idea to eventually make them a full-fledged feature. It took a while to complete that transition without causing a serious backwards-incompatible disruption. Ruby has generally favored avoiding such things, which sometimes means finding some inelegant solutions.

[throwanem]

> it was a good idea to eventually make them a full-fledged feature

Why so?

[vidarh]

Because it provides a clearer way of enforcing calling conventions. Calling a method with the wrong keyword argument raises an error automatically. Calling a method with hash arguments the method expect replies on the method manually checking for unexpected keys. In Ruby as in other languages it was error prone.

[gls2ro]

Positional arguments creates a dependency on the position of the argument. And this is a cause of bugs when calling a method with the arguments in the wrong order.

Keyword arguments remove the depedency on the position.