4 ms·

If using an IDE is necessary to make the code readable, then Java should ship with an IDE. Or just add it to the language. I find myself often reading code ou

by cle 7y ago

If using an IDE is necessary to make the code readable, then Java should ship with an IDE. Or just add it to the language. I find myself often reading code outside of an IDE, such as in GitHub or other hosted repos. Why should it be less readable in those cases? Because it's marginally easier to write? I also write a lot of Go code, and appreciate how "go vet" disallows unkeyed struct literals, forcing you to write the field names when creating structs. It is not an IDE feature, and I can freely browse GitHub or grep around in the command line and the code is just as readable as in an IDE. It also means Go works in a lot of editors and IDEs more easily, because those editors/IDEs don't need to implement a bunch of extra features to make the code actually readable.

seanmcdirmid 7y ago
Verbosity is a huge problem in a language. Verbosity that makes unfamiliar code easier for you to read can actually hurt the readability to a more familiar reader trying to figure out where the bug is. I don’t need that thisIsTheBloodyFooArgument: all over the place if I already know it is the bloody foo argument. Eventually, the code becomes so repetitively noisy that I have to rewrite it stripped down into a text file just to get a gist of the real things I need to understand (like when comments get in the way and don’t help. But really, this is a problem we don’t need to have...tooling could make it so we have the verbose repetitive version that make unfamiliar readers happy and the more concise to the point version that makes familiar readers happy. But for some reason, our profession is infatuated with text files that make this best of both worlds impossible.
- cle 7y ago
  > But for some reason, our profession is infatuated with text files that make this best of both worlds impossible. Because people already have existing tools, lots of them. Text files are an easy way to support all of them. What kind of tooling do you propose that would immediately integrate with IntelliJ, Eclipse, NetBeans, emacs, vim, VSCode, Atom, Sublime, GitHub browsing, grep, etc.?
  - seanmcdirmid 7y ago
    Yes, but then you have people like the comment I was replying to who say that those tools must be inflexibly fixed when the language ships...and so those languages that expect less from tooling (like Go) are somehow better than those (like Java) that expect more. That the text should speak for itself well enough without tooling.

by cle 7y ago

seanmcdirmid 7y ago

Verbosity is a huge problem in a language. Verbosity that makes unfamiliar code easier for you to read can actually hurt the readability to a more familiar reader trying to figure out where the bug is. I don’t need that thisIsTheBloodyFooArgument: all over the place if I already know it is the bloody foo argument. Eventually, the code becomes so repetitively noisy that I have to rewrite it stripped down into a text file just to get a gist of the real things I need to understand (like when comments get in the way and don’t help. But really, this is a problem we don’t need to have...tooling could make it so we have the verbose repetitive version that make unfamiliar readers happy and the more concise to the point version that makes familiar readers happy. But for some reason, our profession is infatuated with text files that make this best of both worlds impossible.

cle 7y ago
> But for some reason, our profession is infatuated with text files that make this best of both worlds impossible. Because people already have existing tools, lots of them. Text files are an easy way to support all of them. What kind of tooling do you propose that would immediately integrate with IntelliJ, Eclipse, NetBeans, emacs, vim, VSCode, Atom, Sublime, GitHub browsing, grep, etc.?
- seanmcdirmid 7y ago
  Yes, but then you have people like the comment I was replying to who say that those tools must be inflexibly fixed when the language ships...and so those languages that expect less from tooling (like Go) are somehow better than those (like Java) that expect more. That the text should speak for itself well enough without tooling.