10 ms·

The problem is one that I've witnessed, but uh: > Good Java should resemble C The recommendations are a mixture of things that are... questionable, and things

The problem is one that I've witnessed, but uh: > Good Java should resemble C The recommendations are a mixture of things that are... questionable, and things that really apply to basically any big refactor regardless of paradigm, language, or problem. But getting back to the issue at hand: what I see from the Java/C# world is a mentality of "abstract unless there's a reason not to", instead of "don't abstract unless there's a reason to". Charitably, this approach might be compared to the micro services pattern: if you're shipping your org chart, and your org chart is thousands of people across four continents, then maybe eagerly building out those fire-walls of decoupling can be useful. Stereotypically, at least, this seems to line up with the kinds of companies we tend to think of as using these languages. But where it becomes a big problem is when it's used in a one, two, five-person project, and all those walls just become massive speedbumps, not only slowing you down but making it hard to drive straight.

raducu 6y ago
> A well-considered class should own an interesting decision and the data needed to make it, not just one or the other. This is not about abstract/non-abstract, Java, C or C# . This is about 99% of people not being able to write decent OOP code. This is not about "programmers" not getting that first awe inspiring feeling when they first see decent OOP code, it is about not caring, not event after 15+ years of programming OOP languages. This is why I always see endless @Service and @Entity code, completely separated, like it's 1996 and we have procedures and structures in Borland Pascal.
treve 6y ago
> Good Java should resemble C If that sentence from the article is the only thing you took issue with, I'd wager you interpret it different than the author's intent. I took it as low on abstractions and mostly imperative.
- brundolf 6y ago
  It wasn't the only sentence I took issue with, it was just the one that raised my eyebrows the highest. > low on abstractions I feel with this that the author is going to the opposite extreme. The takeaway isn't that abstractions should be eliminated categorically, just that they have a cost and shouldn't be fetishized. > mostly imperative I take issue with this too, though this part may be more a matter of personal preference. Yes, it's worse when your imperative logic is split across 15 files, but I see imperative logic itself as something to be done sparingly. Imperative logic means mutation of state, means easy-to-lose-track-of side-effects, means unpredictable behavior. This is sometimes unavoidable at the systems level (where C is typically used), but it is absolutely avoidable at the application layer (where Java is typically used). Here's another one that raised a red flag: > A well-considered class...should be easy to name, ideally with a noun that corresponds to something in the real world with a lifecycle of its own. Real-world-modeling was found a long time ago to be a bad approach to OOP. The author is right to say that classes should represent clearly distinct concepts that are easy to name, but there's no reason those concepts also need to map to real-world entities. Often, they shouldn't.
  - JamesBarney 6y ago
    >means unpredictable behavior There is something to be said about making sure it's clear where and when state mutates. But functional code has it's own set of pitfalls. I've seen otherwise good devs struggle like crazy reasoning about complex functional code. (Especially when it comes to performance) > Real-world-modeling was found a long time ago to be a bad approach to OOP. The author is right to say that classes should represent clearly distinct concepts that are easy to name, but there's no reason those concepts also need to map to real-world entities. Often, they shouldn't. I 100% disagree with this. Most applications are modeling domain logic and business processes as code. And ideally as many of your classes as possible refer to a concept or should translate to simple and understandable objects in your domain. In an ideal world every class would be named after a concept/entity your domain expert understands and uses. *Unless you read real world objects as physical objects, but I think the author meant real world as in domain concepts.
- commandlinefan 6y ago
  Yeah, from the title, I initially agreed with him, but although he's definitely right that over-abstraction leads to some horribly painful Java code, he seems to be arguing in favor of the other extreme: an abomination that I've been seeing more and more of in the past five or six years where nothing is a class unless it absolutely has to be (i.e. when unmarshalling XML or JSON or reading data from an ORM). In Java, this means that everything is declared static, including data. And in a horrible, unholy way, it does resemble C, right down to the non-thread-safety.
philliphaydon 6y ago
> But getting back to the issue at hand: what I see from the Java/C# world is a mentality of "abstract unless there's a reason not to", instead of "don't abstract unless there's a reason to". When I was starting out and reading lots of books and blogs this was very much my mindset. Must use all the patterns!!! But after working on a huge code base with many many many layers of abstraction, I now am of the mindset of just keeping it dead simple. If I need to get something from the database. Just get it. Introduce an abstraction when it’s needed. It’s easy to add an abstraction, it’s harder to take it away.
- oefrha 6y ago
  Obligatory “huge” code base with many many layers of abstraction: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
  - tacker2000 6y ago
    This is hilarious!
- raducu 6y ago
  Cargo cult. One interface per one concrete class. It drove me nuts, it still drives me nuts that we are still having debates about it in 2020.
  - kevin_thibedeau 6y ago
    What's more annoying is when they import this into other languages that aren't hobbled by the design features of Java.
    - waheoo 6y ago
      "modern" PHP frameworks suffer from this idiocy to no end. I'm sold on "pure PHP" but you can get a hell of a lot done with a few simple libraries and avoiding all the bullshit pushing you into classes. Typescript is quickly falling down this rabbit hole as well.
cosmodisk 6y ago
I run a small codebase,where 99% of code is done and dusted and very unlikely to be revisited for years to come. Most of it is written as one off solutions. Could I have written with all the abstractions? Would it have helped?No. So here I am, sitting and thinking whether I'm stupid not to or whether I simply saved the business from using countless hours of unnecessary abstraction.
- jmnicolas 6y ago
  2 weeks ago was my 11th birthday as the sole developper in my workplace. I embraced KISS maybe 2 or 3 years after starting at this company. I NEVER regretted it. I still maintain a few projects started in my non KISS period. I regret every time I have to touch the code base. Of course YMMV.
  - Consultant32452 6y ago
    My version of this philosophy is, "Write code a junior developer can maintain." That means unless absolutely necessary don't use unusual language features, use the most common framework on the market for that problem set, no unnecessary abstractions, etc. So far it seems to work well.
    - imtringued 6y ago
      Programming languages are like any other language. If you use lots of complicated words every time, nobody will understand you.
- raducu 6y ago
  It goes both ways. I've seen beautiful abstractions that make a lot of sense, a la DDD that saved companies a lot of money. I've seen a senior architect almost shed a tear when I told him I loved the way he used the Bridge Design pattern in a project and how easy it was to implement some feature because of it (I don't remember the example.)
pjmlp 6y ago
Apparently it gets missed a lot that Java and C# build on top of C and C++ enterprise culture, which was bubbling with GUI frameworks, CORBA and COM/DOM when Java was designed, and later .NET followed on (given its origin). It feels so strange to make C++ a kind of better language, when it was one of the main creators of that abstraction culture. Naturally, in the last 20 years, the only C++ developers are those that didn't moved on, so now 90's C++ code gets coined with "writing Java in C++", the irony.
bird_monster 6y ago
> abstract unless there's a reason not to Is the _exact_ behavior I have seen in 100% of the Java and C# codebases I've used. > But where it becomes a big problem is when it's used in a one, two, five-person project, and all those walls just become massive speedbumps, not only slowing you down but making it hard to drive straight. I think that most patterns exist to prevent bad things from happening, or to make things easier to understand. I think that in a team of 1-5, there just isn't enough output happening to make either of those things huge concerns. If you're very small, there's not a ton of reason to try to protect yourself from future-scaries that don't exist in your company yet. And then, if the response is "But what about when we grow", that's literally the exact right time to abstract behavior. _As needed_.
cowsandmilk 6y ago
On the “Good Java should resemble C” front, I’ve jumped onto plenty of projects that had methods taking char and I guarantee you those methods were not easy to understand. And the debate on using typedefs to add type checking for things that are just an int underneath is alive and well just as wrapping an int in an object is in Java.

raducu 6y ago

> A well-considered class should own an interesting decision and the data needed to make it, not just one or the other. This is not about abstract/non-abstract, Java, C or C# . This is about 99% of people not being able to write decent OOP code. This is not about "programmers" not getting that first awe inspiring feeling when they first see decent OOP code, it is about not caring, not event after 15+ years of programming OOP languages. This is why I always see endless @Service and @Entity code, completely separated, like it's 1996 and we have procedures and structures in Borland Pascal.

treve 6y ago

> Good Java should resemble C If that sentence from the article is the only thing you took issue with, I'd wager you interpret it different than the author's intent. I took it as low on abstractions and mostly imperative.

brundolf 6y ago
It wasn't the only sentence I took issue with, it was just the one that raised my eyebrows the highest. > low on abstractions I feel with this that the author is going to the opposite extreme. The takeaway isn't that abstractions should be eliminated categorically, just that they have a cost and shouldn't be fetishized. > mostly imperative I take issue with this too, though this part may be more a matter of personal preference. Yes, it's worse when your imperative logic is split across 15 files, but I see imperative logic itself as something to be done sparingly. Imperative logic means mutation of state, means easy-to-lose-track-of side-effects, means unpredictable behavior. This is sometimes unavoidable at the systems level (where C is typically used), but it is absolutely avoidable at the application layer (where Java is typically used). Here's another one that raised a red flag: > A well-considered class...should be easy to name, ideally with a noun that corresponds to something in the real world with a lifecycle of its own. Real-world-modeling was found a long time ago to be a bad approach to OOP. The author is right to say that classes should represent clearly distinct concepts that are easy to name, but there's no reason those concepts also need to map to real-world entities. Often, they shouldn't.
- JamesBarney 6y ago
  >means unpredictable behavior There is something to be said about making sure it's clear where and when state mutates. But functional code has it's own set of pitfalls. I've seen otherwise good devs struggle like crazy reasoning about complex functional code. (Especially when it comes to performance) > Real-world-modeling was found a long time ago to be a bad approach to OOP. The author is right to say that classes should represent clearly distinct concepts that are easy to name, but there's no reason those concepts also need to map to real-world entities. Often, they shouldn't. I 100% disagree with this. Most applications are modeling domain logic and business processes as code. And ideally as many of your classes as possible refer to a concept or should translate to simple and understandable objects in your domain. In an ideal world every class would be named after a concept/entity your domain expert understands and uses. *Unless you read real world objects as physical objects, but I think the author meant real world as in domain concepts.
commandlinefan 6y ago
Yeah, from the title, I initially agreed with him, but although he's definitely right that over-abstraction leads to some horribly painful Java code, he seems to be arguing in favor of the other extreme: an abomination that I've been seeing more and more of in the past five or six years where nothing is a class unless it absolutely has to be (i.e. when unmarshalling XML or JSON or reading data from an ORM). In Java, this means that everything is declared static, including data. And in a horrible, unholy way, it does resemble C, right down to the non-thread-safety.

philliphaydon 6y ago

> But getting back to the issue at hand: what I see from the Java/C# world is a mentality of "abstract unless there's a reason not to", instead of "don't abstract unless there's a reason to". When I was starting out and reading lots of books and blogs this was very much my mindset. Must use all the patterns!!! But after working on a huge code base with many many many layers of abstraction, I now am of the mindset of just keeping it dead simple. If I need to get something from the database. Just get it. Introduce an abstraction when it’s needed. It’s easy to add an abstraction, it’s harder to take it away.

oefrha 6y ago
Obligatory “huge” code base with many many layers of abstraction: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
- tacker2000 6y ago
  This is hilarious!
raducu 6y ago
Cargo cult. One interface per one concrete class. It drove me nuts, it still drives me nuts that we are still having debates about it in 2020.
- kevin_thibedeau 6y ago
  What's more annoying is when they import this into other languages that aren't hobbled by the design features of Java.
  - waheoo 6y ago
    "modern" PHP frameworks suffer from this idiocy to no end. I'm sold on "pure PHP" but you can get a hell of a lot done with a few simple libraries and avoiding all the bullshit pushing you into classes. Typescript is quickly falling down this rabbit hole as well.

cosmodisk 6y ago

I run a small codebase,where 99% of code is done and dusted and very unlikely to be revisited for years to come. Most of it is written as one off solutions. Could I have written with all the abstractions? Would it have helped?No. So here I am, sitting and thinking whether I'm stupid not to or whether I simply saved the business from using countless hours of unnecessary abstraction.

jmnicolas 6y ago
2 weeks ago was my 11th birthday as the sole developper in my workplace. I embraced KISS maybe 2 or 3 years after starting at this company. I NEVER regretted it. I still maintain a few projects started in my non KISS period. I regret every time I have to touch the code base. Of course YMMV.
- Consultant32452 6y ago
  My version of this philosophy is, "Write code a junior developer can maintain." That means unless absolutely necessary don't use unusual language features, use the most common framework on the market for that problem set, no unnecessary abstractions, etc. So far it seems to work well.
  - imtringued 6y ago
    Programming languages are like any other language. If you use lots of complicated words every time, nobody will understand you.
raducu 6y ago
It goes both ways. I've seen beautiful abstractions that make a lot of sense, a la DDD that saved companies a lot of money. I've seen a senior architect almost shed a tear when I told him I loved the way he used the Bridge Design pattern in a project and how easy it was to implement some feature because of it (I don't remember the example.)

pjmlp 6y ago

Apparently it gets missed a lot that Java and C# build on top of C and C++ enterprise culture, which was bubbling with GUI frameworks, CORBA and COM/DOM when Java was designed, and later .NET followed on (given its origin). It feels so strange to make C++ a kind of better language, when it was one of the main creators of that abstraction culture. Naturally, in the last 20 years, the only C++ developers are those that didn't moved on, so now 90's C++ code gets coined with "writing Java in C++", the irony.

bird_monster 6y ago

> abstract unless there's a reason not to Is the _exact_ behavior I have seen in 100% of the Java and C# codebases I've used. > But where it becomes a big problem is when it's used in a one, two, five-person project, and all those walls just become massive speedbumps, not only slowing you down but making it hard to drive straight. I think that most patterns exist to prevent bad things from happening, or to make things easier to understand. I think that in a team of 1-5, there just isn't enough output happening to make either of those things huge concerns. If you're very small, there's not a ton of reason to try to protect yourself from future-scaries that don't exist in your company yet. And then, if the response is "But what about when we grow", that's literally the exact right time to abstract behavior. _As needed_.

cowsandmilk 6y ago

On the “Good Java should resemble C” front, I’ve jumped onto plenty of projects that had methods taking char and I guarantee you those methods were not easy to understand. And the debate on using typedefs to add type checking for things that are just an int underneath is alive and well just as wrapping an int in an object is in Java.