Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pattern Matching for Java

cr.openjdk.java.net

Post reply on HN
Print view View original

81–90 of 152 posts

Re: Pattern Matching for Java

#81

Post by RandomBK »

sgift wrote: post #77
mark242 wrote: post #37

Earlier quoted context omitted.

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 _ => }

> 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 rea…

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.)

Re: Pattern Matching for Java

#82

Post by cromwellian »

sgift wrote: post #79
cromwellian wrote: post #78

Earlier quoted context omitted.

Those aren't new language features though, mostly just standardizing Guava conventions into the JDK.

Fair enough, but they do the job. I understand the wish of the designers to not change the syntax if a standard library extension does the job for 99% of the cases. Changing the language syntax is a far more elaborate process.

I think it gets real ugly once you need nested data structures, the readability goes down (maps of lists of maps). Also, using overloads means it's limited to small arity, e.g. 10.

Not having first class multiline literals really makes it painful to write something like React or GraphQL in Java.

One of the things I give props to MS for is having the courage to evolve C# and TypeScript at a breakneck pace. Each release of TS, they add features I've been wishing for. They seem to be listening to developer productivity issues and responding.

I under Java's desire to preserve backwards compatibility, but they end up breaking it anyway, and make design decisions based on how they can shoehorn things into the older JVMs, but each new release ends up with some issues. Witness how long it has taken folks to migrate to Java8. If we're going to wait years for major releases, then let's make them well worth the trouble when they finally arrive.

Re: Pattern Matching for Java

#83

Post by sgift »

RandomBK wrote: post #81
sgift wrote: post #77

Earlier quoted context omitted.

> 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 rea…

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.)

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.

Re: Pattern Matching for Java

#85

Post by sgift »

cromwellian wrote: post #82
sgift wrote: post #79

Earlier quoted context omitted.

Fair enough, but they do the job. I understand the wish of the designers to not change the syntax if a standard library extension does the job for 99% of the cases. Changing the language syntax is a far more elaborate process.

I think it gets real ugly once you need nested data structures, the readability goes down (maps of lists of maps). Also, using overloads means it's limited to small arity, e.g. 10. Not having first class multiline literals really makes it painful to write something like React or GraphQL in Java. One of the things I give props to MS for is having the courage to evolve C# and TypeScript at a breakneck pace. Each releas…

> Not having first class multiline literals really makes it painful to write something like React or GraphQL in Java.

Certainly. And that's one of my biggest pain points with Java, but a different point in your list. One day they will exist ... one day. Hopefully.

> Witness how long it has taken folks to migrate to Java8. If we're going to wait years for major releases, then let's make them well worth the trouble when they finally arrive.

I've used every release since JDK 6 in production one or two month after it was released. Once that hurt me (Rhino/Nashorn), but usually it hasn't been a problem. I think people who wait until the last moment when the older versions go out of support to switch JDKs do themselves a disservice out of fear. And fear is never a good reason.

Re: Pattern Matching for Java

#86

Post by pvorb »

mark242 wrote: post #60
taeric wrote: post #39

Earlier quoted context omitted.

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 s…

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…

With Java 8 having Optional and Lambdas, this is no longer the case:

  final Optional 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);

Re: Pattern Matching for Java

#88

Post by lmm »

lacampbell wrote: post #58
zastrowm wrote: post #26

Earlier quoted context omitted.

> FYI, I recently found out that C# can actually do multiple dispatch But also good to know, that it can be costly and unsafe. `dynamic` is basically using reflection at run-time, which for most cases is fine, but it's something to keep in mind. It also means that type checking is delayed until run-time instead of compile-time.

A dynamic type is probably just implemented as a tagged bit of data, surely. Which is the exact same way an algebraic datatype would be done. So I dunno why it would be any slower. I think the safety thing is a non issue as well - what arguments could you pass in to the statically typed function that would cause the use of dynamic to bite you in the ass?

> I think the safety thing is a non issue as well - what arguments could you pass in to the statically typed function that would cause the use of dynamic to bite you in the ass?

None if the function is written correctly, but by that logic you don't need type safety at all. The point is that the dynamic technique gives you no warning if you forget to implement one of the cases.

Re: Pattern Matching for Java

#89

Post by lmm »

raspasov wrote: post #41
zerr wrote: post #13

Earlier quoted context omitted.

On the other hand it "prettifies" bad code style - branching by dynamic casts / type comparisons.

I disagree. What's bad about that/what's the alternative?

The problem with pattern matching as I've seen it implemented is that unsafe and safe pattern matching look exactly the same (even the exact same code line can be safe or unsafe depending on context). See the bottom of http://typelevel.org/blog/2014/11/10/why_is_adt_pattern_matc... . For this reason I tend to prefer explicit virtual methods even though they're more cumbersome.

Re: Pattern Matching for Java

#90

Post by ernst_klim »

lacampbell wrote: post #20

Why the fixation on pattern matching? Don't get me wrong, I enjoy the benefit it provides, but for OO code multiple dispatch is a more elegant and idiomatic way to solve the "I don't want to implement the visitor pattern" problem. FYI, I recently found out that C# can actually do multiple dispatch https://blogs.msdn.microsoft.com/shawnhar/2011/04/05/visitor...

> multiple dispatch

> "I don't want to implement the visitor pattern"

Both multiple dispatch and visitor bring type unsafe dynamism and possible runtime errors. Pattern matching and algebraic types fit well into static type system and are much more safe.

Post reply on HN