On Saturday, 25 March 2017 at 14:20:53 UTC, Seb wrote:
https://forum.dlang.org/post/phexetutyelrssyru...@forum.dlang.org)
This has struck me from Ilya's post, as a problem that we had at my previous job: code base of old platform too monolithic, not modular enough; which in that case could turn "existing code base" into "legacy code base" too easily as soon as requirements need some flexibility:
On Sunday, 18 December 2016 at 09:26:09 UTC, Ilya Yaroshenko wrote:
3. Dependencies should be clear. Modularity is a proper way for large std library. In phobos everything integrated with everything. DRuntime -> Phobos abstraction is weird for betterC because system modules can depends universal algorithms, but universal algorithm are more portable if they have not system dependencies.
Now I am aware this case is very different. A standard library, specially excluding std.experimental, should have very stable requirements, and it's ok to make everything depend on all of it because it's supposed to stay. But in the past I've argued[1] that D needs for commercial success a much broader standard library than std or the C++ parallel STL, emulating the more modern examples (not regarding language design but just functionality) of Java, Python or .NET.
So I guess what I mean is that for me "std" would be "core", "core" would be "core.core", and I think D should work towards establishing and offer many other different modules, either as part of the standard library, or de facto standard (e.g. vibe, mir... gui??). But this is off topic and unfortunately far into the future. And then in this situation these additional modules could depend on the existing std, but not among each other.
[1] http://forum.dlang.org/post/vzgxlcfxfxzdezrfx...@forum.dlang.org
