cbrad

I unsuccessfully tried to post a comment on Static Typing and Functional Languages.

First thing to note, is that Functional Java ‘looks’ so ugly, because Java is not naturally suited to expressing these abstractions.

Secondly, type inference appeared in the 1970s, well before Java existed.

Thirdly, the assumption that functional programming implies static typing is difficult. Type system research has been largely motivated by a number of factors over the years, including compiler optimisations for program performance and theorem proving.

Java is the Brier Rabbit of IT. Once touched you can't let go. Its simplistic enough to be inadequate in almost every situation.

From The Book Of JOSH - Scala In The Enterprise

Following on from the previous post, two papers about null in Java. Found both in these comments.

The Introduction of the paper Much Ado About Nothing: Putting Java’s Null in its Place provides a good, very readable description of the issues with null in Java. From the Abstract:

The ubiquity of null in object-oriented programs leads to severe engineering problems for programmers. First, the error messages issued by the run-time checks are typically not sufficiently informative to help the programmer find the source of the error. Second, the type systems in OO languages generally do not distinguish null from other values of (object) type, preventing the programmer from stating important invariants about the flow of null in the type system. Third, programmers’ standard use of null as a sentinel does not unambiguously represent failures. To resolve or avoid these ambiguities, component authors must incorporate additional complexity into their interfaces, and this complexity can lead to subtle bugs.

As a side note, there is an existing implementation of Maybe in Java, as Option in Functional Java.

I have only skimmed the paper Non-Null References by Default in Java: Alleviating the Nullity Annotation Burden. This is an empirical study of null in 5 open source Java projects. The Abstract states:

The results allow us to confirm that in Java programs, at least 2/3 of declarations of reference types are meant to be non-null, by design. Guided by these results, we propose a new non-null-by-default semantics. This new default has the advantages of better matching general practice, lightening the annotation burden of developers and being safer.