"closures were accomplished with anonymous objects until version 8!"

Java has had closures through inner classes since the beginning, albeit admittedly in a verbose way. This is a quote from page 540 of "Concepts, Techniques and Models of Computer Programming":
Full lexical scoping. Full lexical scoping means that the language supports procedure values with external references. This allows a class to be defined inside the
￼￼￼￼￼scope of a procedure or another class. Both Smalltalk-80 and Java support procedure values (with some restrictions). In Java they are instances of inner classes (i.e., nested classes). They are quite verbose due to the class syntax (see the epigraph at the beginning of this section).

But I think this is already enough to do high order programming, given that it effectively allows having functions as values (and hence high order functions), and support all 4 basic techniques high order programming builds upon: procedural abstraction (which relies on closures), genericity, instantiation and embedding [1].

I have to admit that I am not sure if I understand what you mean by "There is simply no way to infer where a value was set without tracing the entire code, which slows development time by a factor of 10 to 100 over more functional techniques that use methods to derive state instead of values". My (possibly wrong) interpretation is that you are referring to lazy execution, given that this technique associates a variable with a function that creates its value but whose execution is delayed until triggered when the value is actually needed.

Is this correct? If it is, then explicit lazy execution can certainly be accomplished in Java, given that, as I have said before, it allows embedding procedure values in a data structure. Of course, this is not as convenient as implicit lazy execution as in Haskell with its non strict evaluation, but it achieves the main purpose of laziness all the same, which is to optimize resources by allowing consumers rather than producers to drive value creation and hence generate data structures incrementally (as they are needed) rather than eagerly (as in simpler data driven techniques): stream programming; another advantage of laziness is of course purely functional persistent data structures in some cases with good performance ([3] and [4]).

"It would also be nice to have the numerical computing techniques from MATLAB"

I couldn't agree more with this. For instance, if possible, for a ML project I think it's better to do as much research/experiments/development as possible in Matlab/Octave, and then translate it to Python or whatever the production language is (would love to hear opinions on this). It would be so nice if such translation could be avoided (maybe a preprocessor could automate it, but still ...).

I believe that the reason is that Matlab is just a much more natural language for mathematical programming. I did the wonderful mooc [2] in Matlab, and much prefered it compared to the Python solutions I saw.

[1] https://ocw.mit.edu/courses/electrical-engineering-and-compu...

[2] https://www.edx.org/course/learning-data-introductory-machin...

[3] http://lambda-the-ultimate.org/node/2665

[4] https://www.cs.cmu.edu/~rwh/theses/okasaki.pdf