Faré Rideau

Scheme has historically been used as a research vehicle for macros. When the fifth revised specification of Scheme (known as R5RS) was written there were no consensus on the best practices for writing a system supporting unhygienic macros.

Since then both R6RS and R7RS has support for unhygienic macros.

Note that there are two important properties of the macro systems of modern Scheme implementations: hygiene and referential transparency. The second property is often overlooked.

The standard syntax-rules macro system of R5RS Scheme is hygienic

If a macro transformer inserts a binding for an identifier (variable or keyword),
the identifier will in effect be renamed throughout
its scope to avoid conflicts with other identifiers.

and referentially transparent

If a macro transformer inserts a free reference to
an identifier, the reference refers to the binding
that was visible where the transformer was specified,
regardless of any local bindings that may surround
the use of the macro.

The first property (automatically renaming of identifiers) is
prevents common errors. This property is easy to hack around in macro systems without automatic renaming. The macro writer simply generates a new identifier (gensym) each time a new identifier is needed.

The second one referential transparency is the killer feature. Names inserted by a macro refers to binding where the macro is defined. This means that the macro writer has control over the…

Things have costs, what's your underlying point? That one shouldn't create such a macro, even if it's a one-liner, because of unquantified costs or concerns...?

Singling out individual macros for "cost" analysis this way is very weird to me. I disagree entirely. Everything has costs, not just macros, and if you're doing an analysis you need to include the costs of not having the thing (i.e. the benefits of having it). Anyway whether it's a reader macro, compiler macro, or normal function, lines of code is actually a great proxy measure to all sorts of things, even if it can be an abused measure. When compared to other more complex metrics like McCabe's cyclomatic complexity, or Halstead’s Software Science metrics (which uses redundancy of variable names to try and quantify something like clarity and debuggability), the correlations with simple lines of code are high. (See for instance https://www.oreilly.com/library/view/making-software/9780596808310/ch08.html which you can find a full pdf of in the usual places.) But the correlations aren't 1, and indeed there's an important caveat against making programs too short. Though a value you didn't mention which I think can factor into cost is one of "power", where shorter programs (and languages that enable them) are generally seen as more powerful, at least for that particular area of expression. Shorter programs is one of the benefits of higher level languages. And besides power, I do think fewer lines of code most often…

The reason I have stuck with Common Lisp, rather than bailed to Clojure or something else, is that the language is so fundamentally good -- Mature, robust, standarized, performant, compiled, gradually-typed -- that it is worth sticking with it, it is worth working to expand its ecosystem.

Regarding the ecosystem, Common Lisp has improved a lot over the recent years. We have Clack (Equiv. of Python's WSGI/Ruby's Rack), a bunch of web frameworks, an ORM, a small set of web-related tools built around those. It's certainly nowhere near the size of the ecosystems of Ruby and Python, but I think it's acceptable given the size of the community.

I do, however, think there has to be a movement like Fare's "Lisp library consolidation"[0] to, if not expand, improve the existing libraries: Build Github Project Pages, Sphinx documentation, a better-looking wiki. Just porting old READMEs to Markdown would be an improvement.

[0]: http://fare.livejournal.com/169346.html

I understand that R7RS got rid of syntax-case and standard Scheme is back to syntax-rules only (which is another thing I like about Common Lisp: the standard has been in existence for 23 years).

I'm reminded of this article (https://fare.livejournal.com/189741.html), where this Common Lisp macro:

(defmacro nest (&rest r) (reduce (lambda (o i) `(,@o ,i)) r :from-end t))

Has to turn into this in Racket (which isn't quite Scheme):

(define-syntax (nest stx)
(syntax-case stx ()
((nest outer ... inner)
(foldr (lambda (o i)
(with-syntax (((outer ...) o)
(inner i))
#'(outer ... inner)))
#'inner (syntax->list #'(outer ...))))))

And was incredibly difficult to reason about. And that author likes Racket.

I think you will be happy with either one. It's targeted mainly toward people familiar with them, but here's a recent comparison:

http://fare.livejournal.com/188429.html

Note that a lot of what Faré likes about racket is somewhat intrinsic in there being one implementation, and a big part of why racket branded itself away from scheme (it was formerly PLT-Scheme).

In lisp there are still a lot of very different implementations in use, so if you want to "grow down" you either have to be non-portable or do a lot more work.

I love Common Lisp, so I will say "learn Common Lisp" but you'll probably be just as happy if you flip a coin (and I would recommend doing so rather than debating much as learning the "wrong" one now is probably better than learning the "right" one in the future).

They are really different languages with similar syntax.

Scheme is opinionated and wants you to program in a certain way (hence TCO being part of the standard), it's also more static and doesn't want to take over the whole machine like Common Lisp and Smalltalk want.

I started with Scheme but I am no longer my idealistic self so I am partial to Common Lisp since I use it for work and don't mind coding in ugly kitchen sink languages as long as they are fit for production use. Not that Scheme lacks amazing implementations such as Chez, Gambit or Chicken (my favourite) but I would have a harder time building something non trivial in those.

As a counter argument you have https://fare.livejournal.com/188429.html from a seasoned Lisper so YMMV.