7 ms·

Another feature, that Java finally adopts, after decades of not adopting it. More and more language features and concepts are being introduced, finally exposing

Another feature, that Java finally adopts, after decades of not adopting it. More and more language features and concepts are being introduced, finally exposing Java-only programmers to them. Lambdas, pattern matching, project Loom, at some point in the future, Java might be called a modern language. Good for Java and Java programmers. Just checked some other languages: - SRFI (Scheme Request for Implementation): https://srfi.schemers.org/srfi-200/srfi-200.html https://srfi.schemers.org/srfi-200/srfi-200.html Syntax: > | ($ record-name pat_1 ... pat_n) a record - GNU Guile: https://www.gnu.org/software/guile/manual/html_node/Pattern-Matching.html https://www.gnu.org/software/guile/manual/html_node/Pattern-... Seems to be implementing the SRFI: > | ($ record-name pat_1 ... pat_n) a record - Rust: https://doc.rust-lang.org/book/ch18-03-pattern-syntax.html https://doc.rust-lang.org/book/ch18-03-pattern-syntax.html and https://doc.rust-lang.org/reference/patterns.html#struct-patterns https://doc.rust-lang.org/reference/patterns.html#struct-pat... > We can also use patterns to destructure structs, enums, and tuples to use different parts of these values. Let’s walk through each value. > Struct patterns match struct values that match all criteria defined by its subpatterns. They are also used to destructure a struct.

elric 5y ago
> Another feature, that Java finally adopts, after decades of not adopting it Java has been steadily moving in this direction for quite a few years now. It's tricky business. There's the language proper, and there's the JVM, which are interdependent. Both are aiming to remain backwards compatible. Introducing new major language features is not an easy feat.
- pavelbr 5y ago
  C# has been adding new major language features all the time since its inception, including pretty much everything we are seeing being added to Java these days.
  - Skinney 5y ago
    Yeah, and this "kitchen sink" approach is partly why I stopped writing C#. Same thing is turning me away from JS. It's exhausting trying to stay up-to-date with the language, in addition to changes in the frameworks and tools on top of the challenges of my day job. I might be showing my age, but I've come to appreciate that features come after long and careful consideration, and not every single release.
pron 5y 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 5y ago
  there 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 5y ago
    I 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.
deleted 5y ago
[deleted]
grishka 5y ago
What I love about Java though, is that this new syntax is very clear and its intentions are obvious when you're reading someone else's code. It doesn't require you to hold a mountain of context in your head at all times like Swift and Kotlin do. Yes, it's verbose at times. But verbosity is a good property for a programming language because it allows the code to be read and understood with ease outside of an IDE.
- Jach 5y ago
  I was almost with you up until the end then I had to just shake my head. I mean, it's readable syntax and doesn't require some crazy new sigils or operators, it's "fine" though I'm also shaking my head at the scope rules for these bindings. Similarly I'm ok with the "fine" syntax of Optional, and being explicit with my Optional.orElse()'s, rather than introducing an 'elvis operator' or some bikeshedded derivative. Though I wouldn't mind such things -- I'm glad Java keeps evolving useful things anyway, but it does wear on you (or at least me) to have to speak them (or even to tell your IDE to speak them on your behalf) as if your mouth was full of sand or to read them as if they're a high school student's essay obviously padded to reach some word count minimum. If I came across this new thing organically, I could go "ah, neat, we have that now" and not necessarily need to go look up the JEP (meanwhile Python's PEP 636 had me going wtf) -- though over time I'd expect to come across it in a negative context where the original programmer made a scope mistake because they didn't read the JEPs, or because they tried to make a change without their IDE's assistance where through various means it could have pointed out shadowing or scope concerns, that I now have to fix. It's in no minor part thanks to Java's verbosity that the overall Java ecosystem is so verbose. Having mostly non-confusing syntax whose meaning you can mostly guess at on first exposure is nice, yes, but isn't so helpful for the more important aspect of having non-confusing programs. For that you really want a more concise and tasteful language over a verbose one. Anyway, I've found that for anything non-trivial about the program itself, I'm going to need an IDE because the meat of the thing is going to be verbosely spread out in many places (sometimes for good reasons, at least in the Java world). Sure, after I acquire the mountain of (program) context, I can review small changes even on paper printouts, but that's true of most anything. Verbosity is not a good property for a language to have in general -- Java itself admits this, otherwise we wouldn't have so many shortcuts in syntax like omitting this, or java 7's diamond operator or try-with-resources or catching multiple exceptions or for-each syntax, or java 8's lambdas and special syntax for simple lambdas, or java 9's var, or... And of course, almost always in some other more concise language a concept is much clearer. There's a reason pseudo-code isn't written to look like Java.

elric 5y ago

> Another feature, that Java finally adopts, after decades of not adopting it Java has been steadily moving in this direction for quite a few years now. It's tricky business. There's the language proper, and there's the JVM, which are interdependent. Both are aiming to remain backwards compatible. Introducing new major language features is not an easy feat.

pavelbr 5y ago
C# has been adding new major language features all the time since its inception, including pretty much everything we are seeing being added to Java these days.
- Skinney 5y ago
  Yeah, and this "kitchen sink" approach is partly why I stopped writing C#. Same thing is turning me away from JS. It's exhausting trying to stay up-to-date with the language, in addition to changes in the frameworks and tools on top of the challenges of my day job. I might be showing my age, but I've come to appreciate that features come after long and careful consideration, and not every single release.

pron 5y 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 5y ago
there 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 5y ago
  I 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.

deleted 5y ago

[deleted]

grishka 5y ago

What I love about Java though, is that this new syntax is very clear and its intentions are obvious when you're reading someone else's code. It doesn't require you to hold a mountain of context in your head at all times like Swift and Kotlin do. Yes, it's verbose at times. But verbosity is a good property for a programming language because it allows the code to be read and understood with ease outside of an IDE.

Jach 5y ago
I was almost with you up until the end then I had to just shake my head. I mean, it's readable syntax and doesn't require some crazy new sigils or operators, it's "fine" though I'm also shaking my head at the scope rules for these bindings. Similarly I'm ok with the "fine" syntax of Optional, and being explicit with my Optional.orElse()'s, rather than introducing an 'elvis operator' or some bikeshedded derivative. Though I wouldn't mind such things -- I'm glad Java keeps evolving useful things anyway, but it does wear on you (or at least me) to have to speak them (or even to tell your IDE to speak them on your behalf) as if your mouth was full of sand or to read them as if they're a high school student's essay obviously padded to reach some word count minimum. If I came across this new thing organically, I could go "ah, neat, we have that now" and not necessarily need to go look up the JEP (meanwhile Python's PEP 636 had me going wtf) -- though over time I'd expect to come across it in a negative context where the original programmer made a scope mistake because they didn't read the JEPs, or because they tried to make a change without their IDE's assistance where through various means it could have pointed out shadowing or scope concerns, that I now have to fix. It's in no minor part thanks to Java's verbosity that the overall Java ecosystem is so verbose. Having mostly non-confusing syntax whose meaning you can mostly guess at on first exposure is nice, yes, but isn't so helpful for the more important aspect of having non-confusing programs. For that you really want a more concise and tasteful language over a verbose one. Anyway, I've found that for anything non-trivial about the program itself, I'm going to need an IDE because the meat of the thing is going to be verbosely spread out in many places (sometimes for good reasons, at least in the Java world). Sure, after I acquire the mountain of (program) context, I can review small changes even on paper printouts, but that's true of most anything. Verbosity is not a good property for a language to have in general -- Java itself admits this, otherwise we wouldn't have so many shortcuts in syntax like omitting this, or java 7's diamond operator or try-with-resources or catching multiple exceptions or for-each syntax, or java 8's lambdas and special syntax for simple lambdas, or java 9's var, or... And of course, almost always in some other more concise language a concept is much clearer. There's a reason pseudo-code isn't written to look like Java.