3 ms·

What you are focusing on is perfectly idiomatic Java. I'll bet for most Java slingers, quite beautiful. Other languages with other standards, yep, nasty. Lan

What you are focusing on is perfectly idiomatic Java. I'll bet for most Java slingers, quite beautiful. Other languages with other standards, yep, nasty. Language wars are tiring, pedantic and really not part of this discussion on schedulers.

LunaSea 9y ago
> other standards Or just standards at all. I'm sorry but when you read lines like this: > if ((i = (r - j) & m) >= 0 && i < n && (q = ws[i]) != null) {} with 6 single character long variable names and 1 two character long variable name, there is something to be said about code quality. And this is a rule that is true across programming languages. This is a typical example of written once / never modified or single maintainer code and it's a bad practice, especially for open source projects.
- boomzilla 9y ago
  You can read the comments (and the linked papers) first. This is an advanced algorithm that could take days (or weeks) to fully internalize the details. One can't expect to just read the code and build a mental model of the program in one parse, no matter how expressive the variable names are.
- buzzybee 9y ago
  This is not a valid argument when the line in question is dealing entirely with abstract constructs(which it is) and all of the variables are function-local, declared on the very same screen, and several of them exist as aliases for more complex constructs. If you haven't encountered a need for this approach, you just haven't had to write really mathy code before. Mathy code derives little value from longer names, but it does benefit from density. If you really think something is wrong with it, post ideas for longer names that will clarify and not substantially impact density. I would probably conventionally use "n0" and "n1" instead of "m" and "n" to represent "n-1", "n" - but the usage he has is consistent throughout the file, which is more than I can say of my stuff sometimes.
stcredzero 9y ago
Most language wars happen because people have trained themselves to techniques optimized for one programming environment's cost/benefit trade-offs, then they misapply those to a a programming environment with different cost/benefit trade-offs. Then they start pointless flame wars and pat themselves on the back for being "smart."

LunaSea 9y ago

> other standards Or just standards at all. I'm sorry but when you read lines like this: > if ((i = (r - j) & m) >= 0 && i < n && (q = ws[i]) != null) {} with 6 single character long variable names and 1 two character long variable name, there is something to be said about code quality. And this is a rule that is true across programming languages. This is a typical example of written once / never modified or single maintainer code and it's a bad practice, especially for open source projects.

boomzilla 9y ago
You can read the comments (and the linked papers) first. This is an advanced algorithm that could take days (or weeks) to fully internalize the details. One can't expect to just read the code and build a mental model of the program in one parse, no matter how expressive the variable names are.
buzzybee 9y ago
This is not a valid argument when the line in question is dealing entirely with abstract constructs(which it is) and all of the variables are function-local, declared on the very same screen, and several of them exist as aliases for more complex constructs. If you haven't encountered a need for this approach, you just haven't had to write really mathy code before. Mathy code derives little value from longer names, but it does benefit from density. If you really think something is wrong with it, post ideas for longer names that will clarify and not substantially impact density. I would probably conventionally use "n0" and "n1" instead of "m" and "n" to represent "n-1", "n" - but the usage he has is consistent throughout the file, which is more than I can say of my stuff sometimes.

stcredzero 9y ago

Most language wars happen because people have trained themselves to techniques optimized for one programming environment's cost/benefit trade-offs, then they misapply those to a a programming environment with different cost/benefit trade-offs. Then they start pointless flame wars and pat themselves on the back for being "smart."