The Future of Ruby

by kylefox • 14 years ago

73 16 14 years ago

zimbatm• 14 years ago

It'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.

nwjsmith• 14 years ago

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.

waxjar• 14 years ago

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.

amalag• 14 years ago

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.

gary4gar• 14 years ago

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

tjic2• 14 years ago

I think you've put your finger on it EXACTLY.

kylefox• 14 years ago

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.

tjic2• 14 years ago

> 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?

Derbasti• 14 years ago

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.

nathany3• 14 years ago

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.

nmcfarl• 14 years ago

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.

halostatue2• 14 years ago

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.

nathany3• 14 years ago

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.

halostatue2• 14 years ago

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

The Future of Ruby

Related Stories