Prose Poetry Code – Page 64 – The Three Written Arts

Creating a sport

Humans have probably played games for about as long as they’ve been human. Some of these are mental (chess, etc.), while others are mostly physical in nature. These physical games, when they become somewhat organized and competitive (two other universals in humanity), can be called sports.

This post, then, looks at what it takes to create the rudiments of a fictional sport. I’ll admit, very few stories will need such fine detail. The specifics of a sport likely won’t feature in any work of fiction, though there are examples of sports being a focus. The video game Final Fantasy X has its Blitzball, for example; it’s both a mini-game and a major part of the culture of Spira, the game’s fictional world. Similarly, the Harry Potter book/movie series has its game of Quidditch, which forms a backdrop for certain events of its story. (And that fictitious sport later received its own video game, Harry Potter: Quidditch World Cup.)

Again, let’s spell out what the post considers a sport. It has to be mainly physical, first of all. Go and chess are both classic games with long histories and intricate strategies, but they are tests of the mind, not the body, so they don’t meet our definition.

Second, sports are competitive. They pit one person or group against one or more others of relatively equal strength. The opposing forces don’t have to be present at the same time—baseball is effectively 9 against 1—but each side must have an equal opportunity to claim victory.

Third, sports have goals. This can be a literal goal, as in soccer or basketball, or a figurative one, like the highest or lowest score. Goals also imply an ending condition, such as time, score, or distance. Otherwise, you don’t have a sport.

Finally, the key factor in turning a game that meets all of the above criteria into a sport is some form of organization. This can be nothing more than a common set of rules, or it can be organized leagues with sponsorship and broadcast rights and billion-dollar contracts. Pickup games of street basketball and gym-class dodgeball fail this test, but they are simplified versions of “true” sports, so they get a pass.

Historical sports

In modern times, we’re familiar with quite a few sports. America has the familiar triumvirate of football, baseball, and basketball, all very popular. Hockey, soccer and rugby are three other big ones around the world, and the Olympics this summer will showcase dozens more. And that’s not counting track and field events, racing (whether on foot or using a vehicle), golf, cricket, and all those others we tend to overlook.

Each of these “modern” sports has a history, but all those histories, whether long (soccer dates back centuries) or short (BMX racing, now an Olympic sport, started in the 1970s) boil down to same thing. Someone, somewhere, started playing a game. More people then began playing. With more players, rules evolved. As the game grew in popularity, it became more fixed in its form, and thus a sport was born.

But sports don’t remain fixed forever. Different rule sets can emerge, and those can give rise to new sports. Rugby split off from soccer when players decided they wanted to pick up the ball and run with it. (Later on, Americans decided they liked a turn-based version better: football.) Cricket never caught on much in the US, but rounders, a simplified version played in English schoolyards, did; after a lot of tweaking, it developed into baseball. The list of “derivative” sports goes on: street hockey, beach soccer and volleyball, Australian rules football…

Nor do sports ever truly die. The Mesoamerican civilizations (Aztec, Maya, Olmec, etc.) have become famous in recent years for the archaeological evidence for their ball game, which dates back as far as 1600 BC. Despite all that has happened since then, a descendant of the Aztec game, now known as ulama, is still played in parts of Mexico. Over in the Old World, the Greek fighting sport pankration, a staple of the classical Olympics that was dropped when they were modernized, has been modified, organized, and subsumed into mixed martial arts.

Birth of a sport

Every culture has its sports. Sometimes, they’re inextricably linked. Few play cricket outside of Britain and its former colonies. Racing on an oval, as in NASCAR, is quintessentially American. Others gain more widespread appeal. Soccer—whatever you want to call it—is a worldwide game. Baseball bas become popular throughout the Americas and Asia. And so on.

Most sports will come about because of a culture. They’ll be part of it, at the start. Sometimes, they’re related to warfare, possibly as training (running, javelin throwing) or as a war “proxy” (the Mesoamerican ball games, maybe). Alternatively, they can be childhood games that “grew up”.

Which sports a culture plays can depend on its outlook on life, its technological advancement, and plenty of other factors. Technology’s role, of course, is easy to understand. After all, you can’t race automobiles until they’re invented. In the same vein, European games before the 1500s didn’t use rubber balls, because they didn’t have them; they tended to use wrapped animal bladders or things like that.

The level of organization is also dependent on these factors. Video replays obviously require video, but that’s an easy one. Precise timing is also necessary for many sports, but it took a long time to master. And from a cultural perspective, it’s not hard to imagine that a more egalitarian society might focus on loosely defined individual competitions rather than team games, while a martial civilization may see rigorously regulated team sports as a perfect metaphor for squad-level battles.

Taking steps

So let’s think about what it takes to make a sport. Looking back at the introduction, we see that we need an organized, competitive, and physical endeavor with well-defined goals. That’s a pretty good start. Let’s break it down in a different way, though, by asking some basic questions.

Who’s playing? Options include one-on-one, like martial arts; one against the “field”, like racing and golf; or team-against-team, as in baseball or football. Anything other than a contest between opposing individuals also requires a total count of players. For “serious” team sports, you can also work out rules for substitutions and things like that.
Where are they playing? Indoors or outdoors is the natural first approximation. But you’ll also want to know the size and shape of the playing area. This is usually the same for every event, but not always. Baseball fields have a bit of variation in the size of the outfield, and the racetrack at Daytona is almost five times as long as the one in Bristol.
What do they need to play? In other words, what equipment does the sport require? Balls are very common, though their composition (rubber, bladder, wood, etc.) can vary. Sticks show up in quite a few sports: baseball, hockey, and cricket are just three. Nets, posts, racquets—the possibilities are virtually endless. That’s not even counting vehicles or, as in polo, animals.
What are they trying to do? “Get the ball in the goal” is one possible objective. “Reach a certain point before X” is another. Those two, in fact, cover most sports Americans recognize as such. Add in “Don’t let the ball touch the ground”, and you’re pretty much set. You can also substitute “puck” or whatever for “ball”, if your sport uses one of those instead. Note that this is the main objective, not the entirety of the rules.
What is and is not allowed? These are the finer rules of the game. They’re the bulk of the gameplay, but a fictitious story is allowed to gloss over them when they’re not pivotal to the action. You have to be consistent, though, but from a storytelling perspective. A sport’s rules don’t necessarily have to make sense. Football’s “catch rule”, the definition of “charging” in basketball, and the whole sport of cricket are evidence of this.
Who wins, and how? This is the victory condition. Some games are time-based, where they end after a certain period has elapsed. Others, such as baseball or tennis, finish after a set number of turns or scores. Sports where score is kept will generally be won by the side with the most scores; golf, though, is a counterexample. Races, of course, go to the one who finishes first, and a few sports (gymnastics and figure skating, for instance, but also boxing) are scored by judges.

There are quite a few other details you can add, like what happens after an event, whether there is enough organization for leagues and championships, etc. The level of detail is important here, though: don’t get lost in impertinent trivia. It’s fun, but you probably don’t need it for the story.

In those stories where it’s warranted, on the other hand, an invented sport can add flavor to a culture. It’s a good illustration that we’re looking at a different set of people. This is what they think is fun. Sure, many cultures will have similarities in their sports. Soccer could plausibly be created just about anywhere, at almost any time. Many of the martial events at the original Olympics came about from soldierly pursuits, and everybody has soldiers. But it’s the differences that we notice the most.

With fantasy, there’s also the potential for new sports that are beyond our capability. Anything involving magic fits this bill; our two fantastic examples above are both physically impossible for ordinary humans. But fantasy worlds might be more amenable to bizarre sports. The same is true in futuristic science fiction. We can’t play games in zero-G today, but that doesn’t mean people on 24th century starships can’t. As with everything in worldbuilding, the only limits are in your mind.

Let’s make a language – Part 14b: Derivation (Isian)

Both of our conlangs have a wide variety of ways to construct new words without having to resort to full-on coinages. We’ll start with Isian, as always, since it tends to be the simpler of the two.

Isian compounds

Isian is a bit more like German or Swedish than English, in that it prefers compounds of whole words rather than tacking on bound affixes. That’s not to say the language doesn’t have a sizable collection of those, but they’re more situational. Compounding is the preferred way of making new terms.

Isian compounds are mostly head-final, and the most common by far are combinations of two or more nouns:

hu “dog” + talar “house” → hutalar “doghouse”
acros “war” + sam “man” → acrosam “soldier” (“war-man”)
tor “land” + domo “lord” → tordomo “landlord”

Note that acrosam shows a loss of one s. This is a common occurrence in Isian compounds. Anytime two of the same letter would meet, they merge into one. (In writing, they might remain separate.) Two sounds that “can’t” go together are instead linked by -r- or -e-, whichever fits better.

Adjectives can combine with nouns, too. The noun always goes last. Only the stress patterns and the occasional added or deleted sound tell you that you’re dealing with a compound rather than a noun phrase:

sush “blue” + firin “bird” → sufirin “bluebird”
bid “white” + ficha “river” → bificha “rapids” (“white river”)

In the latter example, which shows elision, the noun phrase “a white river” would be ta bid ficha, with bid receiving its own stress. The compound “some rapids” is instead ta bificha, with only one stress.

Most verbs can’t combine directly with anything else; they have to be changed to adjectives first. A few “dynamic” verbs, however, can be derived from wasa “to go” plus another verb. An example might be wasotasi “to grab”, from otasi “to hold”.

Changing class

Isian does have ways of deriving, say, a noun from an adjective. The language has a total of eight of these class-changing morphemes that are fairly regular and productive. All of them are suffixes, and the table below shows their meaning, an example, and their closest English equivalent.

Suffix	Function	English	Example
-do	State adjective from verb	-ly	ligado “lovely”
-(t)e	Verb from noun	-fy	safe “to snow”
-el	Adjective from noun	-y, -al	lakhel “royal”
-m	Agent noun from verb	-er	ostanim “hunter”
-mer	Adjective from verb	-able	cheremer “visible”
-nas	Abstract noun from verb	-ance	gonas “speech”
-(r)os	Noun from adjective	-ness	yaliros “happiness”
-(a)ti	Verb from adjective	en-	haykati “to anger”

For the most part, these can’t be combined. Instead, compounds are formed. As an example, “visibility” can be translated as cheremered “visible one”, compounding cheremer with the generic pronoun ed.

-do is very commonly used to make compounds of verbs (in the form of gerund-like adjectives) and nouns. An example might be sipedototac “woodcutting”, from which we could also derive sipedototakem “woodcutter”.

More derivation

The other productive derivational affixes don’t change a word’s part of speech, but slightly alter some other aspect. While the class-changers are all suffixes, this small set contains suffixes, prefixes, and even a couple of circumfixes. (We already met one of those in the Babel Text, as you’ll recall.)

-chi and -go are diminutive and augmentative suffixes for nouns. Most nouns can take these, although the meanings are often idiosyncratic. For example, jedechi, from jed “boy”, means “little boy”, and secago “greatsword” derives from seca “sword”.
-cat, as we saw in the Babel Text, turns a noun into a “mass” noun, one that represents a material or some other uncountable. One instance there was gadocat “brick”, meaning the material of brick, not an individual block.
a-an was also in the Babel Text. It’s a circumfix: the a- part is a prefix, the -an a suffix. Thus, we can make ayalian “unhappy” from yali “happy”.
Two other productive circumfixes are i-se and o-ca, the diminutive and augmentative for adjectives, respectively. With these, we can make triplets like hul “cold”, ihulse “cool”, and ohulca “frigid”.
The prefix et- works almost exactly like English re-, except that you can put it on just about any verb: roco “to write”, eteroco or etroco “to rewrite”.
ha-, another verbal prefix, makes “inverse” forms of verbs. For example, hachere might mean “to not see” or “to miss”. It’s different from the modal adverb an.
mo- is similar in meaning, but it’s a “reverse”: mochere “to unsee”.

That’s not all

Isian has a few other derivation affixes, but they’re mostly “legacy”. They aren’t productive, and some of them are quite irregular. We’ll meet them as we go on, though. For now, it’s time to switch to Ardari.

Software internals: Lists

Up to now, we’ve been looking at the simplest of data structures. Arrays are perfectly linear. Strings are mostly so, until you add in the complications of modern character sets. Objects need a little bit more help, but they can often be reduced to arrays of data. Not so this time around.

Lists are incredibly important to a lot of programming work. In today’s popular languages, they’ve essentially taken over the fundamental position once occupied by arrays. In Python, Ruby, and so many other languages, it’s the list that is the main sequence. In Lisp and Clojure, it’s the universal one, in the same way that NAND is the universal gate in electronics: everything else can be built from it.

But why are lists so useful? Unlike arrays, they lend themselves to dynamic allocation. Elements packed into an array don’t have anywhere to go. If you want to resize the structure, you often have to move everything around. In C++, for example, a vector (essentially a dynamically-sized array) can have elements added and removed, but that can trigger a full resizing, which can move the vector to a different address in memory, thus rendering all your pointers and iterators useless. Higher-level languages don’t have these problems with arrays, but lists never have them in the first place. They’re made to be changed.

Linked lists

The most common method for making a list is the linked list. At its core, a linked list is nothing but a sequence of nodes. A node is typically defined as a structure with a data member (one piece of the data you’re storing in the list) and a link member. This will usually be a pointer to the next node in the list, or, for the last item, a null pointer. In code, it might look like this:

// It is "item type"
struct Node<It>
{
    It data;
    Node<It>* next;
};

A list, then, could be represented as nothing more than a pointer to the first Node. By “walking” through each next pointer, a function can visit each node in order. And that’s all there really is to it.

Working with this kind of linked list isn’t too hard. Finding its length, a common operation in code, doesn’t take much:

// This is assumed throughout, but we'll make it explicit here
using List<It> = Node<It>*;

size_t length(List<It> li)
{
    size_t counter = 0;

    while (li)
    {
        ++counter;
        li = li->next;
    }

    return counter;
}

There are plenty of optimizations we can do to improve on this (it’s O(n)), but it should illustrate the basic idea. If you prefer a functional approach, you can do that, too:

// FP version
size_t length(List<It> li)
{
    if (!li)
        return 0;
    else
        return 1 + length(li->next);
}

That one looks a lot better in a proper FP language, but I wanted to stick to a single language for this post.

Inserting new elements is just manipulating pointers, and changing their value can be done by altering the data members. In general, that’s all you need to know. Even higher level languages are largely based on this same foundation, no matter what interface their lists present to the programmer.

Another option

The drawback of linked lists is the time it takes to find anything in them. Most operations are going to require you to walk some, if not all, of the list. The bigger the list gets, the longer it takes to walk it. In other words, it’s O(n) time.

Different systems get around this in different ways. One possibility is to forgo the use of linked lists entirely, instead basing things around an array list. This is nothing more than a dynamically-sized array like the C++ vector or Java ArrayList, but it can be used like a list, except that it also has a random access interface.

Most of the time, an array list will have a reference to its own block of memory, enough to hold all its current elements plus a few extra. When it runs out of that space, it’ll allocate a new, larger buffer, and move everything to that. On the inside, it would look something like:

struct AList<It>
{
    size_t capacity;
    size_t max_capacity;
    It* data;
}

Array lists work a lot better in an object-oriented system, because you can use methods to simplify the interface, but there’s no reason you need them. Here, for example, is a non-OOP access method for our AList above:

It at(AList<It> li, size_t pos)
{
    if (pos >= li.capacity)
        // Out-of-bounds error...

    return li.data[pos];
}

Inserting is trickier, though, because of the possibility of reallocation:

void insert(AList<It> li, It item)
{
    if (li.capacity == li.max_capacity)
    {
        resize_array(li, li.max_capacity * 2);
    }

    data[capacity] = item;
    ++capacity;
}

Our hypothetical resize_array function would then fetch a new block of memory with double the space, copy all the elements over to it, update max_capacity, and change data to point to the new block. Not hard to do, but non-trivial, and the copy can be time-consuming with large array lists. (It runs in what’s called “amortized” O(n). If you don’t cause a reallocation, then inserts are constant-time. If you do, they’re linear, because of the copy.)

Array lists are probably used more often than linked lists as the backing for high-level languages, and they’re the go-to option even for C++, Java, and C#. That’s because you tend to do a lot of insertions into their lists. If the system can allocate a big enough buffer at the start, then inserting into an array list is no different, internally, from inserting into an empty space in a regular array. Deletions are always that easy.

But the linked list approach will come in handy later on, when we look at trees, and they also have a few key advantages. As always, it’s a balance. If you need random access to elements, array lists are better. If you’re doing a lot of inserting at the ends of the structure, and not all at once, linked lists start to become a more attractive option. And if you’re using a high-level language, you’d use whatever is available. It still helps to know what you’re getting into, though. Knowing how the different types of list work can help you plan your own code’s structure better, even if you never have the choice of which kind to use.

Worldbuilding and the level of detail

Building a world, whether a simple stage, a vast universe, or anywhere in between, is hard work. Worse, it’s work that never really ends. One author, one team of writers, one group of players—none of these could hope to create a full-featured world in anything approaching a reasonable time. We have to cut corners at every turn, just to make the whole thing possible, let alone manageable.

Where to cut those corners is the hard part. Obviously, everything pertinent to the story must be left in. But how much else do we need? Only the creator of the work can truly answer that one. Some stories may only require the most rudimentary worldbuilding. Action movies and first-person shooters, for example, don’t need much more than sets and (maybe) some character motivations. A sprawling, open-world RPG has to have a bit more effort put into it. The bigger the “scale”, the more work you’d think you need.

Level of detail

But that’s not necessarily true. In computer graphics programming, there’s a concept called mipmapping. A large texture (like the outer surface of a building) takes up quite a chunk of memory. If it’s far enough away, though, it’ll only be a few pixels on the screen. That’s wasteful—and it slows the game down—so a technique was invented where smaller versions of the texture could be loaded when an object was too far away to warrant the “full-sized” graphics. As you get closer, the object’s texture is progressively changed to better and better versions, until the game engine determines that it’s worth showing the original.

The full set of these textures, from the original possibly down to a single pixel, is called a mipmap. In some cases, it’s even possible to control how much of the mipmap is used. On lower-end machines, some games can be set to use lower-resolution textures, effectively taking off the top layer or two of the mipmap. Lower resolution means less memory usage, and less processing needed for lighting and other effects. The setting for this is usually called the level of detail.

Okay, so that’s what happens with computer graphics, but how, you might be wondering, does that apply to worldbuilding? Well, the idea of mipmapping is a perfect analogy to what we need to do to make a semi-believable world without spending ages on it. The things that are close to the story need the most detail, while people, places, and events far away can be painted in broad, low-res strokes. Then, if future parts of the story require it, those can be “swapped out” for something more detailed.

The level of detail is another “setting” we can tweak in a fictional work. Epic fantasy cries out for great worldbuilding. Superhero movies…not so much. Books have the room to delve deeper into what makes the world tick than the cramped confines of film. Even then, there’s a limit to how much you should say. You don’t need to calculate how many people would be infected by a zombie plague in a 24-hour period in your average metropolis. But a book might want to give some vague figures, whereas a movie would just show as many extras as the producers could find that day.

Branches of the tree

The level of detail, then, is more like a hard cutoff. This is how far down any particular path you’re willing to go for the story. But you certainly don’t need to go that far for everything. You have to pick and choose, and that’s where the mipmap-like idea of “the closer you are, the more detail you get” comes in.

Again, the needs of the story, the tone you’re trying to set, and the genre and medium are all going to affect your priorities. In this way, the mipmap metaphor is exactly backwards. We want to start with the least detail. Then, in those areas you know will be important, fill in a bit more. (This can happen as you’re writing, or in the planning stages, depending on how you work.)

As an example, let’s say you’re making something like a typical “space opera” type of work. You know it’s going to be set in the galaxy at large, or a sizable fraction of it. Now, our galaxy has 100 billion stars, but you’d be crazy to worry about one percent of one percent of that. Instead, think about where the story needs to be: the galactic capital, the home of the lost ancients, and so on. You might not even have to put them on a map unless you expect their true locations to become important, and you can always add those in later.

In the same vein, what about government? Well, does it matter? If politics won’t be a central focus, then just make a note to throw in the occasional mention of the Federation/Empire/Council, and that’s that. Only once you know what you want do you have to fill in the blanks. Technology? Same thing. Technobabble about FTL or wormholes or hyperspace would make for usable filler.

Of course, the danger is that you end up tying yourself in knots. Sometimes, you can’t reconcile your broad picture with the finer details. If you’re the type of writer who plans before putting words on the page, that’s not too bad; cross out your original idea, and start over. Seat-of-the-pants writers will have a tougher time of it. My advice there is to hold off as long as feasible before committing to any firm details. Handwaving, vague statements, and the unreliable narrator can all help here, although those can make the story seem wishy-washy. It might be best to steer the story around such obstacles instead.

The basic idea does need you to think a little bit beforehand. You have to know where your story is going to know how much detail is enough. Focus on the wrong places, and you waste effort and valuable time. Set the “level of detail” dial too low, and you might end up with a shallow story in a shallower world. In graphics, mipmaps can often be created automatically. As writers, we don’t have that luxury. We have to make all those layers ourselves. Nobody ever said building a world was easy.

Let’s make a language – Part 14a: Derivation (Intro)

By this point in the series, we’ve made quite a few words, but a “real” language has far more. English, for instance, is variously quoted as having anywhere from 100,000 to over a million different words. How do they do it? Up to now, we’ve been creating words in our conlangs in a pretty direct manner. Here’s a concept, so there’s a word, and then it’s on to the next. But that only takes you a very short way into a vocabulary. What we need is a faster method.

Our words so far (with a few exceptions) have been roots. These are the basic stock of a language’s lexicon, but not its entirety. Most languages can take those roots and construct from them a multitude of new, related words. This process is called derivation, and it might be seen as one of the most powerful weapons in the conlanger’s arsenal.

How to build a word

Derivation is different from inflection. Where inflection is the way we make roots into grammatically correct words, derivation is more concerned with making roots into bigger roots. These can then be inflected like any other, but that’s for after they’re derived.

The processes of derivation and inflection, however, work in similar ways. We’ve got quite a few choices for ways to build words. Here are some of the most common, with English examples where possible.

Prefixes: morphemes added to the beginning of a root; “un-” or “anti-“.
Suffixes: morphemes added to the end of a root; “-ize” and “-ly”.
Compounding: putting two or more roots together to make a new one; “football” or “cellphone”.
Reduplication: repeating part or all of a root; “no-no”, “chit-chat”.
Stress: changing the stress of a root; noun “permit” and verb “permit“.

Stem changes (where some part of the root itself changes) are another possibility, but these are more common as inflections in English, as in singular “mouse” versus plural “mice”. Tone can be used in derivation in languages that have it, though this seems to be a little rarer.

Also, although I only listed prefixes and suffixes above, there are a few other types of affixes that sometimes pop up in derivation. Infixes are inserted inside the root; English doesn’t do this, except in the case of expletives. Circumfixes combine prefixes and suffixes, like German’s inflectional ge-t. The only English circumfix I can think of is en-en, used to make a few verbs like “enlighten” and the humorous “embiggen”. Finally, many languages’ compounds contain a linking element. German has the ubiquitous -s-, and English has words like “speedometer”.

Derivations of any kind can be classified based on how productive they are. A productive derivation is one which can be used on many words with predictable results. Unproductive derivations might be limited to a few idiosyncratic uses. These categories aren’t fixed, though. Over time, some productive affixes can fall out of fashion, while unproductive ones become more useful due to analogy. (“Trans-” is undergoing the latter transformation—ha!—as we speak, and some are pushing for wider use of the near-forgotten “cis-“.)

Isolating languages are a special case that deserves a footnote. Since the whole point of such a language is that words are usually simple, you might wonder how they can have derivation. Sometimes, they will allow a more “traditional” derivation process, typically compounding or some sort of affix. An alternative is to create phrases with the desired meaning. These periphrastic compounds might be fixed and regular enough in form to be considered derivations, in which case they’ll follow the same rules.

What it means

So we have a lot of ways to build new words (or phrases, for the isolating fans out there) out of smaller parts. That’s great, but now we need those parts. For compounds, it’s pretty easy, so we’ll start with those.

Compounding is the art of taking two smaller words and creating a larger one from them. (And it is indeed an art; look at German if you don’t believe me.) This new word is somehow related to its parts, but how depends a lot on the language. It can be nothing more than the sum of its parts, as in “input-output”. Or the compound may express a subset of one part, like “cellphone”.

Which words can be compounded also changes from language to language. Putting two nouns together (“railroad”) is very common; which one goes first depends, and it’s not always as simple as head-first or head-final. Combinations of two verbs are rarer in Western languages, though colloquial English has phrasal compounds like “go get” and “come see”. Adjective-noun compounds are everywhere in English: “redbird”, “loudspeaker”, and so on.

Verbs and nouns can fit together, too, as they often do in English and related languages. “Breakfast” and “touchscreen” are good examples. Usually, these words combine a verb and an object into a new noun, but not always. Instrumental compounds can also be formed, where the noun is the cause or means of the action. In English, these are distinguished by being noun-verb compounds: “finger-pointing”, “screen-looking”. They start out as gerunds (hence the -ing), but its trivially easy to turn them into verbs.

Really, any words can be compounded. “Livestreaming” is an adjective-verb compound. “Aboveboard” combines a preposition and a noun. The possibilities are endless, and linguistic prescription can’t stop the creative spirit. You don’t even have to use the whole word these days. “Simulcast”, “blog”, and the hideous “staycation” are all examples of “blended” compounds.

All the rest

Compounds are all made from words or, more technically, free morphemes. Most of the other derivational processes work by attaching bound morphemes to a root. Some of these are highly productive, able to make a new word out of just about anything. Others are more restricted, like the rare examples of English reduplication.

Changing class

Most derivations of this type change some part of a word’s nature, shifting it from one category to another. English, as we know, is full of these, and its collection makes a good, exhaustive list for a conlanger. We’ve got -ness (adjective to noun), -al (noun to adjective), -fy (noun to verb), -ize (adjective to verb), -able (verb to adjective), and -ly (adjective to adverb), just to name a few. Two special ones of note are -er, which changes a verb to an agent noun, and its patient counterpart -ee.

In general, a language with a heavy focus on derivation (especially agglutinative languages) will have lots of these. One for each possible pair isn’t out of the question. Sometimes, you’ll be able to stack them, as in words like “villification” (noun to verb and back to noun) or “internationalization” (noun to adjective to verb to noun!).

Changing meaning

Those derivations that don’t alter a lexical category will instead change the meaning of the root. We’ve got a lot of options here, and English seems happy to use every single one of them. But we’ll look at just a few of them here. Most, it must be said, were borrowed from Latin or Greek, starting a couple hundred years ago; these classical languages placed a much heavier emphasis on agglutination than English at the time.

Negation is common, particularly for verbs and adjectives. In English, for example, we’ve got un-, non-, in-, dis-, de-, and a-, among others. For nouns, it’s usually more of an antonym than a negation: anti-.

Diminutives show up in a lot of languages, where they indicate “smallness” or “closeness” of some sort. Spanish, for instance, has the diminutive suffix -ito (feminine form -ita). English, on the other hand, doesn’t have a good “general” diminutive. We’ve got -ish for adjectives (“largish”) and -y for some nouns (“daddy”), but nothing totally regular. By a kind of linguistic analogy, diminutives often have high, front vowels in them.

Augmentatives are the opposite: they connote greatness in size or stature. Prefixes like over-, mega-, and super- might be considered augmentatives, and they’re starting to become more productive in modern English. By the same logic as above, augmentatives tend to use back, low vowels.

Most of the others are concerned with verbal aspect, noun location, and the like. In a sense, they replace adverbs or prepositions. Re-, for example, stands in for “again”, as pre- does for “before”. And then there are the outliers, mostly borrowed from classical languages. -ology and -onomy are good examples of this.

Non-English

We’ve heavily focused on English so far, and that’s for good reason: I know English, you know English, and it has a rich tradition of derivation. Other languages work their own ways. The Germanic family likes its compounding. Greek and Latin had tons of affixes you could attach to a word. Many languages of Asia, Africa, and the Pacific have very productive reduplication. Although I used English examples above, that’s no reason to slavishly follow that particular language when constructing your own.

In the next two posts, we’ll see how Isian and Ardari make new words. Each will have its own “style” of derivation, but the results will be the same: near-infinite possibilities.

Languages I love

A while back, I talked about the four programming languages I hate. Now, you get the contrast: the languages I love. Just by comparing this list to the last one, you’ll probably get a good idea of how I think, but I don’t mind. It’s my opinion. No matter how much justification I give, it’ll never be anything more. Of course, that also means that I can’t possibly be wrong, so don’t bother telling me that I am.

C++

C++ is almost universally reviled, it seems. I’m in the minority on this one, but I’m not ashamed. C++, especially the “modern” C++ that we got in 2011, is one of my favorite languages. It’s fast (running, not compiling), versatile, and ubiquitous. It really is the everything language. To some, that’s its biggest flaw, but I find it to be its greatest strength.

I don’t like languages that force me to think a certain way. That’s part of the grudge I have against Java, and it’s most of the reason I put Haskell on the “hate” list. I’d rather have a language smart enough to say, “Hey, you know what you’re doing. Use this if you need it, but if you don’t want to, that’s cool.”

C++ is like that. Want to write an imperative program? No problem. Like your functional programming instead? Every release this decade has only added FP tools. Object-oriented? It’s still around. C++ is called a multi-paradigm language, and it truly deserves that title.

It’s not a perfect language by any means. Most of the problems stem from the necessary backwards-compatibility with C, but everyone knows (or should know) not to use those bits unless absolutely necessary. And they’re increasingly unnecessary. We don’t have to deal with raw pointers anymore. Nobody should ever be calling malloc or creating static arrays (of the int a[42] kind) in modern C++.

Every programming language is a compromise, but I think the good far outweighs the bad in C++. It was a close thing last decade, but now it’s no contest. Smart pointers, templates, RAII, constexpr, C++ just has too many good features. If we could drop the C stuff and get some better string handling, we might just have the perfect language.

Haxe

I’ve written about Haxe before, but I’ll reiterate some of the things I said.

Haxe basically started out as a better ActionScript, but it’s so much more, and it’s one of those languages I wish was better known. Pay attention, language makers, because this is how you do strongly-typed. It’s also got functional stuff if you want it, OOP if that’s your preference, and a little bit of generic programming. It’s not quite as multi-paradigm as C++, but it’s far better than most.

The main flaw with Haxe is probably its not-quite-what-you’d-expect idea of “cross-platform”. Haxe has a compiler, but no way to make native binaries by itself. You can get C++ output, and Haxe can start up GCC or Clang for you, but that’s the best you ‘re going to get. Beyond that, the library support is lacking, and the documentation could use some work. The language itself, though, is solid.

This is a language I want to use. It’s just hard to come up with a reason I should. Maybe, if Haxe gets more popular, people will stop seeing it as “ActionScript++” and see it for what it is: one of the most interesting programming languages around.

Scala

Put simply, Scala is what Java should be.

Internally, it’s a horrible mess, I’ll grant. I’ve seen some of the “internal” and “private” APIs, and they only serve to make my head hurt. But the outer layer, the one we coders actually use, is just fine. Scala gives you functional when you want it, OOP or imperative when you don’t. It lets you do the “your variable is really a constant” thing that FP guys love so much. (I personally don’t understand that, but whatever.) But it doesn’t force you into anything. It’s multi-paradigm and, more importantly, trusting. Exactly what I want from a programming language.

Scala is where I first learned about pattern matching and actors. That makes sense, as those are two of its biggest strengths, and they aren’t things that show up in too many other languages…at least not the ones people actually use. But they’re not all. Where it can, Scala gives you back the things Java took away, like operator overloading. Yet it’s still compatible with Java libraries, and it still runs on the JVM. (Supposedly, you can even use it on Android, but I’ve never managed to get that to work for anything more complex than “Hello, World!”)

If Java is old-school C, Scala is modern C++. That’s the way I see it. Given the choice, I’d rather use it than plain Java any day of the week. Except for speed, it’s better in almost every way. It may not be the best language out there—it does have its flaws—but it’s one of the best options if you’re in the Java “ecosystem”.

The field

I don’t love every language I come across, nor do I hate all the ones that aren’t listed above. Here are some of the ones that didn’t make either cut:

Python: I really like Python, but I can’t love it, for two reasons. One, it has many of the same problems as Ruby regarding speed and parallelism. Two, the version split. Python 3 has some good features, but it’s a total break with Python 2, and it has a couple of design decisions that I simply do not agree with. (Changing print from statement to function is only a symptom, not the whole problem.)
Perl: I find Perl fascinating…from a distance. It’s the ultimate in linguistic anarchy. But that comes with a hefty price in both execution speed and legibility. Modern Perl 5 doesn’t look as much like line noise as the older stuff, but it’s definitely not like much else. And the less said about Perl 6, the better.
JavaScript: You could say I have a love/hate relationship with JavaScript. It has a few severe flaws (this handling, for instance), but there’s a solid core in there. Remember how I said that C++’s good outweighs its bad? With JS, it’s almost a perfect balance.
Lisp: Specifically, that means Clojure here, as that’s the only one I’ve ever really tried. Lisp has some great ideas, but somebody forgot to add in the syntax. It’s too easy to get dizzy looking at all the parentheses, and editors can only do so much.
C: As much as I blame C for C++’s faults, I don’t hate it. Yeah, it’s horrible from a security and safety standpoint, but it’s fast and low-level. Sometimes, that’s all you need. And we wouldn’t have the great languages we have today if not for C. Can you imagine a world dominated by Pascal clones?
C#: I don’t hate C#. I hate the company that developed it, but the language itself is okay. It’s a better Java that isn’t anywhere near as compatible. Too much of it depends on Microsoft stuff for me to love it, but it fixes Java enough that I can’t hate it. So it falls in the middle, through no fault of its own.

Magic and tech: weapons

It’s a given that, no matter what the setting, many people will want to know the available methods for hurting someone. In RPGs (whether video games or old-school pen and paper), that’s especially true, since combat is such a major part of the most popular role-playing games. Even written works require conflict, and military conflict is the easiest and most familiar form.

Weapons go back almost as far as humanity itself. Any culture can make spears and knives, even before the advent of metalworking. (And don’t neglect those older materials. Mayan obsidian blades could be sharper than any contemporary European sword.) Bows, bolas, blowpipes, and a hundred other “ancient” weapons can be used in a perfectly mundane world, and there’s no reason why they wouldn’t also exist in our magical realm. But they won’t be the only options…

The true path

Not everybody used swords. I know that’s a common trope in fantasy, but it’s just not accurate. Swords were expensive, requiring skilled craftsmanship, quality materials, and more than a bit of time. It might be feasible for a company of 100 men to all be armed with swords, but not an entire army.

Spears are a good alternative. They’re cheap—nothing more than a point on a pole. Unlike swords, which you needed at least some training to use (“Stick ’em with the pointy end” only gets you so far), spears are user-friendly. And, in a pinch, a pitchfork or spade can fill in. Something like a spear would form the backbone of a mundane army. There would be swordsmen, of course, but they’re more likely to be officers or other leaders.

Most other melee weapons are situational. Pikes are great against cavalry, for example, but cumbersome when fighting foot soldiers. Axes, polearms, and all the other nifty items in your favorite RPG’s weapons section have their own ups and downs. They’ll have their uses, but they won’t be widespread. However, armies of this era were anything but regular. Even trained forces could end up using weapons they weren’t overly familiar with, and the peasant rabble might turn up with whatever they could find.

On the ranged side, things aren’t much better. Bows are ubiquitous, particularly in medieval Europe. (English longbows, as we know, were a game-changer.) Crossbows are another option—and they go back a lot further than people think—but they have the problem of being slower and more complex. Other choices, like slings, have situations where they’re useful; a bit of thought should help you come up with something.

And don’t forget artillery. The catapult, trebuchet, scorpion, onager, and so on all have a long history. Every single one of them has been wholly obsolete since the first cannon, but most fantasy is set slightly before the invention of gunpowder, so they’re all you’ve got. Some are siege weapons, intended to wreak havoc on a walled city, while others are what we would now call anti-personnel weaponry.

And the other side

With magic, more efficient and deadly means of attack are possible. We’ve already decided that there aren’t mages running around throwing fireballs, so that’s off the table, but all that means is that the magical weaponry will be more subtle, yet no less devastating.

Magical energy in this setting, as we know from earlier entries in this series, can be converted to force. We’ve used that to great effect to provide motive power, but we know how force scales: F = ma. The same energy that pushes a magical “car” up to a few miles per hour could send a tiny ball of, say, lead, to a seriously high velocity. Who needs gunpowder when magic can do the same thing? That one was almost trivial, and mages worked it out a while back. Now, every regiment has an assortment of what we might consider magic-powered guns. They’re too expensive to be given to every common soldier, but they’ve all but replaced crossbows, and longbows have been relegated to sieges. (Unlike the real world, where cannons mostly came first, the rules of magic mean that handguns are much easier to make.)

But it doesn’t stop there. Magic helps with humble bladed weapons, by means of sharpening and endurance enchantments. Artillery gets an extra oomph from magical power, but its true value there lies in shot varieties. Burning and smoke are a cinch for the greenest of mages; in a catapult, the effect is better than any boiling oil or barrel of pitch. And, of course, any soldier can benefit from a stamina boost.

What does all this do to the battlefields of our magical setting? For the full answer, we’ll have to wait and see the other aspects of fighting, such as defenses. We can say quite a bit now, though. In general, our magical kingdom’s battles will tend to resemble those of a couple hundred years later. Think more Late Renaissance than High Middle Ages, except without the cannons.

Not everyone has guns, so the largest part of the fighting will still be hand-to-hand, with swords and spears and all the rest. In place of a contingent of archers will be magical gunners, armed with ever more powerful dealers of death. They won’t match today’s high-powered rifles, but they wouldn’t be out of place in the American Revolution, in terms of their effect on the enemy.

Artillery will look more medieval, but there are a few differences. With magic replacing the…ancillary supplies for shot, artillery forces will be a bit less exposed. That means they’ll be free to take more risks, to advance more quickly. Oddly enough, they won’t be as much use in a siege, at least until they get right up to the gates. Circumstances converge to make artillery very good at distance (because it’ll still out-range anything else) and up close (because it can do the most damage), but not so great in the middle.

Other uses

As we know, weaponry isn’t limited to the battlefield. Personal weapons are a feature of any culture, as are the rules governing them. For everything except the magic-powered guns, little will change in this regard. Openly carrying a weapon is still a symbol of ill intent, drawing it more so. Hidden weapons will be harder to find, because they can be smaller or disguised as something innocuous, but mages can point out magical items.

Assassination is easier in the magical kingdom. That’s unfortunate, but not unexpected. With the greater power available, not everyone will see the need for greater responsibility. It’s almost self-balancing, since everyone knows how easy it is, sort of like Mutually Assured Destruction. Blood feuds can erupt into a war in the streets, but that’s not too different from the real world of that time.

The original use for many weapons was killing animals, and this is only helped by magic. Ask any hunter: guns are far better than bows. That’ll be true even when the bullets are powered by the invisible force of magical energy. (This could have environmental issues—hunting to extinction is much easier—but that can wait for a later post.)

All told, adding magic to weaponry has nearly the same effects as adding gunpowder. The world becomes more dangerous, but many new possibilities appear. New avenues of research open up. To fight the growing offense, the mages will be asked to create new defenses. And that will be the subject of the next post in the series: how to protect oneself.

E-zi script, an emoji syllabary

The other day, Twitter announced it would retain its 140-character limit for posts. A hundred and forty letters, spaces, and numerals isn’t all that much, if you think about it. In fact, this paragraph is already far too long to fit in a single tweet.

Speakers of other languages which use other scripts sometimes have it easier. Twitter’s limit applies to characters, not bytes, and all of Unicode is available for use. If you’re writing in Chinese, for example, you can fit a lot more information into 140 characters. That’s because Chinese is a logographic writing system, not an alphabet like ours. There are thousands of symbols, most of them representing part, if not all, of a word. But Chinese writing is hard to learn, especially for Westerners. To make matters worse, we Americans don’t have an easy way to input characters of foreign languages. (A lot of Chinese-made phones do, but that doesn’t help unless you know how to do it.)

What many Americans do have, however, is another input method: emoji. All told, there are about a thousand of the little symbols, representing everything from emotions to animals to food. Why not use those for a script?

E-zi

Enter E-zi, the emoji syllabary. E-zi is a set of rules and conventions to turn English text into a string of symbols—emoji, but also letters, numbers, and the graphical symbols available on all keyboards—that are easily inputted. Due to the nature of the English language, we can’t quite achieve the efficiency of Chinese or Japanese writing, but we can do better than plain text.

To get a taste of how E-zi works, here’s a sample. The text is the first article of the Universal Declaration of Human Rights:

All human beings are born free and equal in dignity and rights. They are endowed with reason and conscience and should act towards one another in a spirit of brotherhood.

In E-zi, this comes out as:

◻ 👤 Bns R 🐗📯 🆓 & = N 💫🔫🔼🍵 & 👉s. 👫 R N🔽d + ♻🌞 & 🚧🔀ns & 👞🔽 🎬 ▶ 1 A🔘* N A 👻 O 🔆🔘*❓d.

By my count, we’ve dropped from about 170 characters to 81. Many of those are spaces, however, and some can be removed without any loss of understanding. A lot of people do that already in cramped conditions like Twitter, with abbreviations like “txt”. This is just taking it a few steps further.

Reading emoji

The core of the E-zi system is in the way emoji are read. By and large, this must be learned, unfortunately, but the basic ideas are pretty simple.

First, every non-alphanumeric symbol can be read in two types of ways. Take ◻, for example, the first icon we used. When written as its own word, it should be read as “all” or “always”. Another symbol, 🔴, similarly indicates the word “red”, and 🔎 is “detail”.

When combined with other symbols (including letters and numbers), these are instead considered to be syllables or sounds. A given symbol can have lots of these syllabic or phonetic readings, but most are easily derived from the lexical form. For example, ◻ has a syllabic reading AHL (I’ll explain this notation later); 🔴 can be R, RE, or RED, with the last two being most common; and 🔎 reads as DEE or the rarer DEET. Put them together as the E-zi “word” ◻🔴🔎: AHL-RE(D)-DEE, or “already”.

This rebus principle is the heart of E-zi. Words are built as groups of sounds, with a large amount of leeway in which sounds can combine. A good illustration of this is the string I used to translate “dignity”: 💫🔫🔼🍵 . This consists of four symbols, as you can see. The first, 💫, is read DI. 🔫, obviously, is “gun” or, in our phonetic notation, GUHN. The little 🔼 indicates a schwa sound, noted as UH. Finally, 🍵 is, well, “tea”. It’s not a perfect match for the English pronunciation of “dignity”, but it comes close enough that we understand what’s meant.

If we would like a lexical reading where we’d normally have a syllabic one, or vice versa, we can use the * symbol after a symbol. We did that in our quote above, with A🔘* “another”.

Plain letters

In the cases where there isn’t an appropriate symbol, we can resort to letters. But it’s a waste to have two sets of the same thing, upper and lower case, so E-zi repurposes the capital letters. Each one stands for a simple word, usually grammatical in nature:

Letter	Translation
A	a/an
B	be (or “is”, etc.)
C	can
D	do
E	e- (electronic)
F	from
G	go
H	has/have
I	I
J	just
K	okay
L	will (future tense)
M	me
N	in
O	of
P	part
Q	question, cue, or queue
R	are
S	is
T	the
U	you
V	very
W	what
X	ex-, or the word “ex”
Y	why
Z	as

Lower-case letters, on the other hand, are absolutely necessary. They can be placed anywhere, and they mostly sound like their English equivalents. You’d also use them to spell out names and other words where the actual letters used are important. A few, however, also have special meaning when placed at the end of a symbolic word. These are based on a very simplified English grammar:

“s” creates a plural form of any word: 🚗 “car”; 🚗s “cars”. This is always regular, so no need to worry about convoluted English plurals like “oxen”.
“d” forms the past tense of a verb: one reading of ⚔ is “fight”, so ⚔d can be read “fought”. Again, totally regular.
“n” makes a verb into a participle form. Using the same example, ⚔n should be read “fighting”. Similarly, Gn is “going”.

These can all be combined. In the larger text, we had Bns for “beings”. It might look odd in the middle of all the symbols, but it works just the same.

Other symbols

E-zi also makes use of the other keys on your keyboard. Numbers work a bit like capital letters, in that they stand for full words—namely, their values. In other words, 1 is to be read as “one”, and so on. You can use the rebus principle to play with these (4m for “form”, ↩8 for “late”), but numbers have no syllabic or phonetic readings.

Most punctuation marks are used like in English. These include the period, comma, question mark, exclamation mark, semicolon, and colon. Quotation marks are, of course, used to mark quoted speech. The apostrophe, on the other hand, is reused as a general possessive suffix: M’ is “my”, T👨’ is “the man’s”, etc. Like “s” and the others, this ignores traditional English sensibilities in favor of logical regularity.

The other symbols are mainly those on the top row of your computer’s keyboard. The number sign # is reserved for use in hashtags, and the caret ^ indicates a signature. The others can be used as symbols:

Symbol	Name	Use
$	dollar sign	dollar, money
%	percent sign	percent
&	ampersand	and
+	plus sign	and, with
–	hyphen-minus	without
/	solidus	and/or
=	equals sign	is, equals
@	commercial at	at
\|	vertical bar	or (choices)
~	tilde	negation, not

Most of these are lexical-only, but &, +, @, | , and ~ work as syllables, too.

Finally, the grave accent ` marks off text as “regular”, i.e., not E-zi script. You use it in pairs, like quotation marks. The other “grouping” symbols, like brackets and parentheses, are reserved for future use.

Special groups

There are two special groups of Unicode symbols that E-zi gives special meaning to. The clock faces are a set of 24 symbols displaying times in half-hour increments. In E-zi, these simply indicate those times, with no other reading possible. For instance, 🕥 means the time 10:30 and nothing else.

Another group is called the “regional indicator symbols” by Unicode. These are the letters A-Z in boxes, but they are considered the preferred way of marking countries. E-zi uses them in this way, always in pairs representing a country code. (In some places, this may cause them to be displayed as a national flag instead. E-zi takes that as a feature.) Thus, since the country code for the United States is US, the E-zi sequence 🇺🇸 can be read as “United States”. In addition, the emoji 👤 can be suffixed to create an abbreviated form representing a nationality: 🇺🇸👤 should be understood as “American”.

All other symbols are unused by E-zi. The “cat faces” such as 😸 are reserved for expansion, while the skin color modifiers (“Fitzpatrick modifiers”) are ignored.

Phonetic notation

English is a notoriously difficult language to pronounce, even before you worry about dialectal differences. Thus, I’m using a phonetic notation to record E-zi syllabic readings. Nothing’s perfect, but as long as we’re in the ballpark, communication will work.

Most consonants in the notation should be read as their IPA values. This means that K is preferred to C, KW instead of QU, and so on, so some words will look odd. A few, though, have to be changed:

Phoneme	Symbol	Example
θ	TH	THIN “thin”
ð	DH	DHIN “then”
tʃ	CH	CHEK “check”
dʒ	J	JEL “gel”
ʃ	SH	NAYSHUHN “nation”
ʒ	ZH	PLEZHUHR “pleasure”
j	Y	YOOZ “use”
ŋ	NG	SONG “song”

Fortunately, I’ve taken the liberty of dismissing a few of the more common dialectal problems. Final “r” is assumed to always be there; it’s an America-centric view, but it makes things easier. It doesn’t mean you have to pronounce it, though. The “wh” sound, on the other hand, is merged with plain “w”, meaning “what” and “watt” are both WAHT. That was hard for me to do, as I still have a separate “wh” sound, but I realize I’m in the minority. Other dialectal sounds are also ignored; you’ll have to find their closest “standard” equivalents.

Vowels are even more problematic. I’ve taken the Wells lexical set and assigned a sequence of letters to each vowel sound in it. That gives us something reasonable to work with, although it can look a little strange at first. Don’t worry if some of these vowels sound the same in your dialect; that just means you have more opportunities for word play.

Phoneme	Keyword	Symbol
ɪ	KIT	I
ɛ	DRESS	E
æ	TRAP	A
ɔ	LOT	O
ʌ	STRUT	UH
ʊ	FOOT	U
ər	NURSE	UR
i	FLEECE	EE
eɪ	FACE	AY
ɑ	PALM	AH
ɔ	THOUGHT	O
o	GOAT	OH
u	GOOSE	OO
aɪ	PRIDE	IY
ɔɪ	CHOICE	OI
æʊ	MOUTH	OW
ɪr	NEAR	EER
ɛr	SQUARE	AIR
ar	START	AR
ɔr	NORTH	OR
or	FORCE	OR
ʊr	CURE	OUR
ər	LETTER	UR
ə	COMMA	UH

The big list

By my count, there are 970 emoji that have both lexical and syllabic readings. That’s way too many to list here, so I’ll just link a PDF chart that you can view at your leisure. Note that it’s sorted primarily by the least complex syllabic reading. My organization skills do leave something to be desired, however.

E-zi script v0.4

Conclusion

I hope E-zi is a fun and interesting way to make your short-form text more descriptive, more efficient, and more alive. Sure, I could have gone and made something with no relation to English whatsoever, but this way is much easier. Not only that, but it’s a method that stands the test of time. The basic principles of E-zi are the same used in Chinese script, Egyptian hieroglyphs, and Sumerian cuneiform, the oldest writing systems we know. In our modern world, however, we have new reasons to want the succinctness of syllabic and logographic script. Thus, unlike these others, E-zi is made with today’s needs in mind. It’s a twenty-first century take on a millennia-old idea.

All of E-zi is free for you to use however you see fit. No charge, no strings attached. So, have fun with it, and let me know if you use it!

The problem with emoji

Emoji are everywhere these days. Those little icons like 📱 and 😁 show up on our phones, in our browsers, even on TV. In a way, they’re great. They give us a concise way to express some fairly deep concepts. Emotions are hard to sum up in words. “I’m crying tears of joy” is so much longer than 😂, especially if you’re limited to 140 characters of text.

From the programmer’s point of view, however, emoji can rightfully be considered a pox on our house. This is for a few reasons, so let’s look at each of them in turn. In general, these are in order from the most important and problematic to the least.

Emoji are Unicode characters. Yes, you can treat them as text if you’re using them, but we programmers have to make a special effort to properly support Unicode. Sure, some languages say they do it automatically, but deeper investigation shows the hollowness of such statements. Plain ASCII doesn’t even have room for all the accented letters used by the Latin alphabet, so we need Unicode, but that doesn’t mean it’s easy to work with.
Emoji are on a higher plane. The Unicode character set is divided into planes. The first 65,536 code points are the Basic Multilingual Plane (BMP), running from 0x0000 to 0xFFFF. Each further plane is considered supplemental, and many emoji fall in the second plane, with code points around 0x1F000. At first glance, the only problem seems to be an additional byte required to represent each emoji, but…
UCS-2 sucks. UCS-2 is the fixed-width predecessor to UTF-16. It’s obsolete precisely because it can’t handle higher planes, but we still haven’t rid ourselves of it. JavaScript, among others, essentially uses UCS-2 strings, and this is a very bad thing for emoji. They have to be encoded as a surrogate pair, using two otherwise-invalid code points in the BMP. It breaks finding the length of a string. It breaks string indexing. It even breaks simple parsing, because…
Regular expressions can’t handle emoji. At least in present-day JavaScript, they can’t. And that’s the most used language on the web. It’s the front-end language of the here and now. But the JS regex works in UCS-2, which means it doesn’t understand higher-plane characters. (This is getting fixed, and there are libraries out there to help mitigate the problem, but we’re still not to the point where we can count on full support.)
Emoji are hard to type. This applies mostly to desktops. Yeah, people still use those, myself included. For us, typing emoji is a complicated process. Worse, it doesn’t work everywhere. I’m on Linux, and my graphical applications are split between those using GTK+ and those using Qt. The GTK+ ones allow me to type any Unicode character by pressing Ctrl+Shift+U and then the hexadecimal code point. For example, 😂 has code point 0x1F602, so I typed Ctrl+Shift+U, then 1f602, then a space to actually insert the character. Qt-based apps, on the other hand, don’t let me do this; in an impressive display of finger-pointing, Qt, KDE, and X all put the responsibility for Unicode handling on each other.

So, yeah, emoji are a great invention for communication. But, speaking as a programmer, I can’t stand working with them. Maybe that’ll change one day. We’ll have to wait and see.

The future of government

This year of 2016 is, in the US, an election year. For weeks we’ve been mired in the political process, and we’ve had to suffer through endless debating and punditry. The end isn’t near, either. We’ve got to endure this all the way to November.

It’s impossible to not think about government right now. As a builder of worlds and settings, I’m naturally drawn to the idea of government as a concept, rather than as its concrete implementation today. Churchill is usually quoted as saying that democracy is the worst form of government, apart from all others that have been tried. We know what others have been tried: republic, monarchy, communism, theocracy, and so on. Looking at the list, maybe it’s true.

What about the future, though? We’re in the midst of a technological revolution that shows little sign of stopping, yet it seems that little of that has paid off in the political sphere. (If you look at some of the computerized voting systems in use today, you might even think we’ve regressed!) But that could be a transitional thing. In the far future, when we of humanity have moved outward, to the rest of the Solar System and beyond, what will government look like then?

Status quo

It’s easy to think that the way things are is the way they will forever be. Conservatism is a natural thing, because it’s the path of least resistance. And in the near-term, it’s the most likely outcome. Barring some major upheaval, the US will remain a federal republic, China an authoritarian, communist regime, and most of the Middle East an anarchic disaster.

There will be a few slight changes, for sure. The Commonwealth nations are always talking about dissolving the monarchy; it’s reasonable to assume that, one day, talk will beget action. The same with most of the other Western monarchies remaining. As jobs are increasingly given over to robots, socialist tendencies will only increase, as they are doing right now in Europe. Something will eventually bring stability to Iraq and Syria. (Okay, that last one is awfully far-fetched.)

But the advance of technology will open up new avenues of government. And if we do manage self-sustaining colonies beyond Earth, then “self-sustaining” may eventually become “self-governing”. A well-settled Solar System means ample opportunity for new nations to spring up, a breeding ground for new experiments in government. So what might those look like?

Direct democracy

One possibility that isn’t that hard to imagine is direct democracy. As opposed to a democratic republic—like most democracies today—a direct democracy dispenses with the elected officers. It is literally of, by, and for the people. Everybody gets to vote. On everything. (Within reason, of course.)

We can’t really do this today on anything higher than a local level, because nobody would have time for anything else! But a few special situations can arise that would make it palatable. Small colonies are the obvious place for a direct democracy; they work just like towns. A very well-connected and well-educated society could bring direct democracy to a larger populace, but likely only on a limited scale. Mundane things might be left to the elected, while serious matters are voted on by the public at large.

The chief downside to direct democracy is that it relies on the knowledge and wisdom of the masses. It requires faith in humanity, not to make the right decision, but only to make an informed one. And, as I said, it’s also too easy to overload the populace. Partisan voting seems like a major trap here, if only because choosing a party is easier than voting on each individual issue.

Techno-socialism

By 2020, a mere four years away, millions of people will have lost their jobs to robots, and it’ll only go downhill from there. A few decades out, and half the world’s population will be looking for work in the ever-fewer fields left to living humans. There are some things computers can’t do, but not everybody has the skills necessary for them.

One solution to this looming employment crunch is already being tested in parts of Europe: the universal basic income. It’s nothing more than a monthly stipend, a kind of all-encompassing unemployment/welfare check. Combine this with the possibility of technology ending the “demand economy”, and you have the makings of a true socialist state: a planned government and economy designed to create and uphold a welfare state. Most people would live on the basic income, with their needs met by government-provided facilities, while those who can have jobs are a cut above, but there’s always the chance of moving up in the world.

This one’s big flaw is human nature. We’re greedy, and we don’t really trust other people to know what’s best for us. This kind of techno-socialism doesn’t remove either need or want, but leaves it in the hands of a (hopefully) benevolent government, and it easily falls prey to a pigeonholing “everyone’s the same” mentality. For the “have-nots”, basic income is enough to provide for, well, basic needs, but not much else. The “haves” would be able to get more in the way of amenities, but the high taxes they would have to pay to provide the public services are definitely a turn-off.

AI autocrats

If you believe the AI singularity folks, advanced artificial intelligence isn’t that far away. The day it surpasses human ingenuity might even be within our lifetimes. It’s only natural to put faith in a higher power, and the AIs might become higher powers, relative to us.

There’s two ways this could go: computer-controlled utopia or tyrannical killbots. Those, however, are two sides of the same coin. Either way, its the AI in charge, not us. If artificial intelligence reaches a point where we can no longer understand it, then we won’t know what it’s thinking. At that point, it’s almost like a “direct” theocracy.

We might willingly put ourselves in such a situation, though. How alluring would it be, the idea of handing control to somebody, something else? You don’t have to worry about anything anymore, because The Computer Is Your Friend.

An AI-controlled society all but leads itself to being planned to the point of ruthless efficiency. It might even work out like an extreme version of the techno-socialism above, except that an even smaller fraction of the populace is gainfully employed.

Corporate oligarchy

Corporations already control most governments from behind the scenes. At some point in the future, they might come out of the shadows. If land rights in space are granted to private firms—under the Outer Space Treaty, they can’t be claimed by nations—then we may see a revival of the old “company town” idea. You work for the Company, you live in its houses, you buy its food, and so on. They’re in control, but you can always end up as one of the shareholders, or make your own corporation.

In practice, this form of government isn’t all that exciting. It boils down to a kind of neo-feudalism where the corporations are the lords and their employees are the serfs…with one exception. Corporations try to maximize profits. If they’re allowed to openly run the show, that will be the number one goal for everybody.

This kind of oligarchy can work, especially if you’re one of the higher-ups, but it’s not without its faults. All those people need to be employed somehow, not to mention fed, clothed, educated, and protected. The ideal corporatist system would have all those needs met by private industry, of course, but automation means there’s only so much work left to be done. Still, for a small society, it might work.

Other possibilities

The imagination can run wild here. The only limits are in the mind. But people are going to be people—unless they’re transhumans and cyborgs—and human nature is one of the strongest forces we know. Most importantly, we won’t change overnight. There will be transition periods, no matter what form of government we eventually reach. There’s even the chance that, given some sort of apocalyptic event, we’ll revert to the tried and true methods of the past. A town in the middle of a disaster will, by necessity, be authoritarian, even dictatorial. With years of peace, though, new ideas can find their footing. With time and space, they may even have their moment in the sun.

Historical sports

Birth of a sport

Taking steps

Isian compounds

Changing class

More derivation

That’s not all

Linked lists

More links

Another option

Level of detail

Branches of the tree

How to build a word

What it means

All the rest

Changing class

Changing meaning

Non-English

C++

Haxe

Scala

The field

The true path

And the other side

Other uses

E-zi

Reading emoji

Plain letters

Other symbols

Special groups

Phonetic notation

The big list

Conclusion

Status quo

Direct democracy

Techno-socialism

AI autocrats

Corporate oligarchy

Other possibilities