The Chinese Typewriter: Past as Prologue

I stumbled across a fantastic book over the holiday break: The Chinese Typewriter – A HistoryIt’s a story of the process of innovation — about imagination bottlenecks and their societal consequences, how use case goals shape (sometimes misdirect) design outcomes, the interplay of national and international politics with information technology, the mathematics and philosophy of organizing language and knowledge, and an array of related topics — via an extended case study of the Chinese typewriter.  It’s also a sort of alternative history of IT–an examination of what might happen when you can’t easily build on prior art. Reading the sample right before bed turned out to be a bad idea; I was awake thinking until 3 am.

Chinese Typewriter

The book begins with the history of the mass-produced typewriter, generally speaking. The “problem” of Chinese typewriting stemmed from the fact that the US-led international typewriter industry, after an initial proliferation of typewriter designs, very quickly standardized on the familiar keyboard and one-phoneme-per-key type that we now know, and thenceforth could not envision any other approach. It fell to Chinese inventors to come up with other alternatives, which in the end involved neither keyboards nor keys, and essentially miniaturized traditional moveable type schemes invented in China 1000 years earlier.

There remained the question of how to encompass the 60,000 or so non-decomposable Chinese characters in any compact mechanical device. Western Christian missionaries actually did a lot of the early work on this question, which tended to skew the results towards vocabulary most pertinent to their interests. The development of three main approaches to Chinese typography takes up the majority of the book, but Mullaney also takes a brief detour through the parallel challenges of encoding Chinese characters for telegraphic transmission. There were a variety of homegrown, mostly regional double-encoding schemes, all of which required the use of “special characters”. Special characters cost twice as much to transmit as “standard” Latin-alphabet characters, thus making telegraphy significantly more expensive for China. One doesn’t have to listen very hard to hear history rhyming with Unicode, as well as the ongoing economic impact to countries with double-byte character systems in view of their need to participate in a global communications infrastructure fundamentally designed around European  languages.

The challenge of coming up with a typewriter design that included a manageable but sufficient number of characters led to a widespread conclusion that the Chinese language was “incompatible with modernity.” This was not limited to foreign observers, by the way. Chinese elites, who were increasingly pursuing secondary educations abroad starting in the late 19th century, were keenly aware of the new centrality of the typewriter and telegraph in government and business affairs overseas and grew increasingly concerned that China was being left behind in the communications revolution.

There were heated debates about the best method for indexing Chinese characters in the absence of a system like a standard alphabet sequence: word-level metadata schemes, in other words, necessary for character retrieval. Rather poignantly, this led to something of an existential culture crisis for elites: Chinese high culture had revolved around the written language for millennia–and yet it turned out there was no real consensus even about the true makeup of a character. As Mullaney puts it, “Had the fundamental essence and order of Chinese script yet to reveal itself”, even after 5000 years of existence and intense scholarly examination?

By the 1930s, Japanese manufacturers had appropriated a couple of the most common approaches and began gaining market share. Their share accelerated as they invaded China in earnest during WWII, and continued in its aftermath, as China’s mostly small-scale manufacturing infrastructure was decimated. China’s experience with modern information technology into the 1950s was thus continually at the mercy of foreign interests–first Western bureaucrats, missionaries, and Western-run standards bodies, whose notions about information design were ill-matched with Chinese needs; and then the Japanese, who devastatingly controlled the means of print production in the lead up and during the war.

It’s not surprising, then, that post-WWII China would be as fixated on developing self-sufficiency in technology as in food and energy production. At the same time, maintaining interoperability with the global communications system is obviously essential. While Chinese technology protectionism is strong, so too is participation in standards bodies and open source projects, the latter being a particularly useful method of ensuring baseline interoperability as well as adaptability to Chinese environments without one-way dependency. Two leading telecom companies I work with have contributor rankings for key open source projects as top-level internal KPIs and other Chinese firms are increasingly taking operational leadership roles in those projects.

China’s early experiences with non-WYSISWG, and ultimately operator-designed input methods in both telegraphy and typewriting would form the core of keyboard-based input methods for Chinese in the computing age. Its alternate paths of IT experimentation also provided experience with predictive natural language approaches, as well as user-driven metadata design. Ongoing keyboard challenges, especially with smartphones, provide keen incentive to apply machine learning to predictive text–in the cloud, with an ever-expanding, real-time training set coming from over a billion internet-connected devices.

Mullaney has a follow-up book planned, which continues the story into the computer age. In the meantime, he’s already provided plenty of pattern-matching between China’s experiences as a technology outsider in the last century and its current initiatives in technology.

What to know before you go: Some general knowledge of Chinese history in the late 19th and 20th century would be helpful in reading the book. A brief perusal of a few Wikipedia articles would probably suffice.

I’m not sure how easy or difficult the book is to follow for someone with no knowledge of the Chinese language. Mullaney describes the various theories of how characters are formed in the course of explaining the different approaches to typewriting, but I suspect a quick primer such as one normally gets in the first couple classes of Chinese 1a would have been a good addition to the Introduction. This article isn’t a bad alternative. And this provides a brief summary about traditional approaches to organizing the language.

And, irony alert! It turns out that the Chinese characters sprinkled throughout the text to illustrate the discussion don’t render on older Kindles. I wound up buying the physical book.


Stop Hiding. Just Ask.

I came across an exchange on Twitter the other day that made me sad. In part:

Opensource newbie

It made me sad because I spent longer than I should have in a similar place: curious, interested, wanting to know more and also to have input, but being surrounded by people who’d been doing “this stuff’ for 20+ years. I was at a loss as to how I’d ever “catch up”, never mind be in a position to provide value.

Here’s the thing: I wound up in that place because I’d invested a good 20-25 years of my life by that point in making sure I was really competent. Competence and knowing what you’re talking about are things that are valued very highly in my family. Moreover, I grew up surrounded by engineers, who tend to enjoy arguing and sometimes pounce with delight on logical lapses or other types of weak arguments. So from an early age, I shied away from spending a lot of time on things that didn’t come naturally. Early in my career, I did the same: I carefully stayed in roles that didn’t require me to have any specialized knowledge. By my mid-30s, I was in a rather small box–one entirely of my own making.

Now, had anyone else told me I just didn’t have what it takes to do any particular kind of job, I most likely would have furiously plunged into proving them wrong. Instead, I took great care to avoid fulfilling the stereotype of the clueless (female) marketeer: I asked no questions that could be “dumb” questions. I’d quietly go read up on things on my own, but a lot of the time I didn’t have enough context to make total sense of what I read. Still, I avoided asking questions.

What finally did it was screaming boredom. I just didn’t want to keep doing what I’d been doing any more. I decided I’d rather be dumb than bored.

It was terrifying.

Eventually I found a colleague who was working in a similar area, but was coming into marketing after a long time as a engineer. We’ll call him Fred. Every so often I’d walk over to Fred’s cube and announce (pre-emptively, in my mind), “Hi, I have another stupid question,” to which he would helpfully reply, “There are no stupid questions, only stupid people.” And then proceed to explain both the theory and the depressing reality of whatever I was asking about. I have since learned to spot Freds fairly quickly, and over the last few years I’ve built up a wonderful network of Freds. Thanks to social media, most of them are not in a nearby cube, but several states or even a continent away–but that means I get a much broader perspective on whatever I’m curious about than if I just asked the person in the next cube whose vantage point on the world likely only differs from mine by a few degrees.

This brings me to a wonderful talk I unexpectedly attended a few months back. My daughter had been taking a Scratch class through Coder Dojo, and the last night of the session, the parents were all asked to gather in a different room for a pitch from one of the Coder Dojo cofounders, Bill Liao (@liaonet).

Liao opened by stating that coding is poetry, which won me over right there. To be good at poetry, he said, you have to be deeply fluent in a language, in a way you can be only if you speak it from a very young age. It goes without saying, perhaps, that when you learn to speak a language in a fluent, natural way, you do it by interacting with other people. Or as Liao put it,  “I learned to code in my bedroom, and I think working alone in your bedroom is a terrible way to learn to code. I think working with others on a project is a great way to learn to code.”  You can watch an abbreviated version of his talk below.

And this, in turn, brings me to a lesson taught to me by my friend Brent Salisbury (@networkstatic), who became active in OpenDaylight in its very early days. He was trying to convince me to get involved. “But Brent,” I protested, “I haven’t coded in 20 years, and I never got good at it even then.” He told me it didn’t matter. ODL desperately needed documentation. QA. “Play around with Python,” he said. “Hell, I’m dyslexic–if I can code anyone can.” The point being that any project in which people are doing things mostly on their own time–which is most open source projects–desperately needs help of all kinds, and will usually gladly welcome a range of skills, not just narrow technical ones. “I’m just learning how to code, but this is really interesting to me–how can I help?” is as good a door-opener as any.

And of course the way to make book-learning–or any learning–really stick is to try to use it. At Brocade, we have a couple of SEs who have spent most of their careers as network engineers, but are really excited about SDN. They’ve been delving into the documentation–both on the ODL site as well as the materials for my company’s distribution–and making notes about how it works in ways that make more sense to someone accustomed to running a network. I myself had learned about SDN and ODL from a more classical software perspective, so reading what they’ve written was really helpful to me, as they naturally point out very practical nits and concerns that hadn’t occurred to me. Now we’re in the process of converting their work into papers the bigger world can access, which should be helpful to a lot of other network engineers trying to get their heads around this stuff. Note: none of us is writing Java code. All of us are contributing to the growth of an open source effort. It takes a village.

Becoming an expert also takes a village. It’s why throughout history, you find innovation happens in clusters, where talented people gather, get to know each other, and exchange ideas. The lone genius is a myth. Mozart was mentored by Haydn, among others.

Ask for help, and ask how you can help.

A Simple Definition of “Open”

I wrote this into an internal FAQ today:

Q: What does “open” really mean?

A: “Open” is used in a variety of ways. An “open” API is an interface that uses standard protocols, tools and models and that can be written to by customers and third-party developers. An API is not, by itself, “open source”. Open source describes a development model in which anyone at all is free to download, improve upon and, with the agreement of the developer community, contribute code to a particular project. It is common to use open source components, often from many different projects, as building blocks of a proprietary piece of commercial software. Increasingly, there are open source projects, including OpenStack and OpenDaylight, which seek to deliver a complete and wholly open solution.

I like it, but given how freighted the whole topic is, it seems rather daringly simple and straightforward. So, dear readers, what nuances, caveats and gotchas am I missing?

Response: Open Networking: The Whale That Swallowed SDN

Art Fewell, whose views I greatly respect, has written a very good post on Network World entitled “Open Networking: The Whale That Swallowed SDN“. It’s a great historical summary of SDN 2011-present, with some noteworthy areas of concern. I agree with the general thrust of Art’s thesis, yet at many points I found myself thinking “Yeah, but…” I started to write a few comments on the Network World page, but the comments turned into a page, so here we are.

Here’s what I really liked in Art’s piece: Continue reading

Thoughts on SDN Consumability

I’ve been using the phrase “SDN consumability” here and there of late, assuming that there was nothing particularly revolutionary in the idea. The response, however, is typically a cocked head, an interested look, and a question: “What do you mean by that?”

So here’s what I mean by that:

In order for SDN to see mainstream adoption, SDN solutions need to be/have

  • Simple to operate – easy to deploy, low-to-moderate learning curve
  • Safe and reliable – tech is stable, nothing blows up, no one gets fired
  • No blue-sky requirements, limited DIY – tech and process migration support available

Continue reading