4 ms·

That baggage is concentrated in one particular JVM language and is largely self-imposed. I write NLP software in Java without resorting to the AbstractFactoryF

That baggage is concentrated in one particular JVM language and is largely self-imposed. I write NLP software in Java without resorting to the AbstractFactoryFactory nonsense prevalent in the enterprise world.

tracker1 12y ago
It happens in both Java and the .Net world.. every time I see "Enterprise" with a product description it makes me cringe... A lot of those abstractions only serve to scenarios; 1) Unit Testing and 2) service/storage portability. In most cases, neither are actually done. In the first case, I find actually writing unit tests in JS to be SO MUCH* better than with .Net or Java. In the latter, YAGNI prevails in my mind. IT's entirely possible to work with "enterprise" platforms without using the excessive design patterns and abstractions, most simply don't. Not to mention that async being an option with C# for YEARS but most code I've seen even running on newer runtimes doesn't use it at all. Node works very well for I/O constrained loads, unless you're risking running out of memory. I actually prefer the node way, and when you favor functional flows over OO design patterns, it gets to be really nice.
- vonmoltke 12y ago
  Java certainly has its warts, but I still think nearly all of what you describe is cultural rather than technical. Whether it's slavish adherence to GoF patterns, or obsession with code coverage metrics, or religious devotion to OO purity it's about the culture of the developer and the team. Java and C#, unfortunately, are the predominant choices of the developers and teams who share this culture. It gives the languages an unfairly bad rap, one which I agreed with until I started my current job.
  - hinkley 12y ago
    You can take Java out of the enterprise, but you can't take the Enterprise out of Java. What's sad is a bunch of us saw this coming the moment a J2EE spec first came out, and complained loudly that it was a trap, to no avail. Version 1 was written by grad students who had no idea what the 7 Fallacies were. Version 2 was so complicated only a few big companies could implement it. It was a sad trainwreck that was hard to watch. And then Spring was supposed to save us all, and now it's more complicated than any of the things it replaced. Which is why I do a lot of front-end code these days.
    - jessaustin 12y ago
      Version 1 was written by grad students who had no idea what the 7 Fallacies were. At the risk of appearing a grad student, what were those?
      - hinkley 12y ago
        http://en.wikipedia.org/wiki/Fallacies_of_distributed_computing http://en.wikipedia.org/wiki/Fallacies_of_distributed_comput... The interesting thing about the 7 fallacies is that we constantly find new ways to make the same mistakes. If we've been doing decentralized computing, someone thinks they can fix all of our problems by centralizing it. If we're in a centralized phase, someone thinks we can solve all our problems by decentralizing it. Exactly like the node and microservices people are doing right now. If you want a front row seat to the next pendulum swing, start learning everything you can about centralized software models now. You'll be sitting pretty in three years when the backswing starts. Maybe we'll try software transactional memory again.
        tracker1 12y ago
        I think that breaking things apart can be very beneficial though... You can run microservices on the same system physically, and give preference to a local service. This does increase complexity of orchestration, but it's still beneficial. Most people wouldn't implement their own local database for a service that has to handle many thousands of simultaneous requests... yeilding to a RDBMS. By the same vein micro-services allow a similar distribution based on a type of work. There's also a difference between writing a handful of microservices, which are a bit more broad vs. breaking every action into it's own service. Beyond this, if you can separate out of band actions via queues this can alleviate a lot. One thing that does get me is how many services are using a SOAP or even REST interface over HTTP vs something lighter. In my current project the backend services operate over 0mq req/res interfaces, while the front-end will communicate over a REST composite interface. In this way there's less disconnect and overhead. It's always a trade-off, but that doesn't mean an approach doesn't have merrit, it's just a matter of striking a balance. Which I would guess is the whole point of all of this.
wlievens 12y ago
Same here! It's perfectly possible to write quality Java code, without trying to cram everything into Spring.
- vonmoltke 12y ago
  Or treating the GoF book as a bible, which is my personal pet peeve.

tracker1 12y ago

It happens in both Java and the .Net world.. every time I see "Enterprise" with a product description it makes me cringe... A lot of those abstractions only serve to scenarios; 1) Unit Testing and 2) service/storage portability. In most cases, neither are actually done. In the first case, I find actually writing unit tests in JS to be SO MUCH* better than with .Net or Java. In the latter, YAGNI prevails in my mind. IT's entirely possible to work with "enterprise" platforms without using the excessive design patterns and abstractions, most simply don't. Not to mention that async being an option with C# for YEARS but most code I've seen even running on newer runtimes doesn't use it at all. Node works very well for I/O constrained loads, unless you're risking running out of memory. I actually prefer the node way, and when you favor functional flows over OO design patterns, it gets to be really nice.

vonmoltke 12y ago
Java certainly has its warts, but I still think nearly all of what you describe is cultural rather than technical. Whether it's slavish adherence to GoF patterns, or obsession with code coverage metrics, or religious devotion to OO purity it's about the culture of the developer and the team. Java and C#, unfortunately, are the predominant choices of the developers and teams who share this culture. It gives the languages an unfairly bad rap, one which I agreed with until I started my current job.
- hinkley 12y ago
  You can take Java out of the enterprise, but you can't take the Enterprise out of Java. What's sad is a bunch of us saw this coming the moment a J2EE spec first came out, and complained loudly that it was a trap, to no avail. Version 1 was written by grad students who had no idea what the 7 Fallacies were. Version 2 was so complicated only a few big companies could implement it. It was a sad trainwreck that was hard to watch. And then Spring was supposed to save us all, and now it's more complicated than any of the things it replaced. Which is why I do a lot of front-end code these days.
  - jessaustin 12y ago
    Version 1 was written by grad students who had no idea what the 7 Fallacies were. At the risk of appearing a grad student, what were those?
    - hinkley 12y ago
      http://en.wikipedia.org/wiki/Fallacies_of_distributed_computing http://en.wikipedia.org/wiki/Fallacies_of_distributed_comput... The interesting thing about the 7 fallacies is that we constantly find new ways to make the same mistakes. If we've been doing decentralized computing, someone thinks they can fix all of our problems by centralizing it. If we're in a centralized phase, someone thinks we can solve all our problems by decentralizing it. Exactly like the node and microservices people are doing right now. If you want a front row seat to the next pendulum swing, start learning everything you can about centralized software models now. You'll be sitting pretty in three years when the backswing starts. Maybe we'll try software transactional memory again.
      - tracker1 12y ago
        I think that breaking things apart can be very beneficial though... You can run microservices on the same system physically, and give preference to a local service. This does increase complexity of orchestration, but it's still beneficial. Most people wouldn't implement their own local database for a service that has to handle many thousands of simultaneous requests... yeilding to a RDBMS. By the same vein micro-services allow a similar distribution based on a type of work. There's also a difference between writing a handful of microservices, which are a bit more broad vs. breaking every action into it's own service. Beyond this, if you can separate out of band actions via queues this can alleviate a lot. One thing that does get me is how many services are using a SOAP or even REST interface over HTTP vs something lighter. In my current project the backend services operate over 0mq req/res interfaces, while the front-end will communicate over a REST composite interface. In this way there's less disconnect and overhead. It's always a trade-off, but that doesn't mean an approach doesn't have merrit, it's just a matter of striking a balance. Which I would guess is the whole point of all of this.

wlievens 12y ago

Same here! It's perfectly possible to write quality Java code, without trying to cram everything into Spring.

vonmoltke 12y ago
Or treating the GoF book as a bible, which is my personal pet peeve.