7 ms·

I think the lesson to learn from Java was that we, developers, were evaluating languages on the wrong parameters. Java is too verbose! (But that can reduce the

by mabbo 6y ago

I think the lesson to learn from Java was that we, developers, were evaluating languages on the wrong parameters. Java is too verbose! (But that can reduce the need for so many comments, and comments can often mislead as software changes. Also, Java 8 was 2014 and it changed the game massively.) Java runs slowly because of the JVM! (But the JVM evolves and improves, giving free upgrades to all Java programs over time. Also, I have a multi-GHZ processor now.) Java takes longer to write! (But the first time you write a program is never the hard part- it's continuous evolution of software that matters.) 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 think Python's success is further evidence of this perspective.

b3kart 6y ago
> 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?
tincholio 6y ago
> 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.
wtetzner 6y ago
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; }
- martinp 6y ago
  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 https://blogs.oracle.com/javamagazine/records-come-to-java
  - Twisol 6y ago
    They were a preview feature until Java 16, though, so they probably haven't seen wide use yet. https://openjdk.java.net/jeps/395 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.)
- humbleMouse 6y ago
  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)
  - AtlasBarfed 6y ago
    Yes, groovy + @CompileStatic is comprehensively better than java with little to no performance loss.
taeric 6y ago
I still think we just don't appreciate actual marketing and corporate sponsorship.
grardb 6y ago
> 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.
- kragen 6y ago
  > 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.
TheRealPomax 6y ago
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.
908B64B197 6y ago
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.
peterashford 6y ago
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

by mabbo 6y ago

b3kart 6y ago

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

tincholio 6y ago

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

wtetzner 6y ago

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; }

martinp 6y ago
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 https://blogs.oracle.com/javamagazine/records-come-to-java
- Twisol 6y ago
  They were a preview feature until Java 16, though, so they probably haven't seen wide use yet. https://openjdk.java.net/jeps/395 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.)
humbleMouse 6y ago
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)
- AtlasBarfed 6y ago
  Yes, groovy + @CompileStatic is comprehensively better than java with little to no performance loss.

taeric 6y ago

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

grardb 6y ago

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

kragen 6y ago
> 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.

TheRealPomax 6y ago

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.

908B64B197 6y ago

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.

peterashford 6y ago

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