4 ms·
"The Ruby community, at least in the US, has proven to be very open to change, see Rails 1, 2 and 3 for example. " That's change? That's like saying you've mo
by jamesbritt 16y ago
"The Ruby community, at least in the US, has proven to be very open to change, see Rails 1, 2 and 3 for example. "
That's change?
That's like saying you've moved from sliced cheese to cheese on white bread to grilled Swiss on toast, and claiming to be open to new tastes[0].
Were there a real appetite for change there would be far more enthusiasm for the dozen+ Ruby Web frameworks instead of the increasing Ruby is Rails is Ruby mantra.
(There's a selection bias in my observation; people open to change often don't self-identify as <language>-ists; they're busy using a variety of languages and libraries. The "Rubyists" open to change are using Clojure, Haskell, Lua, and Go. :) )
Referencing Chad Fowler is sort of ironic, given that he had stood before a Ruby conf crowd and told people to stop working on Nitro; Rails had "won", so there was no need for a competing framework.
Why not declare that REXML "won" (it's in the std-lib after all), that we don't need competing libraries, and leave it at that? Because, as with Web frameworks, that would be stupid.
It's worth noting that REXML got added to the standard lib because of the belief that Ruby should "do XML" out of the box. I have no idea if that's still a compelling argument, though enthusiasm for anything XML has, let's say, diminished. Assuming the low friction of installing gems as needed, and advances in non-std lib gems, it's really hard to argue for keeping it in. But REXML was a gem at the time of its inclusion, there was no great love for XML, and people still wanted to bundle it in.
None of this is new; the debate started as soon as rubygems was reasonably stable, and perked up again once rubygems was moved into Ruby proper. The biggest arguments against splitting out the std lib were that some people work under constrictive code installment policies (so just grabbing gems as needed can be an issue), and that there is an advantage to vetting broadly useful libraries to ensure they play nice with the rest of the core code (i.e., you don't end up with a DB lib that modifies Object or Class with surprising results).
[0] It also reminds me of a line from "The Blues Brothers", "Oh, we got both kinds [of music] -- country and western"
- FooBarWidget 16y agoYes, that's change. With "change" the author meant API-breaking changes, not fundamental paradigm changes. The latter is irrelevant for the point he's making.
- jamesbritt 16y agoWhat API-breaking changes? Moving a library from stdlib to a gem doesn't change the API of the library. About the only difference is having to invoke rubygems before the require. However, changing what people can expect by default in a standard Ruby installation is more of a paradigm change (albeit not terribly grand).
- FooBarWidget 16y agoAPI breaking changes such as Rails 2 -> Rails 3. Read the article.