3 ms·

> 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 ceilin

> 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.

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.