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

Why Do We Keep Building Tightly Coupled Software?

codethinked.com

Post reply on HN
Print view View original

11–16 of 16 posts

Re: Why Do We Keep Building Tightly Coupled Software?

#11

Post by dasil003 »

Davertron wrote: post #10
jonke wrote: post #6

This seems, I could have missed something, more to be about the loose coupling in Object Land. Not about loose coupling in software land. Some sentences seems more or less taken out of context from any Haskell book (pure vs IO). Some seem, again, taken out of context from the OTP Design principle. More annoying is the fact that there is a code example of How Not Todo It but nowhere any How Todo it. I would have liked…

Yeah, to me this article basically sounds like some guy heard you shouldn't tightly couple your software, and wrote a blog post about it to sound smart. That may not be the case, but giving an example of how not to do it, and then NOT giving an example of how to do it just seems silly to me.

I agree. To say loosely coupled software is better is just restating the Law of Demeter. The tricky part is figuring out where the interfaces should actually go. Every abstraction comes with overhead, so it only makes sense if it eliminates some emergent complexity from the whole system. Now I guess given the choice between the copy and paste code monkey and the architecture astronaut I'd choose the latter, but I'm pretty sure I'd rather work with someone who is smart and gets things done.

I think it's all too easy to look at old code with today's perspective, and assume the original programmers were idiots without considering what the code base looked like at the time or what were the requirements and time constraints given to them.

Re: Why Do We Keep Building Tightly Coupled Software?

#12

Post by arohner »

wynand wrote: post #9

This is an interesting problem and as someone who's never been much good at writing big systems, I've given it some thought. A system like Erlang helps here, I think, not because it is functional (and I say this as a functional programming advocate), but because it has a different metaphor for partitioning programs at the medium to large scale: processes. With a process, you have to think about where you draw the "er…

> It's easy to share state. I am not yet sold on the idea that all shared state is evil (since I think there are problems that are easier to deal with when using shared memory)

There absolutely are problems that are easier to deal with using shared memory. Clojure takes a middle ground here, and recognizes that shared state is sometimes necessary, but is often overused, mainly because the language makes it easier to make something mutable than immutable.

Just as you mention about Erlang, "With a process, you have to think about where you draw the 'error boundaries'", in Clojure you can paraphrase that as 'With refs, you have to think about where you use shared state'.

To create a local, immutable variable, you would write

    (let [x 42] ...)
If you wanted to make that mutable, it would be

    (let [x (ref 42)]...)
You have to explicitly say the variable is mutable. This change in defaults alone goes a long way in making Clojure a more correct and loosely coupled language.

Re: Why Do We Keep Building Tightly Coupled Software?

#13

Post by mistermann »

Davertron wrote: post #10
jonke wrote: post #6

This seems, I could have missed something, more to be about the loose coupling in Object Land. Not about loose coupling in software land. Some sentences seems more or less taken out of context from any Haskell book (pure vs IO). Some seem, again, taken out of context from the OTP Design principle. More annoying is the fact that there is a code example of How Not Todo It but nowhere any How Todo it. I would have liked…

Yeah, to me this article basically sounds like some guy heard you shouldn't tightly couple your software, and wrote a blog post about it to sound smart. That may not be the case, but giving an example of how not to do it, and then NOT giving an example of how to do it just seems silly to me.

most of his posts are similar in nature imho

Re: Why Do We Keep Building Tightly Coupled Software?

#14

Post by brown9-2 »

russell wrote: post #8

I have been the sole developer working on a enterprise web project (jboss/spring/hibernate) with extreme decoupling: 400k LOC and 48K of XML tying it together, rampant OOP and patterns du jour. First problem - too much code. Second problem - difficult to debug, because the flow of control often stopped at an interface. If the original developers had done decoupling as needed, the code would have been 50% smaller, mor…

difficult to debug, because the flow of control often stopped at an interface

Not sure if I understand how this is a problem - you should always have the concrete class's name in any stacktraces that you have, either from exceptions or by attaching a debugger. Are you attaching a debugger?

Not only that, but if you have your application's logging based around logger name = class name, you'll always know exactly which classes/objects are in control.

Also, if you have the "XML tying it together" how can anything hide behind the interface?

Re: Why Do We Keep Building Tightly Coupled Software?

#16

Post by silentbicycle »

arohner wrote: post #12
wynand wrote: post #9

This is an interesting problem and as someone who's never been much good at writing big systems, I've given it some thought. A system like Erlang helps here, I think, not because it is functional (and I say this as a functional programming advocate), but because it has a different metaphor for partitioning programs at the medium to large scale: processes. With a process, you have to think about where you draw the "er…

> It's easy to share state. I am not yet sold on the idea that all shared state is evil (since I think there are problems that are easier to deal with when using shared memory) There absolutely are problems that are easier to deal with using shared memory. Clojure takes a middle ground here, and recognizes that shared state is sometimes necessary, but is often overused, mainly because the language makes it easier to…

Indeed. Shared state is absolutely necessary sometimes, it's just not a good default.

Exactly what you said about Clojure applies to OCaml as well, except the syntax in that case is

   let x = 42 in ...
and

   let x = ref 42 in ...
Post reply on HN