6 ms·

I talk with a lot of programmers that think that abstracting everything is super important. Everything must be a black box and the programmer should have no ide

by pixie_ 11y ago

I talk with a lot of programmers that think that abstracting everything is super important. Everything must be a black box and the programmer should have no idea what's happening inside of it. Their code is an over engineered mess of interfaces, dependency injection, and code so deep and isolated you have no idea how anything ever works (I mean like even if you had the source code it's so convoluted you could never make any use of it.)

userbinator 11y ago
Are they mostly Java, C#, or "advanced C++" programmers by any chance? I've noticed such designs seem to be the norm in those cultures. On the other hand, C and Asm programmers tend to be more KISS+YAGNI in their code. Perhaps it correlates with the ability of the language/tools to make it easy to generate huge amounts of code without much thought: if you can create a dozen classes with a dozen methods by a few tens of clicks in the IDE, you're far more likely to do so compared to writing each one of those classes, functions, or even the instructions in them manually. It's a form of cargo-cult thinking combined with the fact that a lot of beginning programmers are exposed to the "abstraction is good" dogma without ever realising that it can turn into too much of a good thing. Vague statements like "single responsibility principle" (what is a "single responsibility"?) can encourage a ridiculous amount of over-refactoring, driven by the idea that shorter functions are better --- which is true up to a point, but I've seen it taken to extremes where more lines in the file are function declarations and their opening/closing braces than actual, purposeful, code. They almost always argue that a shorter function is better ("after all, isn't it easier to read 1 small line than 10?") but neglect to realise that they've actually increased complexity of the whole by forcing readers to go through deeply nested function call stacks. Meanwhile, names tend to get longer due to the specificity of these tiny pieces, which doesn't help much with readability. In some very extreme cases I've seen, the name ends up being longer than the code it describes.[1] Instead, I think we should be teaching abstraction as a tool like any other --- use it when it helps reduce complexity by reducing code duplication, and warn against its overuse. Under-abstracted code is tedious and repetitive, but reasonably straightforward to understand, since most people tend to find reading things linearly to be quite easy. Over-abstracted code is highly nonlinear and takes you through an elaborate maze-like path. [1] http://git.eclipse.org/c/aspectj/org.aspectj.git/tree/org.aspectj.matcher/src/org/aspectj/weaver/patterns/HasThisTypePatternTriedToSneakInSomeGenericOrParameterizedTypePatternMatchingStuffAnywhereVisitor.java http://git.eclipse.org/c/aspectj/org.aspectj.git/tree/org.as...
- venomsnake 11y ago
  Objects were never intended to run in shared space. The only real OOP done today by the original definition is your interaction with your DB via SQL. So now we jump trough hoops to isolate things that are extremely resistant to isolation.
  - klibertp 11y ago
    Objects were never meant to have public attributes. The only way of interacting with objects should be sending messages. I'm talking about what Alan Kay says about the matter. Incidentally, besides Smalltalk, there is another language, which implements this original idea of OO: it's Erlang (just view processes as objects and it all fits).
zamalek 11y ago
> 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.
- seanmcdirmid 11y ago
  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.
  - zamalek 11y ago
    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.
    - 11y ago
dustingetz 11y ago
abstraction means thinking in layers, not having no idea what happens in lower layers. The pattern you describe is caused by OOP and inevitable in many of today's OO systems because OO does not offer sufficiently powerful abstraction capabilities [1]. Imperative often suffers from "We won't attempt to abstract this at all" (which is sometimes better [2]) and functional sometimes suffers from "powerful abstraction capability which requires a high degree of knowledge to wield". Pick where you want to be in the spectrum. [1] See AbstractSingletonProxyFactoryBean in Spring. Spring is an expert team with as well reasoned architecture as is possible in Java, anti-abstractions like this get written because they are the least-bad solution when a shitty problem comes up and the language has you cornered. http://docs.spring.io/spring/docs/2.5.x/api/org/springframework/aop/framework/AbstractSingletonProxyFactoryBean.html http://docs.spring.io/spring/docs/2.5.x/api/org/springframew... [2] "C vs C++ linus torvalds" https://www.google.com/search?q=c%20vs%20c%2B%2B%20linus%20torvalds https://www.google.com/search?q=c%20vs%20c%2B%2B%20linus%20t...
- SeanDav 11y ago
  > "[2] "C vs C++ linus torvalds" Linus is a great programmer and in the kernel space I would listen very closely to what he has to say - minus the profanity and insults. Outside of that space he is as subject to cognitive bias as any other well respected authority. There are many respected programmers that will take the opposite view in the C vs C++ debate.
wtetzner 11y ago
I think it's also important to keep in mind the difference between too much abstraction and choosing poor/wrong abstractions.

by pixie_ 11y ago

userbinator 11y ago

Are they mostly Java, C#, or "advanced C++" programmers by any chance? I've noticed such designs seem to be the norm in those cultures. On the other hand, C and Asm programmers tend to be more KISS+YAGNI in their code. Perhaps it correlates with the ability of the language/tools to make it easy to generate huge amounts of code without much thought: if you can create a dozen classes with a dozen methods by a few tens of clicks in the IDE, you're far more likely to do so compared to writing each one of those classes, functions, or even the instructions in them manually. It's a form of cargo-cult thinking combined with the fact that a lot of beginning programmers are exposed to the "abstraction is good" dogma without ever realising that it can turn into too much of a good thing. Vague statements like "single responsibility principle" (what is a "single responsibility"?) can encourage a ridiculous amount of over-refactoring, driven by the idea that shorter functions are better --- which is true up to a point, but I've seen it taken to extremes where more lines in the file are function declarations and their opening/closing braces than actual, purposeful, code. They almost always argue that a shorter function is better ("after all, isn't it easier to read 1 small line than 10?") but neglect to realise that they've actually increased complexity of the whole by forcing readers to go through deeply nested function call stacks. Meanwhile, names tend to get longer due to the specificity of these tiny pieces, which doesn't help much with readability. In some very extreme cases I've seen, the name ends up being longer than the code it describes.[1] Instead, I think we should be teaching abstraction as a tool like any other --- use it when it helps reduce complexity by reducing code duplication, and warn against its overuse. Under-abstracted code is tedious and repetitive, but reasonably straightforward to understand, since most people tend to find reading things linearly to be quite easy. Over-abstracted code is highly nonlinear and takes you through an elaborate maze-like path. [1] http://git.eclipse.org/c/aspectj/org.aspectj.git/tree/org.aspectj.matcher/src/org/aspectj/weaver/patterns/HasThisTypePatternTriedToSneakInSomeGenericOrParameterizedTypePatternMatchingStuffAnywhereVisitor.java http://git.eclipse.org/c/aspectj/org.aspectj.git/tree/org.as...

venomsnake 11y ago
Objects were never intended to run in shared space. The only real OOP done today by the original definition is your interaction with your DB via SQL. So now we jump trough hoops to isolate things that are extremely resistant to isolation.
- klibertp 11y ago
  Objects were never meant to have public attributes. The only way of interacting with objects should be sending messages. I'm talking about what Alan Kay says about the matter. Incidentally, besides Smalltalk, there is another language, which implements this original idea of OO: it's Erlang (just view processes as objects and it all fits).

zamalek 11y ago

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

seanmcdirmid 11y ago
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.
- zamalek 11y ago
  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.
  - 11y ago

dustingetz 11y ago

abstraction means thinking in layers, not having no idea what happens in lower layers. The pattern you describe is caused by OOP and inevitable in many of today's OO systems because OO does not offer sufficiently powerful abstraction capabilities [1]. Imperative often suffers from "We won't attempt to abstract this at all" (which is sometimes better [2]) and functional sometimes suffers from "powerful abstraction capability which requires a high degree of knowledge to wield". Pick where you want to be in the spectrum. [1] See AbstractSingletonProxyFactoryBean in Spring. Spring is an expert team with as well reasoned architecture as is possible in Java, anti-abstractions like this get written because they are the least-bad solution when a shitty problem comes up and the language has you cornered. http://docs.spring.io/spring/docs/2.5.x/api/org/springframework/aop/framework/AbstractSingletonProxyFactoryBean.html http://docs.spring.io/spring/docs/2.5.x/api/org/springframew... [2] "C vs C++ linus torvalds" https://www.google.com/search?q=c%20vs%20c%2B%2B%20linus%20torvalds https://www.google.com/search?q=c%20vs%20c%2B%2B%20linus%20t...

SeanDav 11y ago
> "[2] "C vs C++ linus torvalds" Linus is a great programmer and in the kernel space I would listen very closely to what he has to say - minus the profanity and insults. Outside of that space he is as subject to cognitive bias as any other well respected authority. There are many respected programmers that will take the opposite view in the C vs C++ debate.

wtetzner 11y ago

I think it's also important to keep in mind the difference between too much abstraction and choosing poor/wrong abstractions.