3 ms·

What’ the hype with pattern matching? What does it solve?

dcminter 4y ago
It's really nice syntactic sugar. Complicated conditional logic cluttered with redundant types turns into a series of simple patterns. "Just" makes it easier to not make stupid bugs (I'm all for it).
- therealdrag0 4y ago
  Agreed. Example from Scala // Given an Option val maybeThing: Option[String] = getThing() // Classic if (maybeThing.isDefined) { useThing(maybeThing.get) } else { NotFoundResponseEtc() } // Pattern matching (not too IDE auto generated exhaustive match cases!) maybeThing match { case Some(thing) => useThing(thing) case None => NotFoundResponseEtc() } This scales well when matching a higher cardinality of things like a variety of Exceptions or enums or other tuple responses like Either etc.
brabel 4y ago
Hype with pattern matching? That sounds quite funny to me considering certain languages (Haskell, Erlang, OCaml...) have had that for decades. What convinced me of the power of pattern matching was seeing a red-black binary tree being implemented effortlessly in Ocaml (I think), while in C++ and Java it was a really difficult algorithm to implement. When you have provably exhaustive pattern matching (i.e. the compiler forces you to handle every possible case), certain things that are very difficult to write otherwise become very easy.
munificent 4y ago
If you've ever done any assembly programming or worked with other old or low level languages, you may have encountered an environment where you can write simple operator expressions, but you can't compose them. So this is OK: a = b + c d = e - f g = a * d But the compiler doesn't allow: g = (b + c) * (e - f) You have expressions that produce, but they don't compose. You can't produce a value from a more complex, nested expression. We, rightly, no longer use languages like that. Pattern matching parallels that, except for assignment and decomposing values. Many languages today let you write: topLeft = rect.topLeft.x; left = topLeft.x; top = topLeft.y; bottomRight = rect.bottomRight; right = bottomRight.x; bottom = bottomRight.y; Or even: left = rect.topLeft.x; top = rect.topLeft.y; right = rect.bottomRight.x; bottom = rect.bottomRight.y; (Because at least you can compose expressions on the RHS.) But they don't let you write: (topLeft, bottomRight) = rect; (left, top) = topLeft; (right, bottom) = bottomRight; Or even: ((left, top), (right, bottom)) = rect; Pattern matching gives you that. It is freely composable destructuring. Also, the "matching" part means that in many languages you can also ask questions about values as you destructure them, which enables a particularly nice style of programming.
- hn_throwaway_99 4y ago
  All of your examples basically map to Javascript destructuring, which is already fully supported. Comment you are replying to is asking about pattern matching for flow control or conditional assignment, which JS doesn't currently support.
- satvikpendem 4y ago
  Is Dart's pattern matching influencing the JS proposal as well? Or are both sort of separate without much influence from either side?
  - munificent 4y ago
    I have read the JS proposal many times, so it's an influence on Dart. I suspect Dart hasn't had much influence on JS because our proposal is newer.
- vips7L 4y ago
  > the "matching" part means that in many languages you can also ask questions about values as you destructure them, I started implementing Lox with Java's sealed classes + pattern matching on switch. The exhaustiveness has been really nice to ensure I cover each new token/expression as I add them.
nvarsj 4y ago
It makes it very easy to deal with nested data structures. Imagine creating a nested map/struct literal, and then extract the values out using a very similar syntax on a single line. It's one of those things that when you get used to, you wonder why other languages don't implement it.
- Alifatisk 4y ago
  I think this answers the question very well, thank you. I found this [1] documentation from Ruby explain what it solves pretty good aswell. [1] https://docs.ruby-lang.org/en/3.0/syntax/pattern_matching_rdoc.html https://docs.ruby-lang.org/en/3.0/syntax/pattern_matching_rd...
deleted 4y ago
[deleted]

It's really nice syntactic sugar. Complicated conditional logic cluttered with redundant types turns into a series of simple patterns. "Just" makes it easier to not make stupid bugs (I'm all for it).

therealdrag0 4y ago
Agreed. Example from Scala // Given an Option val maybeThing: Option[String] = getThing() // Classic if (maybeThing.isDefined) { useThing(maybeThing.get) } else { NotFoundResponseEtc() } // Pattern matching (not too IDE auto generated exhaustive match cases!) maybeThing match { case Some(thing) => useThing(thing) case None => NotFoundResponseEtc() } This scales well when matching a higher cardinality of things like a variety of Exceptions or enums or other tuple responses like Either etc.

brabel 4y ago

Hype with pattern matching? That sounds quite funny to me considering certain languages (Haskell, Erlang, OCaml...) have had that for decades. What convinced me of the power of pattern matching was seeing a red-black binary tree being implemented effortlessly in Ocaml (I think), while in C++ and Java it was a really difficult algorithm to implement. When you have provably exhaustive pattern matching (i.e. the compiler forces you to handle every possible case), certain things that are very difficult to write otherwise become very easy.

munificent 4y ago

If you've ever done any assembly programming or worked with other old or low level languages, you may have encountered an environment where you can write simple operator expressions, but you can't compose them. So this is OK: a = b + c d = e - f g = a * d But the compiler doesn't allow: g = (b + c) * (e - f) You have expressions that produce, but they don't compose. You can't produce a value from a more complex, nested expression. We, rightly, no longer use languages like that. Pattern matching parallels that, except for assignment and decomposing values. Many languages today let you write: topLeft = rect.topLeft.x; left = topLeft.x; top = topLeft.y; bottomRight = rect.bottomRight; right = bottomRight.x; bottom = bottomRight.y; Or even: left = rect.topLeft.x; top = rect.topLeft.y; right = rect.bottomRight.x; bottom = rect.bottomRight.y; (Because at least you can compose expressions on the RHS.) But they don't let you write: (topLeft, bottomRight) = rect; (left, top) = topLeft; (right, bottom) = bottomRight; Or even: ((left, top), (right, bottom)) = rect; Pattern matching gives you that. It is freely composable destructuring. Also, the "matching" part means that in many languages you can also ask questions about values as you destructure them, which enables a particularly nice style of programming.

hn_throwaway_99 4y ago
All of your examples basically map to Javascript destructuring, which is already fully supported. Comment you are replying to is asking about pattern matching for flow control or conditional assignment, which JS doesn't currently support.
satvikpendem 4y ago
Is Dart's pattern matching influencing the JS proposal as well? Or are both sort of separate without much influence from either side?
- munificent 4y ago
  I have read the JS proposal many times, so it's an influence on Dart. I suspect Dart hasn't had much influence on JS because our proposal is newer.
vips7L 4y ago
> the "matching" part means that in many languages you can also ask questions about values as you destructure them, I started implementing Lox with Java's sealed classes + pattern matching on switch. The exhaustiveness has been really nice to ensure I cover each new token/expression as I add them.

nvarsj 4y ago

It makes it very easy to deal with nested data structures. Imagine creating a nested map/struct literal, and then extract the values out using a very similar syntax on a single line. It's one of those things that when you get used to, you wonder why other languages don't implement it.

Alifatisk 4y ago
I think this answers the question very well, thank you. I found this [1] documentation from Ruby explain what it solves pretty good aswell. [1] https://docs.ruby-lang.org/en/3.0/syntax/pattern_matching_rdoc.html https://docs.ruby-lang.org/en/3.0/syntax/pattern_matching_rd...

deleted 4y ago

[deleted]