I like Eric Normand's take here: https://lispcast.com/magical-leverage-languages/
On Sun, Apr 28, 2019 at 9:46 AM <r...@chartbeat.com> wrote: > I agree Erik, macros and the dsl idea are edge cases imho. Having written > clojure for 4 years now (and with 30 as a professional developer) I’ve only > written a few macros and they were for very specific use cases where I > wanted to support something specific. > > I think they are over-hyped features which most people will never use. > That said, it’s nice to have macros when you need them > > On Apr 28, 2019, at 9:41 AM, James Reeves <ja...@booleanknot.com> wrote: > > 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. > > -- > 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. > -- 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.
