A couple years ago, I wrote about signing the Agile Manifesto and the Manifesto for Software Craftsmanship.
Today I want to write about something a lot more important.
Let me use résumés to provide some context.
I used to think that the “Objective” section of a résumé was fluff–a place to dump vague platitudes, maybe. You know the stuff I’m talking about:
Objective: Craft high-quality, enterprise software in an environment where I can make significant contributions to the bottom line of a growing company.
Blah, blah, blah.
Theoretically, this stuff helps you get jobs, but as someone who writes a lot, my drivel-o-meter pegs at such verbiage. Usually, it means about as much as the Business Buzzwords Generator recently posted by the Wall Street Journal.
image credit: David Blackwell (Flickr)
But it doesn’t have to be that way.
Your objectives ought to matter.
Have you ever wanted to write a “for each” loop over all the args of a variadic macro? Or have you ever wanted to overload a macro on the number of arguments? (If you’re saying to yourself, “good grief, why?” — I’ll describe a use case at the bottom of this post.)
I learned how to do this today, and I wanted to blog about it to cement the technique in my own mind.
What happened when I decided to learn this technique. I’m trying to spare you… :-) Image credit: xkcd.com
Simple variadic macros
The first piece of magic you need to do something like this is
__VA_ARGS__. This allows you to write macros that take an arbitrary number of arguments, using
... to represent the macro’s parameters:
__VA_ARGS__ is a standard feature of C99, and I’ve known about it for a long time. I’ve also known about GCC (and Clang’s) extension, which attaches special meaning to
##__VA_ARGS__ if it’s preceded by a comma–it removes the comma if
##__VA_ARGS__ expands to nothing. If I change my macro definition to:
…I can now call
eprintf("hello, world"); without a complaint from the compiler.
But it’s not enough
That doesn’t let me do a “for each” loop, though. All the args that I pass are expanded, but I can’t do anything with them, individually. I have no names for my macro’s parameters–just the anonymous ….
I went poking around, not expecting to find a solution, but I was pleasantly surprised.
When I was a technical director at Symantec, I had to formally certify at the end of each quarter that I had not entered into any “side agreements” with customers.
A side agreement is any arrangement that takes place out-of-band, off-the-books, or using private channels not normally examined by accountants. In business, they are usually a bad thing; they can be used to build Enron- or Madoff-style house-of-cards revenue pipelines that are gleaming and glittery at first glance, but that are ripe for collapse because they’re full of hidden caveats and preconditions.
The former Enron towner, now owned by Chevron. Image credit: DaveWilsonPhotography (Flickr)
The problem of side agreements might not impinge on the consciousness of software engineers much, except when they grumble that sales or execs or product management is “selling the roadmap” instead of shipping features. But would you believe me if I said that engineers perpetrate their own Enron-esque side agreements all the time?
I’ve been focusing on esoteric features of language design for a while. I thought it might be nice to take a detour and explore something eminently practical and easy to explain, for a change.
Let’s talk data and tables.
I don’t mean databases–relational or otherwise; I’m talking about tables of data in source code itself. Sooner or later, every coder uses them. We build jump tables, tables of unicode character attributes, tables of time zone properties, tables of html entities, tables of multipliers to use in hash functions, tables that map zip codes to states, tables of dispatch targets, tables that tell us the internet domain-name suffix for a particular country name…
Depending on the language you’re using and the nature of your data, you might code such tables using arrays, structs, enums, dictionaries, hash maps, and so forth.
I think this is a mediocre solution, at best. Shouldn’t programmers work on funner stuff, like “traveling salesman” problems? :-)
image credit: xkcd.com
In my previous post, I explored why deixis is helpful, how it shows up in our language, and how its use in source code is hampered by limitations in our current programming ecosystems.
I promised I’d explain how we could remedy this problem to increase the expressiveness of our code… That’s what this post is all about.
It starts with names
The magic that makes the web “hyper” is not really in tags. Sure, we use
<a href="x">...</a> to point at something–but there are other ways to point. As I said in my previous post, line numbers point. Method names in source code point at their decl or their impl. Statements like
using namespace std point. Names of build-time dependencies in maven pom.xml files point.
The real magic is that the web has so many things to point to. It has names (notice where “name” appears in the previous paragraph). Every resource–even ones that are dynamically generated–has a URL. Individual paragraphs or tables or images inside a resource can have names, which lets us point to them, too.
We value names.
image credit: xkcd.com
So, if names are so valuable, part of how we make code more “hyper” is to increase the availability of names. Here are some ways to do that.