Fabulous Adventures In Coding : Big Words

Five-Dollar Words For Programmers, Part Five: Reification

Eric Lippert — Fri, 17 Apr 2009 17:36:00 GMT

Today, another in my series on awesomely arcane words for programmers. Reification is the process of turning something that is normally thought of as an abstract concept into something more concrete. It’s from the Latin res facere, “thing making”.

Thing-making happens all the time in non-computer-related domains. Queen Elizabeth, her throne and her crown, for example, are all concrete representations of the abstract concept of “sovereignty”. A judge’s gavel or a statue of a blind woman holding scales make a concrete representation of the abstract concept of “justice”.

You also see reification in teleological rhetoric. “Information wants to be free”, for example, fallaciously reifies “information” for rhetorical impact. And it succeeds in doing so - obviously this is some compelling rhetoric that speaks to lots of people. It makes an interesting point in a memorable way.(*) But hopefully no one seriously believes that the abstract concept of “information” is actually a thing with desires or beliefs. Only concrete entities can actually want something.

In the world of programming language design and implementation, reification is a huge part of what we do; designing languages and building compilers is all about taking extremely abstract concepts like “variable”, “procedure”, “type”, “set”, “class”, and so on, and making a device that reifies those concepts into more concrete textual entities that can be declared and manipulated. Our goal for LINQ in C# 3.0 was to reify ideas like “filter”, “projection”, “group”, “order”, and “query” into concrete entities that could be directly expressed in the text of the program. Adding homoiconicity via expression trees reifies those concepts even further, making them manipulable as runtime objects.

Some of the most interesting areas in the computing industry are those where reifications are still inchoate or contradictory. Consider the tarball that is modern bleeding-edge asynchronous programming, for example. Pretty much everyone agrees that we need some decent way to solidly reify the notion of “asynchronous work”, but how? Looking around, I find that people reify this idea (or closely related ideas) in a dozen different ways. Workflows, coroutines, observable collections, futures and promises come immediately to mind; I’m sure there are many more. This lack of consensus makes the language designers’ jobs much harder.

*************

(*) The alert reader will have just wryly noted that I have indulged in the very rhetorical fallacy that I’m pointing out. I’ve fallaciously reified a quotation into a thing that can succeed, can speak and can make a point. Really I should be making these attributions to the concrete people who speak that statement, not to the abstract statement itself.

And isn’t that ironic, don’t you think? Who would’ve thought? It figures.

Five-Dollar Words For Programmers, Part Four: Boustrophedonic

Eric Lippert — Thu, 26 Mar 2009 16:39:00 GMT

Here’s an almost useless but thoroughly delightful five-dollar word. English of course is read left-to-right. Hebrew and Arabic are read right-to-left. A text is boustrophedonic if it reads left-to-right and right-to-left, alternating.

It’s from the Greek βουστροφηδόν meaning “as the ox turns”; you’d plow a field with an ox right to left and then left to right, obviously.

There are a number of ancient languages which were written boustrophedonically, which I’m sure has given members of the Unicode committee many sleepless nights. The example here is a rare early Latin text written boustrophedonically.

What’s the relevance to computer people not on the Unicode committee, given that odds are slim to none that Word will ever support boustrophedonic editing? That’s how most modern dot-matrix and inkjet printers print. The head goes left-to-right, then prints the image “backwards” right-to-left, and so on.

I discovered this word several years ago when grepping through the Scrabble Tournament Word List post-game to see if HEDONIC was in fact a legal bingo, or if I had played a phony. (It is legal.) But I had partial text matching on, so I hit BOUSTROPHEDONIC first and was intrigued, so I looked it up.

At fifteen letters long, it would run the entire width or height of the board. If OUST, HE and ON were all on the board already in the right place along an edge, you could play the remaining seven letters, get the triple-triple-triple word score plus the bingo bonus, and score 725 points. That would almost double the world record for highest scoring play (CAZIQUES, 392 points).

This seems unlikely, but you never know. Might come in handy.

Five-Dollar Words For Programmers, Part Three: Homoiconic

Eric Lippert — Mon, 23 Mar 2009 23:33:42 GMT

Jeff Atwood was kind enough to once more give me the shout-out in his blog the other day. Thanks Jeff!

This inspires me to continue my series on five-dollar words for programmers. Here’s one that I only learned relatively recently, when I helped write the code that translates a lambda expression into an expression tree which represents the content of the lambda: homoiconic.

A language is said to be homoiconic if the representation of the program can be seen as a data structure expressible in that language. With expression lambdas being convertible to expression trees (which can then be compiled into code at runtime), C# 3.0 is somewhat homoiconic. But it pales in comparison to, say, LISP, where pretty much everything you can do in the language you can also represent as structurally isomophic data.

Something I personally would like to see more of in C# in the future is greater homoiconicity. We could extend expression trees to statement trees, declaration trees, program trees, and so on. This series of steps would enable increasingly powerful and interesting metaprogramming scenarios.

C# suffers from the lack of a metalanguage. We absolutely do not want to go towards the horrible and primitive metaprogramming language exemplified by the C preprocessor language. We already have a great language, C#, so why not use C# as a metalanguage? Wouldn’t it be nice to make C# its own metalanguage? And once we do that, then we get into some truly strange loops, where we could use those data structures in the compiler implementation itself!

This is a long way off and might never happen, but a guy can dream.

Five-Dollar Words for Programmers, Part Two: Orthogonal

Eric Lippert — Fri, 28 Oct 2005 17:00:00 GMT

In geometry, "orthogonal" basically means the same thing as "perpendicular", or "at right angles". The walls are orthogonal to the floor. But algebraists extend the meaning of "orthogonal" beyond mere perpendicularity; to an algebraist, two aspects of a system are orthogonal if one can be varied without changing the value of the other.

Imagine for instance that you were trying to describe how to get from one point in an empty room to another. A perfectly valid way to do so would be to say how many steps to go north or south, and then how many steps to go northeast or southwest. This hockey-stick navigation system is totally workable, but it feels weird because north and northeast are not orthogonal -- you can't change your position by moving northeast without also at the same time changing how far north you are. With an orthogonal system -- say, the traditional north-south/east-west system -- you can specify how far north to go without worrying about taking the east-west movement into account at all.

Nonorthogonal systems are hard to manipulate because it's hard to tweak isolated parts. Consider my fish tank for example. The pH, hardness, oxidation potential, dissolved oxygen content, salinity and conductivity of the water are very nonorthogonal; changing one tends to have an effect on the others, making it sometimes tricky to get the right balance. Even things like changing the light levels can change the bacteria and algae growth cycles causing chemical changes in the water.

Computer people further extend this algebraic notion of orthogonality to their systems. Consider a case I just came across while studying the C# expression binding code, for example. C# warns about unreachable code:

if (false) {
label: // targetted but not reachable
foo(); // warning! unreachable!
if (abc) goto label;
}

and also warns about untargetted labels:

public void foo() {
bar();
label: // reachable but not targetted
blah();
}

"Reachable" and "targetted" are orthogonal in one sense. You can have a reachable targetted label, a reachable untargetted label, an unreachable targetted label and an unreachable untargetted label. But they are nonorthogonal in another sense, as I discovered this week when I almost seriously broke the code generator. The way our code generator works, we must generate IL for an unreachable label if it is targetted by a reachable goto. The notions of reachable and targetted get conflated in this one corner case, meaning that I cannot have a code generator that skips generating all unreachable code. This unexpected nonorthogonality makes it difficult to write a compiler that is both correct and understandable, so I'm trying to figure out ways to either eliminate the nonorthogonality, or capture the problem in a very specific piece of highly localized code that I can comment the heck out of.

Now hold on a minute, I hear you saying. Surely if the goto is reachable then the label will be too! My challenge to you guys is this: how can you have an unreachable label targetted by a reachable goto?

Five-Dollar Words for Programmers, Part One: Idempotence

Eric Lippert — Wed, 26 Oct 2005 17:00:00 GMT

Programmers, particularly those with a mathematical background, often use words from mathematics when describing their systems. Unfortunately, they also often do so without consideration of the non-mathematical background of their colleagues. I thought I might talk today a bit about the word "idempotent". This is a very easy concept but lots of people don't know that there is a word for it.

There are two closely related definitions for "idempotent. A value is "idempotent under function foo" if the result of doing foo to the value results in the value right back again.

A function is "idempotent" if the result of doing it twice (feeding the output of the first call into the second call) is exactly the same as the result of doing it once. (Or, in other words, every output of the function is idempotent under it.)

The most trivial mathematical example of the second kind is the constant function. If f(x) = c, then clearly f(x) = f(f(x)) = f(f(f(x))) ... so f is idempotent (and the constant is idempotent under it). The identity function f(x) = x is also idempotent (and every value is idempotent under it). The function that takes a set of numbers and returns a set containing its largest element is idempotent (and every one-element set is idempotent under it). I'm sure you can think of lots of examples of idempotent functions.

To get a handle on the other sense, pick an operation -- say, doubling. The only value which is idempotent under that operation is zero. The operation "subtracting any non-zero value" has no idempotent values. Squaring has two idempotent values, zero and one.

The second characterization of this concept comes up all the time in practical programming, particularly around caching logic. Usually when used in the computer science sense we don't mean that the effect of the function is invariant under composition, but rather that it is invariant over the number of calls. For example, I don't know how many times I've written:

HRESULT GetTypeLibCreator(ICreateTypeLib2 ** ppctl) {
if (this->m_pctl == NULL) {
    HRESULT hr;
    hr = CreateTypeLib2(SYS_WIN32, pszName, &this->m_pctl);
    if (FAILED(hr)) return hr;
}
*ppctl = this->m_pctl;
this->m_pctl->AddRef();
return S_OK;
}

A nice little idempotent function -- calling it two, three, n times has exactly the same result as calling it once.

The place you see the other characterization of idempotence all the time is in C++ header files. Include a needed header zero times and you'll get "not defined" errors. Accidentally include it twice and you'll get "redefinition" errors. It's a major pain to make sure that every header file is included exactly once. Therefore, most headers use some trick to make them idempotent under the inclusion operation:

#ifndef STUFF_H_INCLUDED
#define STUFF_H_INCLUDED

// headers here

#endif // STUFF_H_INCLUDED

or in more modern systems, the #pragma once directive makes headers idempotent under inclusion.