[toolslive]

You can say the same about Python. However, there the forces push in the opposite direction: Even when there are better pythony runtimes that provide almost identical behaviour (but better performance), everybody sticks to CPython.

[al_borland]

I tried to use non-CPython just last week for the first time. The first thing I tried to install failed. When I looked up the error… I needed CPython.

In my limited experience, I can only assume people are sticking to CPython because it works. Speed doesn’t mean much if libraries and tools fail to function.

[Groxx]

I've seen tons of non-cpython use, so I'm not really sure what claim you're trying to make. Aside from supporting "having a spec allows for many implementations that all work".

[toolslive]

Well, the original comment was implying org mode had limited popularity because there is no specification. I'm claiming cpython is way more popular compared to fe pypy because it has no spec. The typical scenario is: people try pypy. it mostly works but because of some weird problem some library is broken and then they give up.

[Groxx]

Is the claim that pypy has no spec, but cpython does? By that definition I think either both have a spec (they both use https://docs.python.org/3/reference/index.html and both are just "an implementation") or neither has one (since neither fully specifies all behavior and all modules, which is probably true for ~all languages).

[toolslive]

No. The claim is cpython has no spec. The link you posted is about the language. The spec claim is about the behaviour of the runtime.

The underlying claim is hat pypy cannot succeed precisely because there's no clear definition of success/compatibility/compliance. The situation is completely different in the Java world. There there is a specification for the memory model, runtime, aso and you can be sure that when you switch between runtimes, it will just work.

[Groxx]

Gotcha. Broadly agreed then (Java is a very good counter-example), though I think pypy might be succeeding quite a bit more than org-mode in terms of users... and org-mode doesn't have a language spec either afaict. It has a fairly good description of the current code's parsing behavior, but the closest I've seen to something rigorous is https://github.com/200ok-ch/org-parser and even that's still unfinished from the readme (and it seems probably abandoned).

I haven't looked into the actual current state of things though, my last check was a couple years ago. I'd be pretty happy if things have changed, I just haven't seen any sign of that.