A lot of people care. It costs $3500 per server to run Zing Java. Every user of Zing cares enough to pay $3500. Everyone who has written an Android app cares about the distinction too. Dalvik has different quirks than regular Java. (EDIT: Oh boy, that shows how out of date I am. Apparently Android is now using Android Runtime instead of Dalvik....)
> If they need to find another implementation, it's possible, but there's no question about what the default implementation is.
The implementation can, and does, change without the language changing. That's the unfortunate truth about real world deployments. As such, you need a unique name for the interpreter.
> A lot of people care.
Both of these claims are true, but yours is missing the point.
You grow a userbase by appealing to people who don't use or understand your product. People who are already invested to the point of spending $3500 for a custom VM aren't the ones you're trying to clarify things for by using consistent branding.
That's the problem.
And it always had a single official and complete reference implementation in the form of the Sun JVM and later the OpenJDK. kbensons description makes it look as if Perl 6 had/has neither.
> And "Dalvik", for all the Android fans
Dalvik was intentionally incompatible in many ways and wont run a spec conform jar no matter how hard you try. Might as well call CPython a Perl implementation.
> Python has CPython 2.0, CPython 3.0
With CPython X being the official reference implementation for the corresponding language version and all other implementations being incompatible to varying degrees.
It had and has a spec. It's been evolving over time though. It was ambitious enough that no one implementation ever fully implemented it until recently, if ever (I stopped following the project actively a few years back. I'm not sure if any current implementation is fully compliant). That's not a surprise, it's an amazingly complex set of features that are describes, and there's many specs that are never fully implemented, and it's not uncommon to have an aggressive specification run up against reality when people try to implement it. For example, I've heard that the IMAP spec has never been fully implemented, or at least the later ones versions of it.
So, they have a spec, and have had one for a very long time. They have implementations that do the vast majority of the stuff you'll want from that spec, and they've been in that state for a few years.
True though even in the mid to late 90s there were other JVMs available from companies such as Microsoft and IBM. In fact for a period, Sun’s JVM was one of the worst implementations despite being the reference implementation.
...and IronPython, Cython, PyPy, PythonNet, MicroPython, probably plenty more I'm forgetting.
Python 2.x language has several implementations CPython (the reference implementation), Pypy, Jython, IronPython.
Python 3.x language also has several implementations CPython, Pypy
Cython understands Python but it is not Python (I don't know whether it is a strict superset).
MicroPython implements some subset of Python 3.4 (mostly)
It does have multiple compilers for java, at least javac and ecj (eclipse compiler for java) http://blog.deepakazad.com/2010/05/ecj-eclipse-java-compiler...
And if you consider groovy and scala and kotlin it has many more compilers.
JustInTime, HotSpot, Swing, Beans, etc.
That's not really a great comparison. There is one single organization that both defines what python is and implements a compiler/interpreter for it, and that is all you would ever need to know to use it. No ambiguity.
For the most part, language specs are either bundled fairly tightly with a reference implementation, or have a completely different name. (e.g. ECMAscript, SQL)
Bad example: Java actually has many VMs available for it: Oracle, OpenJDK, Zing, and IBM come to mind. (EDIT: And "Dalvik", for all the Android fans). I'm unsure if Java has multiple compilers, but its quite possible.
Python has CPython 2.0, CPython 3.0, and Jython at least. Probably a few others.
When Perl 5 was huge, there were multiple VMs and interpreters: IronPerl comes to mind as a Windows implementation back in the day that had different quirks than the canonical Perl interpreter.