6 ms·

Java also seems to bring with it a lot of cultural baggage for bloated design thinking, like needing overkill factory patterns, accessor patterns, and more. If

by mlthoughts2018 6y ago

Java also seems to bring with it a lot of cultural baggage for bloated design thinking, like needing overkill factory patterns, accessor patterns, and more. If you start creating something called AbstractMonthlyBillingReportAggregatorFactory that inherits from AbstractBillingReportFactory that inherits from AbstractReportFactory all of which implement a Report interface, things have gone unsalvageably far off the rails to be useful any more. It’s fair to say you could do this same thing in C++ or Python etc., and sometimes that does happen. But just anecdotally observing this in many companies, it happens _on purpose_ with Java all the time, but much less so in other ecosystems. In other systems it’s just much easier to get things done without resorting to tons of inheritance misdirection, and many great common libraries already solve problems in those ecosystems with minimal inheritance bloat, giving lots of easy to follow examples.

the_af 6y ago
This is true about enterprisey patterns, which for some reason plague Java more than other languages. I think it's a flaw of the moment in time when Java became ubiquitous -- I mean, it still runs most software than many fashionable technologies these days, but it's not as dominant as it used to be -- rather than the language itself. Modern Java doesn't look like that, but indeed older software built with it did. These are fashions in the software engineering world. Had Ruby dominated the development world at the time Java did, you would have seen the same enterprisey patterns.
- mlthoughts2018 6y ago
  I think that’s largely true, but not completely. It just turns out that certain language features sincerely matter more for business software, such as rapidly mutating object & data models without needs to update them as a ripple effect through other designs in the system, and the ability to trade-off safety or correctness as resources just like memory or runtime complexity, which Java as a language is just not set up to do easily.
  - the_af 6y ago
    Maybe my brain is slow today, so please excuse me if this is not what you're saying. Are you arguing that Java is not set up to "do easily" business software or rapidly mutating data structures? Because Java as a battle tested platform has evolved many cool features for exactly those cases. There are even commercial pauseless garbage collectors (and the noncommercial ones are pretty advanced, too). Java and the JVM run circles around many of the technologies that became fashionable later, such as Ruby or the many javascript frameworks. For an article about "stick to boring and reliable" there seems to be too much push back against Java. I understand the psychological processes involved: stick to boring unless it's the one technology one personally finds unpalatable -- for me that would be COBOL or ColdFusion (and yes, I'm aware Java has been compared to COBOL by proponents of trendier technologies! :P )
    - mlthoughts2018 6y ago
      A reliance on object orientation as a non-negotiable language requirement is intrinsically antithetical to efficiency for business software. If a language supports what I would call “lightweight OO” - extremely low boiler plate, zero required OO constructs (purely optional), and language features that render the concept of dependency injection intrinsically obsolete (because mocking can be done purely through introspection at no cost), then that flavor of OO is well suited for business problems. It has less to do with things like JVM or GC oddities, because those can be straightforwardly engineered around. It’s more about what non-negotiable commitments to specific patterns or strategies come along with the language choice. Pure functional languages are the worst offenders in this area, which is why their benefits aren’t actually benefits and they are poorly suited for business software. Of the core “industry standard languages” Java would be the next worst offender. Conversely, I think C# is an ecosystem that suffered the same limitations as Java but found ways to extend and reinvent that make it more attractive now, though still far behind Python, C and C++.
      - the_af 6y ago
        > A reliance on object orientation as a non-negotiable language requirement is intrinsically antithetical to efficiency for business software. and > Pure functional languages are the worst offenders in this area, which is why their benefits aren’t actually benefits and they are poorly suited for business software. Of the core “industry standard languages” Java would be the next worst offender. You seem to be talking out of principle instead of actually having hands-on experience developing large systems in Java. To be honest, it doesn't seem you're familiar with the language or the platform. I'm not interested in debating your theoretical preconceptions.
- dnautics 6y ago
  > Which for some reason plague Java more than other languages. Is the reason a mystery? Java is the language that got a multibillion dollar marketing pitch at its inception. It was designed to be in "the enterprise" from day 1.
  - the_af 6y ago
    I'm not saying it's exactly a mystery. Java had the misfortune of being ubiquitous when XP and design patterns became all the rage. Every intern using Java had to learn "patterns", and schools where teaching them too. Heavyweight frameworks like Spring (and before that, EJBs( were all the rage too. It took a lot to extricate modern Java from that situation.
    - dnautics 6y ago
      sorry i think I misinterpreted when you said "for some reason"

the_af 6y ago

This is true about enterprisey patterns, which for some reason plague Java more than other languages. I think it's a flaw of the moment in time when Java became ubiquitous -- I mean, it still runs most software than many fashionable technologies these days, but it's not as dominant as it used to be -- rather than the language itself. Modern Java doesn't look like that, but indeed older software built with it did. These are fashions in the software engineering world. Had Ruby dominated the development world at the time Java did, you would have seen the same enterprisey patterns.

mlthoughts2018 6y ago
I think that’s largely true, but not completely. It just turns out that certain language features sincerely matter more for business software, such as rapidly mutating object & data models without needs to update them as a ripple effect through other designs in the system, and the ability to trade-off safety or correctness as resources just like memory or runtime complexity, which Java as a language is just not set up to do easily.
- the_af 6y ago
  Maybe my brain is slow today, so please excuse me if this is not what you're saying. Are you arguing that Java is not set up to "do easily" business software or rapidly mutating data structures? Because Java as a battle tested platform has evolved many cool features for exactly those cases. There are even commercial pauseless garbage collectors (and the noncommercial ones are pretty advanced, too). Java and the JVM run circles around many of the technologies that became fashionable later, such as Ruby or the many javascript frameworks. For an article about "stick to boring and reliable" there seems to be too much push back against Java. I understand the psychological processes involved: stick to boring unless it's the one technology one personally finds unpalatable -- for me that would be COBOL or ColdFusion (and yes, I'm aware Java has been compared to COBOL by proponents of trendier technologies! :P )
  - mlthoughts2018 6y ago
    A reliance on object orientation as a non-negotiable language requirement is intrinsically antithetical to efficiency for business software. If a language supports what I would call “lightweight OO” - extremely low boiler plate, zero required OO constructs (purely optional), and language features that render the concept of dependency injection intrinsically obsolete (because mocking can be done purely through introspection at no cost), then that flavor of OO is well suited for business problems. It has less to do with things like JVM or GC oddities, because those can be straightforwardly engineered around. It’s more about what non-negotiable commitments to specific patterns or strategies come along with the language choice. Pure functional languages are the worst offenders in this area, which is why their benefits aren’t actually benefits and they are poorly suited for business software. Of the core “industry standard languages” Java would be the next worst offender. Conversely, I think C# is an ecosystem that suffered the same limitations as Java but found ways to extend and reinvent that make it more attractive now, though still far behind Python, C and C++.
    - the_af 6y ago
      > A reliance on object orientation as a non-negotiable language requirement is intrinsically antithetical to efficiency for business software. and > Pure functional languages are the worst offenders in this area, which is why their benefits aren’t actually benefits and they are poorly suited for business software. Of the core “industry standard languages” Java would be the next worst offender. You seem to be talking out of principle instead of actually having hands-on experience developing large systems in Java. To be honest, it doesn't seem you're familiar with the language or the platform. I'm not interested in debating your theoretical preconceptions.
dnautics 6y ago
> Which for some reason plague Java more than other languages. Is the reason a mystery? Java is the language that got a multibillion dollar marketing pitch at its inception. It was designed to be in "the enterprise" from day 1.
- the_af 6y ago
  I'm not saying it's exactly a mystery. Java had the misfortune of being ubiquitous when XP and design patterns became all the rage. Every intern using Java had to learn "patterns", and schools where teaching them too. Heavyweight frameworks like Spring (and before that, EJBs( were all the rage too. It took a lot to extricate modern Java from that situation.
  - dnautics 6y ago
    sorry i think I misinterpreted when you said "for some reason"