> it made fixing any minor bug take weeks.

My god.

A lot of these fancy language features sound good on paper but can be so abused that even just coming to understand the code takes up too much space in your head.

https://twitter.com/davidcrawshaw/status/507268175256231936

Emphasis belongs on abused. Interfaces are swell. Subclasses of classes which implement an Interface are swell too, when they extend simply by altering the way said interface is achieved. When you subclass to "add more stuff", however, you get the kind of nonsense described.

The problem, in my opinion, is that the Java community (generalizing, I know) decided to bless that abuse as a best practice.

This is part of why I am so in love with Go. I have never read Go I couldn't understand. It's very clear at heart. I have read through much of the standard library and it all makes sense.

Do you think that's that's because the language inherently makes things readable, or is it simply because the language is too new to have popular anti-patterns?

The simplicity of the language and some of its choices really force you to do things a certain way that comes out almost universally legible instead of going with what may feel easier or "clever" to write. This is why it's so widely criticized (which doesn't mean that some of its criticism isn't fair).

Also gofmt having the last word on what code is acceptable and what isn't helps kill a lot of arguments that aren't worth having.

In a way, it's like the Go team chose to write something that has some of the coder UX of Smalltalk, but in a C-like statically compiled language. There is a useful region of language design space around the "simple language" concept, and they seem to be making the most of that particular design space maxima.

The team promotes heavily dead simple code over PL abstractions. Taken from some golang con slides where they said there would be nothing new in go, only perf and bug removal for a while.

It's an active choice of the language to not allow many syntactic sugars that make the code have a much higher learning curve.

https://www.youtube.com/watch?v=rFejpH_tAHM is a good overview.

In many ways I'm terrified by Java programmers who have never heard of pattern abuse.

"It's just like we all learned in college! Object Oriented programming is supposed to model real-life!"

It is - in execution (message passing), not in taxonomies. You can't model the taxonomies because all set-in-stone languages are inadequate for that (see SICP, for example). Also, it sounds like someone had an inheritance mania on your project. That's an instant loss right there. (But maybe the language used didn't allow for anything better? C++ is notoriously bad in this respect, for example.)

This is definitely not what you learn on college. If you use inheritance instead of composition it is your problem, not OOP problem. You can do the same mess with procedures and structs. OOP is not here to magically solve programmers bad design decisions.

> This is definitely not what you learn on college.

That is definitely the way I was taught OOP in college. I came out thinking it as a steaming, overcomplicated pile of shit. I have since learned better. Of course, there is a whole world of enterprise programmers for whom what was described is "proper" OOP.

Did you attend an "encapsulation, polymorphism, inheritance are our holy buzzwords" (yuck!) kind of technical college or a "focus on messaging patterns" (yay!) kind of technical college? The former kind tends to do that to people.

I actually got this out of a College of Engineering at an actual university. It was mostly the former.

When I learned OOP it was all about inheritance. Only later I realized that aggregation is much easier to handle and that functions that take well defined input and return a value without side effects are easier to maintain.

It's never been all about inheritance, they just forgot to tell that to Stroustrup and Gosling. ;)

Maybe I didn't go to a good enough college, but this is what I was taught. Either way though, this is not how I do OOP.

It is what I had to deal with, though.

After working on some "enterprise" systems myself, I came to the cynical conclusion that Java/C++/C# were never meant to actually solve problems, but to introduce unnecessary complexity and brittle-ness which eventually, inevitably, leads to the hiring of "consultants" for support or new features at exorbitant prices.

These languages, as well as things like WSDL/SOAP, are the late 90's/early 00's snake oil designed to woo clueless manager-types into funneling money to consultants and 'architects'.

I worked a lot with those types and saw the futility of suggesting 'simple' solutions to simple problems - everything had to be over-complicated to justify their salaries.

It left me pretty bitter towards that whole business model. Then again, there's lots of money to be made there....

Ugh, yes. The inheritance tree is just a line, of 4 or more segments.

  interface -> abstract -> base -> TheOnlyImplementationInstantiated

Repeat for a couple more chains, and one line bug fixes require visiting a dozen files to figure out.