There’s nothing like the ringing and then silence about the time you grab your phone. When it does occasionally keep going and you answer, there’s a recorded voice, giving you a lie such as “Your auto warranty is about to expire. This is your final notice…”

Of course, we should just hang up.

Or wait through and sometimes there’s a number we can press to be placed on their “do not call list.” Assuming that anyone believes that those who use robo-dialers would honor such a choice.

Or …

Continue reading →

I was going to write about the existing state machine I have working. It’s very powerful, has parallel features, and its output was shown in Rethinking State Machines meaning I wouldn’t have to actually create any code, just go through a post-mortem.

Then I changed my mind.

My Lisp version was designed intentionally to be an integral extension of the Lisp technology we use internally. It’s not that it’s a trade secret (how does one make a “trade secret” out of something as well known as state machines?) but rather, it’s not actually comprehensible without an understanding of Lisp and the nature of the Lisp development needs that drove its creation.

What I really want to write about is the process of creation that allows one to make the step from “code that works with data” to “data that is representing code.” That’s the jump, the spark, that enables metaprogramming, where the program code is the data to other program code.

And that process warrants starting at the beginning, which is with the problem.

The problem is my desire to allow direct expression of the basis for responding over time to external events. Think of this as the architect’s perspective instead of a developer’s perspective. No matter the language of the system implementation (or set of languages) I want the system to respond properly to any sequence of events.

I want this to be independent of the code that carries out the intention so that I can work “at a higher abstraction.”

Continue reading →