> By not using an IDE, you have to remember the syntax of the language you are using, the subroutines from your own project and their arguments. You also remember (standard-)library subroutines better for your chose programming language.
Use an IDE, and discover + learn the syntax by being assisted. Start biking on a unicycle, and fail.
> When you have to manually find a file to change a subroutine implementation, or to refactor a subroutine, you will have good file names and a good directory structure. The Antipattern of the directory layout of your typical Java Enterprise Project is a Testament to this. (src/main/java/org/company/product/...)
There were no IDEs for Java when it started. And it immensely structured everything. Not having an IDE doesn't mean anything about naming.
> With big projects, it might slow you down to have the IDE load the entire project before you can start working. Some Projects with 40000+ files might take >5 minutes to load.
But in return you'll get something that will tell you what's going on, or even do hot code swaps, saving you a lot more than those 5 min.
> This is almost always the result of bad language design and/or bad library design. An example is developing android apps in Java with Android studio. Here, you will be slowed down a great deal in order to program without Android Studio. There will be a steep learning curve.
The IDE does more than just edit code. Welcome to different resolutions, devices, etc. Please tell me you'd rather have the device mess of J2ME // Symbian.
> Good Open Source Projects encourage people to clone, fork, and maybe even to contribute to a Project. People are able to directly edit files on github, if an IDE is not required and they know the language being used. Not requiring an IDE makes it easier for blind people, who might be using screenreaders to understand your project, and enables people without modern hardware (which might be unable/impractical to run an IDE) to work on your project.
IDEs have makefiles / build.xml / whatever. You're totally uninformed
> Have you ever seen a Java Enterprise Project? Sometimes the Java classes in there have 20+ import statements, automatically generated by the IDE. Working in this style, with such long package names and lots of classes/namespaces eventually almost forces you to use an IDE because there is just so much, that it becomes impractical to remember.
All Java IDEs support maven or whatever is popular right now.
> Not having Autocomplete / Code Generation guides you naturally to writing more compact and idiomatic Code in the Language of your Choice. It helps you to learn language-specific features and syntactic sugar.
That's a language design issue.
In Java, there is the Concept of Getters, Setters, toString, hashCode and so on. These methods can be auto-generated by the IDE.
In practise, this leads to bloat. The IDE is simply compensating for missing language features (built-in hashing of a composite data type, built-in string representation ).
Java fields themselves, along with their setters and getters, are entry points in which to control via annotations whether properties are read-only, write-only, or read/write in multiple contexts (e.g. Spring Configuration, JSON de/serialization), how they're serialized in JSON (serialized type can be different, field name can be adjusted), field ordering, and human readability.
Just thinking setters and getters set and get the property is naive and retrograde.
Agreed. And, also, who cares? Yes, Java is a mediocre language and way too verbose. I spend a bunch of time in Java and I don't notice the worst of that because I (like literally every Java dev I know) use an IDE. You shouldn't separate a language from the standard tooling it comes with/enables - they're intertwined.
Use an IDE, and discover + learn the syntax by being assisted. Start biking on a unicycle, and fail.
> When you have to manually find a file to change a subroutine implementation, or to refactor a subroutine, you will have good file names and a good directory structure. The Antipattern of the directory layout of your typical Java Enterprise Project is a Testament to this. (src/main/java/org/company/product/...)
There were no IDEs for Java when it started. And it immensely structured everything. Not having an IDE doesn't mean anything about naming.
> With big projects, it might slow you down to have the IDE load the entire project before you can start working. Some Projects with 40000+ files might take >5 minutes to load.
But in return you'll get something that will tell you what's going on, or even do hot code swaps, saving you a lot more than those 5 min.
> This is almost always the result of bad language design and/or bad library design. An example is developing android apps in Java with Android studio. Here, you will be slowed down a great deal in order to program without Android Studio. There will be a steep learning curve.
The IDE does more than just edit code. Welcome to different resolutions, devices, etc. Please tell me you'd rather have the device mess of J2ME // Symbian.
> Good Open Source Projects encourage people to clone, fork, and maybe even to contribute to a Project. People are able to directly edit files on github, if an IDE is not required and they know the language being used. Not requiring an IDE makes it easier for blind people, who might be using screenreaders to understand your project, and enables people without modern hardware (which might be unable/impractical to run an IDE) to work on your project.
IDEs have makefiles / build.xml / whatever. You're totally uninformed
> Have you ever seen a Java Enterprise Project? Sometimes the Java classes in there have 20+ import statements, automatically generated by the IDE. Working in this style, with such long package names and lots of classes/namespaces eventually almost forces you to use an IDE because there is just so much, that it becomes impractical to remember.
All Java IDEs support maven or whatever is popular right now.
> Not having Autocomplete / Code Generation guides you naturally to writing more compact and idiomatic Code in the Language of your Choice. It helps you to learn language-specific features and syntactic sugar.
That's a language design issue.
In Java, there is the Concept of Getters, Setters, toString, hashCode and so on. These methods can be auto-generated by the IDE. In practise, this leads to bloat. The IDE is simply compensating for missing language features (built-in hashing of a composite data type, built-in string representation ).
That's a language design issue.
What a shit article