
Java may be verbose, but who cares? - portal_narlish
https://dev.to/danlebrero/java-maybe-verbose-but-who-cares
======
hactually
As someone who avoids IDES, I've always been wary of languages which _require_
an IDE to allow people to work on a project or even make even smallest amount
of changes on a project and rebuilding. The verbosity and oh-so-explicit-my-
brain-hurts overt structured with too many layers of abstractions actually
prevents me from fully understanding what is happening.

Code reviewing for me becomes a chore where I can't focus on the purpose of
the code. I can't read it - understand it and know that my fellow engineers
have understood the task. Underneath the LoC, the Maven/Gradle mess, the
structure and the plugins -- where do I see the engineer's intent?

Not only is Java extremely verbose and requires an IDE to write the code for
you - it is also very complex, hence hard to understand.

Developers spend most of their time reading code, if 70% of it is
autogenerated (imports and layout and code completion to find the right 50
letter function) so why do we make them read machine generated code just to
understand what, in this example, should have been 58 lines of code but
instead becomes a ~440 lines long, 7 file/entity monster when a few simple
functions would have sufficed.

What justifies the complexity of Java? I think this decade belongs to Clojure
for the JVM.

~~~
jjtheblunt
Your last sentence feels ironic: the JVM is itself complex considering its
essence is that the JVM and javac combine to provice the experience of nicer-
than-C++ compilation to a mid 90s Unix, though is almost always running on
Unix-equivalent OSes, so kind of ridiculous. I agree wholeheartedly with the
rest, and am hopeful for things like a Clojure->native compiler, Scala-native,
and of course Swift and Rust...even Go.

------
Sohcahtoa82
I kinda wish the code for the Clojure and Java implementations were posted.

In my limited Java experience, I've found that Java itself is fine, but for
some reason, professional Java developers stick to these crazy idioms that
result in these monstrosities of code. I'm sure we've all heard of FizzBuzz
Enterprise Edition[1]. It's satire, sure, but every dollar of satire contains
a couple cents of truth.

I bet the Java version of that Spark job could have been done in under 100
lines of Java, but it was divided into 7 files totaling over 400 lines of code
because there's this feeling that you're "supposed" to write Java like that.

EDIT: Back in college, I took a machine learning class and wrote programs that
would load training data, use it to classify data, and output results. I did
all the tasks in a single .java file. If I were to do it following Java
idioms, I probably would have needed to separate the code that read the
training data into a TrainingDataLoader class, the code that classified data
into a DataClassifier, and then used a DataPrinter class to output it all,
plus a main class to pull it all together. Great, my single file, ~200 LoC
project is now 4 files and gained dozens more lines of boiler plate to pull it
together.

Stop writing stupid Java code and then blaming Java for your code being
stupid.

[1]
[https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...](https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition)

------
lucidguppy
I would very much like the industry to settle on at most 2 of:

\- Scripting language (python, ruby...) \- Fast language (c++, java.... ) \-
Functional language (elixir, haskell...)

and we concentrate on them to get tooling really good.

[http://blog.cleancoder.com/uncle-
bob/2016/07/27/TheChurn.htm...](http://blog.cleancoder.com/uncle-
bob/2016/07/27/TheChurn.html)

~~~
hactually
Python. Golang. ... uh, Scala?

[https://xkcd.com/927/](https://xkcd.com/927/)

------
specialist
Concision is a virtue.

Errors per LOC per programmer is stable. Reducing LOCs reduces errors.

\---

As for the article...

Comparing Clojure and Java's lambda/streams. Meh. Trading LOCs (function
points) for obfuscation.

For imperative languages (like Java < 8), the correct answer is better APIs.
Like the Java Language, the JDK would also benefit from serious trimming.

------
pawadu
> Imagine deleting 87% of all the code that you have to maintain!

What if those 87% make your code easier to maintain and update?

