Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cyclic dependencies are evil (2013)

fsharpforfunandprofit.com

Post reply on HN
Print view View original

91–100 of 125 posts

Re: Cyclic dependencies are evil (2013)

#91

Post by username90 »

stingraycharles wrote: post #88
username90 wrote: post #78

Earlier quoted context omitted.

I've worked with very high level engineers at Google that thought cyclic dependencies are fine. Sometimes they are just the simplest solution and trying to design abstractions to avoid it just creates a huge mess. If you've working with Java at Google (Guice) makes you learn to hate hiding circular dependencies behind dependency injection, since your binary gets injected by some huge tree of thousands of dependencies…

I have to say that in my whole career of doing Java / Clojure, Google’s SDK are one of the worst in terms of dependency hell. It’s incredibly unpleasant to work with, lots of breaking incompatibilities with libraries, etcetera. I may sound very snarky, but it really feels like an over engineered mess and I suspect the reason they need all these dependency tricks is the fact that it’s over engineered, not necessarily…

You never truly need circular dependencies, however many times letting functions at the same abstraction level call each other greatly simplifies code.

Re: Cyclic dependencies are evil (2013)

#92

Post by [deleted] »

bob1029 wrote: post #3

Language constraints aside, the real world is not something that can be cleanly modeled without the notion of circular dependencies between things. Not very many real, practical activities can be truly isolated from other closely-related activities and wrapped up in some leak-proof contract. Consider briefly the domain model of a bank. Customers rely on Accounts (I.e. have one or many). Accounts rely on Customers (i.…

[deleted]

Re: Cyclic dependencies are evil (2013)

#93

Post by dfgdghdf »

layer8 wrote: post #48

The generic way to remove a cyclic dependency is by Dependency Inversion (not to be confused with Dependency Injection), so that a mutual dependency A B is transformed into the noncircular set of dependencies { A –> BIntf , BImpl –> BIntf , BImpl –> A }. That is, at least one node in the dependency cycle is split into interface and implementation, breaking the cycle. Compilers for languages like C# and Java can deal…

F# could have out of order definitions, but the designers chose not to because it lengthens compile times considerably.

Re: Cyclic dependencies are evil (2013)

#94

Post by edflsafoiewq »

The simplest case where I'd want a circular dependencies is I have a module that defines some data types and functions on those types

  mod widget

  struct Widget

  fn show(Widget) { ... }
  fn join(Widget) { ... }
  fn calc_box(Widget) { ... }
and one function is getting very long and complicated so I want to spin it out into its own module

  mod widget                   mod calc_box
  import calc_box              from widget import Widget

  struct Widget                fn calc_box(Widget) { ... }

  fn show(Widget) { ... }
  fn join(Widget) { ... }
The reason the article gives that this is "evil" is that there is no hierarchy between the modules; the cycle is really just one big supermodule. That's true... but that was basically the point. Where is the "evil" here?

Re: Cyclic dependencies are evil (2013)

#95

Post by [deleted] »

bob1029 wrote: post #3

Language constraints aside, the real world is not something that can be cleanly modeled without the notion of circular dependencies between things. Not very many real, practical activities can be truly isolated from other closely-related activities and wrapped up in some leak-proof contract. Consider briefly the domain model of a bank. Customers rely on Accounts (I.e. have one or many). Accounts rely on Customers (i.…

[deleted]

Re: Cyclic dependencies are evil (2013)

#96

Post by vasergen »

edflsafoiewq wrote: post #94

The simplest case where I'd want a circular dependencies is I have a module that defines some data types and functions on those types mod widget struct Widget fn show(Widget) { ... } fn join(Widget) { ... } fn calc_box(Widget) { ... } and one function is getting very long and complicated so I want to spin it out into its own module mod widget mod calc_box import calc_box from widget import Widget struct Widget fn cal…

In that case you can separate ’struct Widget’ into another file. This way there will be no circular dependency

Re: Cyclic dependencies are evil (2013)

#97

Post by dataflow »

zaphar wrote: post #11
bob1029 wrote: post #3

Language constraints aside, the real world is not something that can be cleanly modeled without the notion of circular dependencies between things. Not very many real, practical activities can be truly isolated from other closely-related activities and wrapped up in some leak-proof contract. Consider briefly the domain model of a bank. Customers rely on Accounts (I.e. have one or many). Accounts rely on Customers (i.…

Sometimes I read conversations about software engineering concepts by career developers and I get this sense that there is this entire hidden world of other engineers that I have somehow managed never to encounter. Every engineer I've ever met who has been doing it for more than a couple years universally decries circular dependencies. Every one of them has come to that opinion via hard won experience dealing with re…

It's not clear the parent commenter actually needs a cyclic reference there, so I wouldn't draw any conclusions from it. Some of us don't believe it's necessary in that example.

Re: Cyclic dependencies are evil (2013)

#98

Post by edflsafoiewq »

vasergen wrote: post #96
edflsafoiewq wrote: post #94

The simplest case where I'd want a circular dependencies is I have a module that defines some data types and functions on those types mod widget struct Widget fn show(Widget) { ... } fn join(Widget) { ... } fn calc_box(Widget) { ... } and one function is getting very long and complicated so I want to spin it out into its own module mod widget mod calc_box import calc_box from widget import Widget struct Widget fn cal…

In that case you can separate ’struct Widget’ into another file. This way there will be no circular dependency

I know how to break the cycle. What I'm asking is why should I break the cycle?

Re: Cyclic dependencies are evil (2013)

#99

Post by leoc »

TeMPOraL wrote: post #44
zaphar wrote: post #11

Earlier quoted context omitted.

Sometimes I read conversations about software engineering concepts by career developers and I get this sense that there is this entire hidden world of other engineers that I have somehow managed never to encounter. Every engineer I've ever met who has been doing it for more than a couple years universally decries circular dependencies. Every one of them has come to that opinion via hard won experience dealing with re…

> Every engineer I've ever met who has been doing it for more than a couple years universally decries circular dependencies. Every one of them has come to that opinion via hard won experience dealing with real world problems they encountered. They may not realize they have them - at runtime, in the object graph, possibly indirectly. There's little difference in principle between cycles in "static" code vs. runtime st…

The fact that computing is shot through with people who think that putting things in-band makes them go away, and that because special cases have nice properties therefore King Canute can abolish the general case with a wave of his hand, is a very large part of the problem with computing.

Re: Cyclic dependencies are evil (2013)

#100

Post by vasergen »

edflsafoiewq wrote: post #98
vasergen wrote: post #96

Earlier quoted context omitted.

In that case you can separate ’struct Widget’ into another file. This way there will be no circular dependency

I know how to break the cycle. What I'm asking is why should I break the cycle?

It depends on situation. As an example, it could be difficult to write tests when you have circular dependency. As well depends on the language there could be strange ’side effects’ which would be difficult to debug.
Post reply on HN