Hacker News Reader

Comment by 43224gg252 | Hacker News Reader

I disagree. That's written in Java.

We detached this flagged subthread from https://news.ycombinator.com/item?id=14795445.

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.

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

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

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.

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.

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

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.

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

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.

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.

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.

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

I can understand people who don't like Java for various personal aesthetic reasons, but I can't understand people who don't like Java but like Go. If you like Go but don't like Java, then either you don't know one or the other well enough, you get distracted by unimportant details and are expressing a "narcissism of small differences", or you're expressing an emotional bias that has nothing to do with technical facts. Seeing that you can't appreciate a low-level scheduling algorithm that would be pretty much identical in any language (this particular Java code is so low-level, that it's almost C) shows that at least the second reason holds.

Having used both Java and Go, the two seem almost indistinguishable to me (well, they differ in many details, but none that matters much, and their more pronounced differences have nothing to do with linguistic features); Java is more or less Go with generics and exceptions.

Java is like Go with generics, exceptions, inheritance (which the author of Java thinks was a mistake), and a separate runtime (JVM).

Those four things alone are pretty big differences, and then there are more intangible yet important differences like stdlib and culture, and implicit interfaces. They are definitely in the same family, but not as closely related as you imply - they are not indistinguishable. I'd say the similarities are more in unimportant stuff like syntax, some of the differences are important.

I think one of the biggest differences is that Go has only value types and references thereto (including the builtin data structures, which are basically just fat pointers). Even if Java gets value types, there will be a huge and useless value/class dichotomy as in C#. But there are dozens of other misfeatures in Java, such as protected/final/first-class-constructors/explicit-interfaces/etc. And this is just the language--the tooling is even worse (and no, a huge, fragmented ecosystem of kitchen-sink tools is not "better" than a few, simple, purpose-made tools).

All that said, I have a lot of criticism for Go as well, especially as a language. I just can't see Java being on par with Go, even with generics. Of course Go has more than a decade of hindsight that Java didn't have (or at least Java was in too deep by then to make the requisite changes).

But there are dozens of other misfeatures in...

Basically applies to most mature widely used languages that have evolved by adding features. In many software projects, the bias is on the side of adding too many features and not accounting for the costs, to the point where someone feels a bit of pain and complains. In Go, the bias is in not having enough, to the point where someone feels a bit of pain and complains.

I'd bet that more language designers are going to opt for the 2nd strategy as we go forward in the 21st century.

The dynamically linked runtime and the JIT are indeed important differences (although not all JVMs share HotSpot's design; some JVMs compile Java AOT and statically link the runtime) -- but they are not linguistic differences, and so nothing that the commenter I responded to could see in the code.

In any event, even regardless of how big you think the linguistic differences are, Java and Go are far too similar to like one and so strongly despise the other (although you could certainly prefer one over the other). We're not talking Go vs. Haskell, or Python vs. C here.

Sorry, I have programmed in Java since 1995 and am now using Go for some years. There are huge differences, so I wonder how you could call those languages somewhat close. Some of the differences, which make me favor Go over Java are:

- functions: Java does not have functions, only methods

- closures: Not sure of the latest state, but until very recently, Java had no closures. Closures are a huge and important element of programming.

- single file executables: make your program easy to deploy, without shipping a JVM, setting up a classpath etc.

- value types: have control to which structures you want to refer by pointer and which should be treated as a value

- goroutines+channels: a far better approach to parallel programming, a goroutine is much more light-weight than a Java thread

- no generics the Java style: eventually Go needs generics, but not in the way Java implemented them.

- no frameworks: possibly not a strict language related issue, but Java grew monstrous frameworks, the Go community has been stay away from them so far.

I could list more reasons for which I prefer Java for large, serious projects (I prefer Go for smaller things) and some of the reasons you list are outdated, but that's not my point, as I don't wish to argue which of them is better (neither is, IMO), nor to focus on their differences. My point is that in terms of language and programming style, their similarities so outweigh their differences, that I cannot understand how one's opinion of both can vary by too much. This is doubly clear when you compare Java and Go to, say, Python, Haskell, JavaScript, OCaml, C++, Rust, Clojure, Scala, Eve, Erlang, Pony etc. If your experience has been mostly in Java and Go, you focus more on their difference, but in the context of all other programming languages that truly differ from those two, I find Java and Go -- at least in terms of linguistic features -- nearly indistinguishable.

I have plenty of programming experience beyond Java and Go :). Currently I am mostly a Lisp programmer, that is why I consider the existence of closures and functions such a huge differentiator for Go vs. Java.

But Java has closures (including type inference), and they're at least as idiomatic in Go, not to mention that all Java collections have map/filter/reduce. As to functions, all Java requires is that they be defined as static members of some class, which is no different than defining them in some namespace. Thanks to static imports, they don't have to be qualified when called. So, not only is this not a huge differentiator, this is not a differentiator at all.

Even though the languages may seem quite similar, the cultures of the two communities and how software tends to be written in each language is vastly different in my experience.

Yes, totally agree.

In my opinion, Java is a great language that has was ruined by enterprise adoption. SOAP, JavaBeans etc, set this precedent of crazy over-engineered solutions in Java and it has never really recovered.

Go seems to attract C and Python programmers that prefer simpler interfaces and doing more with less. It is just a different culture, though I would agree from a language perspective they are very similar.

Which is great, choices are good and you can pick the culture you prefer, but you can only say the languages are similar if you ignore this huge chasm in their cultures.

Reply on news.ycombinator.com