|
|
|
|
|
by jrockway
1283 days ago
|
|
Once things are in the standard library, they're basically impossible to remove, unless you want to break everyone's code and prevent them from updating. If you're making a new programming language today, the standard library is a place where you should think very carefully about everything you add. Every programmer learning the language will have to be familiar with the standard library, so keeping it small is good. But too small, and programmers will always have to reach for third-party packages without maintenance or stability guarantees. For example, you don't want to have to choose among 5 different libraries to write and run unit tests; the language should define that and it should meet everyone's needs (or be extensible with a small third-party library). I think the Rubys and the Perls of the world probably choose too much to add to the standard library, and that's where the comment you're replying to comes from. But, while it's easy to overdo the standard library, it's also bad if you underdo the standard library. Tough and sometimes under-considered aspect of language design. |
|
Back in the day Ruby had built in language features (e.g. Innumerable), and a standard library that was bundled into the distribution (e.g. GServer).
More recent versions of ruby have significantly streamlined the standard library, pushing a lot of the functionality into Gems (libraries). Given that the use of a Gemfile to list library dependencies is absolutely standard practice, the upgrade path simply involves adding a line to the Gemfile.
In practice, these changes have been very well signposted before they have happened.