Re:Diminishing returns of static typing
by nradov on Monday October 02, 2017 @03:07PM
(#15386894)
While it may be frustrating to novice programmers, the distinction between interfaces (List) and implementation classes (ArrayList) is quite valuable, especially when dealing with huge code bases that have to be maintained over decades. Those declarations help to establish an internal design contract and clarify the developer's intent. In this particular case, a future maintenance programmer could switch from ArrayList to any other class which implements the List interface without breaking the program.
[ Parent
| on HN ]
Re:Diminishing returns of static typing
by nicoburns on Monday October 02, 2017 @06:32PM
(#15388544)
True, but there are more elegant solutions. For example, Rust's traits allow you to define a trait (somewhere in between an interface and an abstract class in Java), and then methods can be generic over any object that implements that trait. And structs and traits have a many-to-many relationship.
This allows you implement patterns like duck typing which are idiomatic in languages like javascript, but impossible to implement in java.
Which happens exactly how often? I've been writing java code for the better part of two decades and basically never needed to swap my list/set/map types around. Also, one of the purported benefits of java's typing is your editor can find and refactor / swap all usages, so it doesn't seem to me like this distinction has much value. It instead makes me think it's a fetish for object orientedness...
In fact, the only cases I've ever swapped even a HashMap has been to trove, which implements data structures for builtin types rather than reference types. In which case using interfaces everywhere doesn't help.
Re:Diminishing returns of static typing
by mattnewton on Monday October 02, 2017 @03:43PM
(#15387267)
It’s not about having the difference, it’s about having to explain to Javac what I am using because it’s incapable of doing meaningful type inference.