Personally, my biggest issue is that all of these variations feel a bit bulky. I wish Ruby would decide to do the typing as it was done in Crystal Lang. And maybe then we wouldn’t have multiple ways of doing the typing in Ruby.
TBH, I am not so sure about this (I went at great lengths investigating this feeling last year). I mean, “normal” language development process would’ve probably felt more controlled and reliable for language users, no argument here, but I am not sure it could’ve led to a better language.
But that’s complicated! (When some features are merged a week before release without much discussion, I definitely think many different thoughts.)
I agree. Quire a few languages and projects face the problem of filtering too little with such an approach leading to bloats and lots of barely used and therefore badly maintained features that might be deprecated or slow development down.
Often times the structure is that you gave to create a quality proposa, followed by something like a vote (if even). So there’s a clear path for adding something that is hyped, but it’s not so easy to say no, especially not if the reason is more complex or is about keeping the language simple, or the style or also when there’s cases how a feature can and will be abused in the sense that code will become non-idiomatic. This is worse when a language grows in user numbers and a lot of people come in from other languages that don’t learn, maybe don’t want to learn or disagree with idioms (for example when the job demands it).
This is a pattern of events that many languages go through and usually the “solution” is picking up the next language that still is simple. Until there all of this happens again.
When non idiomatic solutions take hold and widely used libraries work that way the case for new proposals is created so this process reinforcemes itself. So there’s a lot of context, sometimes in time and while of course not all decisions in the past will have been good some might have been good in the context of the time, and when the language changes enough that it feels different you’ll have “warts” on a languages, weird parts that now one should never do.
All of this is pretty bad in my opinion because you end up with a language and especially its ecosystem maturing, but the language and some older bigger libraries and code bases being monstrosities because they had to shift with how the language evolved over time.
All of that of course was done with best intentions. But it leads to this pattern repeating.
I think that both can be true. What got us to the great language we have now may have needed to come from one person’s oversight. What gets us to the next level doesn’t necessarily have to look like what got us here today.
Maybe “working group” is too strong. Perhaps just more explicit invitations on how people can get involved. My PRs to Pathname are getting no reviews. Meanwhile I’ve gotten practically zero contributor interest in others contributing to syntax_suggest (my default gem).
Cohorts, mentoring, and mutual (code) aid could all help.
Someone finally put in words what I’ve always felt about these type annotations in Ruby. I love the pattern-matching approach in the end!
I just hope those annotations can be checked before running code (like Sorbet does).
Personally, my biggest issue is that all of these variations feel a bit bulky. I wish Ruby would decide to do the typing as it was done in Crystal Lang. And maybe then we wouldn’t have multiple ways of doing the typing in Ruby.
My hot take is: the more structural issue is the lack of clarity into how decisions are made. I would like to see working groups or similar in Ruby.
TBH, I am not so sure about this (I went at great lengths investigating this feeling last year). I mean, “normal” language development process would’ve probably felt more controlled and reliable for language users, no argument here, but I am not sure it could’ve led to a better language.
But that’s complicated! (When some features are merged a week before release without much discussion, I definitely think many different thoughts.)
I agree. Quire a few languages and projects face the problem of filtering too little with such an approach leading to bloats and lots of barely used and therefore badly maintained features that might be deprecated or slow development down.
Often times the structure is that you gave to create a quality proposa, followed by something like a vote (if even). So there’s a clear path for adding something that is hyped, but it’s not so easy to say no, especially not if the reason is more complex or is about keeping the language simple, or the style or also when there’s cases how a feature can and will be abused in the sense that code will become non-idiomatic. This is worse when a language grows in user numbers and a lot of people come in from other languages that don’t learn, maybe don’t want to learn or disagree with idioms (for example when the job demands it).
This is a pattern of events that many languages go through and usually the “solution” is picking up the next language that still is simple. Until there all of this happens again.
When non idiomatic solutions take hold and widely used libraries work that way the case for new proposals is created so this process reinforcemes itself. So there’s a lot of context, sometimes in time and while of course not all decisions in the past will have been good some might have been good in the context of the time, and when the language changes enough that it feels different you’ll have “warts” on a languages, weird parts that now one should never do.
All of this is pretty bad in my opinion because you end up with a language and especially its ecosystem maturing, but the language and some older bigger libraries and code bases being monstrosities because they had to shift with how the language evolved over time.
All of that of course was done with best intentions. But it leads to this pattern repeating.
I think that both can be true. What got us to the great language we have now may have needed to come from one person’s oversight. What gets us to the next level doesn’t necessarily have to look like what got us here today.
Maybe “working group” is too strong. Perhaps just more explicit invitations on how people can get involved. My PRs to Pathname are getting no reviews. Meanwhile I’ve gotten practically zero contributor interest in others contributing to syntax_suggest (my default gem).
Cohorts, mentoring, and mutual (code) aid could all help.