Confidential to Addressee

I went looking for some books on debugging after browsing lispmeister’s box of books unpacking. I picked up The Science of Debugging and, since the price was too good to pass up, Secrets of Software Debugging (awesome cover — with lots of code listings in Basic, Pascal and assembler!). Should be fun to read the secrets, such as they were written in 1984.

Back when I was in graduate school writing lots of Lisp code (and I do miss writing Lisp code) I frequently made use of macros to create small domain specific languages (DSLs). Now that I am working on a team writing C/C++ and shell scripts, breaking out the macro-esque code is a little more difficult.

That said, it’s not impossible. I haven’t written enough C/C++ to do much with preprocessor pseudo-macros, but I have written a lot of shell scripts. And I’ve found you can get a good taste of Lisp-style macros in some circumstances.

One situation that I like to employ them is with configuration files. More specifically, these are configuration files that will be sourced by a running shell (using the source or . command). While writing shell-based infrastructures, I’ve often found that you end up putting lots of things in configuration files. You might end up with something like this:

FOO_args=aaa BAR_args=bbb BAR_elements=ccc

This can get out of hand quickly; parameter names on the order of 25 to 40 characters is not unheard of. I find this hard to read and error prone when editing it on a live system (especially embedded ones where you have a limited set of tools).

If find the following a little easier to work with:

foo { define args=aaa }  bar { define args=bbb elements=ccc }

Sure, it’s more lines, but it immediately tells you quite a bit about what the configuration settings are meant to do. In short, it says it better.

The question is, how can this be turned into something the shell can evaluate that will result in the definitions being accessible to the rest of the code?

Consider the following:

#!/bin/bash  SCOPE=  function configure { unset SCOPE SCOPE=$(echo ${1} | tr '[[:lower:]]' '[[:upper:]]') }  function define { for def in ${@}; do eval "${SCOPE}_${def}"; done }

With a slight modification to the idealized configuration code above, the objective of defining the same parameters with a different syntax is achieved.

#!/bin/bash  . ./function-defs.sh  configure foo { define args=aaa }  configure bar { define args=bbb elements=ccc }  echo "FOO_args is ${FOO_args}" echo "BAR_args is ${BAR_args}" echo "BAR_elements is ${BAR_elements}"

Of course, this example is for demonstration purposes and things can get more complicated; consider the case of configure only working in certain circumstances and thus, making define a no-op.

All in all, this technique has made some things a lot simpler for me in some cases.

Having worked professionally as a software developer for a little over 2.5 years after 6 years of graduate school (and getting a PhD in Computer Science) studying programming languages, I have some observations about working in a non-academic environment.

• Functions as values are misunderstood

  The prevailing attitude among those that I have worked with is that functions are… different and not to be messed with. I respectfully disagree with them on a regular basis but I understand where they are coming from. If your only exposure to functions as values is Java’s anonymous classes or C’s function pointers, well, I pity you, but I can see why you would be jaded.

  One of these days I hope to convince more people that functions are data, just like everything else, and can/should be utilized as the incredibly useful construct that they are. (Just ask my co-workers — I am not shy about this point!)

• Meta-programming needs to solve the debugging problem

  While meta-programming is extremely powerful (and in my opinion, the best way to solve some difficult problems), debugging it is not simple. It won’t catch on until it’s simpler to work with. (Case in point: dependency generation in Makefiles.)

• Static is a state to work toward, not to start with

  Insisting on careful design of types too early often causes lots of headaches later. This is especially true when coming up with an API. It is through use that type design gets better.

• Error should be embraced, not shunned

  To me, this is the biggest problem with software development in general right now: the way we deal with runtime errors is a disaster. At the very least, when an error occurs, as a developer, I should be able to look around in the environment of the computation to observe what is going on instead of hope that the process logged something meaningful somewhere.

  This means having runtimes that support features beyond that of simply running instructions: you need ones that let you easily manipulate programs and computations. Furthermore, you shouldn’t have to bake in the logic for such manipulation manually.

  Common Lisp is one of the sanest systems I’ve had the pleasure to work with in this regard; the C/Unix ecosystem is one of the worst.