3 ms·

>Programmers notoriously use easy as a synonym for familiar and given how long Java has been around by now we'd have some evidence showing a major productivity

>Programmers notoriously use easy as a synonym for familiar and given how long Java has been around by now we'd have some evidence showing a major productivity advantage Have you ever heard the phrase "the dog that didn't bark?" You appear to be using an absence of evidence to prove evidence of absence, not to mention an argument from ignorance (which is always possible in our post-Gödel world).

acdha 6y ago
That's a rather pretentious way to miss the point. The question was “Can you expand on this? Why do you think that?” and the response was a sweeping assertion and the name of a couple of products with no further details, or even a clear indication of which of the three languages mentioned further up-thread or others were being used as a basis for comparison. I wasn't asking for a peer-reviewed paper but even, say, “My team had a productivity loss when they switched to Go because [reasons]” would be better than nothing at all.
- shock 6y ago
  I was responding to: > java is very easy to troubleshoot compared to c, go, and rust >> Can you expand on this? Why do you think that? So the comparison is C, Go, and Rust. Yes, I'm familiar with all 3 of them and Java is easier to troubleshoot than either of them because it has better introspection out of the box.
  - acdha 6y ago
    That’s getting closer to what would have been an informative response. It could use further expansion but that could allow someone reading it to weigh how much that would remove a limiting factor in their experience. For example, also having experience with all of them, the overall advantage over C is clear-cut but Rust is a lot less clear since stronger type system and better culture around package management and complexity avoids a lot of problems that otherwise require runtime troubleshooting. Granted, a key part of that is really the question of whether you’re talking about a modern Java project or the more common enterprise Java sort with layers of accreted complexity and probably architecturally frozen at Java 8, where the problem is cultural rather than the language itself.
    - shock 6y ago
      > That’s getting closer to what would have been an informative response. It could use further expansion but that could allow someone reading it to weigh how much that would remove a limiting factor in their experience. Consider that you've gotten more useful information from my response than what you've paid for. If you want the whole picture, buy the book. Your sense of entitlement to more of my time seems misplaced.

acdha 6y ago

That's a rather pretentious way to miss the point. The question was “Can you expand on this? Why do you think that?” and the response was a sweeping assertion and the name of a couple of products with no further details, or even a clear indication of which of the three languages mentioned further up-thread or others were being used as a basis for comparison. I wasn't asking for a peer-reviewed paper but even, say, “My team had a productivity loss when they switched to Go because [reasons]” would be better than nothing at all.

shock 6y ago
I was responding to: > java is very easy to troubleshoot compared to c, go, and rust >> Can you expand on this? Why do you think that? So the comparison is C, Go, and Rust. Yes, I'm familiar with all 3 of them and Java is easier to troubleshoot than either of them because it has better introspection out of the box.
- acdha 6y ago
  That’s getting closer to what would have been an informative response. It could use further expansion but that could allow someone reading it to weigh how much that would remove a limiting factor in their experience. For example, also having experience with all of them, the overall advantage over C is clear-cut but Rust is a lot less clear since stronger type system and better culture around package management and complexity avoids a lot of problems that otherwise require runtime troubleshooting. Granted, a key part of that is really the question of whether you’re talking about a modern Java project or the more common enterprise Java sort with layers of accreted complexity and probably architecturally frozen at Java 8, where the problem is cultural rather than the language itself.
  - shock 6y ago
    > That’s getting closer to what would have been an informative response. It could use further expansion but that could allow someone reading it to weigh how much that would remove a limiting factor in their experience. Consider that you've gotten more useful information from my response than what you've paid for. If you want the whole picture, buy the book. Your sense of entitlement to more of my time seems misplaced.