Java is not really designed for a REPL though. I've used REPL like environments in Swift long before, this and it simply never feels right IMHO compared to a real dynamic language.
And Swift is a much better designed language for this than Java.
Thank goodness for jshell. The only thing holding Java back was its lack of a repl and now it has one, we can embrace Java as the useful concise dynamic succinct language it really is.
I don’t think the argument in the linked article is very good but this apology is worse. It doesn’t really show any merit of Java (more that the repl in Java is much less powerful than in eg CL) or argue against the spirit of the article.
Ummmm yes & no. It has a REPL, but it sure isn't easy to use and very few C# coders actually use it. Contrast that with a dynamic language like Python where people basically live in the REPL. Common Lisp takes this to a whole new level. You really can't equate C#'s REPL to Common Lisp's. This is one of those things where the sum of the thing is greater than its parts. Note that I'm not saying C# isn't a decent language, just very very different than what you get with languages like Smalltalk & Lisp.
I'm curious, how much Common Lisp have you written yourself. Because what I'm reading between the lines is that you consider modern Java to be pretty much equal to Common Lisp in power, and that doesn't make much sense from here.
Take lambdas for example, the amount of arbitrary exceptions you have to keep in mind while using them makes it almost not worth the effort. It's still the same old crappy Java; only with shiny, barely working marketing gimmicks duct taped to the side.
That's the thing though... they aren't real lambdas. They're just syntactic sugar for an interface. If you watch the talk by the head of Java right now at the Clojure conference, he talks about how they're essentially trying to tack on low hanging fruit in hacky ways to keep the language up to date. But secretly it's a mess.
There are quite a few complications of Java lambdas and their abstraction bleeds out in several edge cases. This is a result of their class implementation and would not exist if functions had first class support in the language and barcode bytecode (there are complications there too because they didn't want to change anything at the bytecode level for lambdas).
Lambdas in Java aren't really that complicated. If you understand anonymous classes, you understand lambdas.
That article just compares Java's closures with Javascript's closures. The "limitation" is that Java's closures can only access the final variables of the enclosing scope. But the article agrees that this limitation "can be considered negligible" (seriously, read it-- that's the conclusion.)
Also, starting in Java 8, you don't have to explicitly declare things "final" to use them in anonymous classes or lambdas. They just have to be effectively final, meaning they are not mutated.
> But the article agrees that this limitation "can be considered negligible" (seriously, read it-- that's the conclusion.)
Working both in Java and Lisp professionally, it sure as hell isn't negligible. It changes the way you write code. Lambdas in Java are 80% solution. Java 8 really did make this language finally bearable, sometimes pleasant to work with. 80% solutions are good, but the remaining 20% is not "negligible".
And Swift is a much better designed language for this than Java.