Month: February 2017

Let’s make a language, part 23c: Food and drink (Ardari)

As with Isian, for the Ardari post I won’t be adding too many culture-specific words. Remember that these two conlangs are supposed to be a base on which to build. We’ll stick to generalities here.

For Ardari fès and fan (food and drink, respectively), the situation is largely the same. The three-meal structure is a little older, however, with indrajat “breakfast” and vòllrajat “lunch” being a bit fluid in their timing, but dèllar “dinner” always coming last.

Women aren’t the only ones to cook (lòsty-) in Ardari society. Men do, too, but only in certain ways. It’s the man’s job, for instance, to cook certain kinds of meat (arba). And either sex can bake (päk-), especially if they’re baking bread (namis päk ky). Frying (taynönda) is usually a woman’s job, though.

Ardari speakers eat more meat than their Isian neighbors, and they like their beverages. In addition to vingo (“wine”, usually imported), they have a drink made from a kind of milk (mechi) that is at least as alcoholic. If you don’t like that, though, you can always opt for simple obla “water”.

Soups and stews (both senses are covered by the general term zow) are common, usually laden with different kinds of èlyat “spice”; the historically recent introduction of New World crops expanded this part of the Ardari chef’s repertoire considerably. Salt (akor) used to be just as important, but modern advances have demoted it to just another type of seasoning.

Word List

General terms
  • beverage/drink: fan
  • dinner: dèllar
  • food: fès
  • meal: rajat
  • oven: gralla
  • to bake: päk-
  • to cook: lòsty-
  • to drink: kabus-
  • to eat: tum-
  • to fry: tayn-
Specific foodstuffs
  • bread: nami
  • cheese: kyèsi
  • flour: plari
  • honey: wychi
  • meat: arba
  • milk: mechi
  • oil: dub
  • salt: akor
  • soup: zow
  • spice: èlyat
  • sugar: susi
  • water: obla
  • wine: vingo

Practical Typescript: dice roller

In the last few “code” posts of Prose Poetry Code, there’s been one thing missing. One very important thing, and you might have noticed it. That’s right: there’s no code! I’ve been writing about generalities and theory and the like for a while now, but I’ve been neglecting the ugly innards. Part of that is because I haven’t been in much of a coding mood these past few months. Writing fiction was more interesting at the time. But I’ve had a few spare hours, and I really do want to get back into coding, so here goes.

A while back, I mentioned Typescript, a neat wrapper that sits on top of JavaScript and generally makes it palatable. And at the end of that post, I said I’d be playing around with the language. So here’s what I’ve got, a practical example of using Typescript. Well, dice rollers aren’t exactly practical—they’re a dime a dozen, and nobody really needs them—but you get the idea.

The code

I’ve posted a full ZIP of the code, including a config file, an HTML skeleton, and the JavaScript output. But here’s the Typescript code (dice.ts) for your perusal.

// Simple function simulating a single die roll
function roll(sides: number): number {
    return 1 + Math.floor(Math.random() * sides);
}

// Our "back-end" will roll a number of simulated dice,
// possibly adding a bonus or subtracting a penalty.
// It will return an object containing the rolls and their total.
// (This is really for no reason other than to show off interfaces.)
interface RollResult {
    rolls: number[],
    total: number
}

// Roll a number of dice, and return the results,
// using the object we defined above.
function rollMany(count: number, sides: number): RollResult {
    let rolls : number[] = [];

    for (let i = 0; i < count; i++) {
        rolls.push(roll(sides));
    }

    let result = {
        rolls: rolls,
        total: rolls.reduce((a: number, b: number) => a+b, 0)
    };

    return result;
}

// This is where the interactive portion of the script begins.
// It's really just basic DOM stuff. In a moment, we'll actually
// hook it all up to the page.
function diceRoller() {
    console.log("Rolling...");

    let countBox = document.getElementById("count") as HTMLInputElement;
    let sidesBox = document.getElementById("sides") as HTMLInputElement;
    let addsBox = document.getElementById("adds") as HTMLInputElement;
    let resultRollsText = document.getElementById("result");
    let resultTotalText = document.getElementById("total");

    let count = +countBox.value;
    let sides = +sidesBox.value;
    let adds = +addsBox.value;

    let result = rollMany(count, sides);
    let totalRoll = result.total + adds;

    resultRollsText.innerHTML = result.rolls.join(" ");
    resultTotalText.innerHTML = ""+ totalRoll;
}

// This clears out our results and options.
function clearAll() {
    console.log("Clearing...");

    // Note that this gives us an HTMLCollection...
    let boxes = document.getElementsByClassName("entry");

    // ...which can't be used like an array in for/of...
    for (let b in boxes) {
        // ...and contains only generic HTMLElements.
        (boxes[b] as HTMLInputElement).value = "";
    }

    let resultText = document.getElementById("result");
    let totalText = document.getElementById("total");
    resultText.innerHTML = "";
    totalText.innerHTML = "";
}

// Here's where we connect our functions to the page.
document.addEventListener("DOMContentLoaded", function () {
    let clearButton = document.getElementById("clear");
    let rollButton = document.getElementById("roll");

    clearButton.onclick = clearAll;
    rollButton.onclick = diceRoller;
});

Honestly, if you’ve seen JavaScript, you should have a pretty good idea of what’s going on here. We start with a helper function, roll, which does the dirty work of generating a number from 1 to N, exactly as if you rolled a die with N sides. (It’s not perfect, as JavaScript uses pseudorandom numbers, but it’s the best we can do.) If you take out the two type declarations, you wouldn’t be able to tell this was Typescript.

Next comes something that inarguably identifies our source as not normal JS: an interface. We don’t really need it for something this simple, but it doesn’t cost anything, and it’s a good check on our typing. Our RollResult interface simply defines an object “layout” that we’ll pass from our back-end rolling function to the front-end output. If we screw up, the compiler lets us know—that’s the whole point of strong typing.

After this is the rollMany function. It builds on the simple roll, calling it multiple times and storing each result in an array. This array, along with the sum of its contents, will become the returned object, matching our interface.

We’ll skip over the diceRoller function briefly, as it’s the grand finale of our little app, and I wanted to save it for last. Instead, we move to clearAll. It would be an unremarkable DOM manipulation function, if not for two quirks in Typescript. First, our simple HTML page defines a few entry boxes: one for the number of dice to roll, one for how many sides each die has, and one for a flat bonus or penalty to add to the total. These are <input> text elements, and they all have a CSS class of entry. Iterating over them (and only them) should be a piece of cake, right?

Not quite. See, the obvious way to do this, document.getElementsByClassName, returns an HTMLCollection, which isn’t quite the same thing as a JavaScript array. And Typescript, unless you tell it to spit out the latest and greatest ECMAScript standard (and I haven’t), won’t let you use the easier for..of loop. Instead, you have to use for..in, which iterates over the keys of a collection—for arrays, these are the indexes.

And that brings us to our second problem. See, our DOM collection is full of HTMLElements. These could be anything at all, and are thus usable as essentially nothing. In particular, we can’t change the value property that all input textboxes have, because not every HTML element has them. As any Java or C# programmer knows, we need an explicit cast into the more specific type of HTMLInputElement. That seems like needless drudgery, but it pays off in more complex applications, and we could always use jQuery or something instead. In a “real” setting, we probably would be.

The areas where we output our rolls and their total are simple divs. We don’t have to do any casting with them; we can just clear their innerHTML properties. And the last bit is not much more than your usual “let’s set up some event handlers” block.

That leaves diceRoller. First up are a few variables to hold the DOM elements: 3 text boxes and 2 output areas. Again, we have to do a cast on anything that’s an input element, but that should be old hat by now.

Following that, we make a few variables that hold our input values in number form. I used the idiomatic “unary plus” conversion from string to number here.

Next comes result, which holds (naturally) our resulting roll. I threw in a totalRoll variable to hold the total (including the “adds” roll bonus/penalty), but you don’t really need it; you can calculate that as you’re putting it into the output field. Speaking of which, that’s where we end: joining the result array into a space-separated string (you could use commas or whatever), then putting that and the total into their proper places.

Conclusion

So Typescript isn’t that hard. Counting comments and blank lines, this little thing weighs in at about 80 lines. The resulting JavaScript is less than 50. The difference comes from the strong typing, an interface definition that is purely for the benefit of the Typescript compiler and the programmer, and a few other odds and ends that contribute nothing physical to the finished product.

It may seem silly. We’re writing more code, locking ourselves into the type system, and we’re not really getting much out of it. Sure, we’ve got protection from typos. If I’d misspelled the name of one of the RollResult fields, I’d get an error telling me where I went wrong, but that’s about it.

For something this simple, even that’s enough. I get that error when compiling. I don’t end up with a blank screen or unresponsive page and no indication as to why. JavaScript’s dynamic nature is great, but it’s also terrible. In coding, unlike in real life, there’s such a thing as too much freedom.

Now, if you like, feel free to take this tiny app and improve on it. The HTML, for instance, expects a stylesheet; you could make one. Add in some bells and whistles. Throw up a few preset buttons. Store the last 100 rolls in DOM local storage. Most of all, have fun with it.

On fantasy stasis

In fantasy literature, the medieval era is the most common setting. Sure, you get the “flintlock fantasy” that moves things forward a bit, and then there’s the whole subgenre of urban fantasy, but most of the popular works of the past century center on the High Middle Ages.

It’s not hard to see why. That era has a lot going for it. It’s so far back that it’s well beyond living memory, so there’s nobody who can say, “It’s not really like that!” Records are spotty enough that there’s a lot of room for “hidden” discoveries and alternate histories. You get all the knights and chivalry and nobility as a builtin part of the setting, but you don’t have to worry about gunpowder weapons if you don’t want to, or oceanic exploration, or some of the more complex scientific matters discovered in the Renaissance.

For a fantasy world, of course, medieval times give you mostly the same advantages, but also a few more. It’s less you have to do, obviously, as you don’t have the explosion of technology and discovery starting circa 1500. Medieval times were simpler, in a way, and simple makes worldbuilding easy. Magic fits neatly in the gaps of medieval knowledge. The world map can have the blank spaces needed to hide a dragon or a wizard’s lair.

Times are (not) changing

But this presents a problem, because another thing fantasy authors really, really want is a long history, yet they don’t want the usual pattern of advancement that comes with those long ages. Just to take examples from some of my personal favorites, let’s see what we’ve got.

  • A Song of Ice and Fire, by George R. R. Martin. You’ll probably know this better as Game of Thrones, the TV show, but the books go into far greater depth concerning the world history. The Others (White Walkers, in the show, for reasons I’ve never clearly understood) last came around some 8,000 years ago. About the only thing that’s changed since is the introduction of iron weaponry.

  • Lord of the Rings; J.R.R. Tolkien. Everybody knows this one, but how many know Middle Earth’s “internal” history? The Third Age lasts over 3,000 years with no notable technological progress, and that’s on top of the 3,500 years of the Second Age and a First Age (from The Silmarillion) that tacks on another 600 or so. Indeed, most technology in Middle Earth comes from the great enemies, Sauron and Morgoth and Saruman. That’s certainly no coincidence.

  • Mistborn; Brandon Sanderson. Here’s a case where technology actually regressed over the course of 1,000 years. The tyrannical Lord Ruler suppressed the knowledge of gunpowder (he preferred his ranged fighters to have skill) and turned society from seemingly generic fantasy feudalism into a brutal serfdom. (The newer trilogy, interestingly, upends this trope entirely; the world has gone from essentially zero—because of events at the end of Book 3—to Victorian Era in something like 500 years.)

  • Malazan Book of the Fallen; Steven Erikson. This series already has more timeline errors than I can count, so many that fans have turned the whole thing into a meme, and even the author himself lampooned it in the story. But Erikson takes the “fantasy stasis” to a whole new level. The “old” races are over 100,000 years old, there was an ice age somewhere in there, and the best anyone’s done is oceangoing ships and magical explosives, both within the last century or so.

Back in time

It’s a conundrum. Let’s look at our own Western history to see why. A thousand years ago was the Middle Ages, the time when your average fantasy takes place. It’s the time of William the Conqueror, of the Holy Roman Empire and the Crusades and, later, the Black Death. Cathedrals were being built, the first universities founded, and so on. But it was nothing like today. It was truly a whole different world.

Add another thousand years, and you’re in Roman times. You’ve got Caesar, Pliny the Elder, Vesuvius, Jesus. Here, you’re in a world of antiquity, but you have to remember that it’s not really any further back from medieval times than they are from us. If we in 2017 are at the destruction of the One Ring, the founding of the Shire was not long after all this, about at the fall of the Roman Empire.

Another millennium takes you to ancient Greece, to the Bronze Age. That’s “Bronze Age” as in “ironworking hasn’t been invented yet”, by the way. Well, it had been, but it was only used in limited circumstances. Three thousand years ago is about the time of the later Old Testament or Homer. Compared to us, it’s totally unrecognizable, but it’s about the same length of time between the first time the One Ring was worn by someone other than Sauron and the moment Frodo and Sam walked up to Mount Doom.

Let’s try 8,000, like in Westeros. Where does that put us in Earth history? Well, it would be 6000 BC, so before Egypt, Sumeria, Babylon, the Minoans…even the Chinese. The biggest city in the world might have a few thousand people in it—Jericho and Çatalhöyük are about that old. Domestication of animals and plants is still in its infancy at this point in time; you’re closer to the first crops than to the first computers. Bran the Builder would have to have magic to make the Wall. The technology sure wasn’t there yet.

Breaking the ice

And that’s really the problem with so many of these great epic fantasy sagas. Yes, we get to see the grand sweep of history in the background, but it’s only grand because it’s been stretched. In the real world, centuries of stasis simply don’t exist in the eras of these stories. Even the Dark Ages saw substantial progress in some areas, and that’s not counting the massive advancement happening in, say, the Islamic world.

To have this stasis and make it work (assuming it’s not just ancient tales recast in modern terms) requires something supernatural, something beyond what we know. That can be magic or otherworldly beings or even a “caretaker” ruler, but it has to be something. Left to their own devices, people will invent their way out of the Fantasy Dark Age.

Maybe magic replaces technology. That’s an interesting thought, and one that fits in with some of my other writings here. It’s certainly plausible that a high level of magical talent could retard technological development. Magic is often described as far easier than invention, and far more practical now.

Supernatural beings can also put a damper on tech levels, but they may also have the opposite effect. If the mighty dragon kills everything that comes within 100 yards, then a gun that can shoot straight at twice that would be invaluable. Frodo’s quest would have been a piece of cake if he’d had even a World War I airplane, and you don’t even have to bring the Eagles into that one! Again, people are smart. They’ll figure these things out, given enough time. Thousands of years is definitely enough time.

Call this a rant if you like. Maybe that’s what it really is. Now, I’m not saying I hate stories that assume hundreds or thousands of years of stagnation. I don’t; some of my favorite books hinge on that very assumption. But worldbuilding can do better. That’s what I’m after. If that means I’ll never write a true work of epic fantasy, then so be it. There’s plenty of wonder out there.

Let’s make a language, part 23b: Food and drink (Isian)

There aren’t too many new words this time around, but that’s because (as I said in the intro post for this part) many “meal” terms are largely untranslatable. In addition, a lot of foods simply use the terms for the plant or animal they are derived from, so choch “chicken” can refer to both the bird and its meat, and an Isian speaker can eat puri “apples” just as easily (grammatically speaking) as he can grow them.

So let’s take a look at a few words that are specific to the preparation and consumption of food and drink. First, we’ll start with the basic terms for those two concepts: tema and jasan. Isian speakers used to only have two basic meals (aydis) during a day, but modern times have imported the three-meals-a-day standard. Two or three, the most important is dele, “dinner”, meant to be eaten with one’s family after a long day.

It’s usually the Isian woman who cooks (piri). Some men do, but this is the exception rather than the rule. One popular type of cooking is baking (atri, “to bake”), in which food is placed into an oven (otal). There are, of course, other methods, however.

As with many societies, the most important ingredient for most foods is flour, or cha, which is most often used to make pinda, a kind of bread. Dinner usually includes a kind of meat (shek) somewhere, sometimes in a dab “soup”, and often prepared with hac “salt” and various jagir “spices”; the old days, when seasonings were restricted to the wealthy, are long gone.

Dairy products are common, with mel “milk” often being turned into such products as kem “cheese”. For sweetening, Isian speakers have sugar (sije), but some recipes instead call for simya “honey”. As for drinks, water (shos) is the simplest, but many adults are not opposed to a glass of uni “wine”.

Word list

General terms
  • beverage/drink: jasan
  • dinner: dele
  • food: tema
  • meal: aydi(s)
  • oven: otal
  • to bake: atri
  • to cook: piri
  • to drink: jesa
  • to eat: hama
Generic foodstuffs
  • bread: pinda(r)
  • cheese: kem
  • flour: cha
  • honey: simya
  • meat: shek
  • milk: mel
  • oil: gul
  • salt: hac
  • soup: dab
  • spice: jagi(r)
  • sugar: sije
  • water: shos
  • wine: uni

Magic and tech: food and drink

The need to eat is one of our most basic survival instincts. Every living thing has to do it, and humans have, as in so many other areas, taken the processes of collecting, preparing, and eating food to a level unseen anywhere else on Earth. Many inventions have come about solely for the purpose of making our food better. Sometimes, better means more nutritious. Much more often in history, however, better food is simply food that lasts longer.

And don’t forget about drinks. There’s not an animal alive that doesn’t enjoy a drink of water, but humanity has taken water and flavored it in myriad ways to create beverages. And we use more than just water as a base for our drinks: orange juice is one of the most popular “natural” drinks around, and all we have to do is extract it.

In the world

The history of food is tied to the history of mankind. Cooking seems to have emerged about 10,000 years ago, right around the same time as so many other parts of the Neolithic Revolution, like pottery and plant domestication; before this, we have some evidence of open fires and cooking pits, but not cooking vessels. An announcement in December 2016 (the very week I wrote this post, in fact) details a pottery find in the Sahara that shows biological markers of cooked plant matter dating back about this far. The timing can’t be a coincidence: the first domesticated cereal grains, the oldest ceramics, and a technique that just happens to use both of them? If anything, that sounds like cause and effect to me. Not sure which one’s the cause, though.

Anyway, preparing food has a long history. So does producing it, whether through growing crops or raising stock. Domestication of animals for food took a bit longer than plants (animals are a bit more willful, you see), but it happened. Some would say we’re doing too well at that these days—the free-range movement is all about lowering food production, because the techniques we’ve developed to get the extreme yields lead to extreme suffering on the animals’ part.

Cooking was, for most of human history, something you did over a fire. You could build a box to contain the fire (an oven), put a slab on top of it (a stove or griddle), stick a pot full of water over it to boil (a cooking pot), but it was still a fire. It’s only very recently that we got rid of that, with our gas and electric ovens, our microwaves, and our coffee makers. Yet we go back to the fire even now, when we’re camping or roasting marshmallows, or when the chef breaks out the blowtorch. And gas stoves still use flames, so a lot of Americans retain that millennia-old connection to their Stone Age ancestors.

If there’s anything we have undeniably improved on in the modern era, it’s food preservation. As little as 200 years ago, that was largely limited to salting, pickling, and similar curing processes. In colder climates, you could freeze food through the winter by stuffing it in the snow; everywhere else could get a mild cooling—but not freezing—effect by digging a deep enough hole, which works well for, say, wine. But much food was eaten fresh, or near enough to it. What wasn’t usually came out in some other form: pickles, jams, etc.

Today, by contrast, preserved foods are the norm. We’ve got refrigerators, freezers, canning, vacuum-sealed plastic packaging, and an array of foods specifically designed for a long shelf life. (That’s something else olden days didn’t have. Food sitting on a shelf was food gone to waste.) We have “instant” mixes that, while they may not taste like the real deal, are close enough for people on a budget in time and money. I eat frozen dinners all the time, and they’re basically the same thing. And even when we do use older techniques, we combine them with the new, putting our pickles in the fridge.

Finally, our modern world has given us another benefit in terms of our diet. As we’ve become more connected, as the apparent distances between us have shrunk, we have expanded our palates. Any decent-sized American city will have not only American food, but Italian, Mexican, Japanese, Chinese, and many more. India and Thailand are about as far from the east coast as you can get while still on the same planet, yet immigration and modern food production have combined to let us sample their cuisines from thousands of miles away.

Now with magic

In the general timeframe of the Middle Ages, they didn’t have all that. Sure, there was a booming trade in spices, as there has always been. A few exotic foods made their way to distant locales, though rarely in fresh form. And the European climate in most places was so different from their nearest “exotic” trading partners, the Muslims of the Middle East and North Africa, that many of the food plants simply wouldn’t grow.

Magic, as we’ve provided for our magical realm, won’t change that too much. The distances will still be great, and magical transportation won’t move that much faster than sea travel, once you take into account the often winding roads, the customs checkpoints, the weather, and so on. Grain can keep for a long time, and so can a lot of other food items, but the “goes bad quickly” set won’t shrink very much, because the timing isn’t right. Thus, this part of the exercise won’t be that different from what the real world gives us.

Producing food, however, will get a big boost from magic. Indeed, there’s almost no reason why that won’t be one of the first areas of interest our mages work on. Higher crop yields, protection against crop failure, larger stock, more eggs…these all help everybody in an agrarian society. If the mages don’t focus somewhat on improving agriculture, what good are they? (Even combat-oriented RPGs get this one right. D&D 4th Edition has Bloom as a 2nd-level ritual. Pathfinder’s Plant Growth can be cast at level 5, and it only takes 6 seconds. And that’s not counting the direct “Create Food” stuff.)

So we can assume our magical kingdom will have more food produced. Next up comes harvesting it, often a labor-intensive task. Again, we’ve seen how magic can reduce the labor needed by creating industrial-like machines. All that’s stopping the mages from moving into farm machines is imagination. They may not be to magic-powered combines and tractors yet, but those aren’t too far into the future.

Even a marginal mastery of heat and cold—one we’ve already said this realm has—opens up a lot of avenues for research into refrigeration and cooking. Everything from starting fires to chilling wine gets a boost, along with too many other things to name. Remember that cooking in pre-modern times is mostly about fire. Make that fire easier to work with, and the improvements naturally follow from there. The other processes of cooking, such as chopping, don’t benefit as much, but control over temperature more than makes up for that.

Last, let’s take a look at drinks. Most of those won’t be too modern, as our sodas and imitation fruit juices and “lite” beer take a lot of chemistry and machinery that is out of their league. But cold drinks will be more common, even in summer, and this magical kingdom may learn the joys of iced beverages far sooner than ours did. Fruit juices, easier to extract thanks to magical machines, will likely become popular. Distillation will allow for stronger alcoholic drinks. And then we come back to plain old water. With magic, purification gets a boost (it’s about the same as with alcohol, actually), so clean drinking water isn’t a problem, even in cities.

We’ll leave it on that note, but keep that last idea in mind, because that’s where the next post will go: into the magical cities.

Let’s make a language, part 23a: Food and drink (Intro)

Food. It’s wonderful, it’s delicious, it’s nutritious. We need it to survive, but we have turned that necessity into one of the great simple pleasures of life. And let’s not forget about drinks, either. Without applying our knowledge of foods to the beverage side of things, we’d essentially be limited to drinking water and fruit juice.

In language, terms relating to food and drink can make up a large portion of a lexicon. There are just so many ways of creating a meal, so many ingredients you can use. The sheer size of this linguistic smorgasbord can be enormous. So let’s break it down into a few subtopics.

Preparation

One of the hallmarks of humanity is cooking. How many other animals go to the trouble of preparing food over a fire, or in a sealed box, or in boiling water? And cooking is an ancient practice, one shared by essentially every culture on Earth. We might do things a lot differently from our Neolithic ancestors, but they’d understand our reasons.

But there’s more than one way to cook. Think about all the different implements in your kitchen, and how each one serves a different purpose. We can bake, boil, roast, or fry our food, for instance. Fancier meals can be sautéed, modern ones microwaved. If you’re cooking Chinese, you might stir fry (a compound phrase). A Southerner like myself may instead want something barbecued. And the list goes on.

That’s just for the cooking part itself. Before that, we often perform a number of preparatory steps, and these can also fall under the umbrella of food-related vocabulary. A meal might call for diced tomatoes or chopped onions, for example. Sometimes, we’ll have to tenderize meat or slice some vegetables. Later on, we may need to stir. Many of these words are plainly derived—diced pieces of a food look like dice, naturally—but some can be native.

Let’s not forget the tools we use to cook, either. We’ve got the oven for baking, the stove for a lot of other jobs. Modern American homes are equipped with a microwave oven (usually shortened to microwave, which also functions as a verb, as we saw above). The cabinets will be full of pots and pans, as well as spoons, knives, and the like. Also, we’ve already seen things like cups and bowls that are needed by any would-be chef.

Preparing, like anything else to do with food, is culture-specific, but the basics are fairly general. Still, that hasn’t stopped a number of loanwords entering English, and the same would be true for any other language that comes into contact with a new way of making food. We’ve got, for example, the wok, used in Asian cuisine. There wasn’t a good word to describe the process of sauteing, so we borrowed the one the French used when they taught it to us. As we’ve seen so often, borrowings will be for those things the native language doesn’t already have words for, especially those concepts that aren’t really native.

Ingredients

Human nutritional needs have forced upon us the broad outline of a diet. We all need protein, carbohydrates, a set of vitamins and minerals, and at least some fat (not too much, though). Conveniently enough, in every location where civilization developed, the local flora and fauna offered some way of getting everything we require. For example, the Americas don’t have native wheat—it first grew in western Asia—but corn is a decent substitute, nutritionally speaking. Well, except that it doesn’t provide some essential vitamins. But never fear: beans do, and they grow in practically the same place! The same is true around the world.

Which plants and animals a culture eats will be very dependent on where—and when—that culture lives. In modern or future times, there will be a greater variety of food on the table. Pre-industrial cultures, by contrast, will have a more restricted set of “native” foodstuffs. In general, you can follow the guidelines in parts 19 and 20 for this.

Of course, there’s more to it than that. We eat a lot of different things, and most of them, even in ancient times, came from somewhere else. The most famous of these would have to be the spices. For millennia, these have been some of the most sought-after substances in the world, fueling wars, imperialism, colonialism, trade, exploration, and so much more. Had cloves and cinnamon and cardamom been native to France, Italy, and Britain, the world today would be a very different place. And many of the words we use for these spices are borrowed, often through a chain of languages that might include any of French, Latin, Greek, Arabic, Sanskrit, Malay, Chinese, and many more. On a more mundane note, simple salt is a necessary ingredient for our lives, and it’s far more likely to have a native name.

Mealtime

When do your speakers eat? We’re used to three meals a day nowadays, but that’s far from an absolute. And even when it is the case, that doesn’t necessarily mean it’ll always be breakfast in the morning, lunch around noon, and an evening dinner or supper. (What about second breakfast? Elevenses? Afternoon tea?) Now, that doesn’t mean you can’t gloss your conlang’s meal names into our three, but here’s a place to add in those subtle connotations. As an example of my own: one of my conlangs, Virisai, is spoken by a culture that values lunch as the most important social meal of the day, using it as a break from work, a time to converse with one’s friends, and so on. For them, breakfast is more perfunctory, just enough to wake you up, and dinner is strictly for family.

Whatever you do here, you can work on as many little details as you like. Maybe your speakers have words for different spoons. Perhaps a knife for cutting meat is named differently from the one that cuts pies. Or there could be a different set of meals for some days—or times when there are no meals at all, as with Islam’s Ramadan. Anything like this could have a native word or phrase to describe it.

Drinks

Water, of course, is the most basic drink. Everything else, technically speaking, would be a beverage, and they’re quite specific to a culture. Still, we can draw a number of conclusions by looking around the world. Juice is popular, for instance, though the fruits used are local or regional. Tea and coffee are drinks of choice for billions of people today; your speakers might imbibe them, or have something of the same sort. (Another example of mine: the speakers of my Virisai conlang, being descended from Native Americans, have neither of these, but they have a caffeinated herbal drink made from a native plant.)

Alcohol itself isn’t a drink (unless you’re crazy enough to drink Everclear), but beverages including it have been made for thousands of years, in just about every corner of the world. We’re all familiar with beer (and some of us even know the difference between ales, lagers, stouts, etc.), and any culture you can name will have its own brew, with its main ingredient probably one of the local grains. Grapes are the most common providers of wine, another popular drink throughout history. Fermentation can create other concoctions than these, like the fermented milk of Mongolia. (And where there’s alcohol, there’s sure to be drunkenness and a backlash against the stuff, but that’s for another post.)

Most stronger stuff (usually all described as liquor by laymen) came about later, as distillation became a thing. Here again we see cultural varieties springing up. The Irish have their whisky/whiskey, the Russians their vodka. Scotch, brandy, cognac, moonshine…the list could go on forever. But it’s a sure bet that almost all the words on that list will be loans, except those for the local creations.

Next time

The world of food and drink can keep you occupied for a long time, whether you’re exploring it in word or in physical form. (I’m writing this the day after Christmas, so it’s the latter for me right now.) It’s a great place to delve into the culture behind your conlang, though. And not only that culture. Loanwords and coinages abound in our dietary vocabulary. Even the most American American won’t balk at eating pizza (an Italian word) or a hamburger (literally someone from Hamburg, Germany). We may have more loans than most, thanks to immigration, but I doubt you’ll find, say, a Brit who’s never heard of curry.

Once you’ve cleaned your plate, so to speak, it’s time to move on. After a meal is a good time for reflection, so our next topic will be the mind. We’ll look at our inner thought processes, and we’ll see how language attempts to describe them. For now, it’s time to go. All this talk about food has made me hungry.

Exoplanets for builders

In just over two decades, we’ve gone from knowing about nine planets (shut up, Pluto haters) to recognizing the existence of thousands of them. Almost all of those are completely unsuitable for life as we know it, but researchers say it’s only a matter of time before we find “Earth 2.0”. Like any other 2.0 version, I’m sure that one will have fewer features and be harder to use, but never mind that.

As so many science fiction writers like to add in a large helping of verisimilitude, I thought I’d write a post summarizing what we know about planets outside our solar system, or exoplanets, as we enter 2017. Keep in mind that there’s a lot even I don’t know, although I’ve been following the field as a lay observer since 2000. Nonetheless, I hope there’s enough in here to stimulate your imagination. Also, this will necessarily be a technical post, so fantasy authors beware.

What we know

We know planets exist beyond our solar system. They’ve been detected by the way they pull on their stars as they orbit (the Doppler or radial velocity method), and that’s how we found most of the early ones. The majority of those known today, thanks to the Kepler mission, have been discovered by searching for the change in their stars’ light intensity as the planets pass before them: the transit method. In addition, we have a few examples of microlensing, where the gravity of a planet bends the light of a “background” star ever so slightly. And we’ve got a handful of cases where we’ve directly imaged the planets themselves, though these tend to be very, very large planets, many times the size of Jupiter.

However we see them, we’re sure they’re out there. They can’t all be false positives. And thanks to Kepler, we’ve got enough data to start drawing some conclusions. Of course, these must be considered subject to change, but that’s the way of science.

First, our solar system, with its G-type star orbited by anywhere from eight to twenty planets (depending on who’s counting) starting at about 0.3 AU, looks very much like an outlier. We don’t have a “hot Jupiter”, a gas giant exceedingly close to the star, with an orbit on the order of days. Nor do we have a “warm Neptune” (a mid-range gaseous planet somewhere in the inner system) or a “super-Earth” (a larger terrestrial world, possibly with a thick atmosphere). This doesn’t mean we’re unique, though, only that we can’t assume our situation is the norm.

Second, we’ve got a pretty good idea about which stars have planets. To a first approximation, that’s all of them, but the reality is a little more nuanced. Bright giants don’t have time to form planets. Small red dwarfs don’t have the material to create Jupiter-size giants. Neither of these statements is an absolute—we’ve got examples of gas giants around M-class stars—but they’re tendencies. Everything else, seemingly, is up in the air.

What we can guess

Planets do appear to be everywhere we look. There are more of them around M stars, but that’s largely because there are so many more M stars to begin with. A lot of stars have planets with much closer orbits, so close that you wouldn’t expect them to form. Gas giants aren’t restricted to the outer system, like they are here. And there’s a whole class, the super-Earths, that we never knew existed.

We can make some educated guesses about some of these planets. For example, many of the super-Earths, according to computer simulations, may actually be tiny versions of Neptune, so-called “gas dwarfs”. If that’s true, it severely cuts our number of potentially habitable worlds. On the other hand, the definition of the habitable zone has only expanded since we started finding exoplanets. (Even in our own solar system, what once was merely Earth and maybe the Martian underground now includes Europe, Titan, Enceladus, Ganymede, Ceres, the cloud tops of Venus, and about a dozen more exotic locales.) Likewise, studies suggest that a tide-locked planet around a red dwarf star doesn’t have to be frozen on one side and scorched on the other.

We’ve got a few points where we don’t even have data, though. One of these, possibly the most important for a writer, is the frequency of Earthlike worlds. By “Earthlike”, I don’t simply mean terrestrial, but terrestrial and capable of having liquid water on the surface. Where’s the closest one of those? Until about a year ago, the answer might have been anywhere from 15 to 500 light-years away. But then came Proxima b. If it turns out to be potentially habitable—in the month and a half between my writing this post and it going up, we may very well know—then that almost ensures that Earthlike worlds are everywhere. Because what are the chances that the next-closest star to the Sun has one, too?

Creating a planet

For the speculative writer, this lack of knowledge is a boon. We have the freedom to create, and there are few definite boundaries. Want to put a gas giant in the center of a star’s habitable zone, with multiple Earthlike moons? We can’t prove it’s impossible, and the real-life counterpart might really be out there, waiting to be found.

Basically, here’s a rundown of some of the factors that go into creating an exoplanet:

  • Star size: Bigger stars are shorter-lived, but smaller ones require their “classically” habitable planets to be much closer, to the point where they’ll likely be tide-locked. G-type dwarfs like ours are a happy medium, but not a common one: something like 1% of stars are in the G class, and there’s not much data saying that planets are more likely around them.

  • Star number: Most stars, it seems, are in multiple systems. Binaries can host planets, though; we’ve detected a class of “Tatooine” planets (named after the one in Star Wars, because scientists are nerds) circling binary systems. For close binaries, this is a fairly stable arrangement, but with huge complexities in working out parameters like temperature. Distant binaries like Alpha Centauri can instead have individual planetary systems.

  • Planet size: We used to think there was a sharp cutoff between terrestrial and gaseous planets, based on the difference between the largest terrestrial we knew (Earth) and the smallest gas planets (Uranus and Neptune). Now we know that’s simply not true. It’s more of a continuum, and there may be super-Earths much larger than the smallest mini-Neptunes. And those gas dwarfs appear to be the most common type of planet, but that could be nothing more than observation bias, the way we thought hot Jupiters were incredibly common ten years ago. On the smaller end of the scale, we haven’t found much, but there’s no reason to expect that exoplanet analogues of Mars, Mercury, Pluto, and Ganymede don’t exist.

  • Surface temperature: This is a big one, as it’s critical for life as we know it. We know that liquid water exists between 0° and 100°C (32–212°F), with the upper bound being a bit fluid due to atmospheric pressure. That 100 (or 180) degrees is a lot of room to play with, but remember that it’s not all available. DNA, for example, can break down above about 50°C. Below freezing, of course, you get into subsurface oceans, which might be fun for exploration purposes.

  • Atmosphere: Except for a couple of gas giants, we’ve got nothing here. We have no idea if the nitrogen-oxygen mix of Earth is common, or if most planets we find would be CO2 pressure cookers like Venus. Or they could retain their primordial hydrogen-helium atmospheres, or be nearly airless like Mars. Something tells me that we’ll find all of those soon enough.

  • Life: And so we come to this. Life, we know, changes a planet, just as the planet changes it. A biosphere will be detectable, even from the distance of light-years. It will get noticed, once telescopes and instruments are sensitive enough to see it. And it will stand out. Some chemicals just don’t show up without life, or at least not in the quantities that it brings. Methane, O2, and a few others are considered likely biotic markers. The million-dollar question is just how likely life really is. Is it everywhere? Are there aliens on Proxima b right now? If so, are they single-celled, or possibly advanced enough to be looking back at us? Here is the writers’ playground.

What’s to come

Assuming the status quo—never a safe assumption—our capability for detecting and classifying exoplanets is only expected to increase in the coming years. But I’ve heard that one before. Once upon a time, the timeline looked like this: Kepler in 2004 or 2005, the Space Interferometry Mission (SIM) in 2009, and the Terrestrial Planet Finder (TPF) in 2012. In reality, we got Kepler in 2009 (it’s now busted and on a secondary mission). TPF was “indefinitely deferred”, and SIM was left to languish before being mercy-killed some years ago. The Europeans did no better; their Darwin mission suffered the same let’s-not-call-it-cancelled fate as TPF. Now, both missions might get launched in the 2030s…but they probably won’t.

On the bright side, we’ve got a small crop of upcoming developments. TESS (Transiting Exoplanet Sky Survey, I think) is slated to launch this year—I’ll believe it when I see it. The James Webb Space Telescope, the Hubble’s less-capable brother, might go up in 2018, but its schedule is going to be too crowded to allow it to do more than confirm detections made by other means.

Ground-based telescopes are about at their limit, but that hasn’t stopped us from trying. The E-ELT is expected to start operations in 2024, the Giant Magellan Telescope in 2025, and these are exoplanet-capable. The Thirty Meter Telescope was supposed to join them in about the same timeframe, but politically motivated protests stopped that plan, and the world is poorer for it.

Instead of focusing on the doom and gloom, though, let’s look on the bright side. Even with all the problems exoplanet research has faced, it’s made wonderful progress. When I was born, we didn’t know for sure if there were any planets outside our own solar system. Now, we’re finding them everywhere we look. They may not be the ones science fiction has trained us to imagine, but truth is always stranger than fiction. Forget about “Earth 2”. In a few years, we might have more Earths than we know what to do with. And wouldn’t that make a good story?

First glance: Scala.js

I’ve learned and used a lot of different programming languages. If I had to pick one to take as the moneymaker, it’d probably be JavaScript right now. But JavaScript is pretty awful. It wouldn’t be my first choice if money was no object. That would likely be C++, but there’s one other contender, one language I liked from the first time I saw it. That language is Scala.

Scala has its problems, of course. It’s closely tied to the Java ecosystem, which…isn’t the greatest. Sure, it’s got a huge selection of libraries and frameworks for whatever you want to do, but the Java language itself is atrocious, the JVM has a well-deserved reputation for bloat, and it’s practically banned on the desktop. (And you run the risk of getting sued if you use it on mobile, as Google discovered.) So Scala isn’t exactly a popular option, for very good reason.

But it doesn’t have to be that way. Plenty of languages have been turned into tools for web development by the clever trick of compiling them into JavaScript. For Scala, that would be the job of Scala.js. It’s a relative newcomer (version 0.6.14 at the time of this writing), but it’s already looking good.

What is it?

Scala.js is, simply enough, a tool for turning Scala code into JavaScript. In that, it’s not much different from “transpilers” like TypeScript or Babel. Only the source language isn’t something vaguely reminiscent of the JS it will become. No, you write in Scala, so you have all the expressive power of that language.

I like Scala. It’s one of the few languages I’ve seen that accomplishes the feat of getting me interested in functional-style programming. I absolutely hate the “pure functional” approach of, e.g., Haskell, where you can’t actually do anything, because all those nasty “impurities” like, say, I/O, are restricted, and variables can’t, you know, vary. (Yeah, you can use monads, but they’re limited in how they interact with the rest of your code. That’s kinda the point.) Scala, instead, makes FP style encouraged, but not required. That’s much better.

On top of that, Scala is just a better Java than Java. It’s got most of what Gosling took out as “too hard”, like operator overloading. It’s got pattern matching. Lambdas exist, and they’re easy to write. Scala is what Java programmers wish they could use. Putting it in the browser? Sure.

The good

So we’ve got a better language, and that’s where most of the good comes from. Like what, you may ask? How about strong typing? Sure, you can get that in TypeScript, but Scala uses it to its full extent. The functional style is front and center, and it’s not hidden behind bad syntax like in JS. OOP is class-based, not prototype-based, and you don’t have to worry about browser compatibility. And then there are a lot of things Scala has that just aren’t feasible in JS, like case classes and traits.

Outside of the language proper, you’ve got a good HTML templating system, Scalatags, that has full type safety. And it’s not an addon, not in the JS sense. No, you’re working with something that’s based on Java, remember? You’ve got Java-derived build tools and libraries.

I could go on, but the main advantages of Scala.js come from the simple fact that you’re using Scala in place of JavaScript. Everything else great about it follows naturally from that. If you like Scala, that should be enough to give it a shot. If you hate JavaScript, same deal.

The bad

But it’s not all good. That same Java heritage is the greatest weakness of Scala.js. You’re using Java tools, a Java-based API, JVM-centric constructs. Not a fan of Java? Tough. You really can’t get away from it with Scala. (Really, though, this isn’t that much different from that thing Google did a few years ago. JWT? I can’t remember, and I’m too lazy to look it up.)

A worse shortcoming is the number of limitations Scala.js has on what Scala code you can use. Mostly, this makes sense—you can’t use parallel programming in the inherently single-threaded environment of the browser. You also can’t use any Java libraries; your code, and all the code you import, has to be pure Scala, with a very few exceptions. And then there are a few nits to pick, cases where the developers of Scala.js couldn’t figure out a way to make the construct work in JS. Reflection is one of these: you can’t use it at all, and you can’t use anything that uses it. Macros (the recommended replacement) are a poor substitute for reflection, just as templates are in C++.

Lastly, you’ve got the build environment. If you’ve used any sort of JavaScript tools made this decade, you’re probably familiar with Node, Grunt, Gulp, and the like. Scala.js inherits Scala’s sbt, which is yet another thing to learn. And IDEs don’t seem to like it very much; I’ve never managed to get an sbt-based project talking to an IDE, and Eclipse, Netbeans, and IDEA all laughed at my attempts to use sbt for their projects. Since Scala, like Java, really wants an IDE, this can be a problem. (Maybe they’ve fixed things since then, though.)

The verdict

Although the “bad” section outweighs the “good” in quantity, don’t let that make you think I don’t like Scala.js. I like the idea of it. I can even like the implementation. File sizes are a bit on the hefty side, but they’re working on that. Some of the API limitations can be changed. The thing’s still in beta, remember.

On the whole, if you can live with the restrictions it places on you, Scala.js looks to be a very interesting way of creating web apps without writing raw JavaScript. I know I’m keeping an eye on it.