3 ms·
> Another feature, that Java finally adopts, after decades of not adopting it. Back in 1997, James Gosling published an article that serves as a blueprint to J
by pron 4y ago
> Another feature, that Java finally adopts, after decades of not adopting it.
Back in 1997, James Gosling published an article that serves as a blueprint to Java's evolution to this day: https://www.win.tue.nl/~evink/education/avp/pdf/feel-of-java.pdf https://www.win.tue.nl/~evink/education/avp/pdf/feel-of-java... He explained it further, as related by Brian Goetz in the first 20 minutes of this talk: https://www.youtube.com/watch?v=Dq2WQuWVrgQ https://www.youtube.com/watch?v=Dq2WQuWVrgQ
In short, Java attempts to be "a wolf in sheep's clothing," with a state-of-the-art, innovative runtime, wrapped in a language that's intentionally conservative. Java the language only adopts features that have already proven themselves as worthwhile elsewhere, and when mainstream programmers are ready for them. We don't always live up to that standard, but we try.
So another way of putting what you said is that this is another feature that has proven itself enough, for long enough, and that's matured enough for Java to adopt it. Many if not most programming language features don't make it to that stage.
The flip side is to examine which features have never made it to Java and probably never will (at least, they're not on our long-term roadmap). Those include, among others, macros, extension methods, first-class properties, and async/await.
- SemanticStrengh 4y agothere is nothing to be proud of about lacking extension methods. Kotlin has them and it allow to make amazing APIs that are much more ergonomic/reduce cognitive overhead.
- pron 4y agoI personally think there's much to be proud of in lacking any feature, as long as you deliver what your users expect, especially if the number of users is very large. After all, the goal of a mainstream programming language is not to have as many features as possible, but as few as necessary, where "necessary" takes into account both the common software requirements of the era (which are also shaped by the hardware characteristics of the era) as well as the expectations and habits of the majority of programmers at that point in time. I can tell you that if Java's language team encounters some language feature that solves a particular problem, they'd rather spend spend several years thinking how to avoid adding that feature while still addressing the problem, than the six months needed to implement it. A good strategy for doing that is to wait, and try to think of ways to solve multiple problems with one feature (even if imperfectly) rather than solve multiple problems with multiple features.
- _old_dude_ 4y agoThe same feature does not entail the same tradeoff depending on the languages. For Kotlin, extensions methods are essential otherwise you can not extend existing Java types with Kotlin types. For C#, you need extension methods for LINQ because modifying the .Net runtime was not an option at that time. For Java, changing the VM is not an issue, instead of extension methods you add default methods which can be overridden by implementations. Same feature, different tradeoffs.
- kaba0 4y agoI think Kotlin went the easy way with extension methods. Scala’s solution is much more elegant with implicits (especially now with Scala 3).
- SemanticStrengh 4y agoI'd be very interested in a comparison between scala 3 using/given and Kotlin new context receivers https://github.com/Kotlin/KEEP/blob/master/proposals/context-receivers.md#detailed-design https://github.com/Kotlin/KEEP/blob/master/proposals/context...
- deleted 4y ago[deleted]
- azth 4y ago> async/await Why would those be considered in the first place especially after Loom lands?
- pron 4y agoIt was considered before.