7 ms·

To clarify, I mean that the percentage of macros which are usefully anaphoric is small, not that any given anaphoric macro isn't useful in practice. A macro li

To clarify, I mean that the percentage of macros which are usefully anaphoric is small, not that any given anaphoric macro isn't useful in practice. A macro like `aif` is useful quite often in practice, but there aren't very many macros like `aif`. You're right that it's a personal preference. My own preference is to always be explicit (which also explains my relative distaste for Perl...). With my students, I'm constantly emphasizing that "programs must be written for people to read, and only incidentally for machines to execute"[1]. I feel as though explicity goes hand-in-hand with legibility, while I'll admit it's really just a matter of learning what `aif` does, the same way you have to learn what anything else does, I'd argue that a programmer who has never seen `let-if` before would be able to decipher its meaning from the context, whereas a programmer who's never encountered `aif` will be wondering `wtf`. [1]: Preface to the first edition of SICP.

dang 10y ago
Oh yes, it's true that there are aren't many different anaphoric macros, though I occasionally run across a useful new one. But the core ones (in Arc: aif, awhen, aand) are useful in many places. I don't see that famous SICP as applying to this the way you do. Anaphoric macros obviously don't exist to make programs easier to execute—they're there entirely for humans to read, though obviously the humans don't agree about them. To my mind, wanting a program to be readable by someone who hasn't learned its idioms is like wanting a newspaper to be readable by someone who hasn't learned its words. Some words are easy to guess from context, and that's nice. But others require learning, especially when a text isn't in your native language, and that doesn't make them unreadable.
- groovy2shoes 10y ago
  Well, newspapers are written at a middle-school reading level, or so I'm told. I disagree that anaphora are for readers. I think they're primarily for writers, as a convenience to save them some typing. The extra time spent reading `let-if` vs. `aif` is negligible, a small fraction of a second at worst. But, perhaps the disagreement comes from a fundamental difference in what each of us considers "readable". In my mind, readability is measured by the percentage of readers who comprehend what was written without aid. The amount of obviousness that such a goal demands not only requires explicity, but in my opinion it increases the ease of comprehension even for experts (so long as it's not something surprising to them -- e.g., I wouldn't go out of my way to write `let-if` in Arc since (iirc) it already provides `aif`, and that's what's expected by Arc programmers). On the other hand, I get the feeling that you rather view readability as the maximum of the ease of which each reader could comprehend what was written (not to put words in your mouth, please correct me if I'm wrong). I think that's an equally valid conception of the term, just not one that I share (or even really thought about before, to be honest).
  - dang 10y ago
    Anaphoric macros certainly don't exist to save typing; they would be worse than useless if that were true, and the cost of typing is negligible in any good Lisp program in any case. I think you might be missing the information they add. An 'awhen' is easier to read than a 'let-if' because it encodes more information. It communicates something like: "The following form is organized around a single expression of interest. We're going to evaluate that expression and, if it's non-nil, do something with it (where 'it' is literally the name assigned to the value). We needn't name it explicitly, because the expression and what we're going to do with it are both simple and straightforward". That's a lot of extra information, and it makes 'awhen' semantically much narrower than 'let' (or 'let-if'), which are more general and thus more expensive to read. To read a 'let-if', you must process not only the expression being evaluated but also the name being assigned to it, and there's no implicit guarantee of a single, simple organizing principle to the form. If you get used to them, you'll notice yourself feeling a bit easier when encountering an 'awhen', 'aif' or 'aand' because you instinctively know you won't need to spend as much mental energy to grok it. As sctb put it in a conversation, "When I see an 'aif' or 'aand' form, I have less anticipatory tension than if I see a more general construct like 'let'." It's a bit like the difference between a simple 'repeat n times' macro and, say, a 'do' loop in Common Lisp, which is much more general and thus takes more energy to read. Consuming less of the reader's mental energy is key for readability—it frees up cognition for understanding the rest of the system. This all has to do with making code easier to read, not write. Yes it requires a one-time effort to learn what 'awhen' means, and yes the code will be more obscure to anyone who hasn't taken a minute to learn that yet, but those are tiny costs compared to the lightness that's paid back again and again when the construct is used well. I wouldn't put anaphoric macros in front of a beginning programming student, because learning basic programming is already so hard that any added cost is nontrivial. They're struggling to get up the hill as is, so one shouldn't put any extra tools into their backpack. Moreover, beginning students work only with simple programs where the value of a tool like anaphoric macros doesn't add up to much. But building complex production systems is another matter. There complexity is the arch-enemy, and any tool that lightens cognitive load is an asset.
    - kazinator 10y ago

dang 10y ago

Oh yes, it's true that there are aren't many different anaphoric macros, though I occasionally run across a useful new one. But the core ones (in Arc: aif, awhen, aand) are useful in many places. I don't see that famous SICP as applying to this the way you do. Anaphoric macros obviously don't exist to make programs easier to execute—they're there entirely for humans to read, though obviously the humans don't agree about them. To my mind, wanting a program to be readable by someone who hasn't learned its idioms is like wanting a newspaper to be readable by someone who hasn't learned its words. Some words are easy to guess from context, and that's nice. But others require learning, especially when a text isn't in your native language, and that doesn't make them unreadable.

groovy2shoes 10y ago
Well, newspapers are written at a middle-school reading level, or so I'm told. I disagree that anaphora are for readers. I think they're primarily for writers, as a convenience to save them some typing. The extra time spent reading `let-if` vs. `aif` is negligible, a small fraction of a second at worst. But, perhaps the disagreement comes from a fundamental difference in what each of us considers "readable". In my mind, readability is measured by the percentage of readers who comprehend what was written without aid. The amount of obviousness that such a goal demands not only requires explicity, but in my opinion it increases the ease of comprehension even for experts (so long as it's not something surprising to them -- e.g., I wouldn't go out of my way to write `let-if` in Arc since (iirc) it already provides `aif`, and that's what's expected by Arc programmers). On the other hand, I get the feeling that you rather view readability as the maximum of the ease of which each reader could comprehend what was written (not to put words in your mouth, please correct me if I'm wrong). I think that's an equally valid conception of the term, just not one that I share (or even really thought about before, to be honest).
- dang 10y ago
  Anaphoric macros certainly don't exist to save typing; they would be worse than useless if that were true, and the cost of typing is negligible in any good Lisp program in any case. I think you might be missing the information they add. An 'awhen' is easier to read than a 'let-if' because it encodes more information. It communicates something like: "The following form is organized around a single expression of interest. We're going to evaluate that expression and, if it's non-nil, do something with it (where 'it' is literally the name assigned to the value). We needn't name it explicitly, because the expression and what we're going to do with it are both simple and straightforward". That's a lot of extra information, and it makes 'awhen' semantically much narrower than 'let' (or 'let-if'), which are more general and thus more expensive to read. To read a 'let-if', you must process not only the expression being evaluated but also the name being assigned to it, and there's no implicit guarantee of a single, simple organizing principle to the form. If you get used to them, you'll notice yourself feeling a bit easier when encountering an 'awhen', 'aif' or 'aand' because you instinctively know you won't need to spend as much mental energy to grok it. As sctb put it in a conversation, "When I see an 'aif' or 'aand' form, I have less anticipatory tension than if I see a more general construct like 'let'." It's a bit like the difference between a simple 'repeat n times' macro and, say, a 'do' loop in Common Lisp, which is much more general and thus takes more energy to read. Consuming less of the reader's mental energy is key for readability—it frees up cognition for understanding the rest of the system. This all has to do with making code easier to read, not write. Yes it requires a one-time effort to learn what 'awhen' means, and yes the code will be more obscure to anyone who hasn't taken a minute to learn that yet, but those are tiny costs compared to the lightness that's paid back again and again when the construct is used well. I wouldn't put anaphoric macros in front of a beginning programming student, because learning basic programming is already so hard that any added cost is nontrivial. They're struggling to get up the hill as is, so one shouldn't put any extra tools into their backpack. Moreover, beginning students work only with simple programs where the value of a tool like anaphoric macros doesn't add up to much. But building complex production systems is another matter. There complexity is the arch-enemy, and any tool that lightens cognitive load is an asset.
  - kazinator 10y ago