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.
The other day my daughter was in the backseat as I pulled out of the driveway, and she instructed me to “turn that mirror over here.”
“Which mirror?” I asked.
“That one,” she said, without any clarification.
Image credit: fofie57 (Flickr)
“Which one?” I said again. “I don’t know what you mean when you say ‘that’…”
Eventually I cracked the teenage code and tilted the center rearview mirror toward her so she could check her makeup. :-) But it was harder than it should have been.
A lot of frustration could have been avoided if I could have turned around to face her to see which direction her eyes were pointing–or if she’d just stretched out her finger.
In linguistics, deixis is a sort of pointing—the juxtaposition of something against a reference context to provide meaning. Although we can define words like “here” and “there” in the abstract, their specific meaning always depends on the physical or metaphorical location of the speaker when they’re used. Likewise, “now” and “then” are deictic with respect to the time of an utterance; pronouns like “we” and “you” use deixis that relies on interpersonal context; honorifics are deictic with respect to cultural relationships.
Since the web now permeates our collective experience, think of deixis as a kind of hyperlink. Imagine if I had written my daughter’s sentence like this: “Turn that mirror over here.” It sorta fits, doesn’t it?
Today I’m channeling my inner grumpy old man. And these guys are helping. (I am not old enough to pull off such a face by myself, although life is rapidly helping me get there. ;-)
The reason I’m feeling grumpy is that I’ve had another in a long, long line of conversations about how to write faster code.
It’s not that optimization experts are dumb. Far from it. They are invariably smart, and in general, they are better informed than I am about how pipeline burst cache and GPUs and RAM prefetch algorithms work. I generally learn a lot when I talk to guys like this.
I applaud their passion, even if I think they sometimes get carried away.
No. What’s making me grumpy is that after decades of hard work, we still have compilers that encourage a culture of black magic and superstition around this topic. I thought I signed up for computer science, not voodoo.
To show you what I mean, let’s talk about the humble
inline keyword in C and C++. The amount of FUD and nonsense around it is really unfortunate. How many of the following have you heard?
Ignoring warnings is a bad idea. At some level, we all know this. If we see a sign that says “Warning: Dangerous Undertow” at the beach, we pause (I hope!) and think twice before we get in the water.
Ignore warnings at your peril. :-) Image credit: xkcd.com
Yet we sometimes get cavalier about warnings in software. Specifially, I have heard programmers describe compiler warnings as being less severe than errors–as if worrying about them is optional.
This is simply not true.
In my previous three posts, I explained why the semantics of programming languages are not as rich as they could be. I pointed out some symptoms of that deficit, and then made recommendations about bridging the gap. Finally I introduced “marks”–a feature of the
intent programming language I’m creating–and gave you a taste for how they work.
In this post, I’m going to offer more examples, so you see the breadth of their application.
Before I do, however, I can’t resist commenting a bit on the rationale for the name “marks”.
In linguistics, markedness is the idea that some values in a language’s conceptual or structural systems should be assumed, while others must be denoted explicitly through morphology, prosodics, structural adjustments, and so forth. Choices about markedness are inseparable from worldview and from imputed meaning. Two quick examples: