> they first thing they tell you to do is to install an IDE
Yes, they do that because they assume — due to Java being a recommended first language — that they're talking to someone with literally no programming experience. An IDE for a particular language is something that you can just download and start using to write and build and run and debug code in that language. Thus integrated development environment. (And despite Java IDEs themselves being Java apps, they all ship as installers that install their own embedded JREs for the app to run with, and download JDKs on-demand for projects to bind to; so the newbie dev doesn't even need to know what a "language runtime" is or that Java is!)
The alternative, when crafting a video targeting newbie programmers, would be to explain to them — people who might or might not know what a terminal is, what a shell is, what a compiler is, what a JDK is and how to install one, how to invoke javac, what a build system is, how to pick one and set up its project file, how to select a code editor to use, how to save things with non-.txt file extensions and in the right directory structure to make the build system happy, how to invoke the resulting build, etc — how to do all of those (mostly language-neutral!) things, in order to bootstrap their way up to being able to create a single Java main class and run it.
But on the other hand, if you already know five or ten other programming languages when you learn Java — then you'll already have a favorite code editor (and will assume you can just tell it to install a language-support package for the new language); and you'll already know what compilers and build systems are, and will just want to know how those general concepts are implemented for this specific language; and you'll already know how to invoke those things from a shell or from a build script, and how to ask the compiler for its flags, and how to read its man page to figure out what env-vars it looks at; and will just look up the syntax reference for the build system's project metadata files and some examples in other projects, and have one knocked out in two minutes without ever reading its documentation; etc.
You'll know all these things, because these things are the lingua franca of development-time tooling abstractions — the things that stay the same no matter what specific alternate strategies a given language tries to get you to use. As you learn more languages, the language-specific tooling abstractions will drop away, irrelevant outside of their language; but anything you learn about the language-neutral tooling abstractions will be reinforced by each new language.
You'll learn more-and-more to lean on these language-neutral tooling abstractions when learning a new language, because with them, you'll get up to speed in the new language much faster; stumble less when context-switching languages; and have a confidence for "plumbing" tasks like "how should I dockerize this for reproducible builds and low start-up overhead" or "how do I build this in CI with caching" or "where would a linter pre-commit hook plug into this."
> I don't understand why you bothered
Because I consider the mass belief in the need for an IDE to write Java in particular to be "received folk wisdom" with no actual basis in evidence.
I am personally just as productive when writing Java without an IDE, as I am when coding in any other language not designed for an IDE. I know that; I can measure that.
But moreover, from ~20 years of interacting with other software engineers in various roles, my impression is that that most people who code in Java would also be just as productive without an IDE — provided that, like me, they have experience coding without an IDE (probably in a language that doesn't have good IDE support.)
From what I've observed, it's only the junior engineers, whose only fluent languages are IDE-reliant and so have never done non-IDE development, that truly benefit from a productivity boost when using IDEs. For them, the IDE is acting as training wheels — making them "more productive" insofar as without it, they wouldn't have a solid foundation of "programming reflexes" to rely on. And I mean that in multiple senses — it acts as training wheels for:
• their language-toolchain tooling reflexes (e.g. being able to quickly modify+build+test a thing without a hotkey that just "does that")
• their code-editing reflexes (e.g. knowing their editor well-enough to be able to quickly refactor one class into two with editing gestures rather than a language-specific macro);
• their language reflexes (e.g. building up an intuition for which stdlib package a given class lives in, to write imports quickly — or to take advantage of fully-qualified class names to avoid single-use imports!; being able to remember long method names by "compressing" them, using the library of commonly-used identifier fragments in your head; remembering what parameters a given ADT's methods take by building a greater sense of how those APIs analogize to APIs in other languages; etc.)
> as if you are showing off or something
I was citing my own personal experience as an existence proof of how it's possible to be productive in Java without an IDE, because anecdata is at least better than no data at all. But I didn't mean to suggest I was exceptional; of my other engineer friends who code in multiple languages, not a one of them pulls out an IDE for IDE-supportive languages.
Do you interpret Morpheus to be bragging when he describes to Neo what's outside of the Matrix? My goal here is the same: to point out that your belief in IDEs being more productive might be due more to being in a programming-culture bubble; and that there is a world outside that bubble that believes something different.
> waste your time writing such a long comment
I (and from my observation, many others) use HN comments mostly as a space for blogging. Specifically, for "shooting from the hip" blog posts — the kind where I don't like them enough to spend time polishing it and condensing it to post it onto an actual blog.