Programming language inventor or serial killer?

I usually don't use my blog just to point elsewhere, but this is really funny.

Programming language inventor or serial killer?

The Transient and the Permanent

Time was, a URL was a concrete pointer to a resource. Because it built on DNS, the machine could move to a new network, but the URL was "guaranteed" (in a meaning of the word guarantee very unlike that in normal discourse) to remain the same. For example, if you were publishing a paper, and you wanted readers who might be looking at a hard copy to be able to find updates, you might include the URL.

I just read a paper (Philip Wadler's Call-By-Name Is Dual to Call-By-Value) in which the author says that you can find the original home of the paper by "gooling wadler dual." Now it's not hard to understand why Wadler, who has had as employers recently AT&T, Lucent, and Avaya without changing his job once, would not trust a URL built on the current name of his employer to remain valid. But I think it's a sign of a larger and more interesting trend.

Back when URLs were presumed permanent, search was a very approximate mapping over those URLs. And, as search technology improved and changed by lurches and fits, no two searches were really guaranteed to return the same results. However, Google, with its social-network-baked-in algorithms, has changed the analysis. For fairly important documents, a carefully selected set of keywords (wadler, dual being otherwise fairly unlikely) will if not uniquely, at least reliably, return the wished-for page. Now, URLs are transient, as we move from company to company or ISP to ISP; it is search that is, more or less, permanent.

Now the interesting test will be to see if this page that I'm writing right now climbs very high. I have, after all, repeated "wadler dual" quite a number of times. (Of course, I've pointed at the paper URL myself, so as long as Avaya is Avaya, finding this page is almost as good.)

Informatics

In Europe, the academic departments that in the US would be called "Computer Science" are generally called "Informatics." It's a nice name, the study of information, and perhaps it plays a part in escaping the curse of the computer scientist, of being too closely associated with computer programming. (I remember back in grad school someone posted to the USENET group for the CS department and asked a fairly ridiculous question about how to use Microsoft Mail. I responded and asked if they had had car problems, would they have asked the mechanical engineering department? Yeah, I was a jerk, but still.)

But what's ironic about Informatics and Computer Science in general is that it's really made comparatively little contribution to the scientific study of information. A couple of days ago I made reference to Herbert Simon's idea of a science of the artificial. As chemistry is to chemical engineering, what is to computer science? Most computer science today is a design field, designing programs, yes, but also designing algorithms or data structures or architectures. But still, all design. Where's the foundational science of information?

And the answer is, as you might guess, physics and mathematics. Clever physicists are extending the ideas of thermodynamics and entropy to include information content. People like John Wheeler at Princeton have been arguing that the bit is a fundamental physical entity, and perhaps even more fundamental than matter. Of course, Claude Shannon, a mathematician, created the idea of information science (and to be fair in those days there were no computer science departments anyway), but it's been physics that's carried the banner onward. But physical information science is a soulless sort of creature. It deals with bits, sure, but does not concern itself with the content of those bits.

One fascinating newcomer in this field is biology. If it is true, as some physicists aver, that matter, energy, and information are co-equal entities in our universe, constantly changing form from one to another, then the study of information deserves more attention. The study of matter and energy has long been the province of physics and chemistry. Perhaps the definition of life, that slippery goal, is merely some arrangement that turns matter and energy into information. In a sense entirely removed from bioinformatics and genomic databases, perhaps biology is the real information science.

Teacher, My Brain Has Halted

Are we smart enough to understand the universe? (This is another thought inspired by Evelyn Fox Keller's book Making Sense of Life.) This will sound obvious, but our brains are part of the universe, so it's an open question of whether we can reflectively understand it. It's almost an article of faith among scientists that any phenomenon can be explained, given enough research, but there's no reason to necessarily believe that. There very well may be phenomena more complicated than our brains can comprehend. Why not?

In fact, if we turn to Turing Machines, we know that there is an infinity of functions that TMs cannot compute. The most famous, the Halting problem, is precisely a reflective problem of understanding oneself, of predicting what a Turing Machine will do when confronted with a question about a Turing Machine. Unknowable. Could it be that the problem of consciousness is our Halting Problem? We all seem to assume, albeit in a completely unspoken way, that we will eventually crack the code of consciousness; sure, it's a tough problem, but as technology improves, we'll get it sooner or later.

But maybe not. Maybe the human brain -- the human mind -- is structurally incapable of answering questions about itself. There's certainly strong reason to believe that in general computational models have limited reflective ability, and certainly if you believe that human brains are Turing Machines (you chump!), you must acknowledge uncomputable functions. The universe is a big place, and it might just be bigger than our minds will ever get.

The Physically Rooted Metaphor of Programming

Programming is among the most abstract of human intellectual activities: designing a series of electrical charges and impulses to act in concert, manipulating other charges that, in turn, stand for the abstraction of numbers, or further layered abstractions of other functions or locations. Pretty abstruse stuff.

So why are the dominant metaphors of programming so rooted in physical reality? Data flows from sources to sinks, just like water through a pipe. We use handles to refer to objects. Two nodes handshake. We take the address of variables. We load a program into memory, as if loading cargo into a wagon. This is not even to mention the design patterns, inspired as they are by physical architecture, and of course object-oriented programming which is most obviously a metaphor rooted in the very idea that pieces of programs are like physical things. And don't get me started on the Turing machine.

It's not actually that hard a question to answer. We use physical metaphors because that's what our brains are hardwired to understand. George Lakoff would claim that all of our cognitive metaphors are, ultimately, rooted in physical reality. Is this why other metaphors, like functional programming, farther removed as they are from a physical basis, are less popular even if more powerful?

But what's surprising is not that our metaphors are rooted in physical reality, but that there's been so little experimentation. Why not a journey? Why not a conversation? Why not learning a dance instead of building a house? Why not keeping bees instead of laying pipe? Why not boxing, or climbing a mountain, or writing poetry, or appreciating art, or raising a family?

Bonus Feature: The Headlines We Were Promised, Part 1

Not that you'd notice, but it's the 21st Century. I don't know about you, but so far I'm pretty disappointed. Where's the Moonbase? Where's Starfleet? Where's the apocalypse that wipes out 90% of humanity?

There are glimmers of hope:

Robot ship racing to death crash on Jupiter.

Do We Need Scalars for Programming?

Scalar values -- regular old numbers like integers, floats, and doubles with no associated units -- are the mainstay of programming. Computer architectures are designed to move around integers or floating point numbers pretty rapidly; the original Turing machine architecture assumed that the value of cells on the tape were atomic symbols. Even Claude Shannon's information theory says that the bits being communicated have no intrinsic meaning. This whole a-bit-is-a-bit metaphor for representing numbers has made the life of hardware designers easier, but I don't think it's the right thing for programming anymore.

This isn't to say that we should abandon numbers. No! This is not a hard-core object-oriented screed, that says we must abandon poor old integers for the sake of heavyweight objects that encapsulate their own methods (not that there's anything wrong with that). Numbers are good, but the fact is that when we use numbers, those numbers have meaning. More specifically, those numbers have units.

What's 3? What's 104.2? In the absense of any context, those numbers are meaningless. Only in context can we find out that it's three miles, or 104.2 degrees. Especially for scientific computing, engineering analysis, or financial applications (three fairly important classes of software), a number is almost always rooted in a unit. We all know what happened to the Mars probe when the units didn't match, and software that encoded unit types directly in numeric values would eliminate a large class of fatal but difficult to detect bugs. Two systems I know have this capability: Curl, an MIT spinoff LISPy like language that is positioned as a web client software language to replace Java and HTML, and some work by Paul Morrison take on the problem. But it's silly that standard languages like Java, C#, Perl, etc. don't have this built right into the guts.

Of course, there are countless ways to simulate this, from creating object types with flags representing types, but a robust system would know not only about specific units and measurement systems, but know when length is being compared to length (as in our Mars example), as opposed to, say, temperature, which could produce a compile-time error. Curl goes a step further, and transforms your numbers to mks behind the scenes, so you actually can be fairly loose and sloppy, and it takes care of lining up the units correctly. If you multiply mass times acceleration, you properly end up with a variable that represents force.

There are other applications for scalars, of course, most notably counting and iteration. But I suspect we can do away with all of those as well. That will have to wait for later.

Administrative Note

I might be taking a break shortly; don't be alarmed if I don't update every day. I'll be back.

Is Computer Science a Science?

Generally, I think that any field that feels it must append the word "science" to its name must not be an actual science -- political science, social science, cosmetic science, etc. You don't study "chemistry science" or "physics science," you study "chemistry" and "physics." (This is, btw, another reason why my alma mater is a great school, because the name of the department there is "politics," not "political science.") Under this defintion, computer science probably isn't one.

More seriously, computer science is very different from the natural sciences (it's okay for a group of sciences to have "science" after their name). Computer science is what Herbert Simon calls a Science of the Artificial. It deals with creating artifacts that embody human intention. Natural sciences, in contrast, have no place for intention; they are about inferring the real functioning of reality. Computer science and other design fields (engineering, organizational design, etc.) need not match their theory to an objective reality, they must match their theory with its ability to satisfy human demands.

But Simon goes further. Chemical engineering is a design field, concerned with how one creates a system to process or produce chemicals, roughly. It has a close relationship, obviously, with the natural science of chemistry. But as chemistry is to chemical engineering, what is to other design fields? And is there a science of design? Simon says yes (this is the "science of the artificial" of the title). But it seems to me that, of all the design fields, computer science is the closest to what Simon calls a science of design. It's not just how to construct an algorithm that will embody the intention of the programmer; it's very much about analyzing the process of the creation of the algorithm, of not just measuring the success of the algorithm but studying the act of measurement. Not just how to write good programs, but the science of why some programs are better.

I'm surprised to be writing these words; for years, I've felt that computer science, as implied by the defensive name, isn't actually a science. But reading Simon has made me realize that a science of the artificial is still a science. Whoopie! Stand back, I'm a scientist!

Narrative as the Scaffolding of Understanding

Here's a great piece on the use of "master narratives" in journalism. Evelyn Fox Keller's killer book Making Sense of Life (one day soon I'll write up a real book review) talks about "explanatory narratives" in science. Do these uses of the word "narrative" have anything to do with my running interest in narrative as story architecture? Are they related to the issues of social software as a generator of consent? I think so.

A narrative isn't just a story, a list of events, one damn thing after another. In Prof. Keller's words, "the explanations that propitiate our need for understanding, the stories we like to hear, are those that meet the expectations we bring with us." In other words, when we approach an unknown situation -- a scientific question, a new story, an unsettled question -- we bring with us a certain amount of preconceptions. Those conceptions may come from culture, from similar stories we've heard, from possibly hardwired expectations and symbolism. They both illuminate, by allowing us to reason about the unknown by using more familiar concepts, and obscure, because the mapping from the story to the current situation cannot be exactly correct in all respects. Someone who's never read a detective novel, reading The Big Sleep for the first time, would not only find it unusual, they might even not understand it, since it is grounded so firmly in a (usually) shared set of rules, symbols, relationships between elements that create preconceptions in the reader. In literature, we call a set of these preconceptions a "genre."

So a narrative -- in the sense of a set of expectations and definitions of who is doing the action and what the goal of action is -- is yet another powerful tool (perhaps too powerful?) for engendering consensus in a group. In political reporting, this might be dangerous as it freezes out facts or stories that don't fit into the narrative. But in the exact same way, it represents an extremely efficient, compressed way of communicating a complex set of relationships to someone else, by referring to some shared metaphor of narrative or genre. The stories we share may be our best hope at sharing understanding.

Architectures of Consensus and Dissent

Let me be clear. I don't mean to imply that all groupware products necessarily cause groupthink, nor that the role of social software ought to be solely as an aid to dissent. There's a continuum ranging from lockstep agreement and deaf to outside opinion on one side, and multiple diverging opinions within the group on the other. Neither is a positive outcome for a group trying to make a decision or manage a process, and each has many of its own modalities and failure modes. The goal, of course, is to sail between the Scylla of groupthink and the Charibdis of ever-spiraling disagreement. We call that middle path "consensus." There are plenty of mechanisms to reach consensus: talk until everyone agrees; vote and 50%+1 wins; vote and 2/3 wins; one leader decides; etc. Not all work well, not all work always.

The point is that, given that we're beginning to use software as an aid to decision making and group policy-setting, we need to be more cognizant of the implicit effects that the software architecture has on our ability to navigate across this continuum. The Mindworld project is an example of a software architecture -- adjust one pixel at a time -- in which dissent is extremely difficult to put into the mainstream of opinion. USENET is another architecture, in which there is no central artifact to relate to, no time limit, and no built-in mechanism to discourage dissent; thus, it is a perfect example of a software architecture that encourages divergence.

We make these choices all the time when we design software, but I suspect that many of us do it without giving it deep thought, especially because many of the effects of these features on dissent or consensus may be difficult to foresee, or may emerge only through the combination of many features. To return to the MindWorld example, imagine if the interactive primitive wasn't just "set a pixel," but "move a block," where you could paint a rectangle and move it. That change alone would empower dissent significantly; and yes, maybe too much. So now imagine a system in which you can move blocks, but over time, the size of the blocks allowed became smaller and smaller; that's a system that would impose consensus. Is that fair? Perhaps. The role of dissent is most valuable early in the process, when small changes will add to large changes in the end. Or when the system is so misguided later on that a radical realignment is necessary, and perhaps we need a different mechanism to account for that mode of dissent.

One last side note: legal systems and social systems are architectures, too, and architectures of either that repress dissent do themselves a grave disservice.

Does Groupware Imply Groupthink?

Courtesy of reader Joseph Kondel, here's a wonderful example of how software can mediate collective action to create consensus:
http://douweosinga.com/projects/mindworld.

For those who didn't click (or if it's down, which it seems to be often), it's a little applet which displays a bunch of pixels in a rectangle. Instructions tell the user that the area ought to look like a world map. One pixel is highlighted, and a form asks if the highlighted pixel ought to be land or water. Rinse, lather, repeat, and ten thousand visits later or so, it's moved from random noise to a recognizable world map. Pretty incredible.

What's interesting about it is that there was little guidance given. The directions didn't say "North America should be over here on the upper left, and Europe in the middle..." it just said to make a map, and that's what came up. At what point did a visitor naturally fall into the emerging consensus that that particular blob was North America? Or that the Pacific Ocean would be mostly off the map? No point, and yet it happened.

Furthermore, imagine the difficulty of changing that consensus. Maybe you're a Pacific Islander, and you want to change the map to reflect the actual size of the Pacific. Too bad! Given the momentum of the consensus, it would be prohibitively difficult to move all the pixels of North America over the east, or shrink Asia, or whatever it would take. For the architecture of this application, consensus is what the old chaos mathematicians would call an attractor, and it's a powerful one.

As we build different kinds of groupware/social software, what's the role of consensus, and how powerful is it? Does software make reaching consensus easier or harder? For purely message-driven systems like email lists or USENET, consensus is much harder to reach than it would be in a real-life meeting. But once consensus is reached, breaking that consensus often brings down the flames of wrath. All of this is somehow invisibly coded in the interstices of the software architecture and human nature. Social psychologists have long described the phenomenon of "groupthink," when the opinions of a group of people quickly form consensus, making it extremely difficult for individuals to dissent, and in which the group vastly overestimates the probability that it has reached the best possible strategy. It's like a collective shared overconfidence (remind you of any Presidental administrations?). Could we architect social software that fought groupthink? Or does it just make the gravitational attraction of consensus, even flawed consensus, ever so much more irresistable?

A Press Release I'd Like to See

FLASHPOWER: FLASHMOBS FOR THE ENTERPRISE

You've read about flashmobs in the newspaper. Now, tap the power of flashmobs for your enterprise, realizing ROI on your enterprise software investment, and increasing the stickiness of your customers.

Using our proprietary peer-to-peer, adaptive, autonomic, social-network-aware FLASHPOWER software, direct your employees, customers, and stakeholders to arrive at specific locations. We support over four thousand possible locations through our FLASH LOCATIONS PARTNERS program, including Starbucks(tm), Marriott(tm), and Newbury Comics(tm). FLASHPOWER supports twenty-five different activities for your mobs, including muttering, chanting, clapping, hopping on one foot, and furiously scowling while entering data into their PDA*. Upgrade to FLASHPOWER PRO and receive additional PRO locations, including such important sites as Faneuil Hall, Boston, the QuickStop used in Kevin Smith's film "Clerks," and the 1st base bleachers of Coors' Field**.

Flashmobs are critical elements of the connected enterprise strategy. Use them to mock competitors, sow confusion, distract the media from your most egregious foreign policy mistakes, or destroy the work of mad scientists who dare to play God. Don't let your competitors open up a flashmob gap. It's a first-mover's advantage, with increasing returns on the network effects, and only the most agile and connected enterprises will survive. "Keep the mob on your side."


* Available 1Q 2004.
** Admission not included.
FLASHPOWER, FLASHPOWER PRO, and "Keep the mob on your side" are trademarks of THE AMAZING FLASH. All other trademarks belong to their respective holders. This offer void in the universe.

Unsympathetic

I've railed on IBM's autonomic computing initiative before, but it's been a while, so here's another shot.

The idea behind calling it "autonomic" is that it's inspired by the autonomic nervous system, the part of the nervous system generally out of our control and our awareness. Our heart beats faster when we're being attacked; if you think about it, that's some pretty amazing processing going on without your knowledge. Some part of your brain is looking out your eyeballs, seeing a bear, figuring out that bears are likely to eat you, then deciding that running away is a good strategy, then signaling the heart to beat faster, the pancreas to release adrenalin, etc. All without you consciously making any of those decisions (you're too busy saying, "Holy crap! It's a bear!"). It's a natural why this is appealing to computer operators; they want the computers to make the same sort of assessments: hey, a strange situation has arisen; I better swap out a flaky drive; I'll just checkpoint and make a backup; and then do the actions. Meanwhile, the story goes, the operator is blithely ignorant of the whole situation ("Holy crap! A bear!").

There are two irritating things about this. One is that they didn't even begin to look at the biology of the autonomic nervous system. The ANS has different subsystems, the sympathetic and parasympathetic nervous systems (there's a third, but pay no attention for the moment). One is for generating and restoring energy - digesting food, for example, and slowing down respiration; the other is for spending energy in times of crisis, like the visit from our friend the bear. This itself is an interesting idea for a software system: two competing subsystems, one responsible for reacting to crises, such as attacks or failures; one responsible for providing services and bringing the system back into more optimal configuration. And yet nowhere in any autonomic computing paper I've looked at (and I've looked at more than I care to) is there any acknowledgement that two subsystems are a good idea. If you're going to claim biological inspiration, you might as well look at the biology.

The second irritating thing is in Paul Horn's and writings by Alan Ganek, the claim is made over and over that software must be made "less complex." "It's too complicated!" they exclaim (making little reference to where this complication came from). "We need to make it simple!" And then, in a wonderful bit of sleight-of-hand, they introduce the most complicated and difficult architecture of all time. This is in no way making software less complex. It adds at least an order of magnitude complexity to the entire system. (There's a chance, I suppose, that it might make individual components less complicated. I doubt it. But in any case the total system complexity will be skyscraper high.) This is not in itself a bad thing; we software people get paid to write complex stuff; if it was simple we wouldn't get paid so much. Complexity can be the source of great power and capability, and there's nothing intrinsicially wrong with it. But the IBM claim is beyond disingenuous, and in fact it takes away energy from a reasonable and potentially helpful approach: make the damn software simpler.

Now I know what they meant: the human act of operating software should be simpler, and it's a no-brainer to trade off complexity inside the system for complexity in the interface. It's too bad they had to say it in a way that cheapens both the idea of simple but powerful software, and the still underexplored idea of biological inspiration.

Call for Participation: O'Reilly Emerging Technologies Conference

I've been to a lot of pretty high-end technology conferences; of all of them, O'Reilly ETech is my favorite. It's sort of descendant of O'Reilly's conferences on Peer-to-Peer, but it's morphed into a giant catch-all of new, interesting things. Hardware hacking, nanotechnology, biological computing, blogging, wireless, social software, online games... every year there are surprises. This is very much explicitly not a marketroid conference where VPs of sales who don't know the tech try to get you to buy something. This is where the in-the-lab geeks come out into the sunlight (or, rather, the basement of a Westin) and show off what they've been up to.

This is your chance to shine in flourescent light. Here's the conference description, and here's the call for participation. Submit proposals by September 24!

Disclosure: I've been a speaker at both ETechs so far, and the P2P/Web Services conference before that, and I was a member of ETech's program committee last year. Having said all that, I've never gotten paid by O'Reilly, and I'm not associated with the conference management this year. I do hope to be there.

Endonym

It's official: the word for "what local people call a geographic feature" is endonym. A word that non-local people use is an exonym. Here's a glossary of toponymic terminology compiled by the United Nations. Apparently there's a whole UN agency that worries about endonyms and exonyms (and, by the way, they encourage the standard use of endonyms).

And by the way, here's a map that kicks my map's ass. You can use the pulldown menu on the left to get names in a bunch of different languages (but be patient); "International" uses endonyms (in their native script).

Will We Be Enslaved by Robots?

Maybe, maybe not. But first, someone's got to build them, or more precisely, build a lot more of them and a lot more capable. So the question is, as it has been: what's a robot good for?

Canonically, robots are used for the 3 'D's: dirty, dull, or dangerous. That is, those are the kinds of jobs that we'd rather use robots to do than people. I'm not quite sure I believe the dull part: the fact is that the world population is extremely underemployed, and people would be willing to do a lot of boring jobs, and I suspect that they'd be cheaper than robots.

But I think the application set for robots is a little more complicated. First, there's Distant: applications where we'd like to have a human, but it's too expensive or inconvenient to get one there. Telepresence, such as interacting with your house even when you're at the office; exploration, like extraplanetary missions; or just inconvenient, like ocean bottoms or flooded mines. "Dull" is really two different things: dull because it requires constant attention, and dull because it's repetitive. Finally, there's Difficult: something that humans aren't particularly good at doing. (I'm tempted to add "Dog" for Aibo.)

So looking for a breakthrough robot application, we should first look at the five Ds, and consider human jobs for which it's feasible a robot could displace the humans. For Dangerous, there's certainly enormous interest in military applications, and I suspect that we'll make progress here, especially in hybtid remote-piloted but also semiautonomous robots (for example, the human might direct motion or the camera, but the robot would avoid obstacles and dodge enemy fire). Also, emergency jobs like firefighters or rescue jobs could well be augmented by robots. These are, however, tiny niche markets. Similarly, there are other niche markets for Distant; NASA is certainly developing many robots to explore the solar system. Robot telepresence might catch on; if it does, Michael Swanwick deserves credit for calling it in Stations of the Tide, an amazing science fiction book.

For dirty, there's a potential set of follow-ons to Roomba, but cleaning other surfaces, such as kitchen counters or toilets. Possible, although they'd have to be considerably less obtrusive than Roomba.

Dull. For jobs that require attention, like security guards, I think robotic systems have a great future. Although, having said that, the "robotic" part of it is less important than just sensors and processors. Still, it would be nice to have a giant robotic white blob that chased down escaping prisoners. For jobs that are repetitive, this has so far been the biggest application of robots, on the manufacturing floor. I don't know good numbers, but I do suspect that there are plenty of kinds of manufacturing jobs that are just barely out of reach of robots, and as they become more agile and more perceptive, they will begin to displace human workers (again, there's an economic piece as well, one distorted in the US by the corporate tax code that lets you count robots as a capital expense but not human workers).

Finally, Difficult. What's interesting about this D is that all of the others are about displacing humans doing existing jobs. But Difficult suggests that there are jobs that humans can't do, but jobs we might want done, and that robots could do them. It's hard to imagine these, because we don't have practice coming up with job descriptions that humans can't fill, but certainly they'd be ones that involved great strength, great speed and accuracy, and excellent perception.

Now for people who think that we're just a few years away from a huge market in robots, you must read this article about a cool robot toy that makes the same claim. That article is eighteen years old.

Real Abstractions

Some people are having difficulty with this map project. "Real" was supposed to be slightly ironic, but apparently it's caused some trouble.

Reflecting, I think I see the problem. A name for a country is an abstraction. It's either a string of symbols that encode sounds, or a series of sounds, which the people in a given language have agreed represents a country. In a purist sense, all such abstractions are equivalent, since they are all arbitrary. Complicating this, the very idea of a country is an abstraction! We've made a general agreement that a certain geographic territory, and all of the stuff inside a line, is a country. This would be more defensible if a) those geographic limits matched any actual geographic features or b) they didn't change. But mostly, they don't, and they do, respectively. In fact, the idea of the nation-state is enormously powerful in our world; even fairly pathologically dysfunctional governments like North Korea and Afghanistan are still extraordinarily powerful institutions by any rational human standards; only in comparison with the hyperpowers of the world do they dim; but don't forget that North Korea can call on an army of more than a million people. But, still, we must admit, an abstraction.

So we are, indeed, dealing with abstractions. But let me dismiss a very common and important misconception, that abstractions aren't real. Of course they're real! The opposite of abstract is "concrete," not "real." And to really screw you up, the opposite of real is "unreal", not "artificial." Artificial means that something is created by humans to embody an intention: it is an artifact. As we'd say when interpreting the archaelogy exhibit at the Museum of Science, "An artifact is something people made or used." Artifacts are artificial and vice versa. Abstractions are artificial in this sense, since they are all products of human cognition with the intention of communicating.

Hmm... in keeping with my resolution to have blog entries be first drafts, I'm not going to edit this, but I feel like I'm just crashing through the ceiling on my way up.

Let me rephrase, and get back on track.

A name for a country is an abstraction, one that we find useful. There are many simultaneous names for a country, which carry varying amounts of associated semantic meaning, which will in turn vary for different speakers. For example, "United States" is a fairly semantically rich name to a speaker of English; it refers both to the country of the USA, and gives some indication of the nature of the country. A speaker of French with no knowledge of English at all might recognize the sounds yoo-nye-tid-stayts to refer to the country he calls Etats-Unis, without recognizing that it means the same thing. More plausibly, we could call China "Zhongguo" without knowing it meant "Middle Kingdom." Who is to say which handle is more "real", China, Zhongguo, or Middle Kingdom?

My argument for maps -- my name of the day for the project is "Bell Maps," after Eric Bell, the mathematician who said "the map is not the territory," -- is that the more of these abstract handles we know, with associated semantic value, the better we will be able to understand the other people who share those handles. And when the handles are those that are in fact used by the people who live there, then all the more important for us to know them. Does this mean we have to follow their example and use their names? Well, no, although frankly I think it's rude not to. Does that mean their names are more "real" than those we use? Well, again, not really in a philosophical sense, but I must insist that Deutschland is objectively a more accurate name for that country than "Germany."

One more issue: some people, even more radical than my proposal, said that we should use their script on the maps, that using transliteration into a Latin alphabet was no more real than the traditional English name. Again, all of these things are equally abstract, so I wouldn't say that transliterations are worse. As ideograms, yes, those labels would be valid handles, but a) we have a terrible memory for scripts we cannot read, so these are not particularly memorable handles, and b) we could not pronounce them. It might be educational to show the local name of a country in the local script, but this is not a useful handle for us. Bell Maps are not meant to be a global replacement for all maps around the world; they're meant to be for the English (or at least Latin-alphabet) reading world, as an adjunct to all other sorts of maps. Political maps don't replace geographic maps, or weather maps, or topographic maps. Bell maps are just one more tool to represent the world.

Okay, I'm officially done talking about this for now. Tomorrow, robots!

Names, Territories, Maps, Things

When I was a kid, I was a big fan of a linguistic philosophy called General Semantics (if you haven't figured it out yet, I was an extremely nerdy and strange kid). I dare say I didn't really understand it, but a) it was a key plot device in a science fiction book I liked a lot (The World of Null-A, by A.E. van Vogt), and b) the popularization of the philosophy I read, Language in Thought and Action by S.I. Hayakawa, made it sound cool. (I still have a fond place in my heart for Hayakawa, who in his one term serving as a U.S. Senator from California, remarked during the Panama Canal debate that "we stole it fair and square." There was a man who understand language. And he wore a funny hat.) Now that I think about it, I've always had a weak spot for offbeat linguistic philosophies. Lakoff, Pinker, bring 'em on.

One of the key ideas behind General Semantics is Frege's quote "the name is not the thing," and Bell's more famous quote "the map is not the territory." (Here's an interesting page on General Semantics although the author seems quite negative about some aspects of it.)

Earlier, I took Bell's quote to justify more accurate names for maps, but of course Frege would also tell us that the names aren't the countries either. Of course. We could talk about a number of different kinds of names of countries:
1. The referral name. What the people in a given country A call country B. For example, we call China "China."
2. The orthographic name. What the inhabitants of the country call it, using their own script. I can't easily reproduce China's name here.
3. The phonetic name. How we would pronounce -- or transcribe the pronunciation -- of the local orthographic name. We'd say (or write) "Zhong Guo."
4. The semantic name. What the local name means. Zhong Guo means "Middle Kingdom."

And, to make matters more complicated, there may be any number of each of these. This makes making maps that represent this kind of information tricky. How much information can you pack into a static graphic? How meaningful is the orthographic name to those that can't read the script, much less understand the language? Is "Rossiya" in a Latin alphabet more or less "accurate" or "meaningful" or "useful" than POCC[backwards N][backwards R] in Cyrillic? What about all of the other ethnic groups that live in Russia/Rossiya?

All this mulling -- plus realizing that there's a commercial product called RealMaps -- has made me realize that I've got the name all wrong. I'll take suggestions for a better one, but it occurs to me that these are Name Maps (sort of the ultimate in General Semantics evil); we're making a map of what the names are. The course of study of this field is, of course, cartonomography. Maybe the collection of maps is the Cartonomicon.

Real Map, 0.1

Just for kicks, I took a stab at making a Real Map for Europe. Why Europe? Well, it's much smaller than the whole world, and I also thought it would surprise people just how wrong our traditional names were. I think I was most surprised by Crna Gora, which in fact is Slavic for Black Mountain. So in some sense we got it right. And maybe, if you stretch things, you could get Croatia from Hrvatska. But where on earth did we get Georgia? Even the Russians (strangely, although the Russian word for Russia is Rossiya, the Russian word for Russian is Russki) call it something else.

Did anyone else watching the 1996 Olympics think that the home crowd cheered extra hard for the athletes from Sakartvelo? I guess we'll put an end to that, not to mention ruining a perfectly good Beatles lyric. Hmm.

What's Google/Blogger up to?

I know I'm probably one of only ten people who care about this, but Blogger's left-hand-side "Blogs of Note" list has some funny redirects through Google. I've noticed this in my logs - I'm getting tons of hits as if people are querying google for www.coherenceengine.com. I guess they want to track which blogs are being hit.

More Than Maps

I've realized that my earlier ideas about maps that have the "actual" names of countries were too limited. What about countries with more than one name? What about areas that are claimed by more than one nation? What about history? It occurs to me that, with display technology available in the next few years, we'll be able to radically change what we think of as "maps." Not only will they be fully customizable, in terms of displaying various layers of political, geographical, and environmental information, they will be able to show history, what the ancients called places, or where the ancient roads were.

That's just the start, though. As cool as that will be, it's still just a representation of static -- albeit highly multidimensional and rich -- data. But with sensor networks and wirelessly-enabled map displays, the maps will update in real time; useful for military applications, sure, but also weather, traffic, crowd control, finding friends, etc. In fact, sometimes it astonishes me how limited the J.K. Rowling's imagination is: in just a couple of years, our technology will blaze past the Marauder's Map (and almost everything else in the book, flue powder and flying brooms excepted).

One more step. Why should the map be just a display? The data will be gathered by a ubiquitous network of sensors, but in many cases those devices will also be actuators. The map, then, becomes an input device to affect the environment it represents. Look at a map of a garden; overlay the soil moisture; then water the parts that need it. Maybe the map really will be the territory, after all.