Hacker News Reader

Comment by egeozcan | Hacker News Reader

You can hate Java all you want (a hate which I find confusing but it doesn't matter), but the beauty of the referenced code is very hard to match - given that you don't weirdly define beauty as the lack of braces.

View on HN

> the beauty of the referenced code is very hard to match

- 50 line comments containing type annotations in a strictly typed language and HTML

- 80 column limit

- single character variable names

- variable declarations inside loops

yeah ...

Edit: I like that people downvote without having counter arguments.

I love it when the comments are rich as it helps the IDE, I love the great formatting achieved especially considering the column limit and I also love that the variable names are only single letter when they can be (a local context of a very clearly defined function).

I don't love the variable declarations inside loops and hadn't noticed them, but even if I did, I don't have an opinion about them. Maybe they aren't good for performance? If so, well, then you have a point but I can't say. I'm not a Java expert, I'm not even using it very often.

My first point in the comment you replied was "don't dismiss it just because it's a language you don't like, it actually looks beautiful" and you are arguing that (correct me if I'm wrong) it's not beautiful at all. I wouldn't down-vote you, but it's obvious that we differ on taste. Maybe I should have said that "the beauty of the referenced code is very hard to match if you ignore your bias against a language and appreciate the stylistic choices" as you would probably also agree that it is at least very, very coherent.

> variable declarations inside loops

Depends on the standards. A lot of language standards say to declare vars near where you use them. Does make syntactical analysis easier. See scoping and namespace rules.

Beautiful code should be readable and single character variable name salads are not readable.

If I'm a new contributor and just browsing the code I want to be able to stop on a line an understand what it roughly does just by reading that line without having to replay the whole execution stack in my head as required context.

I agree that the other issues are stylistic and are less important.

The algorithm might be beautiful but it's debatable for the implementation.

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.

> 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.

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.

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.

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."

> variable declarations inside loops

What's wrong with variable declarations in loops?

Nothing. There is not a performance hit in most languages, and it clearly articulates that the variable is only in scope for one iteration of the loop.

That's like judging a piece of literature based on typography and paper quality. Not that those don't matter, but they are secondary. The beauty of this code is in the algorithm it implements and in the mechanical sympathy it exhibits -- not its formatting.

All of your criticisms are kind of superficial and senseless:

- type annotations + HTML in comments - it is called javadoc

- 80 column limit - lowest common denominator for most people, also historically part of Sun code conventions for Java - http://www.oracle.com/technetwork/java/javase/documentation/...

- single character variable names - who cares, a symbol is a symbol

- variable declarations inside loops - more readable, no chance of referencing stale value outside of scope, and HotSpot will probably recompile anyhow

Reply on news.ycombinator.com