The Python library maintainers did exactly what you suggest, and they're still in the situation that they're in. The standard library is poorly maintained for exactly this reason.
A smaller core remains relevant, and is better maintained as a result.
Conversation
No, they didn't do anything close to what I suggest. The standard library was poorly thrown together and not thought out in the first place, and then they lost interest in improving it. They don't want a rich standard library anymore and aren't an example of trying to provide it.
1
Sure they did. They stopped doing it for python3, but Python 2 had several redundant libraries. Like urllib2.
1
They hardly did any of that and it's also not what I'm suggesting. I'm not sure why you're so interested in arguing against a strawman. Python is an example of what I'm suggesting is a good approach. It's a counterexample showing how to do things very poorly.
1
Well, do you have any examples of it being done the way you want it done?
1
Sure, Android's standard libraries along with the Kotlin language and standard libraries. It's an extremely broad and feature rich set of APIs. The platform has a versioned API level with yearly deprecations and removals. Evolves over time without legacy/abandoned apps breaking.
2
You're talking about two different projects, one of which is VERY platform dependent. I can (and do) use Kotlin for much more than Android.
Do you have any examples of a programming language's standard library that offers what you want, without a platform SDK?
1
Kotlin language and standard library take the same approach to gradually evolving without strict backwards compatibility. They avoid making sudden, drastic changes but rather slowly evolve it over time with easy to handle incremental backwards incompatible changes. Same approach.
2
Android's platform libraries and AndroidX Jetpack libraries (developer.android.com/jetpack/androi) certainly count as a form of standard library. The approach is dramatically different than the path taken by traditional platforms.
2
When you're writing an Android app, the Kotlin / Java standard libraries, AndroidX and platform libraries cover nearly everything you need so you hardly need any third party libraries. Java's approach hardly ever actually removes anything in practice so it's not really the same.
2
Still, Java has a rich standard library and they gradually replace the older libraries with newer ones. Jakarta is essentially an extended standard library from outside Java with a similar stability approach. It's one large collaborative project with a lot of bureaucracy.
There are a whole bunch of Jakarta libraries, from the same very collaborative and highly trusted project. It isn't part of Java's standard library, but it's a similar approach nonetheless. It's much different than a bunch of little projects developed by small independent groups.
2
Right, but that's not what you were arguing for. You were arguing for a large standard library, not a high quality group of non-standard libraries.
Heck, Rust has that! (sort of, it's getting better).
1
Show replies
Java has one of the best backwards compatibility stories in the business. If it's a published SDK (java, javax), then it's staying around.
And they have the same problem Python has. People reach for tools other than the ones in the standard library all the time.