Month: January 2018

Release: The Code Breaker (A Bridge Between Worlds 1)

The cycle begins anew…but not really. The Return to the Otherworld won’t come around until 2019 (coincidentally enough, the year in which the original Chronicles of the Otherworld takes place). Until then, you’ll be getting 6 shorter novellas I’ve entitled A Bridge Between Worlds. As the name suggests, they bridge the nine-month gap between Long Road’s End and the next story in the “main” Otherworld sequence, The Second Crossing.

First up is “The Code Breaker”:

Lee never regretted his decision to stay in the other world. He knew it would be hard, but he believed his hard work would be rewarded. Nimiesa left everything she knew behind, and now she waits for the day when she enters a new world of her own: the world of motherhood. Together, they are the first to bridge the stars, but leaving their past behind is harder than it seems.

Once again, the Otherworld series is, for the time being, a Patreon exclusive, and you can get access to it for a pledge of only \$3/month. On top of that, you’ll get the complete first season of the series, as well as many other novels and short stories.

Next up is “The Red Magician”, coming in March. Until then, keep reading!

On mountains

The mountain looms large in our imagination. We speak of summits and pinnacles and peaks as though anything could be compared to a mountain. We use them in logos (Paramount) and brands (Denali) to represent quality, immovability, toughness. Mountains have a majesty, and they always have. The Greek gods had their abode on Mount Olympus. Noah’s Ark is said to be on Mount Ararat. Frodo had to take the One Ring to Mount Doom.

That last, of course, is a purely literary creation. (Some would say the others are, too, but that’s not the point of this post.) And that naturally brings us to the question of how to use mountains in a story. What is so special about them? What makes them stand out in literature? Read on for my thoughts.

Reaching the peak

First, I think that a mountain, more than any other geographical feature, represents achievement. In a way, that’s because we often hear tales of mountain climbing, but those tales only came about because people saw mountains as things to be conquered. And that’s a relatively recent phenomenon. Only in the past few decades has it really become a major source of adventure.

But it’s perfect for that. Climbing a mountain can be a grueling, demanding task. For the tallest and most remote peaks, you need some serious training and preparation. The environment is inhospitable at best, deadly at worst. Just catching sight of the summit is an accomplishment. Reaching it is a true achievement, and the flanks of, for example, Everest are littered with stories of failure.

And really, when you think about it, there’s no reason to bother. The whole thing’s a fruitless pursuit, a pure adventure with no true payoff. Why do people climb Mount Everest? Because it’s there. That’s it. No other reason at all, but that it’s something to do, a visible goal we can strive towards.

In that, the mountain serves as the perfect metaphor. Even better, climbing quite naturally gives us a definite climax, as well as the perfect opportunity for a “false ending” where the presumed climax isn’t actually the conclusion of the story. After all, sometimes the hardest part is getting back down the mountain.

But back to the metaphor…well, metaphor. It really does have a lot of levels, but they all find their way back to that same inescapable conclusion: there’s a peak, and we have to reach it. If you’re a writer who can’t find a way to make that work, then you might be in the wrong line of work. You don’t even have to put a volcanic chasm at the top, as Tolkien did. Any mountain can evoke the same sense of accomplishment, of achieving one’s aims.

Scenery

Beyond that, mountains can also make for good scenery, even in written form. Visually, as you know, a jagged line or solitary, snow-capped peak can be downright stunning. Described well, they can make the same impact in a novel, too. But you have to go about it a different way.

In my opinion, mountains as scenery, as backdrop, work best when they’re integrated into the story, but not the primary focus. A mountain is rugged, remote, inaccessible. It’s not the kind of place that is often the center of attention. Thus, it can fade into the background while still casting a shadow over a setting.

Who knows what lurks out there? Mountains can be the abode of gods, monsters, or just backwoods hill folk. Whatever the case, we’re talking about beings who don’t normally visit the cities and towns. They’re wild, but a different sort of wild than the denizens of, say, a forest. Mountains, because of their harsh nature, imply a harder life. We have the stereotypical image of the “mountain man”, as well as legendary creatures such as the Yeti, and these both speak to the myth of the mountain.

All alone out here

Another thing that follows from the idea of mountains being remote is their isolation. They’re the perfect place to get away from it all. The taller ones are bleak, seemingly lifeless, while shorter peaks may be covered in trees, but they share that common bond. The mountain is a retreat.

Today, we might think of that in terms of ski lodges, campgrounds, or hiking trails, but there’s a deeper history here, one that plays into fantasy and other fiction. If you want to escape, you head to the hills, whatever your reason for escaping in the first place. Monasteries (or their fantasy equivalents) work well in the mountains, and what alpine story doesn’t have a secret hideaway somewhere up above the treeline? Nobody knows about these places for the very simple reason that they’re not meant to be found. So what better place to put them than the one nobody would think to look in?

Disaster

Finally, mountains are a great setting for disaster, whether natural or man-made. Obviously, volcanoes are exciting, dangerous spectacles. Avalanches are more sudden, but their aftermath can make for a good survival story. Flooding (possibly from melting snow) can provide a relatively slow, yet no less unstoppable, threat.

On the highest mountains, it’s the storm that is the biggest, most cinematic of disasters. The snowstorm that struck Mount Everest in May 1996, for instance, spawned the book Into Thin Air and the more recent movie Everest. Once the mountain gets tall enough where climbers need oxygen tanks, then that’s a consumable that can run dry at the exact wrong moment. Add in blinding blizzards, hurricane-force winds, deadly cold—you get the picture.

On the artificial side of the disaster aisle, you have the fantasy standby of the siege, especially when the defenders in their mountain fastness are heavily outnumbered; think the battle of the Wall in A Storm of Swords, although that, strictly speaking, wasn’t an actual mountain. Combined with the idea of a hidden society shut away behind the rocky faces, and you have a lot to play with.

Last on the list, in a strange twist, is what was actually the first mountain disaster movie I ever watched: Alive. The true story of the 1972 Andes plane crash is a gripping tale that needs no embellishment. Weeks of cold, of starvation and injury and general privation, ended in death for most, miraculous survival for a very few. The same story could be told on a deserted island or in the middle of the ocean (In the Heart of the Sea works for the latter), but the mountain setting of this disaster gives it a starkness that anywhere else in the world would lack. For beating the odds, it’s hard to beat the peaks.

First glance: Kotlin

In my quest to find a decent language that runs on the JVM (and can thus be used on Android without worrying about native compilation) while not being as painfully awful as Java itself, I’ve gone through a number of possibilities. Groovy was an old one that seems to have fallen by the wayside, and it’s one of those that always rubbed me the wrong way. A bit like Ruby in that regard, and I think that was the point. Scala was another contender, and I still think it’s a great language. It’s a nice blend of functional and object-oriented programming, a true multi-paradigm language in the vein of C++, and it has a lot of interesting features that make coding in it both easier and simply more fun than Java.

Alas, Scala support is sketchy at best, at least once you leave the world of desktops and servers. (Maybe things have picked up there in the past year and a half. I haven’t checked.) And while the language is great, it’s not without its flaws. Compilation is fairly slow, reminding me the “joys” (note sarcasm) of template-heavy C++ code. All in all, Scala is the language I wish I could use more often.

A new challenger

Enter Kotlin. It’s been around for a few years, but I’ve only recently given it a look, and I’m surprised by what I found. First and foremost, Kotlin is a language developed by JetBrains, the same ones who make IntelliJ IDEA (which, in turn, is the basis for Android Studio). It’s open source under the Apache license, so you don’t have to worry about them pulling the rug out from under you. Also, Android Studio has support for the language built in, and Google even has a few samples using it. That’s already a good start, I’d say.

At the link above, you can find all the usual hallmarks of a “modern” programming language. You’ve got docs, tutorials, lots of press-type stuff, commercial and free support, etc. In that, it’s no different from, say, Typescript. Maybe there’s a bit more emphasis on using IDEA instead of Eclipse or Netbeans, but that’s no big deal. All in all, it’s nothing special…until you dig into the language itself.

Pros

Kotlin’s main mission, essentially, is to make a better Java than Java. Maybe not in the wholesale sense like C#, but that’s the general vibe I get. Java interop is an important part of the documentation, and that’s a good thing, because there’s a lot of Java code out there. Some of it is even good. It’d be a shame to throw it all away just to use what’s undoubtedly a better language.

But let’s talk about why Kotlin is better than Java. (Hint: because it’s not Java.) It borrows heavily from Scala, and this is both intentional and promising. Like Scala, there’s a heavy pressure on the programmer to use the immutable val where possible, while reserving the mutable var for those situations where it’s needed. Personally, I’m not a fan of the “all constant, all the time” approach of e.g., Haskell or Erlang, but the “default constant” style that Kotlin takes from Scala is a happy medium, in my opinion.

In addition, Kotlin makes a major distinction between nullable and non-nullable types. For instance, your basic String type, which you’d normally use for, well, strings, can’t be assigned a value of null. It’s a compile-time error. (If you need a nullable type, you have to ask for it: String?.) Likewise, you have an assortment of “safe” syntax elements that check for null values. Compiler magic allows you to work with a nullable type without hassle, as long as the compiler can prove that you’ve checked for null. That only works with immutable values, another instance where the language guides you onto the “right” path.

Those two alone, nullability and mutability, are already enough to eliminate some of the most common Java programming mistakes, and Kotlin should be lauded for that alone. But it also brings a lot of nifty features, mostly in the form of syntactic sugar to cut down on Java’s verbosity. Lambdas are always nice, of course. Smart casts (the same compiler trick that lets you dispense with some null checks) are intriguing, and one of those things that makes you wonder why they weren’t already there. And then you have all the little things: destructuring assignments, ranges, enum classes, and so on.

All told, Kotlin is a worthy entry in the “what Java should be” competition. It fits the mold of the “modern” language, taking bits and pieces from everywhere. But it puts those pieces together in a polished package, and that’s what’s important. This isn’t something that involves arcane command-line incantations or a leaning tower of 57 different build systems to get working. If you use IDEA, then it’s already there. If not, it’s not hard to get. Compared to the torture of getting Scala to work on Android (never did manage it, by the way), Kotlin is a breeze.

Cons

Yet no language is perfect, and this is no exception. Mostly, what I find to be Kotlin’s disadvantages are minor annoyances, silly limitations, and questionable choices. Some of these, however, give rise to bigger issues.

The heavy emphasis on tracking nullability is worthwhile, but the documentation especially turns it into something akin to religious dogma. That gets in the way of some things, and it can make others cumbersome. For example, although the language has type inference, you have to be careful when you cast. The basic as cast operator doesn’t convert from nullable to non-nullable. That’s good in that you probably don’t want it to, but it does mean you sometimes have to write things in a roundabout way. (This is particularly the case when you’re taking data from Java code, where the null-checks are toned down.)

Interop, in fact, causes most of Kotlin’s problems. There’s no solving that, I suppose, short of dropping it altogether, but it is annoying. Generics, for instance, are just as confusing as ever, because they were bolted on after the JVM had gone through a few revisions, and they had to preserve backward compatibility.

Except for syntax choices, that’s my main complaint about Kotlin, and I recognize that there’s not a JVM language out there that can really fix it. Not if you want to work with legacy Java code, anyway. So let’s take a look at the syntax bits instead.

I can’t say I like the belt-and-suspenders need to have both classes and methods final by default. I get the thinking behind it, but it feels like the same kind of pedantry that causes me to dislike Java in the first place.

Operator overloading exists, after a fashion. It’s about as limited as Python’s, and one of the few cases where I wish Kotlin had swiped more from Scala. Sure, you can make certain methods into infix pseudo-operators, but that’s not really anything more than dropping a dot and a pair of parentheses. You’re not making your own power operator here.

The verdict

Really, I could go on, but I think you see the pattern. Kotlin has some good ideas, none of them really new or innovative by themselves, but all bringing a welcome bit of sanity to the Java world. The minor problems are just that: minor. In most cases, they’re a matter of personal opinion, and I’ll gladly admit that my opinion is in the minority when it comes to programming style.

On the whole, Kotlin is a good language. I don’t know if I’d call it great, but that’s largely because I don’t really know what would make a programming language great these days. I’m not even sure we need one that’s great. Just one that isn’t bad would be a start, if you ask me.

And that’s what we have here. If I get back into Android development in 2018, I’ll definitely be looking at Kotlin as my first choice in language. Anything is an improvement over Java, but this one’s the biggest improvement I’ve seen yet.

Languages of the Otherworld: Introduction

In this new year of 2018, I think my “Let’s Make a Language” series can be retired. Maybe it’ll come out of retirement at some point down the line—that’s all the rage these days, isn’t it?—but it’s at a good stopping point, in my opinion.

But that means I need something else to write about, something to do with constructed languages. Well, since I’ve been writing so much on my own fiction, and one of my main settings involves heavy use of conlangs, why not use that? So here we are. This is another one of my sporadic post series, and it will focus on the languages I have created for my Otherworld setting. So far, I’ve put out 8 short novels (or long novellas, if you prefer) over at my Patreon, with another 6 shorter novellas coming this year. All told, I have plans for a total of 50 stories in the “main” course of this setting, and the languages are a key element. They’re pretty much the reason I started Otherworld in the first place. (That, and because Stargate Universe got canceled. The one thing I can thank Comcast for, I guess?)

So here’s how this is going to work: I don’t know. Seriously. I’m just going to write, and we’ll see what happens. I do want to talk about the creation of languages in general, using my own as both inspiration and example. I want to show off a little, too, and I hope you don’t mind. Most of all, I want this to be a kind of “behind the scenes” set of posts, a producer’s commentary for one element of the Otherworld.

Lay of the land

For this introductory post, I won’t go into too much detail about the languages themselves. Instead, I’ll give a broad overview of my thought processes going into the creation of the Otherworld setting.

First off, when I started Otherworld back in 2013, I had a goal in mind: to create a believable world. I’m not opposed to the kind of generic fantasy that gives no thought to its own backstory, but my preference is verisimilitude. I like a “realistic” world, one that I can imagine myself visiting, living in.

Thus, when making the languages of Otherworld, I didn’t set out to create anything too outlandish. The core conceit of the setting is that the fictional world is inhabited by a parallel development of humans that branched off from the first inhabitants of the Americas at the end of the Ice Age. Given the time and distance differences separating them from our familiar Old World languages, I felt comfortable creating those of the Otherworld from scratch. Too little is known about the protolanguages of America to disprove me, but that also means I didn’t really have much to work with. No matter. I prefer the a priori approach.

Early on, one of my ideas was a multiracial world, though one where the races were superficially similar to those of fantasy literature. So I needed at least one language for each race, because we’re dealing with a pre-modern world that wouldn’t have the normalizing elements of TV, radio, and other mass media. To preserve my sanity, though, I’m only fully detailing the most prominent examples of each. I justify this in text by simple expediency: the protagonists are too far away from other examples. They’re placed in an area that sees members of other races, but doesn’t always recognize their internal differences. So they consider the “Arassea“, for instance, to have a single language, and they name that language after its only known speakers.

My main concession to bias, I suppose, would be the mild stereotyping I’ve done with some of these languages. The Fassea race, to take one example, inhabits islands and coastal regions, and I drew heavily on Polynesian grammar and phonology for them.

All told, Otherworld has nine living races, and thus nine main conlangs. The tenth belongs to the Altea, mythologized forebears that, I must admit, are heavily inspired by the legends of Atlantis. They were human, but highly advanced, and they were the ones who originally colonized (and, for that matter, terraformed) the Otherworld itself. The timing just barely works, based on current archaeological evidence and theories.

So that’s our jumping-off point. Next time, we’ll get to looking at “Virisai”, the common tongue of the main story area. It’s by far the most well-developed of the Otherworld set, so it’s only natural that it gets top billing. Later on, I’ll work the others in where possible.