5 ms·

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 patter

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.

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.