Comment by zamalek | Hacker News Reader

Comment by zamalek | Hacker News Reader

Parent Full thread

> I talk with a lot of programmers that think that abstracting everything is super important.

OOP languages basically back you into this corner once a problem becomes complex enough. As an example, DI is supposed to decrease the coupling so that tests can actually test units and not wind up performing integration testing. Low coupling results in a more agile codebase, but does not intrinsically lead to more understandable code.

What goes wrong is people think that you need to "DI all the things." Like any tool it can be used incorrectly and, from what I have seen, violating the single responsibility principle [when using DI] is what most often leads to unwieldy code. "Got a model class/object? That needs an interface too."

Abstraction is not to blame, it is the incorrect usage of abstraction that is to blame; which is sadly what you are taught in school and college. Spending even one day learning a functional language is enough to drastically improve your understanding of how abstraction is supposed to work in OOP languages.

> I mean like even if you had the source code it's so convoluted you could never make any use of it.

Some IDEs can help with this (VS2015 just added "go to implementation" for C# interfaces), as does the most reliable way to understand code: stepping through it line-by-line (or at least method-by-method) in a debugger - once you have a run-time itable the callee is no longer ambiguous.

TLDR; it's a necessary evil for OOP languages but is often taken too far due to bad theory that is taught to us all.

I don't know if functional languages are much better in preventing abstraction abuses. I mean, a triple indirect function, an incredibly pointless (aka point free) chain of applications, a heavy reliance on data flow, can make the program difficult to understand, and in some languages (the lazy ones), stepwise debugging is difficult.

I'm not saying that functional languages don't have their own problems; however, for some reason that I can't explain they increase your wisdom regarding OOP languages - learning one did that for me at the very least.

Probably because the more examples of programming paradigms that you learn, the better you can generalize, erm, abstract that experience into good form.

OO suffers from the design pattern kind of abstraction as well as the explosion of nouns kind of abstraction because of trying to model everything as analogies to real world concepts rather than focusing on what the program is meant to do. Functional programming suffers from a different kind of gratuitous abstraction, namely the category theory abstract nonsense kind.

I think the main source of overabstraction is the idea that abstraction is a virtue in itself rather than only a tool to accomplish a task. This often takes the guise of different artificial value systems like "testability", "decoupling", and "reusability". These can be good things, but only as a means to an end. People lose track of that sometimes.

I don't think that is an accurate portrayal of OO. There are plenty of nouns out there that do not model real world concepts. I can create an "expression" class/object in a OO program (and do all the time!) to represent parts of an abstract syntax tree. As far as I know, expressions don't exist in the real world. Human language is quite powerful like that.

Overabstraction is often simply a matter of poor problem understanding. Sometimes you don't really know how to solve a problem right, so you bite off parts of it, work your way through many layers until it is solved. The abstractions are not ideal, because not much planning was involved, and you didn't actually have the experience to generalize appropriately but...you needed some way to decompose the problem.

Abstraction is a tool. It has a cost, but sometimes you need to pay it and sometimes you are better off not. We really need better ways of abstracting and, when necessary, unabstracting.

I think that's right, especially the second paragraph about the cause of the explosion of nouns. A common approach to OO programming is to take the problem and identify the nouns in the problem, and then make a class for each of those nouns before having a clear idea of how the program is going to work. This is especially prevalent in combination with TDD. This is a recipe for disaster if you ask me. A good example of this is when Ron Jeffries tried to write a sudoku solver.

Agreed.

> identify the nouns in the problem

This is what I was getting at by mentioning education as a possible culprit. You get out of university with this bad habit right off the bat, instead of the correct one:

Identify the responsibilities in the solution.

Identifying all the nouns in the problem sets you up for failure because you are implementing a solution before you know what the solution actually is. Said another way: you are in a very literal way implementing the problem and not the solution.

What is so wrong about that? You have to understand the problem in some way. Perhaps we could spend a lot of time at the whiteboard understanding the problem waterfall style before we design the actual program? Realistically, this isn't very effective either.

There is nothing wrong about noun identification in itself, you have to solve the problem in some way. The functional approach avoids the nouns, the solutions can be more elegant, but man, coming up with those solutions is much harder. Decomposing a problem without nouns is like doing...math: it is much more difficult than just talking about it! Once you have done the math, you really understand the problem, but that is a very steep mountain to climb.

I keep coming back to RPG's "worse is better" essay. The problem is that while the artifacts that we create might be horribly messy, they are better than the artifacts that are never created at all. Evaluating at a program purely by its end resulting state does not capture the entire, or even most, essence of what it means to write a program.

> Once you have done the math, you really understand the problem, but that is a very steep mountain to climb.

s/really/actually/

And yes, it is hard, but it actually works.

Right, and in the meantime your competitors have shipped and taken over the market with their sub-optimal understanding of the problem, and you can't sell your solution even though it is perfect.

Dependency injection does not decrease coupling, it hides it.

Well-said.

Writing code against IList instead of ArrayList, or IDatabase instead of PostgresDatabase unambiguously decreases coupling.

Not if you explicitely configure the IList to be an instance of ArrayList and expect it to behave like an ArrayList. In that case, just taking an ArrayList is the more honest and more readable option.

There are several things contributing to over-abstraction. Two that I can think of:

1) Professional programmers are constantly hammered with the idea that abstraction and decoupling are always desirable - you've probably heard about TDD. Somehow OOD has been taken over by this school of thought and there are very few good resources on what good OOD is and looks like.

2). Dynamic OO languages force one to have high coverage and many tests to make up for the lack of static verification.

And I don't agree with the TLDR, over-abstraction is not a disease that affects only OO languages.

> over-abstraction is not a disease that affects only OO languages

Agreed, it's present in other languages and has been with us a long time. It does seem to have reached a fever pitch in mainstream OO culture. OO seems to encourage taking even a small piece and giving it the full-blown treatment of layers, design patterns, DI, and the rest. Because each piece is a whole, in a way, so it deserves it, right? Give each part of a program that treatment, and the whole becomes unwieldy to a degree that was seldom seen before OO.

Reply on news.ycombinator.com