Cyclic dependencies are evil (2013) • Hacker News Board

Re: Cyclic dependencies are evil (2013)

#31

Post by ReactiveJelly » Sat, Jan 30, 2021, 6:02 PM UTC

mattgreenrocks wrote: post #24

squibbles wrote: post #9

I still cringe when I think back to some C projects from long ago, where the dependency chains of headers and libraries where unfathomably byzantine. On a related note, lately I have been looking into some biochemistry topics and their relation to computer science. It seems that cyclic dependencies are possibly a requirement for life, which makes faithful simulations of biochemical processes an interesting challenge.

I’m a compiler nerd at the moment. I have an inherent trust of things that bootstrap themselves, as if it means they are conceptually more pure. I’m not sure whether that is 100% well founded, but it sounds similar to some of these observations. :)

I think self-hosting is just a little over-rated for languages. It's good that Rust and C++ are self-hosting, you'd expect those to be languages you can write a compiler in.

But Lua and JavaScript satisfy their own niche just fine without having popular runtimes written in themselves.

Re: Cyclic dependencies are evil (2013)

#32

Post by ReactiveJelly » Sat, Jan 30, 2021, 6:04 PM UTC

jimmaswell wrote: post #27

squibbles wrote: post #9

I still cringe when I think back to some C projects from long ago, where the dependency chains of headers and libraries where unfathomably byzantine. On a related note, lately I have been looking into some biochemistry topics and their relation to computer science. It seems that cyclic dependencies are possibly a requirement for life, which makes faithful simulations of biochemical processes an interesting challenge.

The C language and gcc are a cyclic dependency too.

Only if you don't consider time, or optional dependencies. GCC 10 _can_ be built with GCC 10, but it was probably built with GCC 9 the first time around.

If you can bootstrap it, and you can, then it's not really a hard, unbreakable cycle, right? It's just an option that's quicker than starting from tcc or whatever every time.

Re: Cyclic dependencies are evil (2013)

#33

Post by im3w1l » Sat, Jan 30, 2021, 6:07 PM UTC

iso8859-1 wrote: post #28

im3w1l wrote: post #20

Earlier quoted context omitted.

This resembles sql a lot. Btw I'm surprised that few languages seem to have in their standard library a many-to-many container which supports efficient lookups in either direction.

Which languages support this at all? Are you talking about ORM?

I'm talking about something like this

    std::relation foobars;
    ...
    auto& bars = foobars.forward(foo);
    ...
    auto& foos = foobars.backward(bar);

Edit: Boost apparently has it, see e.g. https://stackoverflow.com/questions/1128144/c-maps-for-many-...

Re: Cyclic dependencies are evil (2013)

#34

Post by nyberg » Sat, Jan 30, 2021, 6:16 PM UTC

ReactiveJelly wrote: post #32

jimmaswell wrote: post #27

Earlier quoted context omitted.

The C language and gcc are a cyclic dependency too.

Only if you don't consider time, or optional dependencies. GCC 10 _can_ be built with GCC 10, but it was probably built with GCC 9 the first time around. If you can bootstrap it, and you can, then it's not really a hard, unbreakable cycle, right? It's just an option that's quicker than starting from tcc or whatever every time.

But how would you build the first GCC in that chain?

Re: Cyclic dependencies are evil (2013)

#35

Post by Aeolun » Sat, Jan 30, 2021, 6:22 PM UTC

kayodelycaon wrote: post #17

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…

Possible reason: selection bias. If everyone else is fine with circular dependencies or at least sees them as a necessary evil... are they going to extremely vocal about the current status quo when there they have no need to defend it?

In my experience, it’s generally less experienced engineers that will happily make a clusterfuck of circular dependendies.

If a more experienced engineer does, it’s generally considered a necessary evil, but not a choice taken lightly.

Re: Cyclic dependencies are evil (2013)

#36

Post by monocasa » Sat, Jan 30, 2021, 6:25 PM UTC

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.…

You would forget everything about a customer if they closed their last account?

Re: Cyclic dependencies are evil (2013)

#37

Post by lazulicurio » Sat, Jan 30, 2021, 6:32 PM UTC

In a related vein, is there any sort of theoretical transform that can be used to convert cyclic dependencies into a tree? Similar to how lambda lifting eliminates free variables. (Other than the obvious one of treating the entire cycle as one node)

Re: Cyclic dependencies are evil (2013)

#38

Post by Smaug123 » Sat, Jan 30, 2021, 6:33 PM UTC

monocasa wrote: post #36

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.…

You would forget everything about a customer if they closed their last account?

No, of course you would maintain a Set as well (possibly even a Map for efficiency).

Re: Cyclic dependencies are evil (2013)

#39

Post by gpderetta » Sat, Jan 30, 2021, 6:44 PM UTC

im3w1l wrote: post #33

iso8859-1 wrote: post #28

Earlier quoted context omitted.

Which languages support this at all? Are you talking about ORM?

I'm talking about something like this std::relation foobars; ... auto& bars = foobars.forward(foo); ... auto& foos = foobars.backward(bar); Edit: Boost apparently has it, see e.g. https://stackoverflow.com/questions/1128144/c-maps-for-many-...

Boost.Bimap is a special case (and built on top) of Boost.Multiindex that allows indexing a logical table with an arbitrary subset of fields.

Re: Cyclic dependencies are evil (2013)

#40

Post by monocasa » Sat, Jan 30, 2021, 6:45 PM UTC

Smaug123 wrote: post #38

monocasa wrote: post #36

Earlier quoted context omitted.

You would forget everything about a customer if they closed their last account?

No, of course you would maintain a Set as well (possibly even a Map for efficiency).

Their whole premise is that

> Customers rely on Accounts (I.e. have one or many).

I'm giving a domain relevant counter example to that premise.

And interestingly enough, that leads you to a clean way of modeling it without the cyclic dependency as you've just done.