The first rule of macro club is "Don't write macros." Macros are powerful, but they should be considered the last avenue of attack. Often macros are a slim wrapper around an API made out of functions, and there just to provide some syntax sugar.
Libraries that use macros more extensively, like core.logic, or the "go" form in core.async, are relatively rare, and cover the cases where nothing else but macros are powerful enough to implement the desired functionality. Instead, it's far better to start with a data-driven approach. A data structure is always preferable over an API, and an API is always preferable over a DSL. This approach can be seen in Datomic, which uses data structures to represent queries and commands, or Ring, where data structures are used to represent HTTP requests and responses. Clojure heavily emphasises data, far more than most other languages, and certainly more than OOP. - James On 15 November 2013 19:51, Brian Craft <craft.br...@gmail.com> wrote: > Pulling this from another thread: > > On Nov 14, 2013, at 2:28 AM, Sean Johnson <bel...@acm.org> wrote: > > The magic of meta-programming (Ruby) vs. magic of macros (Clojure) vs. no > magic (Python). This probably comes down to personal preference, and so is > a potential benefit of any of them, depending on your preference, but it's > a significant difference, so it's worth pointing out. By "magic" I just > mean when the system seems to be more doing something much more powerful > than you can readily see just by looking at the code. A simple few lines of > code are doing all these wondrous things that aren't spelled out completely > in the code (unless you peek under the covers and can understand the black > arts that lie there). In Ruby/Rails this is the result of a lot of > metaprogramming happening, based on conventions (that must be learned). In > Clojure this happens through macros that implement powerful DSLs. In > Python, it doesn't happen nearly as much. Code tends to be more transparent. > > > > This description of ruby, clojure, and python very much matches my > experience (though with ruby I'm relying on the accounts of other > developers that I know, since I haven't personally used ruby). > > Why are black arts and opaque code desirable? It's almost a tautology that > these things are unmaintainable: you can't maintain code if you can't > readily understand it, e.g. if it depends on "black arts", or is not > transparent. > > -- > -- > 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/groups/opt_out. > -- -- 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/groups/opt_out.
