What makes a good standard library?
For example, I can _never_ remember if a function in JS or Python mutates a list/object or returns a new copy. Without editor hints this was an annoyance, as I'd have to try it out, check the source, or search the docs. Such issues never happen with a functional standard library (as in Clojure) where you can always assume immutability.
Meanwhile in Clojure, if I've been gone from the language for a while I forget which list functions return a lazy sequence, a seq, or a vector, and I find myself making frustrating errors as a result. Or how some functions (like map and filter) take the collection as the last argument, and a few others take it as the first.
It seems like a poor standard library design requires acquiring much more 'trivia' about the language to be successful, to write performant code, and (sadly) to pass many technical interviews.
What do you think makes a good standard library? A bad one? Do you have any favorite features you'd like to see more of?
3 comments
[ 4.7 ms ] story [ 17.6 ms ] threadI appreciate these qualities in the standard library of Crystal [1], to name an example.
[1] https://crystal-lang.org/api/1.7.0/
* Some form of discoverability. Ideally there'd be good docs available explaining the behaviour of the library in human friendly language, with multiple code examples. Bonus points for making the library open source and linking directly to the implementation from documentation.
* No breaking changes. It's better to create a new library than try and shoehorn a significantly different release into semantic versioning for the sake of it.
* "Escape hatches" for effectful functions to override default behaviour. For example, a HTTP client library isn't going to be very useful if you can't override pretty much any configuration property.
* Being explicit about any side effects resulting from the code, either in naming or by documentation.