3 ms·

My point remains - "it's the Java way to make it hard".

by hoodoof 11y ago

Turing_Machine 11y ago
Another way of looking at is is that many large Java shops do the kind of government/corporate contract work where you get paid by the line of code. Fill in the blanks.
- hoodoof 11y ago
  Sorry I challenge this notion. I don't believe anyone gets paid by the line of code. Even Java programmers.
  - Turing_Machine 11y ago
    Individual programmers may not (although it's certainly used as a bogus "productivity" metric in many companies) but shops do. Most famously, IBM insisted on paying Microsoft by kLOC for their work on OS/2, and we all know how that turned out.
    - hoodoof 11y ago
      I knew this is what you were referring to. That was a long time ago.
  - orbitingpluto 11y ago
    Well not anymore at least. Streams and lambdas wouldn't be implemented if that was the case.
  - myhf 11y ago
    It would be foolish to explicitly pay for lines of code, but there are lots of situations where that happens implicitly. Most programmers get paid by the hour, and consistently produce about the same number of lines of code per hour. Most large contracts are billed according to the perceived magnitude of the task. The value to the client is more important than the cost to the contractor, but the cost is still a factor. And for a contractor who has already decided which programmers will work with which tools, that cost is directly proportional to lines of code.
pvg 11y ago
I'm not really seeing it. This example is egregious and that's what the author is upset about. If it had, I dunno, just a Maven pom of some sort it would be in the same ballpark of conceptual overhead as npm/grunt/gulp/grumble/glorkle/grlarlarlgh/rvr/gem/bundler/virtualenv/easy_install/pip/hip/hooray/etc.
peeters 11y ago
You're affirming the consequent. The truth is that "it's the enterprisey way to use Java", which is what leads to examples like this. The converse is not true, which is that it's the Java way to be enterprisey.

My point remains - "it's the Java way to make it hard".

by hoodoof 11y ago

My point remains - "it's the Java way to make it hard".

Another way of looking at is is that many large Java shops do the kind of government/corporate contract work where you get paid by the line of code. Fill in the blanks.

hoodoof 11y ago
Sorry I challenge this notion. I don't believe anyone gets paid by the line of code. Even Java programmers.
- Turing_Machine 11y ago
  Individual programmers may not (although it's certainly used as a bogus "productivity" metric in many companies) but shops do. Most famously, IBM insisted on paying Microsoft by kLOC for their work on OS/2, and we all know how that turned out.
  - hoodoof 11y ago
    I knew this is what you were referring to. That was a long time ago.
- orbitingpluto 11y ago
  Well not anymore at least. Streams and lambdas wouldn't be implemented if that was the case.
- myhf 11y ago
  It would be foolish to explicitly pay for lines of code, but there are lots of situations where that happens implicitly. Most programmers get paid by the hour, and consistently produce about the same number of lines of code per hour. Most large contracts are billed according to the perceived magnitude of the task. The value to the client is more important than the cost to the contractor, but the cost is still a factor. And for a contractor who has already decided which programmers will work with which tools, that cost is directly proportional to lines of code.

pvg 11y ago

I'm not really seeing it. This example is egregious and that's what the author is upset about. If it had, I dunno, just a Maven pom of some sort it would be in the same ballpark of conceptual overhead as npm/grunt/gulp/grumble/glorkle/grlarlarlgh/rvr/gem/bundler/virtualenv/easy_install/pip/hip/hooray/etc.

peeters 11y ago

You're affirming the consequent. The truth is that "it's the enterprisey way to use Java", which is what leads to examples like this. The converse is not true, which is that it's the Java way to be enterprisey.