Attention to language interop (especially with C) and a decision not to try and be all things to all programmers was another reason for its success - particularly in data science which relies upon heavily optimized numerical processing libraries that are mostly best written in C, C++ or Fortran.
The reason why Unix and Python win is simplicity. For many people simple == better.
Software is so easy to create and mold that many get trapped in excess complexity. Not being able to write complex software on a platform such as Unix or Python is therefore a feature, not a bug. It prevents you from ever getting trapped in the wet sands of complexity.
If there is a silver bullet in software engineering it is simplicity - and aggressive pursuit thereof.
Except that Python is not that. Multiple inheritance: check. Operator overloading: check. Functional programming: at least some of that (for-comprehensions, map, filter, reduce provided by the language). Exceptions: you got it. Coroutines: sure.
Python provides all the rope to 'get trapped in the wet sands of complexity'. Add the lack of static typing and you can write impermeable systems. There are a lot of Python code bases out which are exactly that. Go is a simple language, Python is not.
Worse is better" is a myth
Richard P. Gabriel:
The lesson to be learned from this is that it is often undesirable to go for the right thing first. It is better to get half of the right thing available so that it spreads like a virus. Once people are hooked on it, take the time to improve it to 90% of the right thing.
Or as aptly summarized by Wikipedia:
Therefore, the worse-is-better software first will gain acceptance, second will condition its users to expect less, and third will be improved to a point that is almost the right thing.
Which is exactly the history of Python (and Unix), compared to 'better' languages of the same era. Note that 'worse' is not necessarily used in a derogatory way. It just means that it is often better to get a good-enough, working, simple implementation out there that quickly adapts and spreads, than making that unicorn perfect system. If you look at the early Python versions and how Python spread over the years, it's a prototypical 'worse is better' example.
Go and other languages listed in the original articles on the other hand require you to understand the full complexity before you even begin or spend most of your time deep in documentation if you decide to learn as you go. Static type language simply doesn't allow you to not understand the type system.
This effect is especially enhanced in Scala, Haskell and similar ones where you will not finish a thing until you get a degree in category theory or Odersky theory.
'Worse' might not be intended to sound bad, but it surely does. It seems it is used to describe Unix and Python by that cohort of programmers whose intention is not to get shit done but to develop some mathematical theory of everything.
People who care about delivering results would not call them 'worse' compared to current alternatives in the first place.
There definitely are better alternatives on the horizon and they are better because they bring more simplicity to the table but not at the cost of giving up intuitiveness.
This is simply not true.
>Which is exactly the history of Python (and Unix)
I was thinking Python (and Windows) :v
Isn't that the whole point of worse is better?
To model complex systems you have to keep them as simple as possible.
Imo the answer is that only one mainstream language bothered to emulate MATLAB's plotting API to the best of its ability.
Bitsavers has all the necessary papers and manuals, and computer museum as well.
Here are some video sessions.
"Yesterday's Computer of Tomorrow: The Xerox Alto │Smalltalk-76 Demo"
https://www.youtube.com/watch?v=NqKyHEJe9_w
"Alto System Project: Dan Ingalls demonstrates Smalltalk"
https://www.youtube.com/watch?v=uknEhXyZgsg
"Eric Bier Demonstrates Cedar"
https://www.youtube.com/watch?v=z_dt7NG38V4
"The Final Demonstration of the Xerox 'Star' computer"
https://www.youtube.com/watch?v=_OwG_rQ_Hqw
The end of the road from Plan 9, Inferno.
Of course, out of these, NT did succeed wildly as well did L4 (e.g. iOS secure enclave).
Some improve in the architecture, some in user land, some in both :).
Because very often the best solution does not win, which is why we are still using x86(_64), Unix, etc.
Python is a good example of worse is better. A functional language could provide more elegant abstractions. But for most people the ML APIs that Python provides are good enough. By taking a pragmatic approach, Python was faster to capture some niches, including machine learning and data science. Now we are at a point that even if another language had better abstractions and had similar library support, it would face an uphill battle because of inertia. Why would someone invest in learning another language for machine learning when Python is good enough?
To me it seems that only a language that has both a good model development story and a good deployment story stands a chance to compete with Python, since deployment (especially on mobile/embedded devices) is a weak point of the Python ML ecosystem.