4 ms·

I agree with the overall message of the article (Lisp is a good substrate to explore syntactic ideas) but find the article just sort of wandering aimlessly to c

I agree with the overall message of the article (Lisp is a good substrate to explore syntactic ideas) but find the article just sort of wandering aimlessly to construct some macros of dubious value. Don't Repeat Yourself is a common tenet of programming. Lisp gives you the opportunity to virtually never repeat yourself because making syntactic abstractions is cheap and easy. It must be recognized however that abstractions range from totally useless to paradigm-shifting, and DRY isn't about saving typing but rather encapsulating ideas into reusable constructs. A common problem I see in production Lisp code bases is the existence of a programmer's set of pet syntactic abstractions that don't really have a high ceiling; you see all kinds of zaps, frobs, and lets for a reason no other than they save some typing. I do not appreciate such abstractions. The Lisp syntactic abstractions I do appreciate are ones that bring me into a new paradigm of thinking. For instance, Lisp includes a set of macros to express complex iteration readably. Without this, iteration wouldn't be much more than writing (un)conditional jumps, and by having the abstractions, you shift your thinking from the notion of jumps to the notion of traversal. Another recent example is a set of macros to simplify index wrangling in tensor algebra. These "macros" already existed in contemporary math in the form of constructs such as Einstein notation and they make reasoning and thinking about tensors easier. This article, in my opinion, treks to the destination of a macro that, while perhaps neat, isn't going to give you higher quality programs.

defgeneric 10y ago
> A common problem I see in production Lisp code bases is the existence of a programmer's set of pet syntactic abstractions that don't really have a high ceiling; you see all kinds of zaps, frobs, and lets for a reason no other than they save some typing. I do not appreciate such abstractions. I found this style irritating at first, but after programming in CL for a while you begin to appreciate the reason for it. The CL specification is basically frozen, which means no new language features. That has led to a collection of "canonical" libraries like alexandria, which brings in a lot of the batteries-included stuff you'd expect. However, if I need a version of `map` or `zap` or something, I'd sometimes rather just write the macro myself and save the external dependency. So a lot of these little single-purpose macros you find all the time are a symptom of the way CL is frozen. Notice how Clojure doesn't have this problem in the way CL does. Another reason for the prevalence of pet syntactic abstractions is that this is actually to a certain degree the way you're supposed to program in CL. The idea is that you start with a runtime "lisp image" which is typically the `CL-USER` package, and your program makes modifications to the lisp image.
- platz 10y ago
  Contrast this with the dictum in Haskell land that typeclasses (abstractions) should have laws to justify their existence. just any random abstraction will not do. although in the small, higher-order functions seem to fill in most gaps. 'syntactic abstractions I do appreciate are ones that bring me into a new paradigm of thinking' indeed.
- deleted 10y ago
  [deleted]
- qwertyuiop924 10y ago
  The same WAS true for scheme: Scheme's spec is fairly minimal, and for many years there was no standard way to handle external dependancies, so such deps were frowned upon in the tiny amount of portable code that existed. SLIB, SXML, and a handful of SRFIs were all you could really depend on. Hell, even Binary I/O wasn't standard. With R7RS, hopefully we can have a larger set of portable code, and fix this problem. But yeah, these kind of abstractions ARE just part of how lisp is designed. The rule is, if you see an idiom in your code, abstract it as a function or a macro.
thaumasiotes 10y ago
> DRY isn't about saving typing but rather encapsulating ideas into reusable constructs I thought it was about making sure that, if you changed something, you changed it everywhere at once.

defgeneric 10y ago

> A common problem I see in production Lisp code bases is the existence of a programmer's set of pet syntactic abstractions that don't really have a high ceiling; you see all kinds of zaps, frobs, and lets for a reason no other than they save some typing. I do not appreciate such abstractions. I found this style irritating at first, but after programming in CL for a while you begin to appreciate the reason for it. The CL specification is basically frozen, which means no new language features. That has led to a collection of "canonical" libraries like alexandria, which brings in a lot of the batteries-included stuff you'd expect. However, if I need a version of `map` or `zap` or something, I'd sometimes rather just write the macro myself and save the external dependency. So a lot of these little single-purpose macros you find all the time are a symptom of the way CL is frozen. Notice how Clojure doesn't have this problem in the way CL does. Another reason for the prevalence of pet syntactic abstractions is that this is actually to a certain degree the way you're supposed to program in CL. The idea is that you start with a runtime "lisp image" which is typically the `CL-USER` package, and your program makes modifications to the lisp image.

platz 10y ago
Contrast this with the dictum in Haskell land that typeclasses (abstractions) should have laws to justify their existence. just any random abstraction will not do. although in the small, higher-order functions seem to fill in most gaps. 'syntactic abstractions I do appreciate are ones that bring me into a new paradigm of thinking' indeed.
deleted 10y ago
[deleted]
qwertyuiop924 10y ago
The same WAS true for scheme: Scheme's spec is fairly minimal, and for many years there was no standard way to handle external dependancies, so such deps were frowned upon in the tiny amount of portable code that existed. SLIB, SXML, and a handful of SRFIs were all you could really depend on. Hell, even Binary I/O wasn't standard. With R7RS, hopefully we can have a larger set of portable code, and fix this problem. But yeah, these kind of abstractions ARE just part of how lisp is designed. The rule is, if you see an idiom in your code, abstract it as a function or a macro.

thaumasiotes 10y ago

> DRY isn't about saving typing but rather encapsulating ideas into reusable constructs I thought it was about making sure that, if you changed something, you changed it everywhere at once.