

The Future of Ruby - kylefox
http://nathany.com/ruby-design

======
zimbatm
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
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
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.

~~~
jinushaun
Easier said than done when developers have "write once, run anywhere"
expectations. Mono famously has to duplicate bugs when implementing .NET.

------
halostatue
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-...](http://www.ruby-lang.org/en/news/2003/12/19/new-ruby-change-
request-rcr-process/)

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.

~~~
nathany
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.

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

~~~
nathany
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.

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

~~~
kylefox
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.

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

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

