On Friday, 9 August 2013 21:50:13 UTC+8, Jace Bennett 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. >
One is Ironclad - a steampunk themed strategy game: http://www.mikera.net/ironclad/ or https://github.com/mikera/ironclad The other is Alchemy, a 7-day Roguelike game: https://github.com/mikera/alchemy Both are somewhat interesting from technical perspective in the sense that the game state is fully functional and immutable. > Jace > > On Fri, Aug 9, 2013 at 4:10 AM, Mikera <mike.r.an...@gmail.com<javascript:> > > 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 clo...@googlegroups.com<javascript:> >> 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 <javascript:> >> 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+u...@googlegroups.com <javascript:>. >> 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.
