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.


Reply via email to