3 ms·
one way to approach this with compromise is to keep the shipped standard library small, but have officially maintained packages from the language foundation for
by no_wizard 3y ago
one way to approach this with compromise is to keep the shipped standard library small, but have officially maintained packages from the language foundation for exceedingly common functionality.
That gives an avenue for exploration, and tight controls and quality control on packages, without bloating the standard library.
- MBCook 3y agoWhat’s so bad about “bloating the standard library”? Java has an incredible amount of stuff and it’s incredibly useful. The compiler should be able to eliminate the unused parts during compilation, it’s not like adding JSON to the standard library is going to make a “hello world” program bigger.
- shit_game 3y ago>The compiler should be able to eliminate the unused parts during compilation, it’s not like adding JSON to the standard library is going to make a “hello world” program bigger. I agree. I would argue against keeping standard libraries terse as an appropriate goal for a language because terse (or alternatively, inadequate) standard libraries are exactly what necessitate third party libraries for common functionality, which in turn lead to this dependency hell that so many people dislike so much. Not to say that a standard library should do absolutely everything, but the more capable a language is out of the box, the fewer third party libraries a language ecosystem will come to rely on, meaning that methodologies will be more consistent in more code and dependency management will be simpler.
- theLiminator 3y agoMostly because it holds the language back due to backwards compatibility concerns.
- theLiminator 3y agoI wish languages took this approach, not sure why they largely don't.