4 ms·

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 (

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.

lamontcg 3y ago
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 3y ago
  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 3y ago
    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 3y ago
      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 3y ago
        > 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 3y ago
tetha 3y ago
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 3y ago
  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.
  - tetha 3y ago
    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.
djur 3y ago
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 3y ago
  > it was a good idea to eventually make them a full-fledged feature Why so?
  - gls2ro 3y ago
    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.
  - vidarh 3y ago
    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.

lamontcg 3y ago

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 3y ago
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 3y ago
  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 3y ago
    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 3y ago
      > 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 3y ago

tetha 3y ago

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 3y ago
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.
- tetha 3y ago
  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.

djur 3y ago

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 3y ago
> it was a good idea to eventually make them a full-fledged feature Why so?
- gls2ro 3y ago
  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.
- vidarh 3y ago
  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.