Re: Instead of pcase

[Emanuel Berg]

Jim Porter wrote:

>> Those of you who are fans of `pcase' may not recognize the
>> cost it imposes on the Emacs Lisp language. You paid that
>> cost already, perhaps a few years ago, and perhaps you
>> enjoy each new language construct you learn. Perhaps, for
>> you, the more complexity of features to be learned,
>> the better.
>
> I'd like to offer a slightly different perspective here, as
> someone who only fairly recently became comfortable with
> Lisp (of any variety). I've used Emacs for a long time, but
> I found Lisp completely incomprehensible until just a couple
> of years ago. While getting started with Lisp isn't terribly
> complex, it's still quite a bit to learn, and it took
> a period where I was between jobs before I could dedicate
> the time I needed to get comfortable with writing Lisp.
>
> I encountered a lot of hurdles with Lisp along the way.
> The first one was extremely basic: I needed to get used to
> the style of indentation and develop an intuition for
> *reading* Lisp code, rather than slowly and laboriously
> translating it into a form I could understand more easily.
>
> The next hurdle was quoting. I still remember that one of my
> first patches to Emacs needed someone else to fix it in
> a followup because I messed up the quoting. The issues of
> quoting came up repeatedly for me as I encountered
> progressively more complex examples of quoting.
>
> This is where we get to 'pcase'. I'll agree that the upper
> limit on complex quoted forms in 'pcase' is very high.
> I've used 'pcase-defmacro' in one nontrivial case, and
> I found it very difficult to get right.
>
> *However*, 99% of the 'pcase' instances I've written or
> encountered are pretty simple for me to understand.
> Once I learned about 'pred' matcher and how to destructure
> via backquote patterns, it was mostly smooth sailing for me.
>
> Now, while I'd certainly say that I enjoy learning overall
> (or else I likely wouldn't have learned Lisp in the first
> place), I don't consider the complexity of a feature to be
> a positive. Instead, I prefer features that give me more
> power or better expressiveness. Often, that expressiveness
> comes at the cost of complexity under the hood (e.g.
> 'pcase-defmacro'), but that's not a positive to me in and
> of itself.
>
> Overall, 'pcase' is one of the parts of Elisp that
> I appreciate the most. Learning the basics of its
> mini-language took just a bit of reading. In addition to the
> docs, seeing examples helped: the first few times were a bit
> tricky to read, but I could usually understand what was
> happening, even if I couldn't (at the time) write my own
> 'pcase' code that worked. However, once I got the basics
> down, I quickly saw the benefits: I could combine a handful
> of basic tools to do bigger things, meaning I only need to
> know a small set of facts before I can tackle a complex
> task. This, to me, is the mark of a good language feature:
> I can compose it in ways that *multiply* the power of each
> (small, easy) bit.
>
> At a higher level, I'd say it's worth considering the
> audience we want to focus on. For veteran (Emacs) Lisp
> programmers, new additions like 'pcase' can increase the
> difficulty of reading new Elisp code: your prior mastery of
> the language isn't any good when you hit that "(pcase".
> However, many programmers today don't know Lisp, of any
> variety. For people like that, learning to contribute to
> Emacs means learning from the very beginning. Having gone
> through this, most of 'pcase' was very easy for me to pick
> up, and other parts of Elisp were much more challenging (it
> took me a long time to get comfortable with writing macros,
> which is also probably one of the reasons I found
> 'pcase-defmacro' to be so tricky).
>
> That said, it's true that every feature we add to Elisp
> increases the overall complexity because now there are more
> things to learn. However, in my opinion, the expressiveness
> of 'pcase' far outweighs this cost.

Well said! Thank you for this post. I agree, and I enjoyed
reading it.

-- 
underground experts united
https://dataswamp.org/~incal