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.
Published in Scientific American, September, 1966.
It starts with a wonderful quote from Alfred North Whitehead:
It is a profoundly erroneous truism, repeated by all copy-books and by eminent people when they are making speeches, that we should cultivate the habit of thinking of what we are doing. The precise opposite is the case. Civilization advances by extending the number of important operations which we can perform without thinking about them. Operations of thought are like cavalry charges in a battle-they are strictly limited in number, they require fresh horses, and must only be made at decisive moments.
In the first paragraph, Strachey already nails it:
The process of writing a program is primarily intuitive rather than formal.
Peter Norvig has written a great review of the paper.
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.
Slides from Joe Bates outlining how by introducing a little error into the computation you can get good results cheaper. I am totally into this.
Xach asked about your year in Lisp on reddit (*). Rather than get a reddit account just to answer the comment, I figured I'd answer here.
Early in the year I got a good chunk of a UNIVAC I emulator working; however, the annoying ambiguities in the representation of numbers caused that to stall. I should finish it and put it on GitHub (assuming there are no licensing problems), so that will be my first 2011 Lisp resolution. Most of the rest of my time was spent dabbling with adaptive systems writing experiments that generally didn't go anywhere. I tried "growing" a system from some basic elements but couldn't get a good handle on what it is I wanted for some time. I finally decided on making functions the basic element of computation with the following properties:(*) Yes, I used to have a reddit account but I got tired of the place a while ago and closed it.
I didn't see as many movies this year as I would have liked (Black Swan, The King's Speech, True Grit all remain unseen so far) but here are some of my favourites from the past year.
Kick-Ass: Vulgar, violent and funny. I was totally blind-sided by this one and when I got out of the theatre with my friend, neither one of us could believe this movie got made — but we were glad that it did. Chloë Moretz stole the show. (Why haven't I seen Let Me In yet? I don't know…) How to Train Your Dragon: I wasn't expecting much but was charmed by the character designs, voice acting and a decent story. It's cute but not hokey. Plus, Toothless reminded me of one of my cats. Inception: How could I not love a movie that employs recursion so ingeniously? Second best movie of the year. The Social Network: Ignore the whole "Facebook movie" nonsense and watch this film for what it is: a character study with great dialogue. The soundtrack is the best I've heard in a while; it fits perfectly in the film and it great to listen to on its own. Best movie of the year. 3D: After sampling more than a few movies in 3D I've come to the conclusion that I don't care about it and that it's not worth the premium to see it. It doesn't add anything aside from gimmicks to a film. (The sole exception has been Avatar, which struck me as something that actually used 3D from the first frame.) And 3D-TV is silly. When we have actual holograms, then I may be interested. Winter's Bone: I was underwhelmed by this one. The acting was quite good — and Jennifer Lawrence deserves recognition for her convincing portrayal — but the story just didn't grab me and I wasn't sure where it was trying to go. This was probably more a technical thing since I found a lot of the dialogue muddled.Last night my wife and I went out to dinner at a bistro in Hamilton and saw Jeff Dunham at Copps Coliseum. By the end of the night we came to realize that the place we loved to eat at has lost it's special touch and that we don't actually like Jeff Dunham's comedy.
Before last night, the bistro we went to used to be one of our favourite places to eat. Unfortunately, the last few times we've been there we were treated mostly with indifference. One of the reasons to go to places that charge about $35 a plate for a meal is the service. Yeah, you're paying for well-prepared food, but it's the service that makes it worthwhile; you go to feel like you're having a special night out. We don't feel we got that on the last three visits. It was kind of sad, then, to have to retire the place from future consideration since we used to love it. So the evening got started on a bit of a downer. (Note that the food at the place is still pretty damn good.) After that, we saw Jeff Dunham's new Identity Crisis show. It started with a guy playing a song about going to gay bars and being terrified — not in the "fish out of water" way but rather the "gay is wrong" way. We didn't find it very funny. Then Jeff Dunham started. Even before the show, I knew Dunham's comedy wasn't exactly high-brow, but he's a good performer. The show solidified the latter and demonstrated that the brow is actually a lot lower than the former lets on. I'll state this flat out: Dunham's comedy didn't make me laugh. It mostly plays on tired stereotypes that have long worn out their welcome. If there is humour to be found in the riffing on marriage with the Walter character, it only shows how much we value the symbolism of marriage over that of an actual relationship. When the Peanut character came out and started doing a Chinese accent, I felt I was watching Mr. Yunioshi in Breakfast at Tiffany's. It was pretty much cringe-inducing. What didn't accompany the portrayals of racist stereotypes in the show was any acknowledgement, subtle or overt, that they are, in fact, stereotypes. Overall, the comedy was more about playing on what people like to think is true rather than what is true. To both of us, that's not good comedy. It was a disappointing night, but at least my wife and I had a good conversation about it.
