7 ms·

Java Doesn't Need to Be So Bad

103 points by dugmartin 15y ago

resnamen 15y ago
It doesn't need to be so bad, but in larger organizations, it often is so bad. It just takes a few bad seeds of pattern-zealotry in an organization to poison the codebase into a God-awful mess. Once the patterns become a common practice, and every constructor has been dependency-injected ad nauseum (despite most interfaces having only ever having 1 implementation), there's just no going back.
- devonrt 15y ago
  It's not just larger organizations. I've seen exactly what you're citing — where even the most trivial objects were injected — in an organization with roughly 5 developers.
cemerick 15y ago
The "I Point the Finger at You, I Have Already Pointed it At Myself" section calls me out for sure… I personally have to live with the shame of a very clear and vivid memory wherein I circled objects that covered nearly four sheets of this paper and wrote, in my own hand and with a clear-head: "A good candidate for an abstract factory! :)" Eventually I realized that the emoticon was mocking me. Laughing at my presumptuousness, laughing at my premature optimization. 10-12 years ago, I was that guy trying to spot "patterns". Ugh. Hopefully my Clojure hacking will tip my karmic balance back to neutral.
- babebridou 15y ago
  I've got a serious mental contingency bomb setup to explode whenever my mind wanders and thinks about reflection. I think about it, the bomb explodes, I stand up and go for a walk and when I come back the whole thought process that lead me to consider reflection is wiped clean, ready for a fresh redesign from scratch. It's not that I don't see value in Reflection, it's just that I'm sick of debugging it. Abstractfactories are not that bad, actually if you're in the habit (like me) to always step in and write an interface before you start any abstract, you pretty soon understand why it's a good or bad idea - interfaces of factories are so damn trivial that even an abstractfreak will see this as redundant work and will want to write an interface of this factory interface and then a factory interface factory through code injection, preferrably through annotations, but it could be from other means such as a properties file or xml configuration, so they think about a factory interface abstract factory (and of course its interface). By then, even the craziest persons give up and just do their job.
btilly 15y ago
A good rule of thumb that has served me well. Never try to abstract something until I'm on my third implementation of something like it. The first time I lack context for what is likely to change. The second time you have to watch out for second system effect, adding all of the things you wanted in the first version. But the third time you tend to have the experience and knowledge to do it right. This is a rule of thumb that should be drilled into the heads of anyone who is even thinking of drinking the patterns kool-aid.
- nupark2 15y ago
  I have the same personal rule. Too often junior engineers think that the worst cardinal sin is to have a small amount of duplicated or less abstract than it could be code. This really isn't the case. Until you really understand the commonality of the problem, attempting to abstractly define the solution will make your future work all the more difficult when it turns out you didn't really understand all the edge cases and exceptions. Three use cases are a good number -- by that time you're much more likely to understand the problem, and by avoiding premature abstraction, you'll have an easier time doing the work.
  - cpeterso 15y ago
    Another problem is that Java and C++ developers often use class inheritance to share implementation code, even if the classes are not modeling proper is-a relationships.
    - agentgt 15y ago
      Actually I think a bigger problem is that Java programmers (not C++) create hundreds of interfaces. Thus Java becomes an artifact hell (EJB 2.0 was a nightmare). Abstract classes on the other hand are very useful but most Java programmers think... "well what if in the future I need...". If Java just had traits/mixins, closures, literals, and some syntax brevity it would be a pretty damn descent language... oh wait that's Scala.
      - 15y ago
revscat 15y ago
Java doesn't need to be, but frequently is. Non-reified generics with their ridiculously verbose syntax are the first thing that came to my mind. God forbid you should try to write your own class which uses them. Not to mention that since spending almost decade of my career working with Java I have since worked with languages that do not have generics, and have not suffered thereby. Generics are, IMO, largely unnecessary. Yes, this is a small subset of Java, but it is one that continually annoyed me.
- luriel 15y ago
  > Not to mention that since spending almost decade of my career working with Java I have since worked with languages that do not have generics, and have not suffered thereby. Generics are, IMO, largely unnecessary. This needs to be drilled into the heads of all the people complaining that Go has no generics before they have even tried to use it. (Also Go's interfaces overlap with many common uses of generics, and Go's useful builtin containers take care of most of the rest).
  - soc88 15y ago
    That people even had the idea that a "C replacement" doesn't need a way to define its own data structure is frightening.
- tsewlliw 15y ago
  Java generics _are_ ugly, but I'd rather write Java with them than without them.
  - SeanLuke 15y ago
    I'm quite the other way around.
ap22213 15y ago
Well, I for one frequently encounter places where the factory / interface / adapter paradigm is a good solution. And, it's not just to be clever. This typically occurs when 1) I am doing enterprise application development, and there are many different instantiations of a particular application, or 2) I am doing enterprise integration, and I have many different libraries and services to work with, sometimes legacy, and often with complex business logic that selects some over others. Granted, I've seen this pattern used all too often and seen over-abstraction, in general. But, I need to be brave and defend this, given that no one else seems to want to. It does have some legs. I use this when working with a lot of different teams / companies and coordinating them all and agreeing to how things will work in production. That's especially true when some of those teams / companies may be interchanged with others. This type of solution makes a lot of sense. However, I would much prefer a dynamic typed solution to avoid the unnecessary boilerplate. And, even better, I would prefer to work only with self-contained software companies that have complete control over their code-base and restrained domain logic. That would be awesome! (but wishful thinking).
swah 15y ago
We could have a poll... What percentage of folks use Java because they want vs because they must? Would you use Java for your startup? With which stack?
- hello_moto 15y ago
  Yes. In fact there's one idea that I'm sort of prototyping right now in which Java would be a nice fit due to WebService integration. Do I want or must use Java? Does not matter to me. The libraries (and their quality) help me write less code and make me feel comfortable (it is psychology, but it matters).
- smackfu 15y ago
  What percentage of working programmers even get to choose their language?

103 points by dugmartin 15y ago

It doesn't need to be so bad, but in larger organizations, it often is so bad. It just takes a few bad seeds of pattern-zealotry in an organization to poison the codebase into a God-awful mess. Once the patterns become a common practice, and every constructor has been dependency-injected ad nauseum (despite most interfaces having only ever having 1 implementation), there's just no going back.

devonrt 15y ago
It's not just larger organizations. I've seen exactly what you're citing — where even the most trivial objects were injected — in an organization with roughly 5 developers.

cemerick 15y ago

The "I Point the Finger at You, I Have Already Pointed it At Myself" section calls me out for sure… I personally have to live with the shame of a very clear and vivid memory wherein I circled objects that covered nearly four sheets of this paper and wrote, in my own hand and with a clear-head: "A good candidate for an abstract factory! :)" Eventually I realized that the emoticon was mocking me. Laughing at my presumptuousness, laughing at my premature optimization. 10-12 years ago, I was that guy trying to spot "patterns". Ugh. Hopefully my Clojure hacking will tip my karmic balance back to neutral.

babebridou 15y ago
I've got a serious mental contingency bomb setup to explode whenever my mind wanders and thinks about reflection. I think about it, the bomb explodes, I stand up and go for a walk and when I come back the whole thought process that lead me to consider reflection is wiped clean, ready for a fresh redesign from scratch. It's not that I don't see value in Reflection, it's just that I'm sick of debugging it. Abstractfactories are not that bad, actually if you're in the habit (like me) to always step in and write an interface before you start any abstract, you pretty soon understand why it's a good or bad idea - interfaces of factories are so damn trivial that even an abstractfreak will see this as redundant work and will want to write an interface of this factory interface and then a factory interface factory through code injection, preferrably through annotations, but it could be from other means such as a properties file or xml configuration, so they think about a factory interface abstract factory (and of course its interface). By then, even the craziest persons give up and just do their job.

btilly 15y ago

A good rule of thumb that has served me well. Never try to abstract something until I'm on my third implementation of something like it. The first time I lack context for what is likely to change. The second time you have to watch out for second system effect, adding all of the things you wanted in the first version. But the third time you tend to have the experience and knowledge to do it right. This is a rule of thumb that should be drilled into the heads of anyone who is even thinking of drinking the patterns kool-aid.

nupark2 15y ago
I have the same personal rule. Too often junior engineers think that the worst cardinal sin is to have a small amount of duplicated or less abstract than it could be code. This really isn't the case. Until you really understand the commonality of the problem, attempting to abstractly define the solution will make your future work all the more difficult when it turns out you didn't really understand all the edge cases and exceptions. Three use cases are a good number -- by that time you're much more likely to understand the problem, and by avoiding premature abstraction, you'll have an easier time doing the work.
- cpeterso 15y ago
  Another problem is that Java and C++ developers often use class inheritance to share implementation code, even if the classes are not modeling proper is-a relationships.
  - agentgt 15y ago
    Actually I think a bigger problem is that Java programmers (not C++) create hundreds of interfaces. Thus Java becomes an artifact hell (EJB 2.0 was a nightmare). Abstract classes on the other hand are very useful but most Java programmers think... "well what if in the future I need...". If Java just had traits/mixins, closures, literals, and some syntax brevity it would be a pretty damn descent language... oh wait that's Scala.
    - 15y ago

revscat 15y ago

Java doesn't need to be, but frequently is. Non-reified generics with their ridiculously verbose syntax are the first thing that came to my mind. God forbid you should try to write your own class which uses them. Not to mention that since spending almost decade of my career working with Java I have since worked with languages that do not have generics, and have not suffered thereby. Generics are, IMO, largely unnecessary. Yes, this is a small subset of Java, but it is one that continually annoyed me.

luriel 15y ago
> Not to mention that since spending almost decade of my career working with Java I have since worked with languages that do not have generics, and have not suffered thereby. Generics are, IMO, largely unnecessary. This needs to be drilled into the heads of all the people complaining that Go has no generics before they have even tried to use it. (Also Go's interfaces overlap with many common uses of generics, and Go's useful builtin containers take care of most of the rest).
- soc88 15y ago
  That people even had the idea that a "C replacement" doesn't need a way to define its own data structure is frightening.
tsewlliw 15y ago
Java generics _are_ ugly, but I'd rather write Java with them than without them.
- SeanLuke 15y ago
  I'm quite the other way around.

ap22213 15y ago

Well, I for one frequently encounter places where the factory / interface / adapter paradigm is a good solution. And, it's not just to be clever. This typically occurs when 1) I am doing enterprise application development, and there are many different instantiations of a particular application, or 2) I am doing enterprise integration, and I have many different libraries and services to work with, sometimes legacy, and often with complex business logic that selects some over others. Granted, I've seen this pattern used all too often and seen over-abstraction, in general. But, I need to be brave and defend this, given that no one else seems to want to. It does have some legs. I use this when working with a lot of different teams / companies and coordinating them all and agreeing to how things will work in production. That's especially true when some of those teams / companies may be interchanged with others. This type of solution makes a lot of sense. However, I would much prefer a dynamic typed solution to avoid the unnecessary boilerplate. And, even better, I would prefer to work only with self-contained software companies that have complete control over their code-base and restrained domain logic. That would be awesome! (but wishful thinking).

swah 15y ago

We could have a poll... What percentage of folks use Java because they want vs because they must? Would you use Java for your startup? With which stack?

hello_moto 15y ago
Yes. In fact there's one idea that I'm sort of prototyping right now in which Java would be a nice fit due to WebService integration. Do I want or must use Java? Does not matter to me. The libraries (and their quality) help me write less code and make me feel comfortable (it is psychology, but it matters).
smackfu 15y ago
What percentage of working programmers even get to choose their language?