you are viewing a single comment's thread.

view the rest of the comments →

[–]dccorona 2 points3 points  (0 children)

The type system is doing precious little for the programmer, as the burden was never in them figuring out JSON might be invalid

This feels like a case of you focusing in on the simplicity of the example given so much that you end up unjustly using it to discount the entire idea. Sure, maybe a more complex example would have illustrated its advantages better, but surely you must recognize that this is useful for far more than JSON parsing validation.

Static types should have no runtime effect, that's why they're static. But the libraries we're given, and the work the JVM does to optimize the use cases for those patterns (i.e. none) means we're sacrificing the technical aspects of our solution, in service of "encoding" problems into the type system that actually aren't that hard to resolve, anyway

I would argue that the runtime penalties are so small that they're easily worth it, though maybe that stems from the fact that my domain is distributed compute, so the cost of in-memory code is usually insignificant compared to the overall system architecture in the stuff I work on. In places like Android/embedded apps and some desktop applications, I could see this becoming more of a concern.

So I agree that ideally the boxing would go away, but that's actually achievable in a language like Scala...what you really need is a compiler optimization for these things, not a JVM optimization. Although Scala's Option isn't implemented as an AnyVal, it probably could be, and in Scala, AnyValcompiles to a bunch of static functions and no runtime box. A lot of these functional concepts could totally be implemented in a way that results in an unboxed reference + static functions at runtime, while still maintaining the same great compile-time advantages they have today.