| I mean, I wasn't being facetious; I am the person I described. I code Java (the 10% of the time that I have to touch it) using Sublime Text and a terminal. Never learned an IDE. I still seem to get things done faster than the IDE people I know. Admittedly, it was slow going for a few days when I first was asked to help with the Java codebase. I had never written Java professionally — and I had even (inconveniently) missed out on ever having to write it for school. But, given that I was already familiar with a number of other languages and their ecosystems (including newer languages influenced by Java!), I could mostly guess what stdlib ADTs and ecosystem libraries probably exist in Java, find them with quick searching when reaching for them, and read the online auto-generated JavaDoc documentation — where and when it existed — to figure out what classes and methods I would need to use to achieve the effect I was picturing. Once I knew the types and their methods and used them a few times, I didn't need any reference for them any more. (Though I should point out that I wasn't entirely without help; these days, even non-IDE code editors like VSCode or Sublime Text, give you some level of project-level fuzzy symbol search, constant/method/identifier auto-complete, reference/definition chasing, etc. They're just limited in their knowledge to the set of symbols they can extract from the code of the project itself — with no access to the "unreferenced" symbols that an IDE would be loading from the runtime and any project-referenced libraries.) In learning Java this way, my only actual problem really did come down to the slap-shod nature of JavaDoc documentation! After languages like Elixir, where the docs for literally every version of every package, plus every version of the runtime itself live together on one website (hexdocs.pm) — in a uniform format, and with community conventions for providing usage examples as runnable doc-tests — Java's third-party library docs living on random websites or not even web-published at all was both painful and somewhat mystifying to me at the time. I do understand now in retrospect, that this is mostly down to Java library authors expecting you to use an IDE... but even then, I still find the lack of care many library authors put into maintaining standardized online documentation very odd. I like to look at the API of a library package as part of comparing/contrasting it to other library packages when deciding which one I should be using — which Java's documentation ecosystem often makes nearly impossible. (Even with a Java IDE, you'd have to create a project that has all of these libraries as dependencies — which might be impossible given dependency conflicts! — just to be able to do that.) (But hey, it's still better than Python's documentation ecosystem.) |
I'm myself a CLI person, and I'd consider myself quite proficient using the shell and console editors like Vim. I know many shortcuts and I manage myself quite well and very fast there.
However, when I do Java development I use an IDE. There's so many things that an IDE does that regular text editors don't (sure, there's ways to hack them to do some subset of those things, but that takes a lot of setup time and they'll always be a subset). Programming efficiency is not about typing fast or speeding up moving a paragraph of code to the end of the file by doing d-}-G-p; but rather to ask the IDE to do a refactor of some code, remove unused dependencies, click on a method to see it's definition or get contextual JavaDoc, to name a few (basic) features that IDE give you,