4 ms·

A while back, while I was a doing Ruby, I remember a discussion that came up regarding moving some of/all of (can't remember) the standard library to Gems so th

A while back, while I was a doing Ruby, I remember a discussion that came up regarding moving some of/all of (can't remember) the standard library to Gems so that, as you say, they could "evolve on their own schedule". It'd be interesting if standard libraries of languages adopted this approach. A release of a language would then become the interpreter/compiler and set of vendored libraries deemed the standard library. Then, in projects, if say, the path module gets updated with new features, I can include that version and not wait for the next major/minor release of the language to get new features/bug fixes.

troygoode 13y ago
node.js follows this pattern relatively strictly (the standard library is quite small, with everything else pushed into userland)
Chris_Newton 13y ago
The term “standard library” has a second interpretation that is increasingly relevant in modern programming: as well as meaning “the [one true] standard library”, it could also mean “the library of standards”. It doesn’t necessarily have to provide its own tools. It can also define conventions and frameworks that establish a baseline for interoperability that everyone else’s tools can work with. I don’t believe it’s realistic to create a standardised toolbox when every new language come along and expect everything in it to still be a good way of doing things ten years later, as requirements change and new ideas come along. This is probably why so many languages today have at least a de facto standard place where you get other libraries when you need them: PyPI, CPAN, Boost, etc. On the other hand, there are many recurring themes that appear in those libraries, particularly in the interface they offer and their overall design: basic data types and data structures, application-specific concepts like windows and database connections and file formats, architectural tools like publish-subscribe mechanics and test hooks. Standardising these common ideas, so it’s as easy as possible to connect up libraries from different sources or to replace one library with another, offers many benefits in efficiency and maintainability for a programming language’s ecosystem as a whole. We already see examples of this being done: many languages have a somewhat standardised interface for connecting to SQL-based database engines, for example. We also see some unfortunate examples where it wasn’t done quickly enough, such as the myriad string types everyone defined in C++ because there was no standard type for so long. I suspect the most successful programming languages of tomorrow may not have anything like as many tools available “out of the box” as Java and Python and C# do today. However, if I were a betting man, I’d wager they will all provide solid foundations for managing third party libraries and much better frameworks and conventions for interoperability between those libraries.

troygoode 13y ago

node.js follows this pattern relatively strictly (the standard library is quite small, with everything else pushed into userland)

Chris_Newton 13y ago

The term “standard library” has a second interpretation that is increasingly relevant in modern programming: as well as meaning “the [one true] standard library”, it could also mean “the library of standards”. It doesn’t necessarily have to provide its own tools. It can also define conventions and frameworks that establish a baseline for interoperability that everyone else’s tools can work with. I don’t believe it’s realistic to create a standardised toolbox when every new language come along and expect everything in it to still be a good way of doing things ten years later, as requirements change and new ideas come along. This is probably why so many languages today have at least a de facto standard place where you get other libraries when you need them: PyPI, CPAN, Boost, etc. On the other hand, there are many recurring themes that appear in those libraries, particularly in the interface they offer and their overall design: basic data types and data structures, application-specific concepts like windows and database connections and file formats, architectural tools like publish-subscribe mechanics and test hooks. Standardising these common ideas, so it’s as easy as possible to connect up libraries from different sources or to replace one library with another, offers many benefits in efficiency and maintainability for a programming language’s ecosystem as a whole. We already see examples of this being done: many languages have a somewhat standardised interface for connecting to SQL-based database engines, for example. We also see some unfortunate examples where it wasn’t done quickly enough, such as the myriad string types everyone defined in C++ because there was no standard type for so long. I suspect the most successful programming languages of tomorrow may not have anything like as many tools available “out of the box” as Java and Python and C# do today. However, if I were a betting man, I’d wager they will all provide solid foundations for managing third party libraries and much better frameworks and conventions for interoperability between those libraries.