What I meant by that is the metaprogramming capabilities that often get cited for allowing devs to create their own domain specific "mini languages". To me that's a "creative" way to write code because the end result could be wildly different depending on who's doing the writing. And creativity invites over-engineering, over-abstraction, and hidden costs. That's what I meant by the "opposite of boring".

You linked me to this comment from another one and I have to agree with this sentiment.

Creating these mini DSLs is something that requires a lot of thought and good design. There is a danger here as you pointed out sharply.

But I have some caveats and counter examples:

I would say the danger is greater when using macros and far less dangerous when using data DSLs. The Clojure community has been moving towards the latter since a while.

There are some _very good_ examples of (data-) DSLs provided by libraries, such as hiccup (and derived libraries), reitit, malli, honeysql, core match, spec and the datalog flavor of Clojure come to mind immediately (there are more that I forget).

In many cases they can even improve performance, because they can optimize what you put into them behind the scenes.

I read comments like these in bewilderment.

Have you worked for a company that hasn’t created its own, as you put it “mini language”?

Have you worked for a company that doesn’t indulge in over engineering, over abstraction and hidden cost?

Do you actually do programming for a job at all?

In practice, though, most developers don’t do that.

There’s a rule of thumb: write a macro as a last resort.

It’s not hard to stick to it. In general, you can go a long, long way with HOFs, transducers, and standard macros before a hand-rolled macro would serve you better.