3 ms·

I don't think the argument itself is Java. I think the argument is that heavy, corporate projects (typically written in Java or C#) can have lots of benefit fro

I don't think the argument itself is Java. I think the argument is that heavy, corporate projects (typically written in Java or C#) can have lots of benefit from IDEs. This isn't to say that there aren't terminal utils that aren't powerful enough to handle such a project. But being able to Ctrl + Alt + LMB an interface and being taken to the implementation (or shown a list of all implementing classes) or pulling a graph of your DIs is damn delicious. It's those types of creature comforts that makes using an IDE worth it for me.

cphoover 8y ago
> "I don't think the argument itself is Java. I think the argument is that heavy, corporate projects (typically written in Java or C#) can have lots of benefit from IDEs." I think this for me is the gist of the problem... A lot of corporations prefer these large monolithic codebases, with a thousand different interfaces and abstract classes. I think this is a mistake in design, and prefer simple applications with simple interfaces. They are easy to maintain, and are more reliable as their are less moving pieces. I'd rather write a small app/service in python, c, JavaScript than work in some horrifically gargantuan and abstract Java code base. This is a problem with enterprise in general, they'd rather incur technical debt to stuff in new features into legacy monoliths, instead of designing small applications and services with simple interfaces.
- transpostmeta 8y ago
  Managing large businesses is complex, and requires complex software. Spreading the complexity between various codebases does not make the software less complex. Large codebases in COBOL, Java and C# are what make the world go round.
- oftenwrong 8y ago
  You seem to be under the impression that Java code bases are inherently "horrifically gargantuan and abstract". I would just like to say that is not the case - they are often like that, but they do not have to be. In my time, I have worked on many Java code bases that are small and simple, and not abstracted-to-hell.
- noxToken 8y ago
  It's not inherently a problem, but I do think that there are certain measures that can be taken to reduce code bloat, stack size, and development time. Someone else already noted that large business software can be a bit complicated solely based on the business needs. Regulatory rules and the ability to audit certain actions in the financial industry tend to add a bit of complexity to business logic, and those are completely unavoidable by law. However, some of this stuff is good practice that comes with boilerplate. A classic example is defining your services in interfaces with a separate class for the actual implementation. This means that even for services that will only be implemented once, you now have the class and an interface. But with an IDE (and since the mappings are clearly defined, I'm sure this wouldn't be a monumental task without a GUI), you write the interface, create a class to implement the interface, and the IDE generates your methods. That's minimal overhead for an IDE, but it require a bit of work on your part to manage in something like vim or emacs.
  - gambler 8y ago
    This has nothing to do with their core point. Yes, Java sucks. This doesn't prove that IDEs suck too. They make Java bearable. They can make editing simpler languages better as well.
    - noxToken 8y ago
      I think you misread or I didn't convey my point well enough. I'm not against IDEs. I think they definitely have their place and are a great tool for development.
- estsauver 8y ago
  I run a complex business. I can guarantee you that I would really prefer if it was a simple business with simple interfaces, dependencies and rules :) It really depends on how much resources your company has, what you're trying to do/prove/show, and how long you have to do it. Google gets idolized for their software, but the reason they can have so much perfection in their software is the amount of money their core business throws off, not the other way around.

cphoover 8y ago

> "I don't think the argument itself is Java. I think the argument is that heavy, corporate projects (typically written in Java or C#) can have lots of benefit from IDEs." I think this for me is the gist of the problem... A lot of corporations prefer these large monolithic codebases, with a thousand different interfaces and abstract classes. I think this is a mistake in design, and prefer simple applications with simple interfaces. They are easy to maintain, and are more reliable as their are less moving pieces. I'd rather write a small app/service in python, c, JavaScript than work in some horrifically gargantuan and abstract Java code base. This is a problem with enterprise in general, they'd rather incur technical debt to stuff in new features into legacy monoliths, instead of designing small applications and services with simple interfaces.

transpostmeta 8y ago
Managing large businesses is complex, and requires complex software. Spreading the complexity between various codebases does not make the software less complex. Large codebases in COBOL, Java and C# are what make the world go round.
oftenwrong 8y ago
You seem to be under the impression that Java code bases are inherently "horrifically gargantuan and abstract". I would just like to say that is not the case - they are often like that, but they do not have to be. In my time, I have worked on many Java code bases that are small and simple, and not abstracted-to-hell.
noxToken 8y ago
It's not inherently a problem, but I do think that there are certain measures that can be taken to reduce code bloat, stack size, and development time. Someone else already noted that large business software can be a bit complicated solely based on the business needs. Regulatory rules and the ability to audit certain actions in the financial industry tend to add a bit of complexity to business logic, and those are completely unavoidable by law. However, some of this stuff is good practice that comes with boilerplate. A classic example is defining your services in interfaces with a separate class for the actual implementation. This means that even for services that will only be implemented once, you now have the class and an interface. But with an IDE (and since the mappings are clearly defined, I'm sure this wouldn't be a monumental task without a GUI), you write the interface, create a class to implement the interface, and the IDE generates your methods. That's minimal overhead for an IDE, but it require a bit of work on your part to manage in something like vim or emacs.
- gambler 8y ago
  This has nothing to do with their core point. Yes, Java sucks. This doesn't prove that IDEs suck too. They make Java bearable. They can make editing simpler languages better as well.
  - noxToken 8y ago
    I think you misread or I didn't convey my point well enough. I'm not against IDEs. I think they definitely have their place and are a great tool for development.
estsauver 8y ago
I run a complex business. I can guarantee you that I would really prefer if it was a simple business with simple interfaces, dependencies and rules :) It really depends on how much resources your company has, what you're trying to do/prove/show, and how long you have to do it. Google gets idolized for their software, but the reason they can have so much perfection in their software is the amount of money their core business throws off, not the other way around.