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.

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.