I like dlang but i don't like dub
first.last at gmail.com
Sat Mar 19 20:32:50 UTC 2022
On Friday, 18 March 2022 at 04:13:36 UTC, Alain De Vos wrote:
> Dlang includes some good ideas.
> But dub pulls in so much stuff. Too much for me.
> I like things which are clean,lean,little,small.
> But when i use dub it links with so many libraries.
> Are they really needed ?
> And how do you compare to pythons pip.
> Feel free to elaborate.
DUB changed my programming practice.
To understand why DUB is needed I think it's helpful to see the
full picture, at the level of your total work, in particular
### An example
My small software shop operation (sorry) is built on DUB and if I
analyze my own package usage, there are 4 broad categories:
- Set A. Proprietary Code => **8 packages, 30.4** kloc
- Set B. Open source, that I wrote, maintain, and evolve => **33
packages, 88.6** kloc
- Set C. Open source, that I maintain minimally, write it in
part only => **5 packages, 59.1** kloc
- Set D. Foreign packages (not maintaining it, nor wrote it.
Stuff like arsd) => **14 package, 45.9** kloc
=> Total = **224 kloc**, only counting non-whitespace lines here.
This is only the code that needs to be kept alive and maintained.
Obviously code that is more R&D and/or temporary bear no
Set A: ooo 30.4 (proprietary)
Set B: ooooooooo 88.6 (open-source)
Set C: oooooo 59.1 (open-source)
Set D: oooo 45.9 (open-source)
### What is the cost of maintaining all that?
At a very minimum, all code in A + B + C + D needs to build with
the D compiler since the business use it, and build at all times.
Maintaining the "it builds" invariant takes a fixed cost m(A) +
m(B) + m(C) + m(D).
Here m(D) is beared by someone else.
As B and C are open-source and maintained by me, the cost of
building B and C for someone else is zero, that's why ecosystem
is so important for language, as a recurrent expense removal. And
indeed, open-source ecosystem is probably the main driver of
language adoption, as a pure capital gain.
Now consider the cost of evolving and bug fixing instead of just
=> This is about the same reasoning, with perhaps bug costs being
less transferrable. Reuse delivers handsomely, and is cited by
the Economics of Software Quality as one of the best driver for
increased quality . Code you don't control, but trust, is a
driver for increased quality (and as the book demonstrate:
### Now let's pretend DUB doesn't exist
For maintaining the invariant "it builds with latest
compiler", you'd have to pay:
m(A) + m(B) + m(C) but then do another important task:
=> Copy each new updated source in dependent projects.
Unfortunately this isn't trivial at all, that code is now
duplicated in several place.
Realistically you will do this on an as-needed basis. And then
other people can rely on none of your code (it doesn't build,
statistically) and then much fewer ecosystem becomes possible
(because nothing builds and older version of files are
Without using DUB, you can't have a large set of code that
maintain this or that invariant, and will have to rely to an
attentional model where only the last thing you worked on is
DUB also make it easy to stuff your code into the B and C
categories which provides value for everyone. With DUB you won't
have say VisualD projects because the cost of maintaining the
invariant "has a working VisualD project" would be too high, but
with DUB because it's declarative it's almost free.
 "The Economics of Software Quality" - Jones, Bonsignour,
More information about the Digitalmars-d-learn