Macros allow for experimentation in language design, not only by third parties, but also by the developers of the language themselves. If you have an idea for some new piece of syntax, it can be tried out in a library first.
Macros are also useful for precompiling code for performance. If you have a literal data structure you need to transform, or even one that's partially literal, you can use macros to transform those parts at compile time. That's not to say macros are written often; but they have an important niche. Regarding DSLs, I don't think applications are often written using an encompassing internal DSL. I think most of the time when people talk about a DSL, it's actually just an overly complex API. In my view, a good DSL is both more consise within a domain, and less powerful than a general purpose language. A regular expression, for example, can concisely search through text, but has no side effects and is guaranteed to halt at some point. Certain regex libraries even go further, and guarantee they will halt within a time proportional to the input text. Ideally we should be aiming for the *least* powerful tool for the job, which often means using data to describe a solution rather than arbitrary code. Not only is this more reliable, it's also more transparent and allows for greater introspection. For example, my own Integrant <https://github.com/weavejester/integrant> library replaces the dependency management of an application with a data structure. This is less powerful, because the dependencies need to be explicitly mapped out beforehand, but it's also more reliable and allows for introspection. Going further, Cognitect's Vase <https://github.com/cognitect-labs/vase> allows for micro-services to be expressed almost entirely through a data structure. Maybe these examples allow people to write applications faster, but I think it's more important that they allow applications to be written more reliably. Over time, applications that are reliable and predictable are going to be easier for people to continue developing. On Sun, 28 Apr 2019 at 05:46, Erik Assum <e...@assum.net> wrote: > First of all, this might very well be a ramble without much sense, but > please bear with me. > Secondly, I’m writing this first and foremost not as an application > programmer. > > Having programmed in the crud-application business some twenty years > professionally, the last couple of them in Clojure, there are (at least) > two things (that might be related) that puzzle me: > > 1) The power of macros > I see, and acknowledge that eg the go-macro core.async is a wonderful > piece of work, and that it’s really cool that it could be done in a > library. But as an application programmer, I really don’t care if it’s a > macro or a language feature, and I couldn’t really see myself investing > that amount of time (nor would I have the skills to do so if I had the > time) to solve my concurrency problems in such a general manner. > > 2) The creating of a DSL for your problem domain, and then write a custom > compiler to solve your problem > In my (most optimistic view) every program that I write is somewhat an > internal DSL, built up of domain-specific functions, glued together with > Clojure. But I don’t feel that this is very specific to how I program in > Clojure vs other languages. > > So what I’d really like to achieve with this post is two things > > 1) Arguments ranging from “Oh, you should look at it from this angle” to > “That’s how I feel too” to “You’re totally wrong, because…” > > 2) Pointers to blogs/articles/codebases which shows how applications > written either with extensive use of macros or by implementing an internal > DSL (and compiler) are significantly quicker to develop than their > brute-force alternatives. > > You might consider this as a first effort to create a presentation around > the subject :) > > Erik. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- James Reeves booleanknot.com -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
