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

101–110 of 152 posts

Re: Pattern Matching for Java

#101

Post by hepta »

Sean1708 wrote: post #93
ernst_klim wrote: post #90

Earlier quoted context omitted.

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

Why does multiple dispatch bring type unsafe dynamism or runtime errors? Or do you just mean C#'s implementation of multiple dispatch?

I think both are not exhaustive (or don't have exhaustiveness enforced by the compiler).

Re: Pattern Matching for Java

#102

Post by ysleepy »

leifg wrote: post #87

Am I missing something or can most of the examples just be achieved with method overloading?

Java only has single dynamic dispatch. That means it will use the method of the most specific sub-class, but will not dispatch on the runtime type of the argument, only its compile time type.

So something like:

  for(None n: expreTree.children()) {
    intMath.eval(n);
  }
will not work as expected if eval is overloaded.

Re: Pattern Matching for Java

#103

Post by jamesblonde »

Sharlin wrote: post #100
chriswarbo wrote: post #99

Earlier quoted context omitted.

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

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?

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.

Re: Pattern Matching for Java

#104

Post by ysleepy »

siddharthbhola wrote: post #84

good approach taken from scala programming language. makes things simpler and shorter.

It is an old concept used in most functional languages, like ML, haskell or even Prolog via unification.

So not an invention of scala, only that is also lives on the JVM.

http://wiki.c2.com/?PatternMatching

Re: Pattern Matching for Java

#105

Post by ernst_klim »

Sean1708 wrote: post #93
ernst_klim wrote: post #90

Earlier quoted context omitted.

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

Why does multiple dispatch bring type unsafe dynamism or runtime errors? Or do you just mean C#'s implementation of multiple dispatch?

Yep, there is no way to check the exhaustiveness in the compile time. Say you have an Expression parent class and a list of child classes: say Add, Const, Var, and a corresponding visitor. Add new child class, and the visitor would be non-exhaustive. Multiple dispatch is not very different in that sense.

I think that Alan Key spoke about dynamic nature of OOP, that's one of the examples. Even in the statically typed environment OOP demonstrates its dynamic nature.

Re: Pattern Matching for Java

#107

Post by Latty »

megawatthours wrote: post #106

You can do this in Java using derive4j: https://github.com/derive4j/derive4j . It generates code for algebraic data types which offer a typesafe interface similar to the `case` statements in languages that natively support pattern matching.

In the same way you could "do" lambdas with single method interfaces in Java pre-8. It was possible, but it was still a pain to do.

Re: Pattern Matching for Java

#108

Post by Latty »

alkonaut wrote: post #91
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...

To me it seems pattern matching without possibility to actually enforce that all cases are matched seems to miss the most useful scenario: What I want to do is create proper sum types. For some reason most OO languages were designed around the idea that being "open for extension" was a good thing. Normally if I make a base class, I want a closed and known set of sub classes. E.g. if I make a payment method then I wan…

Scala gets this right, in my opinion, with sealed traits and case classes. "enum classes" feel like a much more limited option by comparison. Although I'd take either over the status quo to be sure.

Re: Pattern Matching for Java

#110

Post by adbmal »

jamesblonde wrote: post #103
Sharlin wrote: post #100

Earlier quoted context omitted.

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?

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

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

Post reply on HN