Hacker News Reader

Comment by akkartik | Hacker News Reader

eyeroll

I wonder how Robert Martin was implementing SOLID before the wonder that is Go was delivered unto us. And I wonder why all our buzzword-laden codebases are still knee deep in crap if SOLID is so amazingly awesome. We've been hearing about coupling and cohesion for over 50 years now. At what point does thinking in those terms become part of the problem rather than the solution?

Is it possible that Go or any other language du jour just seems cleaner because it's newer and so the cruft hasn't had a chance to form yet? Come back in 10 years, and tell me how amazing it is then.

View on HN

If you've got some great conceptual framework for thinking about code quality that doesn't include coupling and cohesion or some equivalent ideas, please, share it with us all. I'm not holding my breath thought. The reason we keep talking about coupling and cohesion is that these are useful concepts that can be fairly directly applied to most day-to-day software design problems.

This was a nice, fairly short post about how to apply some generally accepted principles of good software design in a specific language. It's a worthwhile read for anyone relatively new to Go programming.

I do, but I don't want to shamelessly plug here. My point was not that these ideas are bad. My point was that they are incomplete, and pointing at them as reasons why a new language is so great is absurd -- when in fact Java supports them just as well.

I think Go is great, but I think it's great because it gets a large number of details slightly more right than the languages of the previous decade. And it will make its mistakes that languages of the next decade will learn from. SOLID is just the bare minimum ante here. Bragging about SOLID is like bragging that your language supports all kinds of data structures.

I am not against thinking in terms of coupling and cohesion but I found the following different and interesting ways to think about separating software:

https://www.destroyallsoftware.com/talks/boundaries

http://shaffner.us/cs/papers/tarpit.pdf

The common theme in both these viewpoints is that the biggest enemy is state, and who is responsible for it, rather than just responsibility on its own.

> Is it possible that Go or any other language du jour just seems cleaner because it's newer and so the cruft hasn't had a chance to form yet? Come back in 10 years, and tell me how amazing it is then.

That's the reason why. Most Go codebases 5/10 years down the road will be as obnoxious as any other 10 year old code base written in any other language. It happens with every generation of developer.

I still remember 4 years ago when Nodejs was deemed simpler, cleaner and easier to maintain than Java ... I would hate having to maintain 4 year old Nodejs codebases today.

> I still remember 4 years ago when Nodejs was deemed simpler, cleaner and easier to maintain than Java ... I would hate having to maintain 4 year old Nodejs codebases today.

Heck, I still remember when Java was simpler, cleaner and easier to maintain than C++! Well, I guess it still is …

it's a nice language BECAUSE the authors push back when asked to add this and that and all the other latest language feature fads.

They really don't get enough credit for constantly dealing with the negative hordes. Add features = language crufty. Don't add features = where's my generics (or whatever).

Exactly. That reason would fly better with me.

"Add features = language crufty."

Truly remarkable that they got it right on the first pass if that's the case. Rob Pike must be a frickin SOOPER GENIOUS.

Dunno about SOOPER GENIOUS, but I reckon he knows his stuff. He's certainly got the chops that prove it.

Reply on news.ycombinator.com