On Tue, 21 Oct 2014 15:37:59 +0200, Sönke Ludwig wrote:
Am 21.10.2014 15:22, schrieb Angst:
On Tue, 21 Oct 2014 10:38:14 +0200, Sönke Ludwig wrote:
Am 20.10.2014 18:12, schrieb Angst:
Don't underestimate the usefulness of trivial/small pieces of code!
Take the grunt plugins:
You could classify a lot of these node modules as trivial: actual code (excluding tests) being around 100 lines. But they are well tested and without them grunt would not be possible.
Standing on tiny shoulders is still nice ;)
Sure, but it also comes at a cost:
Let me reply from my limited experience with npm front-end web dev.
- Selecting the right package may cost more time than writing the code
itself if there are many alternatives
"Search by popularity/starred"-on-by-default seems to fix this problem for grunt.
Become the most used module or die in the long-tail.
I personally haven't done much in this direction, but I've read some
postmortems where the developers have gone through a number of packages,
only to discover that they'd better written the code themselves from the
start. But you are right of course, it always depends a lot on the
- It increases the chance for unintended license violations when
different licenses are involved and a project has dozens of dependencies
There is a module for that:
But on a whole people tend to not really care and expect everything to be MIT or something alike.
It's loosely planned to integrate a license checker directly into DUB.
This will hopefully avoid this issue for the most part.
- It increases the chance for version conflicts when e.g.
"trivial-pack-a" depends on the same dependency "pack-c" as
"trivial-pack-b" (maybe indirectly), but accepts a different
version(range) for that package
Npm solves this by making all dependencies local:
or, in your case:
Unfortunately this won't work for D, as it may result in both compiler
errors (conflicting imports) and linker errors (duplicate symbols).
Would be nice though :)
- It increases the maintenance friction (e.g. you have to wait for all
dependencies to fix compilation on the latest DMD version and you may)
I am not sure how much of a problem this is for npm.
Personally I haven't had any such problems but I haven't been using npm that long either.
Could be a real problem for D(UB).
Yeah, at least the language is stable in case of NPM. But it also
applies to the underlying libraries. For example if vibe.d introduces
breaking changes and several libraries rely on different versions of it.
Of course this is an issue even for bigger libraries, but the chances of
conflicts increase with the number of dependencies.
So it's a nice thing to have in principle, especially for rapid
prototyping, but I'd definitely rather prefer a library that manages a
bunch of trivialities under one umbrella to avoid the above issues.
There are always exceptions of course, though!
If search-by-popularity would be on by default and most people agree with your mindset, then all the trivial modules would die in the long-tail. But first, lets give the trivial modules and giants a place to have a real fight ;)
Well, my hope and reality aren't necessarily the same thing, so I'm sure
that there will be enough small packages ;)
Looking forward to the "monthly downloads" column on code.dlang.org ;)