Obviously I've encountered the advice "no macros unless you know you need them" before. And I even sort of know the syntax and what they do. I don't think that's my problem.
I think I've lived a life without macros. I mean, clearly dynamic-functional and even OOP styles are perfectly capable of building most anything (within my now constrained view of what is feasible). And my head is full of techniques (what an experienced lisper might call workarounds) to deal with their limitations, so I'm habituated to the pain, and the narrow view of 'what is feasible'. So, it's not about whether I need a macro at all, because I could deal indefinitely. There are an endless supply of problems I could solve without them. It's about wisdom, discerning whether its a good tradeoff to use a macro in a given situation. I wish this was the kind of thing that could be taught. Instead, I fear, it must be learned. On Fri, Aug 9, 2013 at 9:50 AM, Jace Bennett <jace.benn...@gmail.com> wrote: > Thanks again, Mike. That's really helpful. > > I'll take a look at the core.matrix stuff to try and understand > implementation and motivation better. > > What games did you make? I'd love to check them out. > > Jace > > On Fri, Aug 9, 2013 at 4: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.
