6 ms·

> I built Docland because I constantly found it frustrating to locate and view API definitions when programming. You'd have to Google the function/class name, s

> I built Docland because I constantly found it frustrating to locate and view API definitions when programming. You'd have to Google the function/class name, skip all the SEO articles, find the page you want, yet the documentation might be poorly formatted or does not support searching. Well you can tell Intellij to just download the sources of libraries used in your project, and then it's ctrl-q on a method to see its javadoc. I did not look at your project, presumably it does something more to add value to this?

martin_dd 2y ago
Author here. The value add is a better browsing experience: with Docland, you can navigate across the class hierarchy, search symbols quickly, and view the package content at a glance. Feel free to check it out!
derefr 2y ago
Why assume that everyone who touches Java code, uses an IDE to do so? If you write code 90% of the time in a frontend or scripting or other kind of language where a lightweight code editor like VSCode is the peak of productivity — and then have to fix bugs in a Java codebase the other 10% of the time — then you're likely just going to work on the Java project using VSCode, rather than learning a whole extra (more complex!) tool just to increase your Java productivity. Docland seems like it would be a good and helpful resource for the people who do things that way.
- 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.)
- martin_dd 2y ago
  Thank you for the kind words! Even though I'm a Jetbrains all products pack user myself, totally agree with you that it's still useful to have API references alongside your main editor/IDE. If there's enough interest I'd love to build a VSCode plugin for Docland.
- orf 2y ago
  > where a lightweight code editor like VSCode is the peak of productivity Your real point is that any IDE/tool has a learning curve, but don’t ever mistake avoiding that curve for “peak productivity”

martin_dd 2y ago

Author here. The value add is a better browsing experience: with Docland, you can navigate across the class hierarchy, search symbols quickly, and view the package content at a glance. Feel free to check it out!

derefr 2y ago

Why assume that everyone who touches Java code, uses an IDE to do so? If you write code 90% of the time in a frontend or scripting or other kind of language where a lightweight code editor like VSCode is the peak of productivity — and then have to fix bugs in a Java codebase the other 10% of the time — then you're likely just going to work on the Java project using VSCode, rather than learning a whole extra (more complex!) tool just to increase your Java productivity. Docland seems like it would be a good and helpful resource for the people who do things that way.

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.)
martin_dd 2y ago
Thank you for the kind words! Even though I'm a Jetbrains all products pack user myself, totally agree with you that it's still useful to have API references alongside your main editor/IDE. If there's enough interest I'd love to build a VSCode plugin for Docland.
orf 2y ago
> where a lightweight code editor like VSCode is the peak of productivity Your real point is that any IDE/tool has a learning curve, but don’t ever mistake avoiding that curve for “peak productivity”