4 ms·

> Why assume that everyone who touches Java code, uses an IDE to do so? Even Gosling admits that writing Java without an IDE is a fools errand.

by koolba 2y ago

vips7L 2y ago
Personally I don’t think Gosling is relevant to Java in 2024. It’s completely different from when he was involved.
- js8 2y ago
  I downvoted you; whether Gosling is relevant or not doesn't address the core argument that Java is hard to use without IDE.
  - vips7L 2y ago
    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.
derefr 2y ago
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.)
- ahachete 2y ago
  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,
  - derefr 2y ago
    > 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.

> Why assume that everyone who touches Java code, uses an IDE to do so? Even Gosling admits that writing Java without an IDE is a fools errand.

by koolba 2y ago

> Why assume that everyone who touches Java code, uses an IDE to do so? Even Gosling admits that writing Java without an IDE is a fools errand.

vips7L 2y ago

Personally I don’t think Gosling is relevant to Java in 2024. It’s completely different from when he was involved.

js8 2y ago
I downvoted you; whether Gosling is relevant or not doesn't address the core argument that Java is hard to use without IDE.
- vips7L 2y ago
  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.

derefr 2y ago

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.)

ahachete 2y ago
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,
- derefr 2y ago
  > 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.