How to maintain compatibility and language quality

gistfile1.md

How to maintain compatibility and language quality

Ruby

Conform to whatever is committed to MRI. There is a standard, but it's not complete enough to ensure compatibility. The standard is describing what is already there and not meant as means for designing the language. No review process for patches.

There is the RubySpec project, which all implementations usually run at least before doing new releases. It's not currently used for designing the future of the language and all teams but the Rubinius team consider contributing to it on regular basis as too much overhead.

Smalltalk

There is an ANSI standard, but it's not complete enough to ensure compatibility. The standard is describing what is already there and not meant as means for designing the language. Kent Beck and others criticize "Balkanization of Smalltalk" (i.e. it is not possible to write Smalltalk programs without targeting a specific implementation). No maintained reference implementation.

PHP

Alternative implementations may not be called PHP. There is no standard. Language design is interwoven with implementation design. Language quality is often criticized.

Perl

There is no official implementation, just an official test suit. In contrast to RubySpec, this is where language design is happening. There are multiple implementations treated as equals.

Java

Standardized bytecode with well defined behavior, lots of implementation. Everyone can participate in the Java Community Process. Two implementations treated as reference implementation (OpenJDK and HotSpot).

Python

New features are proposed via formalized process Python Enhancement Proposals, everyone may participate. Van Rossum has veto. Reference implementation. Situation close to Ruby, but formalized process.

C++

Decided on by C++ Standards Committee, no official/reference implementation.

C

Decided on by ISO working group, no official/reference implementation.

JavaScript

Core language is designed by Ecma International (non-profit committee), client-side stdlib is designed by W3C, server-side is designed by CommonJS committee. Hard to propose changes if you are not in the committee.

Erlang

Uses Erlang Enhancement Process, which is similar to Python Enhancement Proposals, but officially hosted on GitHub and proposals can be submitted as pull requests. Process is highly standardized.

Scala

Scala Improvement Documents, similar to PEPs and EEPs.

The standard MRI thinks is JIS Ruby or comming ISO Ruby.

Yes, that's what I was referring to. But it's insufficient to for instance implement Rails solely based on that standard.

Also, much like the Smalltalk standard, it's describing what is already there and not meant as means for designing the language.

This is a useful compilation for discussions around "How designs Ruby?"

I added Erlang.

1. For the purpose of addressing issues, what is insufficient in the existing standard that prevents implementing Rails solely based on it?
2. What is meant by "means for designing the language"?
3. Size of the community is important as well in this conversation. A process has to be targeted that's reasonable for the size of the Ruby community. Either decide on something that is realistic and keep improving towards the ideal as the community grows, or figure out a way to get enough resources to reach the ideal level.

No review process for patches.

We discuss in Redmine and ML when we change the behavior.

@cwgem:

This is part of a larger discussion going on on ruby-core, twitter and in person.

1. Just a few examples:
   Class A includes module M, module M includes module N after being included in A, N defines method foo. It is not specified if instances of A respond to foo.
   Encodings are not part of the spec.
   Concurrency is not part of the spec.
2. How do I know if something is a regression or intentionally changed behavior, what's the roadmap for language features? Where can I contribute/participate before a change is introduced? What is 1.9 compatiblity?
3. Agreed.

@nurse:
Talk to @brixen about recent changes concerning for instance IO and String interpolation. Also, there are large code parts, esp. in the standard library that behave either different then intended (GServer claims to use a thread pool when in reality it doesn't), untested (again, GServer) or simply make no sense. I know that this is not easy to fix, if at all, I just want to point out that there is an issue worth discussing. There is also an issue for Japanese contributors participating in English discussions and the other way around that is similar hard to fix.

@rkh:
You can request an explanation who introduced a commit. (gserver is too old to be an example)

There is also an issue for Japanese contributors participating in English discussions

What is the issue?

Class A includes module M, module M includes module N after being included in A, N defines method foo. It is not specified if instances of A respond to foo.

I see. This brings up another important point regarding prioritization. A discussion needs to occur on how often cases like these occur, so items that have the greatest impact on a large number of users are presented for clarification first. I'm not sure if such a process is in place, but there does need to be one. Otherwise we're stuck with an overwhelming TODO list.

Encodings are not part of the spec

I raise a flag here because this could require a lot of resources and time dedication depending on how detailed it's made. Before we put anything encoding related in a spec I think there needs to be a comprehensive discussion on how Ruby handles encoding now, and if it's the best way. As encoding could be a potentially complicated subject, we should make sure the architecture itself is solid before spending time writing about how the different processes work.

Concurrency is not part of the spec.

This is a bit tricky to respond to without knowing what areas would be touched upon specifically. Are we just talking about threads and process forking? How will system dependent issue be handled? Windows, for example, does not have fork:

http://msdn.microsoft.com/en-us/library/y23kc048(vs.71).aspx

This is an important point as the level of detail in how system dependent issues are handled could drastically alter the timeline.

How do I know if something is a regression or intentionally changed behavior, what's the roadmap for language features? Where can I contribute/participate before a change is introduced? What is 1.9 compatiblity?

1. How do I know if something is a regression or intentionally changed behavior?

Are there tags/labels for this in redmine to sufficiently address this?

2. What's the roadmap for language features?

Good question. Does this exist at all, even if it's in Japanese? If it's in Japanese just point me to it and I'll translate and post to -core. Of course, this brings up the issue of "what about new features in the future?" I envision the process as something like:

1. A new feature is thought up.
2. A description of how said feature works is written up.
3. This description is posted to ruby-core for discussion. This needs to be done before creating a bug, as new language features often have a good amount of discussion around them. This also helps minimize hidden surprises by getting more eyes on the idea, so we lessen the case of a new feature being further pushed back due to unexpected issues arising.
4. Once the feature has been discussed to the point of where a more solid form of the idea is formed, a bug is created somewhere where voting is allowed. An initial estimate is given on what the target release that contains the feature will be.
5. The community is given a chance to vote on what new features they consider the most valuable. Voting closes when work on implementing the feature begins. This prevents changes in implementation priority later on down the road when backing out of work on a feature becomes extremely difficult. This also gives whoever implements the feature insight into which feature should receive more focus.
6. Implementation work begins, with an update to the target release if necessary. Issues that would push the completion back substantially should be brought up in the bug immediately.
7. Implementation work is completed and announced as part of the changes to the Ruby version affected.

3. Where can I contribute/participate before a change is introduced?

For purposes of addressing the issues, changes should be reported as a bug along with why that change is being introduced. Are there specific instances where this is not happening?

4. What is 1.9 compatiblity?

In what context? Where is 1.9 compatibility mentioned in a way that requires clarification?

@nurse: General feeling of not knowing what's going on. Also, I think that people may seem offensive even if they are not.

@rkh: hmm, it seems FUD.

Sorry, that wasn't my intention, but it was the feeling I got from the RubySpec discussion.

Yeah, I know some people think so, but from such point things won't change.
My recommendation is asking, for example, "Whether this is intended fix or regression?", "Do you have a roadmap?". We'll show you the answer. We are so lazy that we don't work without such request because MRI people are well trained about Virtues_of_a_programmer.

CommonJS doesn't really have widespread adoption. node.js doesn't adhere to CommonJS; the only bits it takes are the Modules implementation, but even that one is tweaked a bit.

This whole write-up is missing one important point: Consistency. Anything great has to be consistent or it will not live for long.