3 ms·

2010: The food is poor, the seats are uncomfortable, the wifi is slow, and we're running half and hour late. 1910: We dream of human flight. 2018: So many dep

2010: The food is poor, the seats are uncomfortable, the wifi is slow, and we're running half and hour late. 1910: We dream of human flight. 2018: So many dependencies; so much disk; who can understand why it all exists; how can anyone stay current; how can you trust it all. 1981: We dream of reusable software, of assemblable software components, of sharing.

digitaltrees 8y ago
Absolutely awesome. Is it ok if I use this myself in the future?
- mncharity 8y ago
  Disney/Berne-wise? CC0. Inspired by Louis CK's Everything Is Amazing And Nobody Is Happy. s/reusable software/code reuse/ was the phrase in use.
ryanbrunner 8y ago
I don't totally buy this comparison. People aren't bemoaning that shared libraries exist in the first place, they're arguing that Javascript's particular approach to them isn't great. Javascript didn't invent shared modules, but their particular approach has led to an explosion of libraries with marginal utility, an anemic at best standard library, dependency management that has historically been a big source of problems and still isn't as mature as other languages approaches, disk size explosion due to each individual application storing their own dependencies (and dependencies often storing different version of libraries in their dependencies). You don't see nearly as many arguments with say, Bundler and the gem ecosystem in ruby.
- mncharity 8y ago
  > their particular approach has led to [...] So, paraphrasing part of that: it's too easy for too many people to share too small pieces of their code; and too easy to use them; which reduces the incentives for centralized monoliths? Ok. :P :) I'll agree that javascript's ease and culture of fine-grain sharing raises still regrettably-unaddressed needs for social and technical infrastructure beyond the "1990's CPAN, but now as a github ecosystem" currently in widespread use. > I don't totally buy this comparison. Hmm, so upon reflection, maybe that's right. Consider an "npm code quality can be abysmal" complaint. Which in part unpacks as "I wish it was harder for mediocre programmers to share their code". An analogy for "this airplane, is this slow wifi really the best they could do?" might be "Sorting on aggregate project-level stars is the best we can do? Really? Not even Consumer-Reports-like multi-attribute ratings?" In contrast, an "isn't npm horrible - there's so much bad code" seems more like "abysmal wifi... we should be driving instead". Pointing at the community-wide fine-grain sharing as the problem, rather than at associated technosocial debt, or at renormalized-by-success expectations. Yes, the npm ecosystem has various and serious flaws. But it still seems the closest we've yet managed to come to a large diverse community easily sharing code.

digitaltrees 8y ago

Absolutely awesome. Is it ok if I use this myself in the future?

mncharity 8y ago
Disney/Berne-wise? CC0. Inspired by Louis CK's Everything Is Amazing And Nobody Is Happy. s/reusable software/code reuse/ was the phrase in use.

ryanbrunner 8y ago

I don't totally buy this comparison. People aren't bemoaning that shared libraries exist in the first place, they're arguing that Javascript's particular approach to them isn't great. Javascript didn't invent shared modules, but their particular approach has led to an explosion of libraries with marginal utility, an anemic at best standard library, dependency management that has historically been a big source of problems and still isn't as mature as other languages approaches, disk size explosion due to each individual application storing their own dependencies (and dependencies often storing different version of libraries in their dependencies). You don't see nearly as many arguments with say, Bundler and the gem ecosystem in ruby.

mncharity 8y ago
> their particular approach has led to [...] So, paraphrasing part of that: it's too easy for too many people to share too small pieces of their code; and too easy to use them; which reduces the incentives for centralized monoliths? Ok. :P :) I'll agree that javascript's ease and culture of fine-grain sharing raises still regrettably-unaddressed needs for social and technical infrastructure beyond the "1990's CPAN, but now as a github ecosystem" currently in widespread use. > I don't totally buy this comparison. Hmm, so upon reflection, maybe that's right. Consider an "npm code quality can be abysmal" complaint. Which in part unpacks as "I wish it was harder for mediocre programmers to share their code". An analogy for "this airplane, is this slow wifi really the best they could do?" might be "Sorting on aggregate project-level stars is the best we can do? Really? Not even Consumer-Reports-like multi-attribute ratings?" In contrast, an "isn't npm horrible - there's so much bad code" seems more like "abysmal wifi... we should be driving instead". Pointing at the community-wide fine-grain sharing as the problem, rather than at associated technosocial debt, or at renormalized-by-success expectations. Yes, the npm ecosystem has various and serious flaws. But it still seems the closest we've yet managed to come to a large diverse community easily sharing code.