The Future of Ruby
nathany.com
The Future of Ruby
1–10 of 19 posts
Re: The Future of Ruby
#2It's not really clear what the issue is/are.
Anyone can propose a change. It just takes a lot of effort because language changes often have a lot of ramified implications. Most of the ideas are crap and it's frustrating to the originator but adding a process won't solve that issue.
Most of the discussions are available trough http://bugs.ruby-lang.org/ or the ruby-core mailing-list and the language's behaviour is well defined thanks to the http://rubyspec.org/ project.
The only real issue that I know of is that some of the discussions are done in Japanese which secludes the biggest part of the developers. Instead of proposing a scatter-gun solution it would be great to have something specific in that regard.
Re: The Future of Ruby
#3It's not really clear what the issue is/are. Anyone can propose a change. It just takes a lot of effort because language changes often have a lot of ramified implications. Most of the ideas are crap and it's frustrating to the originator but adding a process won't solve that issue. Most of the discussions are available trough http://bugs.ruby-lang.org/ or the ruby-core mailing-list and the language's behaviour is wel…
[deleted]
Re: The Future of Ruby
#4So, basically its
People with ad-hoc system Vs Process advocates.
It would be interesting how these discussions pan our. something to keep an eye on
Re: The Future of Ruby
#5> If someone were to say “Ruby is defined by its'
> implementation”, we could not argue... [ elided ]
> This is why we need a language reference.
Huh?
I'm entirely open to the ideas proposed here, but I fail to see any ACTUAL benefits. The fact that a new process to define and manage the language prevents a rhetorical device from being used - that's a serious argument in favor of the change?
Am I missing something?
Re: The Future of Ruby
#6So, basically its People with ad-hoc system Vs Process advocates. It would be interesting how these discussions pan our. something to keep an eye on
I think you've put your finger on it EXACTLY.
Re: The Future of Ruby
#7It's not really clear what the issue is/are. Anyone can propose a change. It just takes a lot of effort because language changes often have a lot of ramified implications. Most of the ideas are crap and it's frustrating to the originator but adding a process won't solve that issue. Most of the discussions are available trough http://bugs.ruby-lang.org/ or the ruby-core mailing-list and the language's behaviour is wel…
The largest issue seems to be that Ruby implementations other than MRI have to replicate its bugs in order to be considered a 'Ruby'. A language specification/design would help to solve that problem.
I for one would like to see a focus put on cleaning up the standard library (gem-ifying much of it?) rather than a design committee.
Re: The Future of Ruby
#8It's not really clear what the issue is/are. Anyone can propose a change. It just takes a lot of effort because language changes often have a lot of ramified implications. Most of the ideas are crap and it's frustrating to the originator but adding a process won't solve that issue. Most of the discussions are available trough http://bugs.ruby-lang.org/ or the ruby-core mailing-list and the language's behaviour is wel…
The largest issue seems to be that Ruby implementations other than MRI have to replicate its bugs in order to be considered a 'Ruby'. A language specification/design would help to solve that problem. I for one would like to see a focus put on cleaning up the standard library (gem-ifying much of it?) rather than a design committee.
I still don't really get the problem.
If a bug is recognised as such, simply don't implement it in the same way. If it's not, it's either a bug not previously discovered or intended behaviour.
Re: The Future of Ruby
#9> If someone were to say “Ruby is defined by its' > implementation”, we could not argue... [ elided ] > This is why we need a language reference. Huh? I'm entirely open to the ideas proposed here, but I fail to see any ACTUAL benefits. The fact that a new process to define and manage the language prevents a rhetorical device from being used - that's a serious argument in favor of the change? Am I missing something?
A formal definition of the language could separate implementaion specific bugs from actual language features. It would thus help implementers of alternative implementations of Ruby.
Re: The Future of Ruby
#10Perl has/had this same problem. The route forward, that was chosen, was to formalize the process with Perl6. It's been 12 years in the making so far, it's not quite production ready, and it's certainly very different than Perl5.
The lesson I learn from this is that with programming languages governance is part of the thing, radical changes affect everything. The language is not hived off from its governance.