As a genomicist I'm half biologist, half data scientist. I think for the majority of my problems, it's the verbosity of Java that I just cannot stand. Maybe the instruction I've had in Java is flawed, but the amount of codewords to do anything has really kept me away from it.

I don't really ever run into the same problem twice. I've never been able to write anything as concise for a one-off problem as I can using Python or Perl (or even Awk) for data wrangling.

Scripts are superior in term of usability for what you do. Period.

Java is for enterprise scale applications, where dozens or hundreds of developers contribute to the code base, for a decade or more.

The boilerplate, the verbosity, strong types, the dependencies on complementary tools is what makes a large code base maintainable in the long run. If cared for.

If you need to scrap a website a couple of times, convert text from one format to another. Yea just use some script. Throw away code that nobody but you will ever need to touch or even look at. It is possible to write a python, Perl, JavaScript, or even Php app at scale. It may require a bit more due diligence though. Frameworks have been introduced to help with that.

The article is written by someone who doesn't fully understand Java. No need for interface to support injection. Interfaces are commonly written by CS graduates or uninformed long time OOP developers, but composition and DI have been around for over a decade. I stopped reading when the interface was pointed out as the only way to go.

It sounds like you want to use Clojure.

> if you don't ... have unit tests

Uhhh... you should have unit tests no matter what language (or culture) you're dealing with.

Depending on your application, you can go a long way with integration tests alone.

> You can write concise pure Java if you don't rely on libraries

Hum... No, you can not. Java is missing basic tools for abstracting idioms, break your code semantically, and reusing your code. Without those, you'll just write stuff again and again, hope you have a very good IDE.

> It's simple

It's simple the same way Go is simple. The language itself is small, in ways that make your code complicated. On this competition, Brainfuck is unbeatable.

> it's super fast

C, C++, Rust and Fortran are fast. Java is not. It's a second tier, at around the same speed as C# (obviously), Go, and Haskell.

> Java is missing basic tools for abstracting idioms

Such as?

Any kind of flexibility on the syntax, metaprograming, reflection is so useless that it could as well not be there, high order constructions where the compiler can infer the idiom, well, really anything.

It has relatively recently gained usable high order functions, and seems to have stopped there.

Could you point out specific use cases? Are you referring to lisp-like macros? Constructs like Higher Kinded Types?

I'm just trying to understand where you're coming from.

Well, I'm saying that Java doesn't have any of those. Other languages have some concept they run away with, like macros for Lisp, monads on Haskell, named parameter enumeration and monkey patching on Python. Even PHP relies heavily on object enumeration.

All of those techniques are kind of equivalent in power, spread through a curve trading flexibility (expresivity) with organization (possibility of analysis). Java has nothing near that curve.

I'm not sure what you mean by named parameter enumeration or object enumeration to be honest.

> spread through a curve trading flexibility (expresivity) with organization (possibility of analysis). Java has nothing near that curve.

Java definitely leans towards the organization part of the curve. It doesn't need a single concept to run away with, because it knows that there is no magic bullet that will solve everything. Monkey patching is dangerous, especially when you're programming large systems that end up being used in finance or ecommerce.

On a side note, if I'm not mistaken, Brian Goetz mentioned that something similar to higher kinded types was not off the table for Java sometime down the line in a recent panel.

Do I see a case of the Blurb? I'm not sure, but it does resemble it. (By the way, you'll have a hard time finding any site written on Python that doesn't use monkey patching, e-comerce or not).

Anyway, parameter or objects enumeration are when a library uses both the field names and their values as input, people use them to define DSLs on a function call or object construction. Parameter enumeration does afford applicative semantics, but (mutable) object enumeration affords full monadic semantic, so it's easy to construct Turing complete DSLs (and I guess, why Python people avoid it).

It is really hard to explain how those concepts are useful, mostly because they only work when everything else on the language help. If you try them on Java, they will be mostly useless. C# for example has a fully generic implementation of monads, with specialized syntax that isn't very far from Haskell's, do notation. Yet, with its bad type inference and the inflexible interface hierarchy it got from copying Java, it is nowhere near as useful.

> It's simple, it's super fast

to what baseline are you comparing it to?

This is potentially a bad example, but the current "fastest" web frameworks as per the techempower benchmarks are all Java.

I'm not familiar with it, do you mean this one? https://www.techempower.com/benchmarks/

Rust, C, and Go appear to be on the top.

Sorted by full stack frameworks only: https://www.techempower.com/benchmarks/#section=data-r18&hw=...

They're not: C++ and Rust have winners for some of the tests.

Of course you can write more performant code with lower-level languages, though there is a reason that almost no web framework/application is written in them - the additional burden of managing memory outweighs the (actually surprisingly little) performance benefit. If you look at examples on the site, in basically every other benchmark Java and sometimes Go rank the best.

I should clarify that I sorted by fullstack frameworks with ORMs. Obviously C or C++ can be made faster.

Too late to edit now though.