hypertext

Exploring the Power of Deixis

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.

Deixis

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?

Continue reading →

In Which Warnings Evolve Wings

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.
Continue reading →

Introducing Marks

In my previous two posts (here and here), I described how and why programming languages can’t talk about many issues that affect programmers–important issues like product requirements, design constraints, intellectual property, and more. I also inventoried the mechanisms that extend the semantics of languages today, and explored why those mechanisms have limited value. If you haven’t read those posts, please do; what I say next won’t make a lot of sense without that foundation.

In the intent programming language that I’m creating, the solution to this problem is called “marks” (a name which alludes to linguistic markedness). Marks play a role somewhat analogous to adjectives and adverbs in human language; they are crucial enrichers. They resemble decorators or annotations in other languages, though their power is much, much greater.

Without further ado, let me provide a blueprint for this bridge across the semantic gap that I’ve been lamenting–the design guidelines for “marks.” Then I’m going to show you an example of how easy it could be to use marks, and how much power they give you.

image credit: Curious Expeditions (Flickr)

Blueprint

  1. Code and its compiler(s) must have a compile-time API specified by the language.
    It’s not okay if Clang generates one type of AST, GCC a second, and MSVC a third; all compilers that support the language must expose a spec-compatible, programmable API for all language constructs. For example, I need to be able to find out what parameters and local variables are declared in a function, and what their data types and other characteristics are. This is similar to what reflection offers, but reflection doesn’t help at all, because I need this before run-time. (Kudos to D, which provides compile-time reflection very similar to what I’m describing…) As I mentioned in my post about making a codebase const-correct, the lack of this feature is really a serious design flaw. Why should code, of all things programmers deal with, be impossible to code against?

Continue reading →