The Future of Ruby(nathany.com)
nathany.com
The Future of Ruby
http://nathany.com/ruby-design
5 comments
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 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.
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.
Easier said than done when developers have "write once, run anywhere" expectations. Mono famously has to duplicate bugs when implementing .NET.
[deleted]
I think the Japanese language is a big issue and Matz's decision to not make changes to the GIL in spite of Rubinius making great progress in that regard.
Some of this has been tried in Ruby before. They're called RCRs (Ruby Change Requests).
http://www.ruby-lang.org/en/news/2003/12/19/new-ruby-change-...
The experiment…failed.
http://www.ruby-forum.com/topic/148408
While it would be nice to see more discussion off-email, I think that's hard enough to be unlikely.
http://www.ruby-lang.org/en/news/2003/12/19/new-ruby-change-...
The experiment…failed.
http://www.ruby-forum.com/topic/148408
While it would be nice to see more discussion off-email, I think that's hard enough to be unlikely.
That's an interesting find.
I hope the failure in 2003-2008 doesn't predetermine the outcome of such an effort in 2012, assuming such an effort does takes place.
I hope the failure in 2003-2008 doesn't predetermine the outcome of such an effort in 2012, assuming such an effort does takes place.
For me, it wasn't a find. I was there. In the wars. The horrors I could tell you of the RCR Wars of ought-five… The find was merely providing a [citation] to my memory of the earlier process.
Seriously, problems around things like refinements aside, it seems to me that Ruby is progressing faster and more regularly than it has for years. Yes, it sometimes takes major alarmist posts by non-MRI implementers to get the attention of enough people to get a course adjusted (e.g., refinements), but I think that we're seeing much better collaboration and development on Ruby and more compatible Rubies than would be possible with the RCR mechanisms that were previously involved.
Imperfect, but by keeping to the tools that the main developers already use (email)…it is less problematic. I also think that it has helped that there have been implementor summits at several of the major conferences. Further, I think that it's helped that Matz himself is also working on an alternative implementation (mruby).
Seriously, problems around things like refinements aside, it seems to me that Ruby is progressing faster and more regularly than it has for years. Yes, it sometimes takes major alarmist posts by non-MRI implementers to get the attention of enough people to get a course adjusted (e.g., refinements), but I think that we're seeing much better collaboration and development on Ruby and more compatible Rubies than would be possible with the RCR mechanisms that were previously involved.
Imperfect, but by keeping to the tools that the main developers already use (email)…it is less problematic. I also think that it has helped that there have been implementor summits at several of the major conferences. Further, I think that it's helped that Matz himself is also working on an alternative implementation (mruby).
The communication is improving and Matz is onboard. I was really happy to see the IRC logs from December 10th. At least people are talking.
As mruby gains traction, people will want to know the differences between mruby and MRI. I think it's a perfect reason for Matz to be involved in RubySpec, and for an accessible language reference.
As mruby gains traction, people will want to know the differences between mruby and MRI. I think it's a perfect reason for Matz to be involved in RubySpec, and for an accessible language reference.
So, 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
It would be interesting how these discussions pan our. something to keep an eye on
I think Python's process is pretty ad-hoc too, in that anyone can champion an idea and everyone can discuss on the mailing list. There aren't many formalities, other than (1) a few core people get to make the final decision, and (2) at the end of the discussion the yes/no stamp (and importantly, the reasoning behind the decision) is documented.
I think you've put your finger on it EXACTLY.
Perl 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.
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.
> 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?
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.
Sorry. That's some poor organization of the writing on my part, which I've revised slightly.
My article is still leaning heavily on Brian Ford's talk for the reasons why the current (lack of) process is an issue that needs consideration. I certainly could've done a better job of summarizing that before throwing in my 2 cents.
My article is still leaning heavily on Brian Ford's talk for the reasons why the current (lack of) process is an issue that needs consideration. I certainly could've done a better job of summarizing that before throwing in my 2 cents.
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.