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

111–120 of 152 posts

Re: Pattern Matching for Java

#111

Post by chriswarbo »

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.

I don't agree with this. Many programming concepts outside functional programming can be very hard to grasp, yet we expect students to pick them up, and we expect front-end Web devs to use (some of) them every day.

Some examples off the top of my head:

- Pointers (e.g. the many incompatible meanings of "" in C).

- Classes and instances.

- Implicit state.

- Mutable global state!

- Concurrency (events, continuations, actors, etc.).

- Multithreading. Yes, it's a form of concurrency, but it also offers a unique combination of being a) the default go-to strategy for implementing concurrency, and b) so fundamentally hostile to any attempts at understanding.

- `x = x + 1`. This can be completely baffling when first encountered!

In this context, functional programming doesn't really require anything particularly difficult. Maybe recursion is hard to grasp, but that's not unique to FP; FP just uses it more often, making it harder to avoid. The only thing I can think of that's pretty much a requirement in FP, that we don't already require everyone to grasp, is first-class functions; and they're already pretty widespread in scripting languages.

What about monads? What about denotational semantics? What about cartesian closed categories? What about all that other complicated math stuff? None of it is needed to do FP*! Just grab a small Scheme interpreter, ignore "call/cc" or anything ending in "!", and start coding.

Let's look at, say, the accepted papers from the last OOPSLA (Object-Oriented Programming, Systems, Languages & Applications): http://2016.splashcon.org/track/splash-2016-oopsla#event-ove...

Looking through the titles, I don't know what an "enclave" is, or "conditional future synthesis", or "first-class effect reflection". I have no idea what a "non-linearizable concurrent object" is, or what constitutes a "dependent object type". Does that mean I'm not good enough at math to learn OOP? Not at all; I can just run `python` and start hacking.

Re: Pattern Matching for Java

#112

Post by ddispaltro »

pron wrote: post #97
brogrammer_1 wrote: post #95

Earlier quoted context omitted.

Type erasure for generics...

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…

I completely agree, what a blessing in disguise. Scala wouldn't be possible without it.

Re: Pattern Matching for Java

#113

Post by Sean1708 »

ernst_klim wrote: post #105
Sean1708 wrote: post #93

Earlier quoted context omitted.

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…

I'm sorry would you mind going into a bit more depth about that example? It's not obvious to me why the compiler can't figure out the the visitor is no longer exhaustive.

Re: Pattern Matching for Java

#114

Post by RhodesianHunter »

jnordwick wrote: post #62
rdnetto wrote: post #29

Would be really great to see this make it's way into the language. Here are some ways I've found to work around its absence: * adding a match() function to a common base type. So if it could have subtypes Foo(x), Bar(y, z), then the signature would look like: T match(Function foo, BiFunction bar); * in the cases where I don't have control over the common base type, I've written a builder pattern that constructs a seq…

Just use another language if you want pattern matching so badly. Twisting Java to look like Scala doesn't do the language justice.

You act as if what op described must be the entirety of their code base. What if pattern matching is just a small part of a larger problem better solved with Java?

Re: Pattern Matching for Java

#115

Post by Sean1708 »

adbmal wrote: post #110
jamesblonde wrote: post #103

Earlier quoted context omitted.

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…

Take Lisp as a perfect example, I doubt you'd find very many people who think that you need to be strong at maths to learn Lisp. I wonder if this misconception came about because of Haskell's (unfounded) reputation of being a "scary abstract maths language".

Re: Pattern Matching for Java

#116

Post by dkarl »

jeremyjh wrote: post #45
dkarl wrote: post #31

I feel these new language features that get grafted onto Java end up awkward and unpleasant to use. Java is still Java, and it exacts a stiff awkwardness tax for writing code in a style different from how Java OO was envisioned 15-20 years ago. The examples in the linked article look fine, but the difference between pattern matching as "possible direction" and pattern matching as "new language feature" could easily e…

Oracle's most profitable customers are still using Java 6. That wouldn't change if they were pushing Kotlin.

I don't know Kotlin, but judging by their "Kotlin for Scala Developers" article I don't know if it would be a big enough jump to get people excited, especially since a project like this would take years to come to fruition. I think Scala is a good first try at what the successor language could be, but it has two problems: its reputation as a hard language, and the fact that it partly deserves said reputation. (Maybe if Odersky succeeds in simplifying the concepts underlying Scala as he's trying to now with Dotty, the result will be a potential Java-killer.) Oracle would have to fund a research project to choose an existing candidate and spend years developing it to fit the role it would play in the market. Which sounds very unlike Oracle, so I'm not holding my breath.

EDIT: And to your point, I think it's a bad sign if their most profitable customers think that none of the Java language updates they've released in the last ten years is worth upgrading for. The longer their customers stick with 2006-era Java, the longer they pass up Oracle's current offerings, the less attached they feel to the future of the platform, and the more likely they are to make a big change when they do make a change.

Re: Pattern Matching for Java

#117

Post by raspasov »

lmm wrote: post #89
raspasov wrote: post #41

Earlier quoted context omitted.

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.

The pattern matching I have in mind is very dynamic in nature and does not concern itself at all with some static notion the data that is being matched. Either there's a match, or there isn't. It's a very binary outcome.

Re: Pattern Matching for Java

#118

Post by peeters »

chriswarbo wrote: post #99
peeters wrote: post #11

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

> 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 didn't use "modern" to describe features, I used it to describe languages. Modern languages have a tendency toward multi-paradigm feature inclusion. So while the features themselves aren't new, combining well-received features from other languages and paradigms is largely a characteristic of modern languages. And newer languages have the upper hand here since it's easier to include a feature from the start than it is to retrofit it into a language.

Re: Pattern Matching for Java

#119

Post by barrkel »

lacampbell wrote: post #56
barrkel wrote: post #30

Earlier quoted context omitted.

Multiple dispatch is sometimes more elegant, provided you can divorce the method being dispatched to from the argument classes. If you need to do it with a visitor pattern and multiple callbacks, it's much worse. If you need completeness checking, it's worse. If you've got a simple concise algorithm best expressed in a loop, it's worse. If you've got a nested structure that you want to partially destructure, it's wor…

would you be able to give me a pseudo code example of things that are easy to do with pattern matching, but not multiple dispatch? I'm intrigued, I always considered them equivalent.

Here's some concrete examples in Rust:

http://pzol.github.io/getting_rusty/posts/20140417_destructu...

It's not just about finding the right bit of code to run; it's also about pulling some fields out of the polymorphic value so they're available as nice short names, without qualification.

Re: Pattern Matching for Java

#120

Post by macca321 »

peeters wrote: post #11

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

I retrofitted F# style "discriminated unions" (which are basically sealed heirarchies) into C# by creating a series of generic types `OneOf` 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`.

I don't know if this would work in Java, given the generic type erasure, but it might...

1. https://github.com/mcintyre321/OneOf

Post reply on HN