[richhickey]

I think Christophe's is the talk, and Yegge seriously misunderstood it, if he even bothered to watch it. Christophe's point was that basing the underpinnings of a DSL on macros was frequently a mistake, vs a data + functions approach that "leads to greater dynamicity". It is inarguable that macros are less flexible than functions (e.g. they can't be applied) and less composable. Christophe's argument wasn't against macros, but that they should be the last layer of sugar, not the core mechanism of a DSL. This approach has been advocated and practiced by Lispers forever. Ditto the advice to not use a macro when a function will do.

And for Yegge to imply that more serious Clojure devs like Christophe are macro averse because they are afraid they might not understand someone else's macro code shows his complete lack of familiarity with Christophe's macro skills and other work of the community.

Taking potshots at things you don't understand and people you don't know (while leaving out the link so others could verify) smells like a FOX-news rhetorical approach to me. Ditto political labeling (though in the programming community the negative tag is "conservative", whilst in politics it is "liberal"). Tag the thing you don't like with the negative label, then rationalize, and spew misinformation. "Clojure's community came pre-populated with highly conservative programmers from the pure-functional world: basically Haskell/ML types": surveys[0][1] say... nope.

He even ignores the bulk of his own criteria in his labeling exercise. Clojure has almost none of the things on his "Conservative Stuff" list except STM (huh, is GC conservative too?) and almost all of the things on his "Liberal Stuff" list. None of his 1-8 conservative points apply to Clojure (and I see nothing wrong with conservative about speed - Common Lisp has always pursued it, and its pursuit always involves risk), and all of his 9 liberal points apply to Clojure.

Clojure devs are liberals that want their programs to work.

If Yegge doesn't like Clojure, fine. But to rationalize like this is weak.

Yawn.

[0] http://cemerick.com/2010/06/07/results-from-the-state-of-clo...

[1] http://cemerick.com/2012/08/06/results-of-the-2012-state-of-...

[technomancy]

> If Yegge doesn't like Clojure, fine. But to rationalize like this is weak.

A bit of historical context from the last time this came up:

http://groups.google.com/group/seajure/browse_thread/thread/...

[saurik]

So, in 2008, you made a comment (below, emphasis mine) about reader macros (yes, which I realize are not identical to macros; please understand that I use a couple reader macros in my day-to-day coding process and am not naive as to their implementation or function) that, at least to me, pretty strongly supports the narrative that Steve is painting: that the goal I somehow "have fewer features that people are less likely to use wrong as otherwise it gets confusing".

> I am unconvinced that reader macros are needed in Clojure at this time. They greatly reduce the readability of code that uses them (by people who otherwise know Clojure), encourage incompatible custom mini-languages and dialects (vs namespace-partitioned macros), and complicate loading and evaluation.

https://groups.google.com/forum/m/?fromgroups#!topic/clojure...

FWIW, this is the same argument that comes up often, from many different members of the community. The namespacing argument is commonly included and sounds technical, but is also trivially solvable; as in, was already solved in a comment during the primary-cited discussion of reader macros on the #clojure IRC channel, but was then dismissed due to the real reason: that reader macros make your code less understandable to other people who know Clojure (the exact same form of argument Steve is talking about, one layer removed).