Comment on JEP 305

[alex at syncwords.com]

First of all, let me start by saying that I wish there were a better place for the general public to provide feedback to proposed language changes. I understand that this feedback can get overwhelming, but it's also bizarre to have an "open" process and release public "preview" features but with few avenues, other than this list and, I guess, Twitter, for the wide, experienced, and plenty wise Java community to give feedback.

Specifically, I want to share my feedback regarding the "Pattern Matching for instanceof" feature. I think "flow typing" is a great idea, and I don't like the current JEP 305 proposal because it forces the declaration of a new variable. Declaring a variable is onerous because each variable needs a good name. It is difficult to think of a good name for a variable that redeclares another variable which already has a good name. Moreover, having two names for the same variable hurts readability. It also breaks refactoring. Additional problems are weird constructs like if (!(a instanceof Foo b)). Flow typing is more general.

There is no reason given for why the variable should be renamed, other than claimed harmony with a future, major language expansion under the banner of pattern matching. I hope that expansion does not make it. I read over Brian Goez's and David Bierman's document. What I have to say is this: Every language is shaped by the kinds of programs their authors write. Java was and is a general-purpose language that followed and (to a lesser extent) still follows the Keep It Simple, Stupid principle. The pattern matching proposal, however, seems like syntactic sugar written by and for programmers working on AST parsers. Not a lot of people work on those. (Incidentally, I dabble in them, and even I don't think it's worth trying to replace a mess of if statements with a mess of switch clauses, and then add chapters to Java books to explain how it all works.) If we're going to pick a use-case that is poorly addressed by the Java language, it should be scientific computing and AI (numpy, pytorch, etc). These would benefit from operator overloading and range expressions.
 
Aleksandr Dubinsky