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 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 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.
