Javascript hasn't it yet, but there is an active proposal for it in the standardization committee: https://github.com/tc39/proposal-pattern-matching


On Wed, 5 Aug 2020 at 21:34, Luciano Ramalho <luciano@ramalho.org> wrote:
On Tue, Aug 4, 2020 at 1:37 PM Tobias Kohn <kohnt@tobiaskohn.ch> wrote:
> And experience from other programming languages who took the leap to having
> pattern matching shows that it quickly becomes a quite intuitive and easy to use feature.

The languages I know about that have pattern matching had it from the
start as a core feature.

I am curious to learn about languages that adopted pattern matching
later in their evolution.

Cheers,

Luciano


>
> Cheers,
> Tobias
>
> P.S. Please excuse my late reply; I am currently on vacation.
>
>
>
> Quoting Larry Hastings <larry@hastings.org>:
>
>
>
> On 7/31/20 12:36 AM, Tobias Kohn wrote:
>
> And since pattern matching is really
> a new feature to be introduced to Python, a feature that can
> be seen in different lights, there is no 'Python-Programmer
> intuition' that would apply in this case.
>
> It's not fair to say "intuition doesn't apply because it's new syntax".  There are plenty of examples of intuition serving a Python programmer well when encountering new syntax.  A Python programmer's intuition is informed by existing syntax and conventions in the language.  When they see a new construct, its similarity to existing constructs can make understanding the new syntax quite intuitive indeed.
>
> Take for example list comprehensions.  Python 1 programmers hadn't seen
>
> a = [x for x in y]
>
> But they knew what square brackets meant in that context, it meant "creates a new list".  And they knew what "for x in y" meant, that meant iteration.  Understanding those separate two concepts, a Python 1 programmer would be well on their way to guessing what the new syntax meant--and they'd likely be right.  And once they understood list comprehensions, the first time they saw generator expressions and set and dict comprehensions they'd surely intuit what those did immediately.
>
> The non-intuitiveness of PEP 622, as I see it, is that it repurposes what looks like existing Python syntax but frequently has wholly different semantics.  For example, a "class pattern" looks like it's calling a function--perhaps instantiating an object?--but the actual semantics and behavior is very different.  Similarly, a "mapping pattern" looks like it's instantiating a dict, but it does something very different, and has unfamiliar and seemingly arbitrary rules about what is permitted, e.g. you can't use full expressions or undotted-identifiers when defining a key.  Add the "capture pattern" to both of these, and a Python programmer's intuition about what this syntax traditionally does will be of little help when encountering a PEP 622 match statement for the first time.
>
> Cheers,
>
>
>
> /arry
>
>
>
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-leave@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/2VRPDW4EE243QT3QNNCO7XFZYZGIY6N3/
> Code of Conduct: http://python.org/psf/codeofconduct/



--
Luciano Ramalho
|  Author of Fluent Python (O'Reilly, 2015)
|     http://shop.oreilly.com/product/0636920032519.do
|  Technical Principal at ThoughtWorks
|  Twitter: @ramalhoorg
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/PI44AV5C2F2IMO6PJSYVJOPXGQ62JMHQ/
Code of Conduct: http://python.org/psf/codeofconduct/