6 ms·

IMO this is the biggest thing available to modern languages that Java is missing. I would absolutely love to see this, particularly pattern decomposition. I w

by peeters 10y ago

IMO this is the biggest thing available to modern languages that Java is missing. I would absolutely love to see this, particularly pattern decomposition. I wonder if you could do it without something analogous to Scala's sealed classes though--you really want your type checker to be able to assert every match has considered every branch (without having to specify a "default" everywhere). That means you need to be able to mark classes as not-dynamically-extendible, so the type checker has the full set of subtypes available. Edit: Just got to the bottom of the article. Looks like sealed hierarchies is exactly what they explore.

mark242 10y ago
I mean, reading this article is basically a giant advertisement for Scala and its powerful pattern matching. functionThatReturnsAnyVal match { case i: Int if i > 2 => System.out.println("Greater than 2") case i: Int => System.out.println("Less than or equal to 2") case s: String => System.out.println("Hello, " + s) case _ => }
- taeric 10y ago
  This still seems a terrible example just to try and avoid naming an object. Isn't the comparison to: Object o = functionThatReturnsAnyVal(); if (o instanceof Integer) { Integer i = (Integer) o; if (i > 2) { System.out.println("Greater than 2."); } else { System.out.println("Less than or equal to 2."); } } else if (o instanceof String) { String s = (String) s; System.out.println("Hello, " + s); } I get that the case syntax is kinda nice, but this particular example just doesn't seem to get there for me. Roughly half the lines, which is good. None of them hard to reason about. Which makes it a wash. Or is the comparison to something else?
  - nightmunnas 10y ago
    (String) o; :)
    - taeric 10y ago
      Fair. :) I was much more worried about if I had the required spaces at the beginning of the line, than if I wrote this correctly. Still a static error, though, that the compiler would catch.
  - emef 10y ago
    > I get that the case syntax is kinda nice, but this particular example just doesn't seem to get there for me. Roughly half the lines, which is good. None of them hard to reason about. Which makes it a wash. I suppose it's a matter of opinion, but to me the comparison of these two snippets is nowhere near "a wash". The readability of the former is leaps and bounds ahead of the java version, and it will only be more apparent as the example grows in complexity.
    - taeric 10y ago
      As either example grows in complexity, they both wash down to a check and a call to another method to do the heavy lifting. In that case, the length of the methods will not grow apart from each other heavily. And let me be clear. My gripe is only with the example. Not the idea. I happen to like pattern matching, but have never used it like those. Usually I use it to tease apart data by parts. (though, to be fair, I have found I use it less than I thought I did. Not sure why...)
  - chairmanwow 10y ago
    I think the prettier syntax actually really helps write code faster. A similar form of syntactic sugar appeared with lambda expressions. Instead of needing to explicitly subclass and write out the overriding method, you can just create an anonymous function. It's way less code and it makes the resulting code easier to reason about. The code's intent is more elegantly conveyed.
  - mark242 10y ago
    In reality my function would rarely exist in the Scala world since having a weakly-typed return like that is cringeworthy to say the least. But it's better to see this in action with Scala options. val myOptionalVar: Option[String] = functionThatReturnsOption() myOptionalVar match { case Some(str) if str.length > 10 => System.out.println("This is a long string.") case Some(str) => System.out.println("This is a short string.") case None => System.out.println("This code would be fifteen lines of null checking in Java.") }
    - pvorb 10y ago
      With Java 8 having Optional and Lambdas, this is no longer the case: final Optional<String> myOptionalVar = functionThatReturnsOptional(); final String output = myOptionalVar .map(str -> str.length() > 10 ? "This is a long string." : "This is a short string.") .orElse("This code would be fifteen lines of null checking in Java."); System.out.println(output);
    - tylerpachal 10y ago
      I think this is less-rare than you think. In my Scala code, I have a lot of matching on weakly-typed values which come from parsing JSON objects (where I also deal with a lot of optional values).
- hota_mazi 10y ago
  You mean it's a giant advertisement for ML and its powerful pattern matching?
- sgift 10y ago
  > reading this article is basically a giant advertisement for Scala and its powerful pattern matching. Javas strength has always been to take the good parts of its competitors after they've checked out in production (and not just "wouldn't this be a great idea ..?") and implement them. It will probably never be ahead of the curve due to this, but at least it is remarkably free of "looks good in theory, useless in reality"-features.
  - RandomBK 10y ago
    In general, I agree with all but your last point. There are many things in Java that were good ideas at the time of introduction, but turned out horrible (serializable, finalize, etc.)
    - sgift 10y ago
      Fair enough. I think both of your examples exist since JDK 1.0 (or 1.1), though I'd have to look to be sure. I think they've wised up after that.
    - brogrammer_1 10y ago
      Type erasure for generics...
      - pron 10y ago
        Wrong. Type erasure for generics is one of Java's luckiest breaks. At worst, it imposes a tiny inconvenience, but in exchange this is what allowed Java not to bake a variance model into the VM and libraries, and this is precisely what allows languages with different variance models -- like Java, Kotlin and Clojure -- to both share code and actual data objects with no runtime conversions. This is something that can't happen on .NET (see, e.g. how clumsily their Python implementation interacts with generics). This was a huge win for almost no cost.
        ddispaltro 10y ago
        I completely agree, what a blessing in disguise. Scala wouldn't be possible without it.
chriswarbo 10y ago
> IMO this is the biggest thing available to modern languages that Java is missing. It always amuses me to see features of ML, a language from 1973, described as "modern"; e.g. algebraic datatypes, pattern-matching, type inference, parametric polymorphism, etc. C (from which many popular languages like C++, Java, C#, PHP, etc. are derived) came out in 1972. I wouldn't say it's a case of being "modern", so much as paying attention to what else has been tried before, rather than sticking with what one already knows (when designing a language).
- Sharlin 10y ago
  I wonder what the programming world would look like now if functional programming concepts had broken through in the 80s and 90s, instead of OO. C would no doubt still be C, filling the same minimalistic imperative close-to-iron niche, but what about higher-level languages?
  - jamesblonde 10y ago
    The move towards Interactive Applications has helped OO and scripting languages. There are still plenty of applications for functional programming in the most demanding of environments, for safety and high availability. However, most students are not good enough at math to learn functional programming concepts. Whether that's the teachers' fault or the students' fault or society's fault, I can't say. But if we paid programmers for safety critical systems much more than we pay for good front-end developers, you would see a much higher level of adoption of functional programming languages.
    - adbmal 10y ago
      > However, most students are not good enough at math to learn functional programming concepts. When does this misconception disappear? You don't need to be good at math to use functional programming. It's nice that there is a correspondence between math and FP, but it's mostly irrelevant when coding. You could as well say you need a FP background when learning math. Both statements are nonsense and usually spread by people who mostly read complicated blogposts instead of writing actual code using FP. FP just offers a nice bunch of intuitive and predictable ways of processing information.
macca321 10y ago
I retrofitted F# style "discriminated unions" (which are basically sealed heirarchies) into C# by creating a series of generic types `OneOf<T0, ..., Tn>` which can hold exactly one value, Each type has a `.Match` and `.Switch` methods, in to which you have to pass lambdas to handle each case `.Match(Func<T0, TResult, ..., Func<Tn, TResult>`. I don't know if this would work in Java, given the generic type erasure, but it might... 1. https://github.com/mcintyre321/OneOf https://github.com/mcintyre321/OneOf
- deleted 10y ago
  [deleted]
- deleted 10y ago
  [deleted]

by peeters 10y ago

mark242 10y ago

I mean, reading this article is basically a giant advertisement for Scala and its powerful pattern matching. functionThatReturnsAnyVal match { case i: Int if i > 2 => System.out.println("Greater than 2") case i: Int => System.out.println("Less than or equal to 2") case s: String => System.out.println("Hello, " + s) case _ => }

taeric 10y ago
This still seems a terrible example just to try and avoid naming an object. Isn't the comparison to: Object o = functionThatReturnsAnyVal(); if (o instanceof Integer) { Integer i = (Integer) o; if (i > 2) { System.out.println("Greater than 2."); } else { System.out.println("Less than or equal to 2."); } } else if (o instanceof String) { String s = (String) s; System.out.println("Hello, " + s); } I get that the case syntax is kinda nice, but this particular example just doesn't seem to get there for me. Roughly half the lines, which is good. None of them hard to reason about. Which makes it a wash. Or is the comparison to something else?
- nightmunnas 10y ago
  (String) o; :)
  - taeric 10y ago
    Fair. :) I was much more worried about if I had the required spaces at the beginning of the line, than if I wrote this correctly. Still a static error, though, that the compiler would catch.
- emef 10y ago
  > I get that the case syntax is kinda nice, but this particular example just doesn't seem to get there for me. Roughly half the lines, which is good. None of them hard to reason about. Which makes it a wash. I suppose it's a matter of opinion, but to me the comparison of these two snippets is nowhere near "a wash". The readability of the former is leaps and bounds ahead of the java version, and it will only be more apparent as the example grows in complexity.
  - taeric 10y ago
    As either example grows in complexity, they both wash down to a check and a call to another method to do the heavy lifting. In that case, the length of the methods will not grow apart from each other heavily. And let me be clear. My gripe is only with the example. Not the idea. I happen to like pattern matching, but have never used it like those. Usually I use it to tease apart data by parts. (though, to be fair, I have found I use it less than I thought I did. Not sure why...)
- chairmanwow 10y ago
  I think the prettier syntax actually really helps write code faster. A similar form of syntactic sugar appeared with lambda expressions. Instead of needing to explicitly subclass and write out the overriding method, you can just create an anonymous function. It's way less code and it makes the resulting code easier to reason about. The code's intent is more elegantly conveyed.
- mark242 10y ago
  In reality my function would rarely exist in the Scala world since having a weakly-typed return like that is cringeworthy to say the least. But it's better to see this in action with Scala options. val myOptionalVar: Option[String] = functionThatReturnsOption() myOptionalVar match { case Some(str) if str.length > 10 => System.out.println("This is a long string.") case Some(str) => System.out.println("This is a short string.") case None => System.out.println("This code would be fifteen lines of null checking in Java.") }
  - pvorb 10y ago
    With Java 8 having Optional and Lambdas, this is no longer the case: final Optional<String> myOptionalVar = functionThatReturnsOptional(); final String output = myOptionalVar .map(str -> str.length() > 10 ? "This is a long string." : "This is a short string.") .orElse("This code would be fifteen lines of null checking in Java."); System.out.println(output);
  - tylerpachal 10y ago
    I think this is less-rare than you think. In my Scala code, I have a lot of matching on weakly-typed values which come from parsing JSON objects (where I also deal with a lot of optional values).
hota_mazi 10y ago
You mean it's a giant advertisement for ML and its powerful pattern matching?
sgift 10y ago
> reading this article is basically a giant advertisement for Scala and its powerful pattern matching. Javas strength has always been to take the good parts of its competitors after they've checked out in production (and not just "wouldn't this be a great idea ..?") and implement them. It will probably never be ahead of the curve due to this, but at least it is remarkably free of "looks good in theory, useless in reality"-features.
- RandomBK 10y ago
  In general, I agree with all but your last point. There are many things in Java that were good ideas at the time of introduction, but turned out horrible (serializable, finalize, etc.)
  - sgift 10y ago
    Fair enough. I think both of your examples exist since JDK 1.0 (or 1.1), though I'd have to look to be sure. I think they've wised up after that.
  - brogrammer_1 10y ago
    Type erasure for generics...
    - pron 10y ago
      Wrong. Type erasure for generics is one of Java's luckiest breaks. At worst, it imposes a tiny inconvenience, but in exchange this is what allowed Java not to bake a variance model into the VM and libraries, and this is precisely what allows languages with different variance models -- like Java, Kotlin and Clojure -- to both share code and actual data objects with no runtime conversions. This is something that can't happen on .NET (see, e.g. how clumsily their Python implementation interacts with generics). This was a huge win for almost no cost.
      - ddispaltro 10y ago
        I completely agree, what a blessing in disguise. Scala wouldn't be possible without it.

chriswarbo 10y ago

> IMO this is the biggest thing available to modern languages that Java is missing. It always amuses me to see features of ML, a language from 1973, described as "modern"; e.g. algebraic datatypes, pattern-matching, type inference, parametric polymorphism, etc. C (from which many popular languages like C++, Java, C#, PHP, etc. are derived) came out in 1972. I wouldn't say it's a case of being "modern", so much as paying attention to what else has been tried before, rather than sticking with what one already knows (when designing a language).

Sharlin 10y ago
I wonder what the programming world would look like now if functional programming concepts had broken through in the 80s and 90s, instead of OO. C would no doubt still be C, filling the same minimalistic imperative close-to-iron niche, but what about higher-level languages?
- jamesblonde 10y ago
  The move towards Interactive Applications has helped OO and scripting languages. There are still plenty of applications for functional programming in the most demanding of environments, for safety and high availability. However, most students are not good enough at math to learn functional programming concepts. Whether that's the teachers' fault or the students' fault or society's fault, I can't say. But if we paid programmers for safety critical systems much more than we pay for good front-end developers, you would see a much higher level of adoption of functional programming languages.
  - adbmal 10y ago
    > However, most students are not good enough at math to learn functional programming concepts. When does this misconception disappear? You don't need to be good at math to use functional programming. It's nice that there is a correspondence between math and FP, but it's mostly irrelevant when coding. You could as well say you need a FP background when learning math. Both statements are nonsense and usually spread by people who mostly read complicated blogposts instead of writing actual code using FP. FP just offers a nice bunch of intuitive and predictable ways of processing information.

macca321 10y ago

I retrofitted F# style "discriminated unions" (which are basically sealed heirarchies) into C# by creating a series of generic types `OneOf<T0, ..., Tn>` which can hold exactly one value, Each type has a `.Match` and `.Switch` methods, in to which you have to pass lambdas to handle each case `.Match(Func<T0, TResult, ..., Func<Tn, TResult>`. I don't know if this would work in Java, given the generic type erasure, but it might... 1. https://github.com/mcintyre321/OneOf https://github.com/mcintyre321/OneOf

deleted 10y ago
[deleted]
deleted 10y ago
[deleted]