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.)
My experience is that you are slower/way slower without an IDE.
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,
> sure, there's ways to hack them to do some subset of those things, but that takes a lot of setup time
The things I mentioned (local symbol auto-complete, reference-chasing, global go-to-symbol) are things that modern code editors do by default for any programming language they can syntax-highlight. (And also, unlike with an IDE, they don't require any understanding of a particular "project" format to do so. You can git-clone any random repo, throw it at them, and they'll see a directory tree of source files and blindly index everything in it.)
> ask the IDE to do a refactor of some code, remove unused dependencies,
Honestly, I think I just... haven't ever felt the need to do these things in Java?
When I'm fixing bugs, I'm usually just rewriting one line that calls something to call something else instead. Or adding a check for an edge-case. Or wrapping a blocking call in a semaphore or worker pool. Or making something more idiot-proof by replacing a primitive `int numSeconds` with a Duration. 99% of my "coding" time for a Java problem is actually spent investigating whatever heisenbug brought the problem to me (usually after already passing through a coworker's IDE's debugger, to no avail.) The actual solution I arrive at after such investigation, is usually trivial.
Which is to say, I write Java code, but I never really need to maintain any. I'm not on the team that owns the codebase; I'm just a pinch-hitter there to quickly fix customer-facing DevOps issues discovered in prod.
And, at least for that role — which might admittedly be an unusual one for a Java project — I don't think an IDE would help me get problems solved any faster than I already solve them.
> The things I mentioned (local symbol auto-complete, reference-chasing, global go-to-symbol) are things that modern code editors do by default for any programming language they can syntax-highlight
They can suggest some code, but they are like a dumb autocomplete. Your next sentence about understanding the project itself is the whole point - intellij can give me suggestions for my backend’s endpoints when I write the frontend, and clicking on such a href will jump to the controller.
It’s a pretty magical experience and I would even go as far that I would dare claim I’m writing Java code faster thanks to such a superior IDE than I would write some less verbose other PL.
Modern editors with good Java support, while not being full-fledged IDEs, rely on a Java language server. They don't blindly index .java files in a directory. It is also very desirable to index external dependencies.
> The things I mentioned (local symbol auto-complete, reference-chasing, global go-to-symbol) are things that modern code editors do by default for any programming language
Sure, they can. But as said, they are still quite basic stuff compared to what IDEs do. It's better than nothing, but they don't contribute to productivity as IDEs do.
> Honestly, I think I just... haven't ever felt the need to do these things in Java?
This is surprising for me, but hey, each of us are a different use case.
My recommendation is to try an IDE extensively, and then you decide what suits you better. I did this, and never looked back (for Java programming; I'm still using Vim extensively for general text edition, for example).
As someone who really likes IDE's especially since Java has such good free ones like intejilli I think they are awesome but for changing one line of code it's overkill. I often just use online editors for quick stuff if I can.
Most people write Java with an IDE. In fact, if you search for Java tutorials on YouTube, they first thing they tell you to do is to install an IDE. In other words, I don't understand why you bothered to waste your time writing such a long comment that are not applicable and have no use to others, as if you are showing off or something.
> 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.
It’s not hard. I’ve done it in neovim and vscode. Evoking Gosling as if his opinion matters more when he isn’t involved in Java made my comment relevant.
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.)