Hacker News Reader

Comment by arihant | Hacker News Reader

Well, Java isn't verbose. Certain codebases have gotten verbose because they are being maintained for years (decades?) with extremely functional tools. Give a Go team IntelliJ and 20 years, and then we can compare Go and Java codebases.

> But I think it's a perfectly fair point that the language you can write effective in vi is -- all other things being equal -- better than the language that requires an IDE.

I would have to disagree with this point as well. To me, it feels like suggesting that computing is better with punch cards. Because, it is then also a fair point that a way of computing that can be done without a computer and editor is -- all other things being equal -- better than the way of computing that requires a computer and editor.

I think that thinking this way will also help numb the next leap in methods of instructing computers, and performing computation. Whether that involves a programming language or not.

View on HN

"Well, Java isn't verbose."

Maybe its just the code I've read, but its generally much longer than other languages to accomplish the same thing. A bunch of little things add up, such as "extends" instead of ":" for inheritance. Naming things is often longer - maybe its not the language core itself, but a counter example is python coding standards keeps them much shorter. With Go, there's duck typing to not have to declare obvious types (such as for strings).

The goals of the programs in enterprise java apps probably differ by an emphasis on readability and not writing speed. I.e. lambdas are written quicker to write, but maybe a reader would understand a strategy pattern's goal quicker.

> With Go, there's duck typing to not have to declare obvious types

Not a Go developer, but I think you mean type inference, not duck typing.

Not really, Go uses duck typing for interfaces. You declare an interface to require functions X, Y, and Z. Any type that has functions X, Y, and Z suddenly implements that interface whether you want it to or not.

As I understand it, the correct term for that is "structural typing." Duck typing is similar, but applies exclusively to dynamic languages. See: https://en.wikipedia.org/wiki/Duck_typing#Structural_type_sy...

Java programs got that way not because of language, but because teams of thousands of developers managing same codebase for decades. Explicitness and non-magicness are extremely valued in that environment.

Imagine you're refactoring a code written by employee #12340 that was written 10 years ago. With Go, you'd go file after file decomposing the program to finally figure out that if he just used a word to implement an interface, you only had to read that file and a javadoc. Long class names are still easier to look than signatures of functions.

Java emphasises abstraction. Go emphasises composition. Both have its uses, but what I was refuting was people claiming that Go is better than Java which I think is extremely uninformed conclusion.

> Explicitness and non-magicness are extremely valued in that environment.

This is not my experience with Java programs.

Enterprise Java programs often have many layers of magic abstraction, like Aspect-Oriented Programming, dependency injection, IOC.

Furthermore, people love using configuration files over code to determine program behaviour (see servlet configs, etc).

If you had said this comment 5 years ago, I would agree. I think you should take a look into today's Java development environment. It's world class, and light-years ahead of anything else out there.

Good to hear. I haven't programmed in Java in about that much time :)

Reply on news.ycombinator.com