I don't program in Ruby but every time I look at it I see something different depending on who wrote the code and what their personal style is. It seems like it has every syntax in there somewhere.
IMO that's one of the biggest weaknesses of Ruby. The language offers lots of different ways to do the same thing. You can say that makes the language more expressive. Sure, but it also means as a newcomer, there's a lot more language features to learn about. It makes the language less approachable to outsiders.
Python and Ruby occupy similar niches. Python has many more libraries, so people will say, that's why Python has been more successful, but IMO, even if Python and Ruby had as many useful libraries, most people would still choose Python, because it's a simpler and easier to learn language. That may have contributed to Python getting a headstart in the beginning.
I'm sure some people would say that's a case of "worse is better", but I think you also have to have some empathy for other programmers. When collaborating on a programming project, having a project that is easier for others to understand is easier. Having a language with less weirdness, less peculiarities and less complexity is a plus.
I think it’s much simpler than that. Ruby didn’t have good documentation in English until the mid-2000’s. Python was in use by the English-speaking world before the turn of the century. Documentation + you can generally understand it at a glance == total Python dominance.
Looking at recent Python code, it also seems like the simplicity is being lost in the rush to add features.
> Looking at recent Python code, it also seems like the simplicity is being lost in the rush to add features.
My inkling is that this is because it is hard to have a general purpose language that lends itself to both novices and experts, and to small scale and large scale. Not impossible, but hard. Those categories desire/need different things, and will use the language in vastly different ways.
BASIC (for all its problems) was a better first language for many people than C or Fortran, but BASIC also didn't scale well to larger systems (structured variants scaling better). Then you start getting BASICs supporting OO and other features which complicate them and lose the appeal to novices, but more effectively meet the needs of intermediate-to-advanced users and maintainers of medium-to-large scale systems.
See also Pascal and its evolution. From a small language to a still small but not as small language in Delphi and others. For the novices, they can still use that small core. But it's now harder for them to onboard with a larger project or a project developed by more advanced users of the language. Especially as the standard library (for the language implementation, if not the language proper) grows.
Scheme, over the various revisions, has seen a similar conflict, culminating in the effective rejection of R6RS and the division into small and large for R7RS.
And those are languages that were largely meant to support novices and learners. Python started off similarly. Now it's older, and its users have aged, and they want to do more powerful things with it and maintain larger and larger systems with it.
On the small vs large side, look at the evolution of JavaScript. It was literally meant for in-page scripting, to do small things and not be the larger system, but a mere component. Like a shell script that copies two files contrasted with the actual OS or shell implementation. But now 25 years or so later it's a vastly different language, and people are building distributed systems on top of it.
You could create nice GUI programs with Delphi with just basic Pascal knowledge, you didn't even have to know about pointers, initializers, virtual functions, templates or any of the crap that comes with C++.
My point with it, though, is that even though you could still use that straight-Pascal core, the language (Delphi) permits more. Which, I presume, many if not most advanced users and large system maintainers took advantage of (my time with it was brief, and I did only use/learn the core Pascal parts).
Python is the same way, there is still (and always has been) a core that is particularly well-suited for novices and a slightly larger core that is sufficient for any small-to-medium system. But as you gain expertise and want to use the language to do other things, or to develop larger systems, you will likely exceed that core. Delphi with Object Pascal was similar. You could still use that core, and accomplish a lot (same with Python), but you cannot guarantee experts or larger systems won't exceed that core.
And that's the language dilemma: How to appeal to both novices and experts, small and large system maintainers? The features that each will want or need are different. Go stayed pretty stable for a decade and kept to its mostly small core, but even it has added generics now because people (maintaining larger libraries, in particular) are chafing under its present constraints. And with these changes, you'll see a (potential, may not happen I suppose but I'd be surprised) major shift in the way the language is used by more expert users that pull it away from its previous model.
You're probably right about the availability of documentation, but I also think Python is much easier to generally understand at a glance. Less features, less quirks means the language is easier to learn.
I don't program in Ruby but every time I look at it I see something different depending on who wrote the code and what their personal style is
I'd say this is a plus, at least in certain dimensions. One of the best descriptions I've heard of Rails' ActiveSupport (a collection of extensions to built-in types included in Rails) is as a dialect of Ruby, one specific for developing web applications. Other domains could and should use different dialects.
That's a problem with LISP-style languages too. Too much flexibility and dynamic syntax leads to write-only languages, or at least languages that are write-only-by-the-original-author.
You can see the opposite end of that spectrum in Go, which can be readily read by anyone since there's generally only one good way to do anything.
