3 ms·

I get an allergic reaction to any rationale that includes the tired phrase "easier to reason about". That's on my bingo card right next to "promote synergy"...

by mhd 7y ago

I get an allergic reaction to any rationale that includes the tired phrase "easier to reason about". That's on my bingo card right next to "promote synergy"... Now, I'm not inherently against having small modules for small tasks, but I'd much prefer if those are used like sprinkles on a more solid foundation. So a small Perl module on CPAN? Sure. Your whole web app consisting of small modules, turtles all the way down? No, sir, no. It also means that you've got plenty of build systems, it's incredibly hard to change the output of all your dependencies to not-ES5, it's way more frequent that one developer introduces new dependencies, possibly duplicates etc. Sadly there's no decent way out. JS is getting a new syntactic feature every second Monday, but no big std lib movement is out there that I'm aware of. Sure, you probably wouldn't want to fit the Go/Python/Java core lib into a browser, but for the backend it would be quite nice, and would make tooling for the frontend less fragile. (And to be honest, even frontends are approaching mid-tier desktop UI complexity; otherwise we could've and should've stayed with jquery) I don't need to be able to reason about single modules independent from each other often. I need to trust the whole system enough to not lose sleep over it.

lmm 7y ago
> It also means that you've got plenty of build systems, it's incredibly hard to change the output of all your dependencies to not-ES5, On any realistic sized project you already need tooling for handling dependencies in bulk. If you want to build everything for ES6, that should be a problem you solve once in your build/dependency manager, not per-depednency. > it's way more frequent that one developer introduces new dependencies, possibly duplicates etc. I actually disagree with this: if you have large frameworks then you're more likely to have duplication, because you'll have frameworks that overlap but don't completely cover each other. E.g. C++ projects tend to end up with 5 different string classes, because every framework you use will bring its own (because C++ relies on big heavy frameworks because it has a very high per-library overhead due to limited tooling). Small focused dependencies make that less likely.
- mhd 7y ago
  I don't quite get the latter. First of all, if the foundations are sound and the core language provides a good enough module already, neither large frameworks nor small modules need to duplicate that. And if it isn't included, why would 16 small subsystems have fewer duplicates than 2 large frameworks? By the way, C++ is exactly the trajectory I see JS moving towards. A plethora of different sub-languages and library sets. Only with the difference that it's both easier from a tooling and culture perspective to bring in new tiny modules.
  - lmm 7y ago
    > First of all, if the foundations are sound and the core language provides a good enough module already, neither large frameworks nor small modules need to duplicate that. A language standard library is just another framework - Python's one is famously "where modules go to die", but we see much the same problems in e.g. Boost. A "good enough" solution in the standard library can be worse than nothing, as it means better alternatives struggle to gain enough momentum, and this gets worse as time goes by: functionality that's in the standard library has to evolve slowly. > And if it isn't included, why would 16 small subsystems have fewer duplicates than 2 large frameworks? Because the common things can be in their own small pieces. If a database-access library, a web templating library, and a config parsing library all need to do string manipulation, then if they all implement it themselves we'll see duplication, whereas if they all use an external library then we won't (this is after all the point of libraries). Maybe the ecosystem will have two different string manipulation libraries on the go with one gradually displacing the other, but that's likely to only happen when there's a genuine improvement being made. Whereas if everything's a big framework then eventually everything implements its own copy of the common utilities that just about everything ends up needing - collections, datastructure manipulation, all the really generic stuff.
recursive 7y ago
Deno will have a more substantial standard library. https://github.com/denoland/deno_std https://github.com/denoland/deno_std

by mhd 7y ago

lmm 7y ago

> It also means that you've got plenty of build systems, it's incredibly hard to change the output of all your dependencies to not-ES5, On any realistic sized project you already need tooling for handling dependencies in bulk. If you want to build everything for ES6, that should be a problem you solve once in your build/dependency manager, not per-depednency. > it's way more frequent that one developer introduces new dependencies, possibly duplicates etc. I actually disagree with this: if you have large frameworks then you're more likely to have duplication, because you'll have frameworks that overlap but don't completely cover each other. E.g. C++ projects tend to end up with 5 different string classes, because every framework you use will bring its own (because C++ relies on big heavy frameworks because it has a very high per-library overhead due to limited tooling). Small focused dependencies make that less likely.

mhd 7y ago
I don't quite get the latter. First of all, if the foundations are sound and the core language provides a good enough module already, neither large frameworks nor small modules need to duplicate that. And if it isn't included, why would 16 small subsystems have fewer duplicates than 2 large frameworks? By the way, C++ is exactly the trajectory I see JS moving towards. A plethora of different sub-languages and library sets. Only with the difference that it's both easier from a tooling and culture perspective to bring in new tiny modules.
- lmm 7y ago
  > First of all, if the foundations are sound and the core language provides a good enough module already, neither large frameworks nor small modules need to duplicate that. A language standard library is just another framework - Python's one is famously "where modules go to die", but we see much the same problems in e.g. Boost. A "good enough" solution in the standard library can be worse than nothing, as it means better alternatives struggle to gain enough momentum, and this gets worse as time goes by: functionality that's in the standard library has to evolve slowly. > And if it isn't included, why would 16 small subsystems have fewer duplicates than 2 large frameworks? Because the common things can be in their own small pieces. If a database-access library, a web templating library, and a config parsing library all need to do string manipulation, then if they all implement it themselves we'll see duplication, whereas if they all use an external library then we won't (this is after all the point of libraries). Maybe the ecosystem will have two different string manipulation libraries on the go with one gradually displacing the other, but that's likely to only happen when there's a genuine improvement being made. Whereas if everything's a big framework then eventually everything implements its own copy of the common utilities that just about everything ends up needing - collections, datastructure manipulation, all the really generic stuff.

recursive 7y ago

Deno will have a more substantial standard library. https://github.com/denoland/deno_std https://github.com/denoland/deno_std