Yes that's a very strange comment and taints the perspective of the author for the entire article. Kotlin and Scala are also functional or include strong functional abilities, as do many modern languages not on the JVM, so I'm not sure what being "functional" has to do with his omission.

He only considers statically typed languages to be worthy. He doesn't spend much time on Groovy, writing it off as a scripting language. That is my take on why he left it out.

There is a comment from the author that states he hasn't mentioned Clojure because it's FP language. He doesn't go into details bit it looks like he just skipped everything that doesn't support class based OOP. Scala has this feature.

Clojure supports this though.

And given that removing the FP nature of Scala pretty much hamstrings its value proposition, I can see why he'd be dismissive of it on those grounds.

Clojure supports class based OOP? Never heard of it. Could you give me a link to the relevant documentation page?

Not really a OOP programmer, but I think the following cover some reasonable subset of OOP:

https://clojure.org/reference/multimethods

https://clojure.org/reference/protocols

That's selling Clojure a little short. Clojure has full Java interop via reify, proxy, gen-class, deftype and definterface.

It's not class-based OOP.

Clojure supports protocols and multi-methods, the building blocks of CLOS, Common Lisp Object System.

Already at Xerox PARC, Lisps started to support OOP, with FLAVORS for Interlisp-D being one of the first ones.

EDIT: Disregard the last paragraph, lispm is right.

'Loops' was developed at Xerox PARC for Interlisp. Flavors was from MIT for Lisp Machine Lisp. Multimethods were first developed for Common Lisp in CommonLoops around 1986 at Xerox PARC.

Thanks for the correction. I typed it on the go without checking first.

Via records (defrecord) and protocols.