
Why Lisp macros are cool, a Perl perspective (2005) - pcr910303
http://lists.warhead.org.uk/pipermail/iwe/2005-July/000130.html
======
dang
A thread from 2018:
[https://news.ycombinator.com/item?id=17990114](https://news.ycombinator.com/item?id=17990114)

2014:
[https://news.ycombinator.com/item?id=8698074](https://news.ycombinator.com/item?id=8698074)

2012:
[https://news.ycombinator.com/item?id=4246143](https://news.ycombinator.com/item?id=4246143)

2009:
[https://news.ycombinator.com/item?id=795344](https://news.ycombinator.com/item?id=795344)

~~~
Y_Y
2022:
[https://news.ycombinator.com/item?id=32644851](https://news.ycombinator.com/item?id=32644851)

~~~
giancarlostoro
I know you're being funny but it's part of the community culture to always
link to prior discussions cause they might spark continuing discussion and
extended context to the article.

~~~
RHSeeger
I didn't read it as mocking the people posting previous discussions. Rather, I
read it as saying "and it'll be discussed again... it always is".

~~~
giancarlostoro
Well thats kind of a given for posts with so many repeated prior discussions.

------
overgard
I don't think Lisp is ugly or anything, but part of me wonders if, in
languages with syntax, the lack of expressivity is a feature rather than a
bug. Partially because wrong things look wrong, if the syntax is intelligently
designed. The setx example he gave seemed perfect in that respect, while it's
superficially pretty neat, the maintainer in me started to think about what it
would be like to debug that, or all the horrible ways it could act slightly
different than you'd expect. I kind of like that assignment in the languages I
use is really boring for the most part. I dont think that setf example is a
footgun per se, but, I would have to look at it more closely than in another
language like python.

~~~
kyllo
The best thing about a highly expressive language is that you can do anything
you want to.

The worst thing about a highly expressive language is that you can do anything
you want to.

Expressive power vs. intelligibility (for the sake of common convention and
communication in a team setting) is a real tradeoff, and the "principle of
least power" does partially explain the popularity of slightly less-powerful
languages like Java, Python, and Go, where there is generally just one
idiomatic pattern for accomplishing a given task.

~~~
jacobush
I have done some Real Work ™ in Lisp, but dear deity, Forth... that to me
_really_ is _you can do anything you want to_ \- in such a scary way I have
never worked up the courage to actually learn it.

~~~
astrobe_
If you go full Forth you start with writing your own interpreter, so what you
are scared of is really your own shadow.

And that's one of the qualities of Forth: to stop worrying, stop being scared
of yourself, stop being scared of the future... Or more precisely it learns
you to fear the right thing: namely the Great Evil of Accidental Complexity,
which often disguise itself as necessary evil.

~~~
jacobush
That resonates... I'm actually afraid of what I may become taking that path.
:)

------
valw
I wrote a blog post making a similar point with Clojure as an example:
[https://vvvvalvalval.github.io/posts/2018-01-06-so-yeah-
abou...](https://vvvvalvalval.github.io/posts/2018-01-06-so-yeah-about-
clojures-syntax.html)

The core ideas are timeless really, but the examples might be a bit more
relatable today.

I'm reproducing the ToC here:

    
    
      1. Does syntax matter?
      2. The ingredients of Clojure's syntax
        2.1 Data literals
        2.2 Macros
      3. Consequences
        3.1 Verbosity is a solved problem
        3.2 Separation of concerns: code layout ⊥ program structure
          3.2.1 Example: the Builder Pattern
        3.3 Code = Data = Data Viz
        3.4 Tooling as libraries
        3.5 An 'all-tracks' language: embedding paradigms
          3.5.1 Example: Web UIs
        3.6 Saner language stewardship
      4. Summary

------
ragebol
What's with the `=3D` all over the place? I tried searching for it but that
doesn't do much useful unfortunately.

~~~
thomaslee
[https://en.wikipedia.org/wiki/Quoted-
printable](https://en.wikipedia.org/wiki/Quoted-printable)

Note that 0x3D is the "=" character in ASCII, so "=3D" in QP is "=" in ASCII.
:)

This email has probably been through a few conversions to QP and back again
between different email clients. Perhaps some buggy client got confused
between an ASCII "=" and a QP escape sequence or something like that.

~~~
ragebol
Roughly what I expected, TIL, thnx

------
B1FF_PSUVM
Unpopular opinions, CLVII: Sturgeon's law applies to macros. Squared.

~~~
RHSeeger
Being able to write new control structures is something I miss in most
languages. Lisp macros make it much easier to do that. Tcl uplevel and upvar
are another way to approach it.

~~~
LessDmesg
Curious: what kind of new control structures do you miss in other languages?

~~~
stevelosh
This would save me literally thousands of lines of code at my day job:

    
    
        (defmacro ?= (symbol-or-symbols expr)
          (let* ((symbols (etypecase symbol-or-symbols
                            (cons symbol-or-symbols)
                            (symbol (list symbol-or-symbols))))
                 (tmps (loop :for s :in symbols :collect (gensym (symbol-name s))))
                 (err (gensym "ERROR")))
            `(multiple-value-bind (,@tmps ,err) ,expr
               (if (not (null ,err))
                 (return ,err)
                 (setf (values ,@symbols) (values ,@tmps))))))

------
Rerarom
What curious newbies might miss from discussions of macros is that they are a
separate language operating at compile time. They are usually advertised as
code operating on itself or something like that. They're not. Powerful, yes,
but not that cool.

~~~
btilly
Your comment is true about most languages, but false about Lisp.

Lisp has no compile time vs run time distinction. It only has lists. What is
done with a list depends on what the first thing in the list is determined to
be:

1\. Function - evaluate the arguments then pass it to the function.

2\. Macro - manipulate the list according to the macro and then get another
list.

3\. Special Form - follow the special rules for the special form. (The list of
special forms varies from Lisp to Lisp, and are the elementary building blocks
from which the language was built.)

In Lisp, macros are advertised as code operating on itself, because that is
exactly what they are. And yes, they are exactly that cool.

~~~
ImprobableTruth
Macros are fully expanded before the rest of the code is executed. Trying to
argue that Lisp doesn't have a distinction between compile time and run time
because you usually have the compiler (or at least interpreter) available at
runtime strikes me as just playing semantics games.

~~~
RHSeeger
Do you have a citation for this? I was under the impression it was entirely
possible for lisp macros to be expanded at runtime. For example, you could
have data that is passed to a function and then used as code (because code and
data are the same thing). The system doesn't know it's going to be used as
code until it is, so the macros can't be expanded until then.

~~~
lispm
If Lisp uses an interpreter (which runs Lisp source code), you may see macro
expansions at runtime.

For compiled code, there usually will be no macro expansion at runtime. Lisp
will not macro expand code in compiled code, since all macros need to be
expandable at compile-time.

But: if you explicitly want it, you can generate code at runtime and then you
need to call EVAL or COMPILE. Then macro expansions might happen.

