On Wednesday, 11 November 2015 at 17:19:31 UTC, David Nadlinger
wrote:
Of course, many of the problems could have probably been
avoided if there was an iron-clad rule that the module
dependency graph must remain acyclic from the beginning of
development (at least at the level of units of compilation).
But how could they have known how bad it would get otherwise? I
don't think this is reflected in our documentation anywhere, at
least not in a prominent place.
— David
There is some literature about whether this kind of rule,
enforced at compile-time, can benefit software architecture in
general, in the context of F# projects vs. similar C# projects.
(Answer: probably yes - there's a relationship between cyclical
dependencies and other accidental coupling; you can make some
case for it both theoretically and in statistics)
http://evelinag.com/blog/2014/06-09-comparing-dependency-networks/#.VkP6mL_eNYU
Looking at what D does now, at least according to "The D
Programming Language" (2010), it tries to allow any ordering but
throws an exception at runtime when ambiguious cases are
detected. So there's already some precedent to avoid cyclical
dependency simply to avoid those errors. The coupling argument
and the compile-times argument just add more urgency to it.
Nim enforced the same dependency rule as F# the last time I
looked, but I think that position was softening towards
"optional" due to some community pressure. I don't think anything
makes this architecture style actually impractical and it might
help to have the compiler warn towards it - although the same
kind of community pressure is going to arise if it did do so.
After all, nobody likes to be told that they are writing Bad Code
:)
