This is an anonymous question sent in by a member who does not want their name disclosed. Please be thoughtful with your responses, as these are usually tough questions to ask and answer.
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (5)
The standard library of a language is a collection of tools you most likely want to use sometimes but not every time you write a program. Those are most of the time to big to include in every program or are some kind of niche ( like "Math" modules). That's why you have to import parts of the standard library each time you want to use them. The standard library is also installed with every copy of the language, thus you don't need to install dependencys if you want to use someones code thats purely build with the standard library. A common example would be Threading, many languages include a way to have multi threaded processes, but you, as a developer, can decide whether to use it or not.
Nice explanation. I'm curious, if anyone has an idea, of how different language creators/maintainers think about the use of standard libraries. Which languages have the most robust standard library vs the ones that are more minimal, (or comparisons across different spectrums) and why that is?
There's a fundamental contention between maintainability/bulk and usefulness.
C++ opted for a minimal standard library for the longest time. It kept the language small, and made it easy to keep those libraries maintained. But for the longest time a lot of basic tasks in C++ were a chore, since there just wasn't a library for them. It really felt like you couldn't make a pure C++ program since there was always something missing. (This has changed in recent years, but it still leans towards minimal)
Compare this to Java that seemed to put everything and anything into the standard library. You could develop things quickly, since everything you needed was there. Over the years however a lot of the API became antiquated. But since it's part of the standard it's stuck there forever, requiring maintenance and guaranteed support. Or you have to deprecate and risk breaking somebody's project.
Languages like Python and NodeJS take the approach of having community supported packages for a lot of featureS (though Python's standard libray is quite feature rich on its own). The package approach is a good way to keep the language easy to use without maintaining a large standard library. It has the drawback that many, potentially essential, APIs are maintained at sub-par quality, and may be abandoned by their developers.
Nobody knows what the the right balance is. It's not likely the same for each language, as it's more domain driven than language drive. Certainly though an easy way to integrate community packages is a huge boon. Having too much crud lying around however, both standard and in the community, hurts everybody though.
Let's use baking a cake as an example. You're a cakemaker, it's what you do. You take a recipe, go into a kitchen, and bake a cake.
Every kitchen is somewhat different: not everything is in the same place, nor is everything always in the same place. But it's possible to bake a cake in all of these, as they have:
This is all the stuff you need to bake a basic cake. You won't get anything fancy, but without all of this you won't be able to bake a cake at all. We call this the "standard library" of cake baking: all the essentials to bake cakes.
If you wish to bake a fancier cake, say with a frosting, cherries, and sprinkels, you'll have to use more than the standard. You might get lucky and have them in your current kitchen, but you can't rely on it. You'll have to make a note in your recipe on how to acquire these items, or to check you have the frosting gun before starting.
The fancier the cake the more likely you need ever more special components or equipment. This isn't part of the standard library since not everybody will need it, and a typical kitchne can't fit all the stuff everybody would ever need. So the "standard library" sticks with the basics, giving room to add more as needed.
LEGOs
When you buy a box of LEGOs pieces you get a bunch of different parts that may vary in shape, size and colors. All these small pieces can be attached to each other in different ways so that you are capable of building whatever your imagination desires.
Wanna make a car?
Go ahead and do it.
Wanna build a house?
You probably can.
How about a fake gun?
Yep. What are waiting for?
All these LEGO pieces can be considered as methods and classes that come pre-prepared by the language you are using so you you don't have to rebuild the wheel every single time you want to make a new project.