Hacker News Reader

Comment by hoodoof | Hacker News Reader

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

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.

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.

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.

Sorry I challenge this notion. I don't believe anyone gets paid by the line of code. Even Java programmers.

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.

I knew this is what you were referring to. That was a long time ago.

Well not anymore at least. Streams and lambdas wouldn't be implemented if that was the case.

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.

Reply on news.ycombinator.com