Michael Nygard on JSR 308 and dynamic languages:
Every language has a complexity budget. Java blew through it with generics in Java 5. Now, seriously, take another look at this:
@NotEmpty List<@NonNull String> strings = new ArrayList<@NonNull String>();Does that even look like Java? That complexity budget is just a dim smudge in our rear-view mirror here. We’re so busy keeping the compiler happy here, we’ll completely forget what our actual project it.
All this is coming at exactly the worst possible time for Java the Language. The community is really, really excited about dynamic languages now. Instead of those contortions, we could just say:
var strings = ["one", "two"];Now seriously, which one would you rather write? True, the dynamic version doesn’t let me enlist the compiler’s aid for enforcement. True, I do need many more unit tests with the dynamic code. Still, I’d prefer that “low ceremony” approach to the mouthful of formalism above.
So, getting back to that mainstream Java developer… it looks like there are only two choices: more dynamic or more static. More formal and strict, or more loosey-goosey and terse. JSR 308 will absolutely accelerate this polarization.
I have a similar feeling with Scala — I have no doubt it’s now probably 50 times faster than JRuby, and will probably continue to be at least an order of magnitude faster for the foreseeable future; its type system will probably catch errors I never knew I was able of making — but I just can’t see myself having fun programming in it.
I dunno. Scala’s certainly more fun than Java. The combination of type inference and greatly streamlined syntax makes static typing a whole lot easier to deal with.
Well, at least 99% of the time. The problem is the rare occasion when you find yourself backed into some corner, and instead of simply opening a trap door with a cast (unchecked warning!) you end up rummaging through a toolbox of arcane type variations, trying to figure out what bizarre combination of self types, existential types, and structural types will allow your code to compile. Or maybe it’s some of the other zillion special-case types that Scala has. Or maybe there’s an implicit type conversion that’s causing problems, or maybe one that’s missing, or somebody forgot to use <% in a library method’s parameter so your implicit type conversion is ignored. Or maybe you’ve just got your covariance and contravariance confused somewhere. Or… aw heck.
In my earlier observation on that topic, I noted that the problems pretty much only show up with polymorphism (using that term in the OO sense). Especially when combined with generics other than arrays—where type erasure is trouble just waiting to happen.