Hacker News Reader

As usual, I think it depends on the situation. Certain parts of Java's verbosity are just a net loss. However, some of those pain points have been addressed, and they're working on addressing others.

For example:

    public class Point {
        private final x;
        private final y;

        public Point(int x, int y) {
            this.x = x;
            this.y = y;
        }

        public int getX() {
            return x;
        }

        public int getY() {
            return y;
        }
    }

I don't think this level of verbosity helps readability (at least not for anyone familiar with the language). Luckily, there's Lombok (and I think a recent or upcoming Java version is adding support for record syntax):

    @lombok.Value
    public class Point {
        int x;
        int y;
    }

Records were introduced in Java 14 [1]. An immutable DTO, with minimal boilerplate, that still behaves a class. Example:

record Point(int x, int y) {}

[1] https://blogs.oracle.com/javamagazine/records-come-to-java

They were a preview feature until Java 16, though, so they probably haven't seen wide use yet.

https://openjdk.java.net/jeps/395

Java 16 was only released within the last few weeks! (Gradle still has some trouble compiling it or running on it; Gradle 7 should be dropping soon with explicit Java 16 support.)

Take a step up the enlightenment ladder and put a type dynamic language on top of java. Lombok is silly and makes your object’s serialization capabilities a dice roll. Keep annotations to a minimum and bring in a type dynamic language (groovy, kotlin, etc)

Yes, groovy + @CompileStatic is comprehensively better than java with little to no performance loss.

Exactly.... all the benefits of dynamic, with all the benefits of static compilation.

I have no problem whatsoever with groovy, but I heard “all the parts Java programmers hate about JavaScript with all the part JavaScript developers hate about Java”, and I had to reread your reply to realize you are not writing something like this :D

I find static languages much easier for large code bases. Also, can you code dynamic features with java's reflection API?

https://docs.oracle.com/javase/tutorial/reflect/index.html

Kotlin is statically typed. It has full type inference, though (AFAIK).

Kotlin is statically typed. Perhaps you mean Clojure.

Like this? https://common-lisp.net/project/armedbear/

I've used plenty of dynamic languages before, but I don't see how that would help in this case.

The point is that I wanted statically typed records, which a dynamic language won't give me. Java has added syntax for defining records now, which is great, but I'm not (yet) able to use the latest version.

> makes your object’s serialization capabilities a dice roll

Not sure how? The effect of @Value is documented.

You can go even further with Java 16, which came out last month.

    record Point(int x, int y) { }

No lombok needed. That is the same code, but it also has equals and hashCode methods.

https://openjdk.java.net/jeps/395

I don't think this is a good example, because it's easy to read in any case. The readability of the easy parts is not what matters - it's the readability of the hard parts, since that's where you'll spend 95+% of your attention.

My point is that adding that level of verbosity for something that should be simple makes it really hard to find the important parts of the code.

Boilerplate obfuscates.

C# solves it well with auto Properties. Java records will be a nice addition.

> Norvig's code is beautiful and very good Lisp. But it's so dense that it requires more lines of explanatory comments than actual functionality. The code's functionality isn't self-evident. And sure, you can write Java code that has the same flaws, but I find it's easier to write readable Java code than it is to write readable Lisp.

I mostly agree with this in general, but in my opinion, this kind of stuff gets exacerbated with programmers like Peter Norvig.

I was a really early MOOC student, and I was taking Udacity's first programming courses. I was a senior in college and already had plenty of coursework and multiple jobs/internships under my belt when I took their "Introduction to Programming" course. It was extremely easy for me.

The next programming course in their curriculum was "Design of Computer Programs," which is a course by Peter Norvig. When it was released, it had the difficulty set at "Beginner." While people were still going through the first iteration of the course, it got changed to "Advanced."

The problem, in my opinion, was the code. Even though it was Python, it was always extremely dense and required an insane amount of thought in order to comprehend what was going on. His variable and function names were also often very short and not descriptive enough.

I was able to get through the course, but it was a lot harder than I'd like to admit. As a mildly more seasoned programmer (I'm turning 30 soon), I would not think highly of a coworker's abilities if they wrote code like this. You definitely need to be smart to write the code the way Norvig does, but it takes a certain skill to write code that other people can understand, and I don't think he has that skill, regardless of the programming language.

All that is to say is that it's probably not just Lisp's fault, at least in this case.

> You definitely need to be smart to write the code the way Norvig does, but it takes a certain skill to write code that other people can understand

Just as functionality is relative to a purpose, readability is relative to an audience; Edmund Spenser is difficult for most of us to read today, and Dan Brown is incomprehensible if you speak only Chinese. The code of Norvig's that I've read (if we include the comments) is very readable to me, but I'm not a senior in college. (Without the comments I think I would have a terrible time.)

If I'm writing code with people like Norvig as an audience, I'll write it differently than if my audience consists of relative novices.

which means if you're working with other people in a business, a whole class of programmers won't be able to work well with your code. I think this makes the OP's point for them

Yes, that's always the case. Whenever you're writing, your writing is more accessible to some audiences than to others, according to how familiar the vocabulary and conceptual framework you're using are to them. So it's important to know what audience you're writing for so you can tailor your style to be maximally accessible to them.

It's tempting to think that you can organize kinds of writing on a one-dimensional continuum of levels from "more recondite" to "less recondite", with people being able to read anything at or (more easily) below their level, but it's totally false. Yesterday I went to check out some power usage statistics in the datasheet for a microcontroller I wanted to use for a project. To my dismay, it said, and I quote, "电流消耗是多种参数和因素的综合指标,这些参数和因素包括工作电压、环境温度、I/O引脚的负载、产品的软件配置、工作频率、I/O 脚的翻转速率、程序在存储器中的位置以及执行的代码等。"

I mean, that's surely understandable to many more people than what I'm writing here. But I'm not one of them. (Fortunately, in this case the data tables mostly answered my questions.)

> Norvig's code is beautiful and very good Lisp. But it's so dense that it requires more lines of explanatory comments than actual functionality.

I've thought the same. Just look at the comment for the `print-translations` function. Like yeah, the code is short, and I am sure it didn't take Peter long to write it: he's one of the best out there after all. But if this were real software, how long until the comment becomes out-of-sync with the implementation, due to negligence or simple laziness? Is it not safer, and a better use of time, to write code that itself reads more like that comment, which I'd guess would be the case with Java, and even more so with Python?

> but I find it's easier to write readable Java code than it is to write readable Lisp.

I think that depends a bit on the style. Pattern-heavy, "clean" Java is a mess of boilerplate that makes it very hard to find where things actually happen, let alone get an"idea at a glance" of what the code is about. Concise code might be harder to get started with, but in the end tends to be easier (for me, at least) to grok.

In any case, the main difference here, beyond the languages, is Norvig being a genius.

There's more to Java than the language: It's a complete ideology.

The boilerplate, insistence on explicit pattern naming and the comically long identifiers are all attempts at making boring enterprise code easy to read and modify by mass produced offshored "enterprise coders". With the UML certs that comes with them.

Try putting someone of Norvig's caliber on a team of these "enterprise coders" and watch him run in circles around them. Of course, none of them could ever hope to keep up. But good luck hiring a lot of Norvigs.

The nice thing about concise, highly performant, and most importantly, highly documented code is that it gives you the best of all worlds: it lets the computers do what you need as fast as possible, while also letting programmers get their learn on and actually deepen their understanding of the language they work with because the code comes with its own textbook.

You need all three though: take any of those aspects away, and you end with something that's going to get ripped out when the next programmer needs to maintain the codebase either because it's wastefully verbose, needlessly underperformant, or no on can understand what the hell all these "clever tricks" (usually based on an understanding of computer science, rather than software development - the two haven't been the same thing for decades now) do.

Agree with this. My central belief about code is that you read it more than write it, so legibility and simplicity are usually the most important features. That's one of the reasons I really liked Java. These days I feel that Kotlin achieves similar goals - arguably a little better than Java

I still think we just don't appreciate actual marketing and corporate sponsorship.