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

141–150 of 254 posts

Re: JavaScript Pattern Matching Proposal

#141

Post by chc »

christophilus wrote: post #125
curun1r wrote: post #121

Earlier quoted context omitted.

It's probably more of a "know your audience" decision. Anyone who's used an ML-derived language will understand the motivation for pattern matching. But a large percentage of JS developers don't really have much background in non-mainstream languages or programming language theory, so they chose an example that's likely to resonate more with that group.

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

I think you're a super anomalous member of any programming language's community. I doubt even one programmer in a thousand has written F# professionally (not being hipster here — I haven't done it myself).

Re: JavaScript Pattern Matching Proposal

#142

Post by lispm »

masklinn wrote: post #100
stiGGG wrote: post #69

Earlier quoted context omitted.

Yeah, this applies to all that old Lisp features.

AFAIK pattern-matching is not a historical Lisp feature, it's usually been limited to simple destructuring. In the modern acception of tree patterns (as opposed to text patterns aka regular expressions), I guess it comes from ML (and possibly prolog but prolog's unification goes even further?): it doesn't look like ISWIM had tree patterns and I can't find older references.

In Lisp pattern-based programming has been first implemented in 1962 in by D.Bobrow (METEOR). From then on there are many implementations of pattern matching in Lisp based software, from Planner, to rule-based systems, LISP70 (Tesler, ...)...

Re: JavaScript Pattern Matching Proposal

#143

Post by jwr »

WaxProlix wrote: post #112
lgessler wrote: post #108

Looking at this as someone who's been writing a lot of ClojureScript lately, I'm reminded of how nice it is to be writing in a Lisp: if I felt this was the right syntactic construct for a common-enough problem in my codebase, I'd write a macro for it and get on with my life without having to wait for it to trickle through committees, compilers, and browser implementations.

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 macros, they can be libraries widely accepted by the community.

I had a similar thought when reading the ECMAscript extension proposal: I'm glad that in the languages I use, features like that can be provided by libraries.

Re: JavaScript Pattern Matching Proposal

#144

Post by mattferderer »

I would imagine you could do typeof === "string" or instanceof Foo to add JS's limited type support? Elixir is similar in that it's not a typed language but can allow limited types like this.

I personally wish the syntax was similar to overloading functions in other languages, but I doubt that's possible due to the way destructuring & default values were implemented.

Re: JavaScript Pattern Matching Proposal

#145

Post by lispm »

_delirium wrote: post #82
stiGGG wrote: post #69

Earlier quoted context omitted.

Yeah, this applies to all that old Lisp features.

I think of full-featured pattern matching as a fairly recent addition even to Lisp. Lisp has had some pattern-matching constructs forever of course (cond, destructuring-bind, Norvig's sexp matcher from PAIP [1], etc.). But it's only with the more recent emergence of optima [2] as a de-facto standard that it now has really good pattern matching. It was probably the #1 thing I missed in Lisp, after having used ML a bit…

The first embedded language for programming with patterns for Lisp was implemented 1962 by Daniel Bobrow.

https://dspace.mit.edu/handle/1721.1/6106

Re: JavaScript Pattern Matching Proposal

#146

Post by mpfundstein »

goatlover wrote: post #103
Prefinem wrote: post #84

Earlier quoted context omitted.

Life is more fun with fat arrows sometimes new Promise(function (resolve, reject) { methodOne(data, function (error, response) { if (erorr) { reject(error); } else { resolve(response); } }) }) vs new Promise((resolve, reject) => methodOne(data, (error, response) => error ? reject(error) : resolve(response)));

That one liner has a lot going on. The first one is easier to read.

no

Re: JavaScript Pattern Matching Proposal

#147

Post by snek »

genezeta wrote: post #77

Leaving aside syntax preferences or other superficial concerns, I find it discouraging that "Motivating Examples" for a proposal include direct references to particular libraries, or particular libraries' examples. I mean, that one (of two) motivations for adding a feature to a language is "Terser, more functional handling of Redux reducers", just feels wrong and casual.

Usage of these libraries are not the reason this proposal exists, but rather demonstrating how the proposal fits with popular tools and such within the ecosystem.

Re: JavaScript Pattern Matching Proposal

#148

Post by GlennS »

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 feel like JavaScript is already a sort of functional language, so going in this direction is ok.

It's the object/class additions where I think it's all going a bit C++.

Start with prototypical inheritance, but with a Java-style `new` keyword that makes everything confusing. Next bolt on classes on the one hand, while correcting your prototype system `Object.create` on the other.

R has 3 different object systems and none of them are any good. How long before JavaScript catches up?

Re: JavaScript Pattern Matching Proposal

#150

Post by halestock »

genezeta wrote: post #77

Leaving aside syntax preferences or other superficial concerns, I find it discouraging that "Motivating Examples" for a proposal include direct references to particular libraries, or particular libraries' examples. I mean, that one (of two) motivations for adding a feature to a language is "Terser, more functional handling of Redux reducers", just feels wrong and casual.

I actually drew the opposite conclusion. As in, "here's an example of how a commonly used library is overly verbose and how it could be simplified with this language extension."
Post reply on HN