As someone who avoids IDES, I've always been wary of languages which <i>require</i> 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.<p>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?<p>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.<p>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.<p>What justifies the complexity of Java?
I think this decade belongs to Clojure for the JVM.
I kinda wish the code for the Clojure and Java implementations were posted.<p>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.<p>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.<p>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.<p>Stop writing stupid Java code and then blaming Java for your code being stupid.<p>[1] <a href="https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition" rel="nofollow">https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...</a>
I would very much like the industry to settle on at most 2 of:<p>- Scripting language (python, ruby...)
- Fast language (c++, java.... )
- Functional language (elixir, haskell...)<p>and we concentrate on them to get tooling really good.<p><a href="http://blog.cleancoder.com/uncle-bob/2016/07/27/TheChurn.html" rel="nofollow">http://blog.cleancoder.com/uncle-bob/2016/07/27/TheChurn.htm...</a>
Concision is a virtue.<p>Errors per LOC per programmer is stable. Reducing LOCs reduces errors.<p>---<p>As for the article...<p>Comparing Clojure and Java's lambda/streams. Meh. Trading LOCs (function points) for obfuscation.<p>For imperative languages (like Java < 8), the correct answer is better APIs. Like the Java Language, the JDK would also benefit from serious trimming.