I agree! :) On Fri, Aug 9, 2013 at 10:10 AM, Mikera <mike.r.anderson...@gmail.com>wrote:
> On Friday, 9 August 2013 05:07:10 UTC+8, Jonathan Fischer Friberg wrote: > >> I'd suggest avoiding macros until you absolutely know that you need them. >> Usually they aren't necessary. >> >> >> Problem with this is that you don't really know when you need them unless >> you know what they do. >> > > I'm not saying "don't learn how macros work". Learning is always good. > > My recommendation is just that your default approach should be to avoid > using them unless you have tried very hard to achieve your goal with pure > functions first, and convinced yourself that it isn't possible. > > Macros are only *needed* IMHO when one of the following applies: > - You want to create new language/DSL syntax that isn't expressible with > normal function application rules (e.g. short-circuiting evaluation, new > control structures etc.) > - You need to do custom code generation at compile time for some good > reason (e.g. performance, since macros enable you to do compile-time > specialisation of code) > > I wrote about these and gave some examples in a blog post a few months > back for anyone interested: > > http://clojurefun.wordpress.com/2013/01/09/when-do-you-need-macros-in-clojure/ > > > > >> >> On Thu, Aug 8, 2013 at 9:58 PM, Jace Bennett <jace.b...@gmail.com> wrote: >> >>> Thanks, Mike. >>> >>> I guess my simple example is too simple. Out of the hypothetical, have >>> you used techniques like this? >>> >>> I have this nagging feeling that there is a more direct and idiomatic >>> way to glean this sort of information from my code. I mean, that's why we >>> use AST's, right? So we can process them? I shouldn't need a data structure >>> like the endpoint map in the first place. I just don't know how to >>> capitalize on this rather abstract and vague notion. >>> >>> How do folks usually go about it when they have a desire to query the >>> running system about its shape and structure? >>> >>> >>> >>> On Thu, Aug 8, 2013 at 2:36 AM, Mikera <mike.r.an...@gmail.com> wrote: >>> >>>> I'd suggest avoiding macros until you absolutely know that you need >>>> them. Usually they aren't necessary. >>>> >>>> Prefer writing pure functions (without side effects) - these are easier >>>> to reason about, easier to test, simpler to write correctly and easier to >>>> plug together / compose via higher order functions. >>>> >>>> For example, in your endpoint example I would probably just use three >>>> functions: >>>> - a pure "add endpoint metadata to an endpoint map" function >>>> - an impure "update endpoints" function that updates endpoints using an >>>> endpoint map >>>> - a function that calls both of the above to declare and launch a new >>>> endpoint >>>> >>>> There might be a few other helper functions as well but hopefully you >>>> get the idea. >>>> >>>> >>>> On Thursday, 8 August 2013 03:19:15 UTC+1, Jace Bennett wrote: >>>>> >>>>> Thanks to the community for a wondrous programming environment. I >>>>> discovered SICP last year, and fell in love with the idea of lisp. But >>>>> I've >>>>> come to a point where I think I need practice on moderately sized projects >>>>> before more reading will help. >>>>> >>>>> When starting on almost any moderately scoped effort, I quickly run >>>>> into a class of problems which I think may be a fit for macros, but I want >>>>> to understand what is the idiomatic way to approach them in clojure. >>>>> >>>>> Most of my professional experience is in .NET, and that is probably >>>>> coloring my thought patterns a bit. In that context, I often use >>>>> reflection >>>>> scans and type metadata to configure infrastructural bits and dry things >>>>> up. Instead of having to explicitly register components in the more >>>>> dynamic >>>>> areas of my app, I use conventions to select components to register from >>>>> the metadata I have about my code. >>>>> >>>>> I can imagine using macros in clojure to accumulate metadata about my >>>>> declarations so that I can query them at runtime. For example, maybe a >>>>> "defendpoint" macro that sets up a handler AND adds it to the routing >>>>> table >>>>> (or more directly an "endpoint map" which I then use to make routing >>>>> decisions among other things). >>>>> >>>>> Admittedly, something about the sound of the phrase "it's just data" >>>>> tells me I'm sniffin up the wrong tree here. But I don't know how to turn >>>>> that nagging feeling into working code. >>>>> >>>>> Is this a reasonable use of the macro? What about doing the >>>>> registration at macro-expansion time vs emitting runtime code to do it? >>>>> How >>>>> should one approach the problems space otherwise? >>>>> >>>>> Thanks for your time. >>>>> >>>> -- >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Clojure" group. >>>> To post to this group, send email to clo...@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+u...@**googlegroups.com >>>> >>>> For more options, visit this group at >>>> http://groups.google.com/**group/clojure?hl=en<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+u...@**googlegroups.com. >>>> >>>> For more options, visit >>>> https://groups.google.com/**groups/opt_out<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 clo...@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+u...@**googlegroups.com >>> >>> For more options, visit this group at >>> http://groups.google.com/**group/clojure?hl=en<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+u...@**googlegroups.com. >>> >>> For more options, visit >>> https://groups.google.com/**groups/opt_out<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. > > > -- -- 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.
