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

JavaScript Pattern Matching Proposal

github.com

Post reply on HN
Print view View original

161–170 of 254 posts

Re: JavaScript Pattern Matching Proposal

#161

Post by edflsafoiewq »

masklinn wrote: post #107
Analemma_ wrote: post #25

Earlier quoted context omitted.

Pattern matching doesn't work the same way as switch/case though. Using that syntax would be misleading and confusing.

C's switch/case is essentially a special case with a limited set of values (literals) and no destructuring. You can extend it to less trivial patterns and blam pattern matching.

No, switch is not like a special case of match. C's switch is a kind of computed goto and can build irreducible control flow graphs. match is a reducible structured control-flow construct whose power comes from destructuring. match is much, much more like an if-else chain than a switch.

Re: JavaScript Pattern Matching Proposal

#162

Post by edflsafoiewq »

LOLCAT1024 wrote: post #160

This proposal will increase code coupleing by fixing the object structure, this will lead to refactoring problems and so on. A better approach would allow to match objects by their fileds while leaving the structure of the object unspecified.

Can you elaborate? What do you mean "match objects by their fields"? How does the proposal not already do that?

Re: JavaScript Pattern Matching Proposal

#163

Post by emodendroket »

sibeliuss wrote: post #154
minor3rd wrote: post #126

Earlier quoted context omitted.

I think it's a stereotype from the old web when it didn't require as much technical skill as other programming fields. Most of my colleagues started in other languages and learned Node/JS on the job.

With JavaScript being the most used language in the world I highly doubt the old stereotypes still apply

Unless front-end development as a category has completely disappeared in the last few years there are certainly quite a few people who don't know how to do anything else.

Re: JavaScript Pattern Matching Proposal

#164

Post by westoncb »

sibeliuss wrote: post #154
minor3rd wrote: post #126

Earlier quoted context omitted.

I think it's a stereotype from the old web when it didn't require as much technical skill as other programming fields. Most of my colleagues started in other languages and learned Node/JS on the job.

With JavaScript being the most used language in the world I highly doubt the old stereotypes still apply

Is it the most used language in the world? Seems like I keep hearing comments like that, but the rankings I've seen don't list it that way.

Re: JavaScript Pattern Matching Proposal

#165

Post by emodendroket »

jwr wrote: post #143
WaxProlix wrote: post #112

Earlier quoted context omitted.

And the next person to maintain your codebase would be grateful for your choice and insight, I'm sure. Permissiveness is good for small projects but it can feel like getting into a suit tailored specifically for everyone else as projects get bigger.

I don't think this snarky remark is warranted. I think the point was that in Lisp-style languages (such as Clojure/ClojureScript) new features such as pattern matching can easily be added without "changing the language", as libraries. This is how core.async was added to Clojure, to pick a non-trivial example. Or more to the point, how core.match works. Additions such as those do not have to be one lonely programmer's…

Yes, but I think the other point is well-made, as well: languages that allow this can be very difficult to work in if you have to maintain a large app with multiple contributors over a long period of time.

Re: JavaScript Pattern Matching Proposal

#166

Post by emodendroket »

bcheung wrote: post #156

I'm wondering whether types would be required to implement static analysis to see if a particular scenario in the match is not handled. Haskell has the ability to generate a compile error if you don't have a match specified for each possible permutation. This makes it easy to make sure you handle all possible inputs. This probably wouldn't be possible in JS. Probably the best that could be done would be if the defaul…

The example seems to be a dictionary, so of course you cannot guarantee that all possible permutations are covered.

Re: JavaScript Pattern Matching Proposal

#167

Post by whatever_dude »

frou_dh wrote: post #122

You know that quip about C++ being an octopus made by nailing extra legs onto a dog? Is the same phenomenon somehow tasteful when it comes to ECMAScript {({..., sy: nt => ax, ...}({,})} ?

I think C++ is the best example of where JS is heading.

We have different ways of doing the same thing, and you have to know the "right" and "wrong" ways based on whatever was the latest proposal.

We have fringe proposals that are just based on something cool some other language did, and they might stick or they might not.

We'll soon have the really obscure constructs that nobody uses except for this guy on the 3rd floor, and he's really vocal about it so watch out.

Maybe we'll even finally get macros in JavaScript [1] soon.

1: http://peter.michaux.ca/articles/macros-in-javascript-please

Re: JavaScript Pattern Matching Proposal

#168

Post by pmarreck »

Tloewald wrote: post #119

So the proposal is super confusing to me (but I hadn't seen match before). At first I thought it had something to do with regex. Essentially it's a switch variant that is (a) confusingly named 'match' (bad) (b) returns a value (good?) (c) and is actually a kind of function (wha?), since it (d) supports recursion, but (e) doesn't require break (good), (f) looks like a bag of inline functions but isn't (bad). How about…

Huge fan of pattern matching and destructuring with rebinding in Elixir (where it actually goes far deeper), it makes code way more succinct. It seems like you haven't grokked it yet (or played with it by trying to write code with it and feeling out what it's actually doing for you vs. the alternatives)... read https://elixir-lang.org/getting-started/pattern-matching.htm... as well as https://elixir-lang.org/getting-started/case-cond-and-if.htm... where you will see that this proposed construct is almost the same syntactically as `case` in Elixir.

Changing `case` in JS to these entirely different semantics would break pretty much everything, which is likely why a new keyword was needed.

Re: JavaScript Pattern Matching Proposal

#169

Post by cshepp »

mpfundstein wrote: post #135
cshepp wrote: post #35

Pattern matching would be a great addition to JS. I built a pattern matching library[1] with a very similar syntax back in 2015 (although I will be the first to admit that it's a naive implementation). It makes validating/traversing deeply-nested objects much less verbose. I'm excited to see where this proposal goes. [1] https://github.com/cshepp/Kasai

Shameless plug but here is my pattern machter [1] :D Example: // simple factorial const factorial = n => match(n) .when(0, 1) .otherwise(n => n * factorial(n - 1)); // walking a tree class Tree { constructor(left, right) { this.left = left; this.right = right; } } class Node { constructor(value) { this.value = value; } } const T = (l, r) => new Tree(l, r); const N = v => new Node(v); const walkT = t => match(t) .when…

Method-based syntax for pattern matching is easier to read and grok (IMO), but it lacks the dynamic capabilities of data-oriented syntax (in Kasai, patterns can be built/manipulated at runtime). It's interesting to compare the two approaches.

Re: JavaScript Pattern Matching Proposal

#170

Post by noxToken »

curun1r wrote: post #157
christophilus wrote: post #125

Earlier quoted context omitted.

> But a large percentage of JS developers don't really have much background in non-mainstream languages or programming language theory Not to side-track the issue, but I keep hearing this. I'm wondering if this is true, and if so, how such a statement is verified. I'm currently a full-time JS dev, but have written my own programming languages, have professionally written in C, C++, C#, F#, Ruby, and others, and have…

It's certainly been my experience that there are a lot of JS developers who aren't like you, though I have met a few who are. But JS has traditionally been one of the most accessible languages. Before transpilers became common, view source allowed non-programmers to learn javascript by example. And because of it's use in the front-end/web, you saw a lot graphic designers and other non-programmers learn it to be able…

> Javascript also goes out of its way to be friendlier. While other languages complain when you try to add two different width integers, Javascript will happily add a number and a string together. It's something that drives those of us with a static typing background nuts, but makes the language more approachable overall.

We have differing definitions of friendly. Since I understand types and operator overloading, I know that 1 and "1" are different. I also know that the operator + does traditional math addition and concats Strings. If I didn't, it would probably drive me bonkers that "1" + 1 is "11" in JS instead of 2 or even "2". Having knowledge about types and overloading automatically tells me that String + Int = String.

I'm not saying that JS is bad since it lacks static typing. I'd argue that lack of static typing makes a language tougher to learn rather than more approachable. The barrier of entry is lower, but makes comprehension tougher.

Post reply on HN