7 ms·

Now even Java has pattern matching, what's Javascript's excuse? Literally the only feature preventing Typescript from being my perfect language.

by akavi 4y ago

Waterluvian 4y ago
https://github.com/tc39/proposal-pattern-matching https://github.com/tc39/proposal-pattern-matching I'm not sure if it's stalled or not. But it's being discussed.
- jackworks 4y ago
  We're still developing this proposal. be patient LOL
  - Waterluvian 4y ago
    I've got infinite patience for the brave souls who propose and implement TC-39 specs. =)
  - akavi 4y ago
    Sorry, that was rude of me. I know it's a ton of work, and am endlessly appreciative of the work you (I assume?) and others have been doing to push this forward.
  - javajosh 4y ago
    Wow that's a proposal! I really like the idea of pattern matching, and I'm glad you're steering clear of modifying switch, but I find the sketches in the proposal pretty hard to read, especially with the combinator examples. I hope you guys take your time and stay more proud of what you leave out than what you put in.
    - TheRealPomax 4y ago
      This is something that far too few folks put in their progress/change logs. "We didn't do ..." is so incredibly important.
    - hn_throwaway_99 4y ago
      The combinator example is the JS equivalent of what was discussed in another comment on this article, https://news.ycombinator.com/item?id=35247615 https://news.ycombinator.com/item?id=35247615. I like having the clarity of using different "and" and "or" keywords instead of overloading && and ||. But I definitely agree with the sentiment - every new feature is another thing that a developer needs to learn if they encounter that code. There should be a large "barrier to entry" for new features.
BiteCode_dev 4y ago
Given the terrible result we came up with in the Python community, I understand the JS wants to take their time. It's a great feature, but it's hard to get right, especially on an existing language. Not to mention JS is not typed, but pattern matching that can't match typescript types would be terrible.
- sgt 4y ago
  What's wrong with match? I've used it quite a bit and it is quite powerful.
  - BiteCode_dev 4y ago
    The syntax is reusing regular python syntax with completely different effects, so you have to learn 2 syntaxes. Trying to do simple things like matching the content of a variable will fail if you forget you have to use a dotted path if you want to avoid binding. Trying to do advanced things such as "match a dict with variable key names and values, but you wish to enforce the number and the types and unpack them in variables" is ridiculously twisted to do, when it's even possible. I use match/case, but it like the early years of type hints or asyncio: terrible ergonomics, and we know there is a ceiling to how much it can improve.
  - vexna 4y ago
    Its incredibly powerful! One downside is variables captured in the match are lifted to the function level. The lack of block level scoping in the match statement leads to a lot of people shooting themselves in the foot by overwriting a variable that they didn't intend to. On a personal note, I find the 2 levels of indentation to reach the case body to be too much as well... but that's just a personal preference.
Yahivin 4y ago
Check out Civet https://civet.dev/#pattern-matching https://civet.dev/#pattern-matching
dgb23 4y ago
I don't see a huge benefit for pattern matching in JS outside of it being expression based rather than statement based. Either way, the benefit has to be enormous. It's a feature that can easily break existing code.
- baq 4y ago
  In a world where upgrading node versions without language changes breaks existing code I wouldn’t be too worried.
- int_19h 4y ago
  How would it break existing code?
  - dgb23 4y ago
    Because it is an expression that introduces a new keyword. You could say “return match…” It’s not easy to introduce without breakage. Not saying it cannot be done. But PHP didn’t manage to for example. It also isn’t real pattern matching but that’s a different issue.
    - int_19h 4y ago
      Oh, so you were referring to the specific syntax in the current proposal, rather than pattern matching in general? Java and C# show how the syntax can be done in a fully backwards-compatible manner. It looks like it's just not the JS way by choice - apparently every new keyword that was added since ES5 is an actual keyword reserved in all contexts, not context-dependent?
      - dgb23 4y ago
        That’s good to hear!
Alifatisk 4y ago
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.

Now even Java has pattern matching, what's Javascript's excuse? Literally the only feature preventing Typescript from being my perfect language.

by akavi 4y ago

Now even Java has pattern matching, what's Javascript's excuse? Literally the only feature preventing Typescript from being my perfect language.

Waterluvian 4y ago

https://github.com/tc39/proposal-pattern-matching https://github.com/tc39/proposal-pattern-matching I'm not sure if it's stalled or not. But it's being discussed.

jackworks 4y ago
We're still developing this proposal. be patient LOL
- Waterluvian 4y ago
  I've got infinite patience for the brave souls who propose and implement TC-39 specs. =)
- akavi 4y ago
  Sorry, that was rude of me. I know it's a ton of work, and am endlessly appreciative of the work you (I assume?) and others have been doing to push this forward.
- javajosh 4y ago
  Wow that's a proposal! I really like the idea of pattern matching, and I'm glad you're steering clear of modifying switch, but I find the sketches in the proposal pretty hard to read, especially with the combinator examples. I hope you guys take your time and stay more proud of what you leave out than what you put in.
  - TheRealPomax 4y ago
    This is something that far too few folks put in their progress/change logs. "We didn't do ..." is so incredibly important.
  - hn_throwaway_99 4y ago
    The combinator example is the JS equivalent of what was discussed in another comment on this article, https://news.ycombinator.com/item?id=35247615 https://news.ycombinator.com/item?id=35247615. I like having the clarity of using different "and" and "or" keywords instead of overloading && and ||. But I definitely agree with the sentiment - every new feature is another thing that a developer needs to learn if they encounter that code. There should be a large "barrier to entry" for new features.

BiteCode_dev 4y ago

Given the terrible result we came up with in the Python community, I understand the JS wants to take their time. It's a great feature, but it's hard to get right, especially on an existing language. Not to mention JS is not typed, but pattern matching that can't match typescript types would be terrible.

sgt 4y ago
What's wrong with match? I've used it quite a bit and it is quite powerful.
- BiteCode_dev 4y ago
  The syntax is reusing regular python syntax with completely different effects, so you have to learn 2 syntaxes. Trying to do simple things like matching the content of a variable will fail if you forget you have to use a dotted path if you want to avoid binding. Trying to do advanced things such as "match a dict with variable key names and values, but you wish to enforce the number and the types and unpack them in variables" is ridiculously twisted to do, when it's even possible. I use match/case, but it like the early years of type hints or asyncio: terrible ergonomics, and we know there is a ceiling to how much it can improve.
- vexna 4y ago
  Its incredibly powerful! One downside is variables captured in the match are lifted to the function level. The lack of block level scoping in the match statement leads to a lot of people shooting themselves in the foot by overwriting a variable that they didn't intend to. On a personal note, I find the 2 levels of indentation to reach the case body to be too much as well... but that's just a personal preference.

Yahivin 4y ago

Check out Civet https://civet.dev/#pattern-matching https://civet.dev/#pattern-matching

dgb23 4y ago

I don't see a huge benefit for pattern matching in JS outside of it being expression based rather than statement based. Either way, the benefit has to be enormous. It's a feature that can easily break existing code.

baq 4y ago
In a world where upgrading node versions without language changes breaks existing code I wouldn’t be too worried.
int_19h 4y ago
How would it break existing code?
- dgb23 4y ago
  Because it is an expression that introduces a new keyword. You could say “return match…” It’s not easy to introduce without breakage. Not saying it cannot be done. But PHP didn’t manage to for example. It also isn’t real pattern matching but that’s a different issue.
  - int_19h 4y ago
    Oh, so you were referring to the specific syntax in the current proposal, rather than pattern matching in general? Java and C# show how the syntax can be done in a fully backwards-compatible manner. It looks like it's just not the JS way by choice - apparently every new keyword that was added since ES5 is an actual keyword reserved in all contexts, not context-dependent?
    - dgb23 4y ago
      That’s good to hear!

Alifatisk 4y ago

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.