How did Ruby and Python prevent fragmentation while ML and Lisp did not?

I don't think Ruby should be compared to ML. I think Ruby should be comared to OCaml. ML, if it gets compared against anything, should be compared against the category that includes Python, Ruby, Perl, and JavaScript. This category is about as fragmented as Lisp.

The problem with this new category is it doesn't have a simple, clear definition. Lisp is pretty much defined by S-expressions, and MLs by their type systems. This new family might be defined by their common approach to object systems (i.e. objects as dicts), although that's really more representative than fundamental.

[1] I'm under the vague impression that Common Lisp and SML are somewhat more fragmented than other members. I wonder if this correlates to their being the "Common"/"Standard" dialects.

For example, you can say that ML fragmented into SML and OCAML, but then what's Haskell? Is it a fragment of SML? Well, not really. But then, SML and OCAML are significantly different languages, which have taken their inspiration from sources outside of their "parent language" as well.

On top of this, look at, for example. Boo. Boo is a lot like Python, but is it a fragment of Python? Also, C, C++, C#, Java, now even Go.

I think the point of this is what is the point at which a new language becomes no longer a "fragment" of its parent, and becomes a new language in its own right?

or maybe I'm wrong :)

In the case of Python, there are such dictators. With Ruby, it was less the dictator and more the dictates of a poorly defined language specification. "The spec is this running C code" is thought by many to be a smell. (Also said for VP8.) In the case of Ruby, multiple groups of several people each worked for long stretches of time (half a year or more) to come up with parsers and non MRI specifications for Ruby syntax.

Conversely, one can implement Lisp or Smalltalk syntax quite quickly, which means the barrier to fragmentation is pretty small. Python is still fairly small. I think that there would be more fragmentation without its benevolent dictator.

Widespread internet access, along with the tremendous utility that the internet holds for developers, strongly encourages the concept of a canonical implementation of a language, in a way that simply didn't seem nearly so important 20+ years ago.

(It's also interesting that the internet encourages this notion of canonical implementation even while simultaneously encouraging the creation of forks.)

Scheme seems fragmented because a lot of research work use it as the primary tool. For example, you have languages like Larceny which were primarily designed to study Garbage collections or even probabilistic language models using Church Scheme.

The ease in which Lisp and Scheme allows you to create new languages and perform exploratory work has spawned a lot of newer implementations.

And People also come up with newer implementations for a specific goal in mind. For example, Bigloo Scheme was created in order to enable Scheme programming style where C(++) is usually required.

Ruby and Python (and Perl, etc.) are languages for pragmatists. Their user communities are overwhelmingly dominated by folks who've got a practical problem to solve, and primarily see the language as a tool to help solve that problem. They also tend to be rather "CISC"-y, which makes trying to customize them less attractive because complicated things are harder (and often less fun) to tinker with.

Lisp and ML (and Forth, etc.) are languages for language geeks. They might see a lot of practical use, but they're also popular as a solid working base from which to experiment with new language ideas. And they benefit from being fairly small and orthogonal. Most fans of languages in this camp have written their own implementation of their language of choice - partially out of being a language geek, and partially because their specs are clean enough that doing so isn't a very intimidating prospect.

You could say that both Python and Ruby are instances of Lisp's fragmentation, rather than unfragmented alternatives. (I am not a Lisp programmer, BTW.)