7 ms·

The problem is not the language. It is possible to write very elegant and well-structured software in Java. The abstraction bloat usually seen in Java software

by Hermel 6y ago

The problem is not the language. It is possible to write very elegant and well-structured software in Java. The abstraction bloat usually seen in Java software comes from somewhere else, and I’m not sure where. Is it a symptom of corporate software? Is it Java’s popularity that attracts lots of mediocre programmers? Or is it that Java is often used for solving complex problems that are by definition hard to get right?

tester34 6y ago
I tend to believe in environments like Java or C# there's shiittton of focus on architecture, patterns, interfaces and generally testability there's shitton of discussions about those topics in those langs So it may be reason why people tend to over abstract stuff.
eandre 6y ago
In my experience languages have a culture of their own. For example, C++ has a culture of caring about low-level details to squeeze out maximum performance. I once found myself writing something that wasn't performance critical in C++ due to a library I needed, and just minutes later I caught myself reading up on move semantics for maximum efficiency. I couldn't help myself getting sucked in by the language culture! Java's culture, in my opinion, is one of abstractions. There's little in the language to force you down that path, other than decades of it being the prevalent way Java is written, which bleeds into the standard library, core frameworks, and becomes the Java Way of Thinking.
- polotics 6y ago
  Totally! Java developer's over reliance on design patterns and abstractions tends to enable atrocious designs, very often the first idea that came to mind at a very early time in the design process, clambering on to a monstrous implementation that somehow runs. In Python, the relative flexibility and pseudo-code nature of the language means that more designs get tried, and simplicity wins. In C++, developer self-selected into being hard-core, so you get hard-core code...
  - smitty1e 6y ago
    The unofficial motto of Java seems to be "whoever dies with the biggest stack trace wins".
  - pjmlp 6y ago
    Ironically the GOF book used C++ and Smalltalk, while Java did not exist.
- pydry 6y ago
  Java's culture also seems to emphasize social class distinctions that mirror the corporations it is used in. There's an architect programmer and a worker bee. Everyone wants to be the architect and to create the "enterprise" framework used by the worker bees.
- realusername 6y ago
  > Java's culture, in my opinion, is one of abstractions. There's little in the language to force you down that path, other than decades of it being the prevalent way Java is written, which bleeds into the standard library, core frameworks, and becomes the Java Way of Thinking. Yes exactly, that's why I personally stay away from Java. The language is totally fine, the tooling is also fine, performance is great, there's everything there in theory to build and maintain great projects, however, the culture is atrocious and overengineering is everywhere. And that's very hard to go against decades of culture momentum going this way.
- q-big 6y ago
  > Java's culture, in my opinion, is one of abstractions. Haskell's culture is also one of abstractions, but of a very different kind of abstractions than Java.
- raducu 6y ago
  Java is used for a lot of integration problems, of course it has a thing for abstractions and interfaces.
- cutler 6y ago
  Yet C# and PHP also suffer from the same problem so it's more than a Java problem. Verbose OO languages seem to give rise to cultures of over-abstraction.
flukus 6y ago
It's partly in the language itself with everything needing to be an object and the way you have to fight the language to use lower level abstractions like static methods, out of the box the language is encouraging abstractions whether they're needed or not. That's mostly just unpleasant though, beyond that it seems to be something deeply ingrained in the culture, even something as simple as a structure (a simple class with public fields) is a heresy in the java world, you need to make those members private and add getters/setters or you're likely to get warnings from the IDE and probably not pass code review. The enterprise world builds more and more abstractions on top of this but the problem is very deeply rooted. A good part of the problem though is just programmers trying to solve hard meta problems instead of boring repetitive business problems.
lmm 6y ago
Nah, the language drives its culture. When every IDE offers to generate 8-12 lines to "encapsulate" a single field and every coding standard tells you that the resulting code is better, it becomes very hard to escape the mentality that writing zillions of extra lines is how you do "decoupling" and what you should be doing.
- raducu 6y ago
  Its not theat IDEs force you to generate code, its that IDEs are quick to hide code. I almost never read java files from start to finish, I just quickly navigate by methods/call hierarchy, in some side view, so its really easy for forgive Java for being verbose. Actually I rarely remember java class names or methods, I just know a heuristic shortcut on how to find them. After 15+ years of Java, I don't even see the boilerplate code, my brain ignores it like it ignores adds on webpages.
  - lmm 6y ago
    Imagine how much more effective you'd be if you'd been working in a non-boilerplatey language and spent 15+ years learning to see the essence of what code was doing, rather than having to expend that mental capacity on skipping over boilerplate.
    - raducu 6y ago
      When you work with huge codebases, 80% of the time is spent reading/navigating code. The IDE hides the boilerplate, I really don't mind it.
      - lmm 6y ago
        > When you work with huge codebases, 80% of the time is spent reading/navigating code. And you don't see this as an indication that reducing code size is important?
        raducu 6y ago
Darmody 6y ago
I don't know the reason but I can see this happening in PHP. Things that were very simple and straightforward are now obfuscated withing layers upon layers of abstraction.
- throw_m239339 6y ago
  > I don't know the reason but I can see this happening in PHP. Things that were very simple and straightforward are now obfuscated withing layers upon layers of abstraction. Abstractions that do not fix any of PHP's problems by the way (like its chaotic std lib, its weird mix of dynamism and rigidity, bizarre alt syntax for control flow, all the error reporting cruft, adhoc variable creation as side effect of certain function calls, context-less output buffers, antiquated scoping rules...), PHP is just adding features to the language without removing the bad parts. The irony, it's so bad as being a templating language PHP devs are using another templating language on top of it(smarty,...).
newsgourmet 6y ago
Sun and now Oracle's business was to lend out consultants, so they benefit from a complex enterprise architecture.
barrkel 6y ago
Unit testing, leading to dependency injection, leading to IoC containers, leading to lots of tools to assemble, intercept and rewrite code at execution time. But mostly unit testing. The commitment to isolated testable units of code is what generates abstractions of dubious value. Don't use a class where you could use an interface: easier to mock. Don't use a static method where you could use an instance method on a collaborator: easier to inject, replace and mock. Your object graph getting too hard to compose, or other design smells? Don't worry, we have tools to handle the complexity, so you don't have to try and reduce it.
- throw_m239339 6y ago
  > Unit testing, leading to dependency injection, leading to IoC containers, leading to lots of tools to assemble, intercept and rewrite code at execution time. it's funny since in theory TDD should reduce API surface as it is supposed to make people think about API before implementation. But then , TDD and DDD intersect and it's not much TDD anymore when the domain model has to be implemented...
- alquemist 6y ago
  Don't mock. Test production code, maybe with faked storage.
  - mschuster91 6y ago
    Often enough software has dependencies on external services (think of stuff like a CRM database, payment and shipping providers, integrations with CDNs, external identity verification services) where one has to go with mocks for testing if stuff like error handling etc. works.
    - alquemist 6y ago
      Fake external storage / rpc dependencies.
      - vbezhenar 6y ago
throw_m239339 6y ago
The problem used to be the language. Java used to be extremely rigid in the way it forced the developer to write classes everywhere, factories and what not. This and the std lib API as well which was quite verbose. And let's not get started on Java EE which was the recommended way to develop Java applications. All of that are certainly part of the language. Remember how hard and verbose it was to hydrate records from a DB result and turn them into Java objects with pure JDBC? The language certainly was at fault.
- cobbzilla 6y ago
  > Remember how hard and verbose it was to hydrate records from a DB result and turn them into Java objects with pure JDBC? The language certainly was at fault. I don't blame the language for this. It wasn't that hard to read/write objects using JDBC (it did usually create a lot of boilerplate) Please name a major programming language that has built-in ORM features -- a library is the best place for this sort of stuff. For Java this was J2EE/EJB (stupidly over-engineered) and Hibernate/JPA (decent if you avoid the footguns). For Ruby you have ActiveRecord, Python has Django and SQLAlchemy, etc.
cjfd 6y ago
I think it starts in the language. As a language it is the most bureaucratic one of all. These very deep import paths, the ban on multiple inheritance and the rule that a file can only contain one class all make the language bureaucratic. Programmers willing to put up with that are the more bureaucratically inclined ones and hence one ends up with all of these spurious layers of abstraction, giving every field a getter and a setter and so on.
- xxs 6y ago
  >As a language it is the most bureaucratic one of all.These very deep import paths... getter/setters Standard java libraries like java.lang, java.util, java.util.concurrect, java.net, java.io, java.nio etc, hardly suffers from that part. This is the language - quite straightforward, hardly any getter/setters - relatively simple hierarchy and so on. Then java.awt and later swing, java.bean came with more getters/setters, deeper hierarchies. Those are defunct now of course. I'd blame it on the idea of having visual UI editors to cause the extra fluff. Then xml, spring and all the friends came. Java got the reputation. Still I'd argue the core java packages don't suffer from deep factory-of-factory jazz. (I avoid most of DI and resent mocks in tests)
- raducu 6y ago
  Java is quite good in its niche. Java is not a language where you quickly slap some duck tape code. Java is not a language where you use your minimalistic VIM-like editor, it is a great language for quick navigation, great search and making sense of the code with a proper IDE.
raducu 6y ago
It is just human nature actually. Just like only X% of programmers really "get" recursion, only (X/10)% really like/feel OOP and abstract thought in general.
BlargMcLarg 6y ago
Really really over-simplified, I feel it comes down to a combination of when it was invented and for what reason. Why was Java invented? People wanted a simpler language. What do simpler languages do? Attract more people who aren't willing to put up with a lot of hassle (e.g. memory management, garbage collection, cross-platform). Unfortunately, software dev back then was arguably much simpler (less requirements, less competition) and incredibly lucrative (= people less interested and without affinity come in for the money). The worst seniors I meet are generally Java one-trick ponies, incredibly knowledgeable in Java and the domain of the app, but that's it. Despite most of these apps doing incredibly basic CRUD stuff, they tend to end up more complicated than a freaking game engine, the complete other side of the spectrum. As a younger dev, it is really difficult to fight against these seniors. Most seniors that care have left, they got the whole market begging at their feet. Other seniors have given up. There's a small number of seniors that still care, and there are layers of bureaucracy between suggesting a change, incorporating it, and seeing the results. It isn't unheard of to have half a year pass by from the suggestion of a change to the first signs of its effect. For many a young dev, that's half a year away from moving jobs without falling under immense scrutiny.
valenterry 6y ago
The language is of course part of the problem. Because having to write de facto one file per class does not really allow you to write very elegant software. It forces you to write files over files and no one wants that, so they fall back to primitive types. For the abstraction bloat it is actually similar. Here the reason is that for the longest time (and even nowadays) Java makes it painful to work with functions. So now instead of just a plain function, you have to create a class with an interface that has one method... and instantiate it. Great... not.
room271 6y ago
The problems stem from the lack of top-level functions; everything has to live within a class. In reality, classes (or 'modules' if you prefer) should be low-granularity things in most programs.
tomxor 6y ago
I've also seen plenty of horrifically deep layered stuff in PHP, and to a lesser extent JS. Just like Java, it's possible to write elegant well structured code in any of these languages (yes even PHP, even though I still hate PHP). And of course you can... purely in terms of organizing building blocks most object orientated languages are pretty much a super set. I think the problem is most people are not consciously aware that object orientated approaches are just a pattern, and like any pattern you shouldn't apply them to everything. Being built in to many languages gives the impression they are as fundamental as a loop or a function - those are technically still abstractions, but far more primitive and less subjectively applicable... Object oreanted patterns feel like they are in between domain specific and basic building blocks, the higher you go the more polarizing these become, trying to use a DSL will seem absurd for one thing extremely elegant for another - when classes fit they are beautiful, but when they are carelessly used as a default, they are annoying bags of loosely coupled functionality and data that only serves to obscure relationships. I'd speculate that the prevalence of poorly applied OOP is more to do with legacy and culture of the language along with the focus on how to use the language for newcomers.
hinkley 6y ago
There weren’t a lot of people with experience in OOAD, and all of a sudden we needed an army of Java developers. J2EE 1.0 came out, and was both over and under engineered (baroque and unworkable, which is ironic given the 7 fallacies come from their employer). And then Design Patterns came out, and it was all over but the crying.

by Hermel 6y ago

tester34 6y ago

I tend to believe in environments like Java or C# there's shiittton of focus on architecture, patterns, interfaces and generally testability there's shitton of discussions about those topics in those langs So it may be reason why people tend to over abstract stuff.

eandre 6y ago

In my experience languages have a culture of their own. For example, C++ has a culture of caring about low-level details to squeeze out maximum performance. I once found myself writing something that wasn't performance critical in C++ due to a library I needed, and just minutes later I caught myself reading up on move semantics for maximum efficiency. I couldn't help myself getting sucked in by the language culture! Java's culture, in my opinion, is one of abstractions. There's little in the language to force you down that path, other than decades of it being the prevalent way Java is written, which bleeds into the standard library, core frameworks, and becomes the Java Way of Thinking.

polotics 6y ago
Totally! Java developer's over reliance on design patterns and abstractions tends to enable atrocious designs, very often the first idea that came to mind at a very early time in the design process, clambering on to a monstrous implementation that somehow runs. In Python, the relative flexibility and pseudo-code nature of the language means that more designs get tried, and simplicity wins. In C++, developer self-selected into being hard-core, so you get hard-core code...
- smitty1e 6y ago
  The unofficial motto of Java seems to be "whoever dies with the biggest stack trace wins".
- pjmlp 6y ago
  Ironically the GOF book used C++ and Smalltalk, while Java did not exist.
pydry 6y ago
Java's culture also seems to emphasize social class distinctions that mirror the corporations it is used in. There's an architect programmer and a worker bee. Everyone wants to be the architect and to create the "enterprise" framework used by the worker bees.
realusername 6y ago
> Java's culture, in my opinion, is one of abstractions. There's little in the language to force you down that path, other than decades of it being the prevalent way Java is written, which bleeds into the standard library, core frameworks, and becomes the Java Way of Thinking. Yes exactly, that's why I personally stay away from Java. The language is totally fine, the tooling is also fine, performance is great, there's everything there in theory to build and maintain great projects, however, the culture is atrocious and overengineering is everywhere. And that's very hard to go against decades of culture momentum going this way.
q-big 6y ago
> Java's culture, in my opinion, is one of abstractions. Haskell's culture is also one of abstractions, but of a very different kind of abstractions than Java.
raducu 6y ago
Java is used for a lot of integration problems, of course it has a thing for abstractions and interfaces.
cutler 6y ago
Yet C# and PHP also suffer from the same problem so it's more than a Java problem. Verbose OO languages seem to give rise to cultures of over-abstraction.

flukus 6y ago

It's partly in the language itself with everything needing to be an object and the way you have to fight the language to use lower level abstractions like static methods, out of the box the language is encouraging abstractions whether they're needed or not. That's mostly just unpleasant though, beyond that it seems to be something deeply ingrained in the culture, even something as simple as a structure (a simple class with public fields) is a heresy in the java world, you need to make those members private and add getters/setters or you're likely to get warnings from the IDE and probably not pass code review. The enterprise world builds more and more abstractions on top of this but the problem is very deeply rooted. A good part of the problem though is just programmers trying to solve hard meta problems instead of boring repetitive business problems.

lmm 6y ago

Nah, the language drives its culture. When every IDE offers to generate 8-12 lines to "encapsulate" a single field and every coding standard tells you that the resulting code is better, it becomes very hard to escape the mentality that writing zillions of extra lines is how you do "decoupling" and what you should be doing.

raducu 6y ago
Its not theat IDEs force you to generate code, its that IDEs are quick to hide code. I almost never read java files from start to finish, I just quickly navigate by methods/call hierarchy, in some side view, so its really easy for forgive Java for being verbose. Actually I rarely remember java class names or methods, I just know a heuristic shortcut on how to find them. After 15+ years of Java, I don't even see the boilerplate code, my brain ignores it like it ignores adds on webpages.
- lmm 6y ago
  Imagine how much more effective you'd be if you'd been working in a non-boilerplatey language and spent 15+ years learning to see the essence of what code was doing, rather than having to expend that mental capacity on skipping over boilerplate.
  - raducu 6y ago
    When you work with huge codebases, 80% of the time is spent reading/navigating code. The IDE hides the boilerplate, I really don't mind it.
    - lmm 6y ago
      > When you work with huge codebases, 80% of the time is spent reading/navigating code. And you don't see this as an indication that reducing code size is important?
      - raducu 6y ago

Darmody 6y ago

I don't know the reason but I can see this happening in PHP. Things that were very simple and straightforward are now obfuscated withing layers upon layers of abstraction.

throw_m239339 6y ago
> I don't know the reason but I can see this happening in PHP. Things that were very simple and straightforward are now obfuscated withing layers upon layers of abstraction. Abstractions that do not fix any of PHP's problems by the way (like its chaotic std lib, its weird mix of dynamism and rigidity, bizarre alt syntax for control flow, all the error reporting cruft, adhoc variable creation as side effect of certain function calls, context-less output buffers, antiquated scoping rules...), PHP is just adding features to the language without removing the bad parts. The irony, it's so bad as being a templating language PHP devs are using another templating language on top of it(smarty,...).

newsgourmet 6y ago

Sun and now Oracle's business was to lend out consultants, so they benefit from a complex enterprise architecture.

barrkel 6y ago

Unit testing, leading to dependency injection, leading to IoC containers, leading to lots of tools to assemble, intercept and rewrite code at execution time. But mostly unit testing. The commitment to isolated testable units of code is what generates abstractions of dubious value. Don't use a class where you could use an interface: easier to mock. Don't use a static method where you could use an instance method on a collaborator: easier to inject, replace and mock. Your object graph getting too hard to compose, or other design smells? Don't worry, we have tools to handle the complexity, so you don't have to try and reduce it.

throw_m239339 6y ago
> Unit testing, leading to dependency injection, leading to IoC containers, leading to lots of tools to assemble, intercept and rewrite code at execution time. it's funny since in theory TDD should reduce API surface as it is supposed to make people think about API before implementation. But then , TDD and DDD intersect and it's not much TDD anymore when the domain model has to be implemented...
alquemist 6y ago
Don't mock. Test production code, maybe with faked storage.
- mschuster91 6y ago
  Often enough software has dependencies on external services (think of stuff like a CRM database, payment and shipping providers, integrations with CDNs, external identity verification services) where one has to go with mocks for testing if stuff like error handling etc. works.
  - alquemist 6y ago
    Fake external storage / rpc dependencies.
    - vbezhenar 6y ago

throw_m239339 6y ago

The problem used to be the language. Java used to be extremely rigid in the way it forced the developer to write classes everywhere, factories and what not. This and the std lib API as well which was quite verbose. And let's not get started on Java EE which was the recommended way to develop Java applications. All of that are certainly part of the language. Remember how hard and verbose it was to hydrate records from a DB result and turn them into Java objects with pure JDBC? The language certainly was at fault.

cobbzilla 6y ago
> Remember how hard and verbose it was to hydrate records from a DB result and turn them into Java objects with pure JDBC? The language certainly was at fault. I don't blame the language for this. It wasn't that hard to read/write objects using JDBC (it did usually create a lot of boilerplate) Please name a major programming language that has built-in ORM features -- a library is the best place for this sort of stuff. For Java this was J2EE/EJB (stupidly over-engineered) and Hibernate/JPA (decent if you avoid the footguns). For Ruby you have ActiveRecord, Python has Django and SQLAlchemy, etc.

cjfd 6y ago

I think it starts in the language. As a language it is the most bureaucratic one of all. These very deep import paths, the ban on multiple inheritance and the rule that a file can only contain one class all make the language bureaucratic. Programmers willing to put up with that are the more bureaucratically inclined ones and hence one ends up with all of these spurious layers of abstraction, giving every field a getter and a setter and so on.

xxs 6y ago
>As a language it is the most bureaucratic one of all.These very deep import paths... getter/setters Standard java libraries like java.lang, java.util, java.util.concurrect, java.net, java.io, java.nio etc, hardly suffers from that part. This is the language - quite straightforward, hardly any getter/setters - relatively simple hierarchy and so on. Then java.awt and later swing, java.bean came with more getters/setters, deeper hierarchies. Those are defunct now of course. I'd blame it on the idea of having visual UI editors to cause the extra fluff. Then xml, spring and all the friends came. Java got the reputation. Still I'd argue the core java packages don't suffer from deep factory-of-factory jazz. (I avoid most of DI and resent mocks in tests)
raducu 6y ago
Java is quite good in its niche. Java is not a language where you quickly slap some duck tape code. Java is not a language where you use your minimalistic VIM-like editor, it is a great language for quick navigation, great search and making sense of the code with a proper IDE.

raducu 6y ago

It is just human nature actually. Just like only X% of programmers really "get" recursion, only (X/10)% really like/feel OOP and abstract thought in general.

BlargMcLarg 6y ago

Really really over-simplified, I feel it comes down to a combination of when it was invented and for what reason. Why was Java invented? People wanted a simpler language. What do simpler languages do? Attract more people who aren't willing to put up with a lot of hassle (e.g. memory management, garbage collection, cross-platform). Unfortunately, software dev back then was arguably much simpler (less requirements, less competition) and incredibly lucrative (= people less interested and without affinity come in for the money). The worst seniors I meet are generally Java one-trick ponies, incredibly knowledgeable in Java and the domain of the app, but that's it. Despite most of these apps doing incredibly basic CRUD stuff, they tend to end up more complicated than a freaking game engine, the complete other side of the spectrum. As a younger dev, it is really difficult to fight against these seniors. Most seniors that care have left, they got the whole market begging at their feet. Other seniors have given up. There's a small number of seniors that still care, and there are layers of bureaucracy between suggesting a change, incorporating it, and seeing the results. It isn't unheard of to have half a year pass by from the suggestion of a change to the first signs of its effect. For many a young dev, that's half a year away from moving jobs without falling under immense scrutiny.

valenterry 6y ago

The language is of course part of the problem. Because having to write de facto one file per class does not really allow you to write very elegant software. It forces you to write files over files and no one wants that, so they fall back to primitive types. For the abstraction bloat it is actually similar. Here the reason is that for the longest time (and even nowadays) Java makes it painful to work with functions. So now instead of just a plain function, you have to create a class with an interface that has one method... and instantiate it. Great... not.

room271 6y ago

The problems stem from the lack of top-level functions; everything has to live within a class. In reality, classes (or 'modules' if you prefer) should be low-granularity things in most programs.

tomxor 6y ago

I've also seen plenty of horrifically deep layered stuff in PHP, and to a lesser extent JS. Just like Java, it's possible to write elegant well structured code in any of these languages (yes even PHP, even though I still hate PHP). And of course you can... purely in terms of organizing building blocks most object orientated languages are pretty much a super set. I think the problem is most people are not consciously aware that object orientated approaches are just a pattern, and like any pattern you shouldn't apply them to everything. Being built in to many languages gives the impression they are as fundamental as a loop or a function - those are technically still abstractions, but far more primitive and less subjectively applicable... Object oreanted patterns feel like they are in between domain specific and basic building blocks, the higher you go the more polarizing these become, trying to use a DSL will seem absurd for one thing extremely elegant for another - when classes fit they are beautiful, but when they are carelessly used as a default, they are annoying bags of loosely coupled functionality and data that only serves to obscure relationships. I'd speculate that the prevalence of poorly applied OOP is more to do with legacy and culture of the language along with the focus on how to use the language for newcomers.

hinkley 6y ago

There weren’t a lot of people with experience in OOAD, and all of a sudden we needed an army of Java developers. J2EE 1.0 came out, and was both over and under engineered (baroque and unworkable, which is ironic given the 7 fallacies come from their employer). And then Design Patterns came out, and it was all over but the crying.