5 ms·
I found "Java for Everything" really interesting, so thanks for posting it. It also seems it's been featured on HN many times[1], and the progression of comment
by type_enthusiast 2y ago
I found "Java for Everything" really interesting, so thanks for posting it. It also seems it's been featured on HN many times[1], and the progression of comments (from 10 years ago to 4 years ago, to 1 year ago where nobody commented) feel like an archaeological strata that shows how things change and how they stay the same.
[1] https://hn.algolia.com/?q=java+for+everything https://hn.algolia.com/?q=java+for+everything (just searching for the URL doesn't work, because it started as http and changed to https 5 years ago)
- type_enthusiast 2y agoFWIW, while I'm not sure I agree that JVM is the right solution for every problem, I agree with much of the author's sentiment from that time, which is: programs are written much less frequently than they are run, so surely developer keystrokes are laughably unimportant compared to runtime performance and other user-facing concerns.
- cxr 2y agoThe post is a lot more about Java-the-language and has very little to do with the JVM.
- eek04_ 2y ago> programs are written much less frequently than they are run, so surely developer keystrokes are laughably unimportant compared to runtime performance and other user-facing concerns. Taking this to its logical conclusion all programs should be written in assembly. The reality is that there's a tradeoff: Programmer time vs performance, and which parts of performance matter. I've worked using anything with performance from assembly to shell scripts (including C, C++ and Java). It is all tradeoffs. Do users want more features, or more speed? Are we running at a scale or situation where ultimate usage of hardware matters, or not? Saying we should do ultimate amounts of investment in performance when there's three users and one programmer doesn't make sense. They'd typically rather have more features and adequate performance.