std.compress

[Jakob Ovrum]

On Wednesday, 5 June 2013 at 07:39:12 UTC, Jonathan M Davis wrote:
> Maybe some do, but many don't, and 1000 lines is _far_ from too 
> much. If we
> start making modules that small, we're going to end up with 
> tons of them to
> wade through to find anything.
>
> - Jonathan M Davis

We have a standard library in disagreement with the language's 
encapsulation mechanics. The module/package system in D is almost 
ignored in Phobos (and that's probably why the package system 
still has all these little things needing ironing out). It seems 
to owe influence to typical C and C++ library structure, which is 
simply suboptimal in D's module system.

Third-party libraries tend to do a much better job at this. For 
example, Tango goes all out and embraces the package and module 
system, and the result is an extremely organized tree of modules 
with appropriate granularity. Code isn't hard to find because 
everything isn't just dumped into (bloated) blobs in a flat 
structure like in Phobos; it's organized into a tree. It seems 
like a no-brainer with the D language, and Phobos is the only D 
library I know that doesn't embrace this style of organization. 
The result is awful coupling throughout; with Phobos, we can't 
even write Hello World without pulling in half of the standard 
library.

It's not just about the actual dependencies a module has, but the 
perceived dependencies; important from a readability perspective. 
I know a lot of D programmers embrace selective imports when 
working with Phobos, because just seeing a plain import statement 
such as "import std.datetime;" tells you very little about what 
the importing module actually does, and it's harder to figure out 
exactly where unqualified symbols come from when reading the 
module's code.

I think the programmer should have a choice of convenience versus 
readability/fine dependency management when importing. The 
current module system does a decent job at enabling this already, 
and it's bound to get better with improvements like DIP37. 
Scripts and certain application code may want to prioritize 
productivity over finely managed dependencies, while library code 
- especially the *standard* library! - should definitely aim for 
lean coupling that makes sense.

To that end, I think a lot of improvements can be made without 
breaking user code, but I'd be very much willing to see all kinds 
of breakage if it means we can get rid of the present standard 
library of substandard quality. The language may have been 
declared stable, but Phobos is in no laudable state.