Hacker News new | ask | show | jobs
by sillysaurusx 2179 days ago
I have a visceral dislike of pattern matching. Lisp shows just how much people will abuse it in real-world production codebases. It becomes impossible to understand even simple logic without comments. I’d link to some examples, but I’m on mobile; suffice to say, pull up the emacs codebase and read through some of the more advanced modules like edebug.el. I’m not certain that one uses pattern matching, but it’s a perfect example of “this codebase cannot be understood without extensive study of language features.”

You may argue that I am simply not versed enough in pattern matching. “You should study harder.” I would argue that simplicity is worth striving for.

I hope this PEP never moves beyond draft.

It’s also shocking that most people here seem to be tacitly supporting this, or happy about it. Yes, it’s cool. Yes, it might simplify a few cases. But it will also give birth to codebases that you can’t read in about, say, 5 years. And then you’ll have a bright line between people in the camp of “This is perfectly readable; it does so and so” and the rest of us regular humans that just want to build reliable systems.

And oh yes, it becomes impossible to backport to older python versions. Lovely.

5 comments

A good pattern matching library in Lisp makes code a heck of a lot more readable.

Firstly, even basic list destructuring with destructuring-bind is an improvement over a soup of car/cadar/caddr/.

Suppose we are in a compiler and would like to look for expressions of he pattern:

   (not (and (not e0) (not e1) (not e2) ...))
in order to apply DeMorgan's and rewrite them to

   (or e0 e1 ...)
I would rather have a nice pattern matching case like this:

   (match-case expr
      ...
      ((not (and @(zeromore not @term)))
       `(or ,term))  ;; rewrite done!
      ...)
than:

   (if (and (consp expr)
            (eq (car expr) 'not))
            (consp (cdr expr))
            (consp (cadr (expr)))
            (null (cddr expr))
            (eq (caadr (expr)) 'and)
            (eq (cadr expr) 
      ... ad nauseum)
Even if a fail-safe version of destructuring-bind is used to validate and get the basic shape, it's still tedious:

    (destructuring-case expr
         ...
       ((a (b c))
        (if (and (eq a 'and)
                 (eq b 'not))
           ... now check that c is a list of nothing but (not x) forms
           )))

I don't have a pattern matcher in TXR Lisp. That is such a problem that it's holding up compiler work! Because having to write grotty code just to recognize patterns and pull out pieces is demotivating. It's not just demotivating as in "I don't feel like doing the gruntwork", but demotivating as in, "I don't want to saddle my project with the technical debt caused by cranking out that kind of code", which will have to be rewritten into pattern matching later.
People use pattern matching all the time in ML or rust or haskell or Scala or Elm. It's totally uncontroversial there, and it's helpful to readability, not harmful. Erlang and Elixir also show it works in untyped languages pretty well.
Python is famous for its readability. ML, rust, and Haskell are famous for their unreadability.
Apart from Clojure, lisps generally do not support destructuring pattern matching on an object/dict.
The defining feature of lisp is that it can support whatever you want, because the AST is available at compile time and is completely regular. If your point is about dicts specifically, then you might be technically correct, but I assure you that the majority of lisp codebases do support exactly the sort of pattern matching in this PEP. And the abuses are frankly egregious. Racket is the worst offender of them all, with syntax matching.
Trivia or Optima in Common Lisp support that.
I’ve never had this issue with lisp code bases, and I’ve read through quite a bit of lisp by now. For me, lisps—whether CL, Clojure or Emacs Lisp—are some of the easiest languages for me to identify and correct the source of a bug in.
Can you provide any examples?