std.fileformats?

[H. S. Teoh]

On Mon, Jan 06, 2020 at 11:38:25PM +0000, Laeeth Isharc via Digitalmars-d wrote:
> On Monday, 6 January 2020 at 21:05:37 UTC, JN wrote:
> > On Monday, 6 January 2020 at 19:40:10 UTC, berni44 wrote:
> > > b) Should we instead remove some of these? Probably std.zip is
> > > here the first candidate. (I put some work in it in the last few
> > > weeks, but it would be fine for me throwing this away.)
> > > 
> > > It's on a gut level - just wondering, what you think about this.
> > > 
> > > [1] https://code.dlang.org/packages/std-experimental-xml
> > 
> > IMO all except base64 could be removed. Putting everything into the
> > standard library made a lot of sense in the times before we got a
> > package manager. Nowadays it might be better to simplify the
> > standard library and just have XML, JSON, ZIP, CSV as "blessed"
> > packages.
> 
> Dependencies will be our doom.  Whereas if you use something in Phobos
> then you have some confidence it will still build across platforms in
> a couple of years.
[...]

I agree, recent experiences have led me to the conclusion that
dependencies are a liability rather than a benefit.  The only exception
is if you copy the code into your source tree, and periodically
(manually) update it.  Dependency resolution is NP complete (gives a
whole new meaning to "dependency hell"); that should be a big red flag
that dependencies are something to be avoided where possible, or at
least treated with care, not relished.

Even std.zip has been the source of trouble in the past: users would
install dmd, code away happily, then get slammed with linker errors they
don't know how to resolve.  Eventually, the solution is to bundle zlib
with the dmd distribution packages.  Again, you see, dependencies are a
liability, and the solution is to bundle the dependency with your main
package so that the user never has to do any dependency resolution.

This is why I've found that Adam's arsd libraries have been the best out
of the D libraries out there: his philosophy of minimal (preferably no)
dependencies, and everything bundled in a single source file, has been a
boon. You just copy the source file into the right place in your source
tree, check it in as part of your code repo, and never have to worry
about sudden breakage beyond your control.  Every now and then, just to
stay up to date, git pull Adam's repo and copy the new file(s) over.

Doing this manually may seem tedious in this day and age of instant
gratification, but it's actually a benefit:

(1) Since you manually copy the file(s) over, you're aware of what
dependencies exactly you're pulling in, and (hopefully) are taking
measures to prevent pulling in unnecessary extra cruft;

(2) You will likely have enough sense to make sure your code compiles
with the new version of the file before committing to the repo, thus
avoiding the all-too-common problem of code breakage due to
incompatibility with newer versions of the dependency: if it's checked
in, it compiles, 100% guaranteed. Your buildability does not depend on
the volatile state of some random server somewhere out there on the
Internet.

(3) Your collaborators will never be compiling using different versions
of your dependencies and getting different results, which cause a lot of
headaches trying to track down problems (everyone's build behaves
slightly differently).

(4) Should the upstream authors of the dependency abandon their project,
vanish into the ether, or the dependency otherwise becomes unavailable,
your code will still compile and still work. Again, you remove the
possibility of random breakage caused by random internet outages.
Future readers of your code will appreciate that *all* the code is there
in the repo, without big missing chunks from dependencies that may no
longer exist 10 or 20 years down the road. Even if the code will no
longer compile by then, they can at least still see how it works. (And
if you take this to the logical conclusion, bundling the exact version
of the compiler you used to build the executables seems a logical
possibility that will ensure compilability far into the future, even
after your dependencies' maintainers have long abandoned it.)


After so many decades of academia and industry alike trumpeting code
reuse, I'm starting to become skeptical that perhaps King Code Reuse has
invisible clothes. Dependency hell is a smell suggesting that something
is fundamentally wrong with the concept.


T

-- 
That's not a bug; that's a feature!