I can build strawmen too:

- SmugCeeWeenie: I am so fast, look (oops, core dumped)

- SmugGoWeenie: abstractions are so nasty we should get rid of functions, so that everyhting is laid out clearly. Hopefully, I have copy/paste.

- SmugAdaWeenie: Functions are not procedures and records cannot store objects. Real engineers do not "prototype" code.

- SmugHaskellWeenie: Yeah, it compiles! Job done.

> In the space year 2015 people are still doing this.

About first class functions? citation needed.

- SmugHaskellWeenie: cabal sandbox init, cabal install this, cabal install that, write code, add ghc pragma, wtf! add ghc pragma, wtf! add ghc pragma ... Yeah, it compiles! Job done. Almost, time to get rid of the warnings. add ghc pragma, and another, and one from the top Carol and ... yeah, it compiles with no warnings.

A functional approach:

      (defun mirror (tree)
        (when tree
          (tree 
              (tree-data tree)
              (mirror (tree-right tree))
              (mirror (tree-left tree)))))

For completness, here are the definitions:

      (defpackage :trees (:use :cl)
                  (:shadow #:copy-tree))
      (in-package :trees)
      (defstruct (tree (:constructor tree (data &optional left right))
                       (:type list))
        data left right)

As well as a test case:

      (mirror (tree 4 
                    (tree 2
                          (tree 1)
                          (tree 3))
                    (tree 7
                          (tree 6)
                          (tree 9))))

      => (4 (7 (9 NIL NIL) (6 NIL NIL)) (2 (3 NIL NIL) (1 NIL NIL)))

Macros are not needed. You only need the UNWIND-PROTECT special operator, which is the generic feature you are looking for.

Macros do not necessarly transform code at compile-time. A late-binding interpretation is possible. See for example http://programmers.stackexchange.com/a/274200/33157.

Even in an interpreter, they're expanded at "Load Time" as opposed to runtime.

I am not sure, but it seems that this may be implementation-dependent.

See also the Ada Gems serie of articles: http://www.adacore.com/adaanswers/gems/

Nice article.

By the way, you may want to watch this course by Hal Abelson and Gerald Jay Sussman (Henderson Escher example):

http://ocw.mit.edu/courses/electrical-engineering-and-comput...

Also, the article reminded me of LOGO.

When you try to apply all functions, the space becomes limited and you cannot see the resulting piece, especially when it gets tall.

> After doing a function rather than instantly showing the next cube put a .5 second opacity transition

Please, no animation. Instantaneous feedback is perfect as it is. My 2cts.

Yeah .5 seconds is way to long, the reason for the animation is that in this game you are looking at the list of functions and only after you are done does your eyes have time to register changes elsewhere. If it has already changed your brain has to try to figure out what has changed when the system can provide hints.

Because you would rapidly move them around changing it to be 0.05 or something just slow enough so that your brain would notice movement above, but not slow enough to impede in trying new things.

I am surely missing something, why would you want to delay in the function?

The GSM shield messes up if you poll too often, IIRC.

You should reevaluate your architecture.

Instead of delaying in code, think about having the main loop enter the execution routines of a few FSMs (modem FSM, i/o FSM, etc). In this model, a FSM state function can just return early if it's waiting for an even, giving execution time to other FSMs.

Of course, a better approach would be to run a RTOS on your uC, like the venerable FreeRTOS. Then you can just run tasks that can sleep, communicate via queues, and you can even get preemption if you wish. But I'm not sure it's available for the Arduino.

Additionally, since you're using a SIM90x, why are you polling the modem? Out-of-band events (incoming call, new text message) usually arrive in the form of Unsolicited Messages, like +CMTI for a new SMS or RING for an incoming call. You can interrupt on each character received via UART, and do your processing there.

That's how it works now (the FSM), which is why an interrupt isn't really necessary (the rotary dial state doesn't do anything other than poll for the dialing). Also, it's a bit overkill to load a RTOS for the 50 lines of code this thing has.

The polling of the shield is done because that's the way the shield library works, and I didn't want to rewrite the entire thing when it works fine as it is now, really...

Debouncing the switch? Check if the input is triggered, and then check it again a short time later to see if it is still triggered.

Yes, the use of macros is not always justified in the examples, because Python is quite expressive already.

However, the ability to have macros is orthogonal with the feature set of the language. What is interesting is the ability to inspect and modify a Python AST.

Of course, meta-programming is a way to integrate otherwise absent features of a language as-if they were built-in. Python is sufficiently dynamic that most things can be done using existing facilities, like reflection and metaobjects (the @case example, as you mention).

But there is a difference between using those facilites at runtime and producing some code at macro-expansion time (this might be relevant for Cython, for example).

You can, for example, define a domain-specific language that is directly translated as Python, and not interpreted like an API-based representation would. You can even apply custom type checking for that DSL.

Or, you could analyze an existing python source code and produce a translation in another language without having to reimplement a parser (see the Python-to-Javascript example, or Common-Lisp's Parenscript).