An essay in which I expound upon the benefits of the lowly wire and resist the temptation to wireless-ize the world of personal gadetry. This weekend, in a futile effort to preserve my back and wrists, I've retooled my home office by including picking up a new mouse and keyboard. The only thing available at the local store was wireless, either bluetooth or using a proprietary dongle. While reasonably nice to use from an ergonomic standpoint they immediately began having interference with my network, including dropping or repeating keystrokes and mouse clicks. After 2 days of frustration I returned them. Then, after searching 3 stores to find a decent wired keyboard, I gave up in frustration. Wireless all.

The Good

Wireless sounds like a good idea. The promise of "No wires!" means no tangles, no restriction of movement, and no ugly cords all over your desk. This is especially attractive when you use a laptop 100% as I do. The last thing I want on an airplane is a wire to get tangled up in the seat. The wireless devices all look quite sleek and futuristic. And the accuracy of modern laser trackers on virtually all surfaces is quite simply astounding. Wireless promises a trouble free computing experience.

The Bad

For all of the good, there's actually a lot of problems with wireless devices. First: all wireless gadgets must have batteries, which means one more thing to monitor, charge, and replace. Next, the minute you have an active network over the air you have to worry about eavesdropping. That means security layers, network protocols, and the bane of bluetooth: pairing. The act of connecting two devices which are a scant 2 feet from each other simply isn't worth the pain. I returned three bluetooth headsets over the years due to pairing issues. Once you get your device set up and authenticated you still must worry about interference. I found that my keyboard would drop key presses if I was doing my hourly backup over the network at the same time. Not doing two things at once is the opposite of progress. And finally, to add insult to injury, wireless devices cost more. Now let's consider the alternative.

Wires

Wires are simple to use. You attach a wired mouse to your computer by plugging it in. Through the magic of USB, the device is immediately detected and the driver installed. Plus you get power for free, so no more batteries to replace. Nothing goes over the air you don't have to worry about eavesdropping, so no security system and no pairing. No RF transmission means no interference with the 4.8 billion other wireless devices in my house. In addition to the security aspects wires are usually faster and cheaper. USB 2.0 is far faster than even the latest Wifi N standards, which I suspect is why Apple doesn't sync the iPhone over wifi. And the cost of course is fantastic. No extra batteries and radio transmitters makes any gadget cheaper to produce. The costs of wireless (financial, technical, and mental) are worth the benefits in some situations. But for lots of things: just go with a wire. It works.

Animation is just moving something over time. The rate at which the something moves is defined by a function called an easing equation or interpolation function. It is these equations which make something move slowly at the start and speed up, or slow down near the end. These equations give animation a more life like feel. The most common set of easing equations come from Robert Penner's book and webpage.

Penner created a very complete set of equations, including some fun ones like 'spring' and 'bounce'. Unfortunately their formulation isn't the best. Here is one of them in JavaScript


easeInCubic:function(x,t,b,c,d){
returnc*(t/=d)*t*t+b;
},
easeOutCubic:function(x,t,b,c,d){
returnc*((t=t/d-1)*t*t+1)+b;
},

They really obscure the meaning of the equations, making them hard to understand. I think they were designed this way for efficiency reasons since they were first implemented in Flash ActionScript, where speed would be important on the in-efficient. It makes them much harder to understand and extend, however. Fortunately, we can refactor it to be a lot clearer.

Let's start with the easeInCubic equation. Ignore the x parameter (I'm not sure why it's there since it's not used). t is the current time, starting at zero. d is the duration in time. b and c are the starting and ending values.

easeInCubic:function(x,t,b,c,d){
returnc*(t/=d)*t*t+b;
},

If we divide t by d before calling this function, then t will always be in the range of 0 to 1, and d can be left out of the function. If we define the returned version of t to also be from 0 to 1, then the actual interpolation of b to c can also be done outside of the function. Here is some code which will call the easing equation then interpolate the results:


                var t = t/d;
                t = easeInCubic(t);
                var val = b + t*(c-b);

We have moved all of the common code outside the actual easing equation. What that leaves is a value t from 0 to 1 which we must transform into a different t. Here's the new easeInCubic function.


        function easeInCubic(t) {
            return Math.pow(t,3);
        }

That is the essence of the equation. Simply raising t to the power of three. The other formulation might be slightly faster, but it's very confusing, and the speed difference today is largely irrelevant since modern VMs can easily optimize the cleaner form.

Now let's try to transform the second one. An ease out is the same as an ease in except in reverse. If t when from 0 to 1 then the out version will go from 1 - 0. To get this we subtract t from 1 as shown:

        function cubicOut(t) {
            return 1-Math.pow(1-t,3);
        }

However, this looks awfully close to the easeIn version. Rather than writing a new equation we can factor out the differences. Subtract t from 1 before passing it in, then subtract the result from one after getting the return value. The out form just invokes the in form:

function easeOutCubic(t) {
     return 1 - easeInCubic(1-t);
}

Now we can write other equations in a similarly compact form. easeInQuad and easeOutQuad go from:

easeInQuad:function(x,t,b,c,d){
returnc*(t/=d)*t+b;
},
easeOutQuad:function(x,t,b,c,d){
return-c*(t/=d)*(t-2)+b;
},

to

function easeInQuad(t) {  return t*t; }
function easeOutQuad(t) { return 1-easeInQuad(1-t); }

Now let's consider the easeInOutCubic. This one smooths both ends of the equation. In reality it's just scaling the easeIn to the first half of the t, from 0 to 0.5. Then it applies an easeOut to the second half, from 0.5 to 1. Rather than this complex form:

easeInOutQuad:function(x,t,b,c,d){
if((t/=d/2)<1)returnc/2*t*t+b;
return-c/2*((--t)*(t-2)-1)+b;
},

We can compose our previous functions to define it like so:

        function cubicInOut(t) {
            if(t < 0.5) return cubicIn(t*2.0)/2.0;
            return 1-cubicIn((1-t)*2)/2;                
        }

Much cleaner.

Here is the original form of elastic out, which gives you a cartoon like bouncing effect:

easeOutElastic:function(x,t,b,c,d){
vars=1.70158;varp=0;vara=c;
if(t==0)returnb;if((t/=d)==1)returnb+c;if(!p)p=d*.3;
if(a<Math.abs(c)){a=c;vars=p/4;}
elsevars=p/(2*Math.PI)*Math.asin(c/a);
returna*Math.pow(2,-10*t)*Math.sin((t*d-s)*(2*Math.PI)/p)+c+b;
},

and here is the reduced form:


        function easeOutElastic(t) {
            var p = 0.3;
            return Math.pow(2,-10*t) * Math.sin((t-p/4)*(2*Math.PI)/p) + 1;
        }

Moral of the story: "Math is your friend" and "always refactor".

These new equations will be included in a future release of Amino, my cross platform graphics library.

Listening to some podcasts about mobile devices I heard over and over statements like "iPhone changed the world with multi-touch" and "Android could compete with Apple if it had multi-touch." This simply isn't true. Okay, while perhaps not a lie, the success and value of of multitouch is extremely overrated. In fact, the iPhone barely uses multi-touch!

Don't believe me? Think back to the iPhone of 2007 when it launched. Or just look at the Apple provided apps in today's iPhone (since not much has changed). How many of these built-in apps use multi-touch? I can only count 3: Maps, Photos, and Safari. All three of them use multi-touch in a single simple way: zooming in and out. You could make a non-multitouch iPhone by simply providing a zoom-out button for these three apps (and a quick-tap for zooming in).

Very little of what made the iPhone interface so revolutionary was multi-touch. What made it so great was the focus on using a single finger for virtually all interaction with the device. The designers at Apple decided from day one to make a device that was finger centric. This means UI controls that are large and require only a tap gesture to activate. Swipe gestures are used for navigation. And that's it. Taps and swipes with a single finger. That's what made the iPhone so great, not multi-touch (or the accelerometer, for that matter).

Oh, and one more thing made it great. The large screen with a capacitive touch sensor. Older touch enabled devices (like my old beloved Treo) used resistive screens which were far less accurate and required you to either push hard with your finger or use a stylus. A Treo with a capacitive screen could have supported an iPhone like interface with ease (even on the much slower hardware available to it at the time).

While the hard glass iPhone screen does support multiple touch-points at once, that's not what made it a success. It's designing an interface and device from the ground up for finger-based touch interaction that changed the mobile device playing field. Multi-touch is simply a red herring.

Finger photo used under Creative Commons from Flickr user bayat

An open letter to language designers: please, for the good of humanity, kill your sacred cows. Yes, i know those calves look so cute with big brown eyes and soft leathery skin, but you know what? Veal is delicious!

Let me preface this by saying that I am not writing my own language. The world doesn't really want a new language, especially one from me. I made one a few years ago. While only a few dozen people were horribly maimed, I still consider it a failure and don't wish a repeat experience. The world does not want a new programming language, especially from me. But since you are hell bent on creating a new one, you might as well make it an improvement.

So open up your looking balls and point them right here. Our sacred cow wilderness safari begins now. Buckle up! It's going to be a long and awkward ride.

Lets start with the big cow, since it leads most of the ones that follow.

Cow #1: source code is ASCII text on disk.

You may think the storage of source code isn't really a language issue, but it is. A programming language isn't just the language anymore. It's the entire ecosystem around the language; including editors, libraries, source control systems, and app deployment. A language in isolation is so useless it might as well be LISP. I don't mean that to demean LISP, the badass godfather of languages. I mean it as: if you aren't thinking about a whole ecosystem then your language will mathematically reduce to LISP, so why are you bothering.

Back to the topic at hand. This is the 21st @#!% century!! Why, for the love of all things pure and functional, are we still storing our source code as ASCII text files on disk? One answer is "that's how we've always done it". Another is that our tools only work with text based code. So what?! I have a ten 1GHz devices sitting on my shelf unused and a 4 way multiprocessing laptop. Why are we being held back by the ideal of ASCII text? This cow must be shot now!

If we switch to using something other than text files, say XML or JSON or maybe a database, then many interesting things become possible. The IDE doesn't have to do a crappy job of divining the structure of your code. The structure is already saved. It's the only thing that's saved. The IDE can also store useful metadata along with the source and share it with other developers through the version control system, not through comments or emails. We could also store non-code resources, even non-text resources, right along with the code. Oh, and tabs vs spaces, style issues, etc. become moot. But more on that later.

Oh, and before you ask, putting your files in a directory structure and calling them 'packages' doesn't count. Think beyond the cow corral.

Cow #2: source code must be editable by plain text editors. IDEs should be optional and unnecessary.

Cowpatties! Unless you write your code exclusively with echo and cat, you are already using an IDE. A plain text editor is just an IDE with no useful features. We all use IDEs, the question is how much functionality does it provide you. When programmers say they shouldn't have to use an IDE, what they mean is they shouldn't be locked into using someone else's favorite IDE instead of the one they prefer. (I wouldn't mind being locked on a desert island with IntellJ, for example but I'd commit suicide if I was stranded with Eclipse).

Rejecting an required IDE is an issue of having specs and multiple implementations, not the concept of IDEs in general. I don't draw graphics in a text editor, I use Photoshop. The problem is that Photoshop has a closed file format that must be reverse engineered by Gimp. To go without an IDE is to go without 20 years worth of UI improvements. We are building a 21st century language here. Assume an IDE and plan for it. Cow dead. Yummers!

Cow #3. Less syntax is good.

No. While technically a language can express everything using just a nested tree structure (ala LISP) that doesn't mean it's a good idea. Syntax matters. Programming languages are user interfaces *for programmers*, not the computer. They let the programmers express what they want it the most convenient way possible and have the compiler talk to the computer. Certainly syntax can be too cumbersome or verbose, but that is about giving the programmer more to remember. Minimal syntax isn't the answer. The more specific the programmer can be the better. We want to give as much information as possible to the compiler so it can generate efficient binary code (where 'efficient' varies depending on the problem domain).

Minimal syntax is seductive because we like the idea of being concise and typing nothing extra. This is all very well and good. But the solution isn't to remove syntax, but rather make it optional. If the compiler can figure out what the programmer means without extra parenthesis and semicolons, then great, but let us add it back in if we want clarity. Make typing our variables optional for when we are hacking, but let us be more strict when we get to production. The syntax needs to scale with our needs, not yours. Oh, and what do you think of my nice leather wallet?

Cow #4. Holy wars: Whitespace. Indenting. Bracing. Tabs vs Spaces.

Irrelevant. Completely irrelevant. This is a style issue that can be enforced (or not) by the IDE. As long as it saves the source in a canonical format you can edit the code in any style you want. If you want to hide braces, do it. The IDE will handle the details for you. If you want to use square brackets instead of parenthesis, do it. The IDE will convert it. A funky syntax for escaping multiline text? Who cares. I can paste it into the IDE and it will deal with it. If you want to use dingbats symbols instead of keywords, do it. The IDE will handle it. (hmm. that's not a bad idea, actually. Have to think about it some more).

These are holy wars that matter unreasonably much to us but have not practical difference in the real world. Simply specify the semantic meaning and let the dev choose what they wish. Having good defaults matters, of course, but don't allow your cool new language to get trapped in the tar pit of programmer holy wars. Leave that for the cows.

Cow #5. What the world needs is a better type system.

No. The world doesn't care about yet another cool type system. You won't get programmer adoption by emphasizing how awesome your types are. No one will say: "Woah! Check out the type system on that one!". What the world needs is good modules. An escape from classpath hell. The ability to add a new module and know it will work without modification and without breaking something else. Let the compiler rewrite anything inside a module without affecting the outside. Fix versioning. These are those hard problems that need to be solved, not type systems. My code won't get magically faster and bug free through your awesome type system. Another cow bites the dust.

Cow #6. We must not let programmers extend the syntax because they might do bad things.

So?! We are adults. Let us shoot ourselves if we really want to. Let us override the syntax of the entire language if it would help us solve real world problems. Just make sure the changes are cleanly scoped, then let us have at it. The amazing success of JavaScript has been because it was so flexible that real world programmers could try different things and see what works, in the real world (seeing a common theme here?). Usage of JavaScript has evolved tremendously in the past decade, so much so that you could say the language itself has evolved (even if the syntax changes have actually been minimal).

So, no. Your language doesn't need to provide X. The language should programmers build it themselves. One more cow down the drain. Get your swim fins.

Cow #7. Compiled vs Interpreted. Static vs Dynamic.

Nobody cares. All languages are compiled at some point, the question is when. All languages live somewhere between the platonic ideals of static and dynamic. If we can get useful work done then we don't care where your language fits mathematically.

Cow #8. Garbage collection is bad.

No. Garbage collection is good. It has increased programmer productivity tremendously and eliminated an entire class of bugs (and security exploits). The problem is garbage collection isn't perfect. So grow your hair long enough to escape from your ivory tower and fix the GC, don't eliminate it.

GC systems often have bad nondeterministic performance, especially in interactive applications. They treat all objects the same. They provide the programmer with no-insight into what is actually going to happen. So improve the GC. Let us give it more hints about what we actually want. Why should the GC system treat my cached textures the same as a throwaway string. This is also a place where better IDE integration would help. If you make it easy for me to see where GC might be a problem then I, the programmer with the knowledge of what I'm actually trying to accomplish here, can provide the compiler with better information. Research modern infoviz. Get out of your pure text mindset.

We can rebuild this GC cow. We have the technology.

In memoriam

I hope I've provided a bit of guidance before you go off to your language shack in the woods and come back with type safe encapsulated 'genius'. Once again, you really shouldn't be building a new one language anyway, we have more than we need. Please, please. please, don't make a new language. Since you are determined to not heed my warnings, the least you can do is not injure the world further.

And please kill a few cows on your way out.

The twit-o-sphere came alive last week with the news that Adobe is canceling their Flash for Mobile products. I even briefly joined in.  Many see this as evidence that the open web has won (it has), or a justified comeuppance for Adobe's historical slights to Apple (it might be), or perhaps vindication of Steve Jobs' rant anti-Flash (it was), and maybe even that Microsoft was really to blame (it's a stretch).  Lost in all this, I wonder, is the effect this actually has on Adobe beyond their short term problems.

Lets step back a minute and consider what Adobe actually does.  They have some enterprise backend products for document management and (amazingly still used) a server side platform in Cold Fusion.  They have some cloud products (Acrobat.com) built on the the Flash platform. Then there is Flex, an enterprise application platform designed to steal Java developers from Sun, as well as a mobile advertising and analytics platform (Omniture). And of course Flash for mobile.

Oh yeah. And they also make Photoshop, Illustrator, Fireworks, and a bunch of other industry leading graphics and content creation tools so pervasive that some have called them the Adobe tax.

This really sounds like two different companies, doesn't it?  I'm not exactly sure when, but at some point Adobe strayed from focusing on high quality content creation tools for designers and artists. They entered the "platform space": trying to be an enterprise company, a software as a service company, and own the mobile content market.  That's a whole lot for any company to do, especially one who traditionally focused on content creation tools.  In the end I think it just became too much for one company to do, and it takes away from the thing they are good at: killer tools for designers.  If killing of mobile flash lets them focus on their core competency then this is a good thing for everyone.

Adobe is known for tools used by professionals to create content. The Flash designer tool is used by professionals to create animated interactive content. Currently, the format of the final output is a SWF file. Do the purchasers of this tool care? Not really. Flash designers want to create content that is viewable by the most people. The audience wants great content accessible from the most devices. Neither of these two groups of people gives one whit about the actual format of the bits.  Flash, the runtime, was simply an end to a means.  With HTML 5 technologies becoming viable for interactive animated content, the Flash designer tool can simply output a new binary blob to be uploaded onto web servers.  The designers won't care, the audience won't care.  Everyone will get on with making/viewing their content and Flash Designer CS 22 will sell millions of copies.  This really isn't a big deal.

Well, except for one group of people who really truly do care about mobile Flash: the makers of iPad competitors. Apple's refusal to allow Flash onto the Safari mobile browser created a market opening for a device that *would* play Flash.  While it was never a big factor for webOS, it was a flagship feature for the BlackBerry Playbook and various Android Tablets.  They've now lost a checkbox in their feature war with the iPad.

No matter. The world will move on.  The mobile web is built on HTML 5 standards. And in 5 years the mobile web will simply be the web; which may foretell the end of the desktop Flash plugin as well, but the end result is the same. Adobe will continue to sell world class content creation tools. Tools which output whatever format the world actually wants. And now, finally, the world wants HTML 5.

Long Live the Web. Long Live Adobe.

The Web is amazing for answering questions. Suppose you want to answer a question like, "what does the .JPG file extension mean", then the answer is just an internet search away. Millions of answers. However, if you stray from the common path just a tiny bit things get hairy. What if you want to get a list of all file extensions? This is harder to find. Occasionally you might find a PDF listing them, but if you are asking for all file extensions then you probably want to do something with that list. This means you want the list in some computable form. A database or at least a JSON file. Now you are in the world of ‘public’ data. You are in a world of pain.

Searching for “list of file extensions” will take you to the Wikipedia page, which is open but not computable friendly. Every other link you find will be spam. An endless parade of sites which each claim they are the central repository of file extension data. They all have two things in common:

  • They are filled with horrible spam like ‘scan your computer to speed it up’ and ‘best stock images on the web’ and ‘get your free credit report now’.
  • They let you add new extensions but don’t let you download a complete list of the existing ones.

What I want is basic facts about the world; facts which are generated by the public and really should belong to the public. And I want these facts in a computable form. So far I cannot find such a source for file extensions. These public facts, as they exist on the internet, have morphed into a spam trap: vending tiny bits of knowledge in exchange for eyeball traffic. These sites take a public resource and capture all value from it, providing nothing in return but more virus scanner downloads. That they also provide so little useful information is the reason I have not linked to them (though they are obviously a search away if you care).

The closest I can find to a computable file extension list is the mime type database inside of Linux distros. This brings up a second point. Every operating system, and presumably web browser, needs a list of all file extensions, or at least a reasonable subset. Yet each vendor maintains their own list. Again, these are public facts that should be shared, much as the code which processes them is shared.

File Extensions are not the only public facts which suffer the fate of spam capture. I think this hints at a larger problem. If humanity is to enable global computing, then we need a global knowledge base to work from. A knowledge base that belongs to everyone, not just a few small companies, and especially not the spammers.

Wikipedia and it’s various data offshoots would seem to be the logical source of global computable data, yet the results are dismal. After a decade of asking, Wikipedia’s articles still aren’t computable in any real sense. You can do basic full text search and download articles in (often malformed) wikimarkup. That’s it. Want to get the list of all elements in the periodic table? Not in computable form from Wikipedia. Want to get a list of all mammals? Not from them. Each of these datasets can actually be found on the web, unlike the list of file extensions, but not in a central place and not in the same format. The data offshoots of Wikipedia have even bigger problems, which I will address in a followup blog.

So how do we fix this? Honestly, I don’t know. Many of these datasets do require work to build and maintain and those maintainers need to recoup their costs (though many of them are already paid for with public funds). If this was source code I’d just say it should be a project on GitHub. I think that's what we need.

We need a GitHub for data. A place we can all share and fork common data resources, beholden to no one and computable by everyone.

Building and populating a GitHub for data, at least for these smaller and well defined data sets, doesn't seem like a huge technical problem. Why doesn’t it exist yet? What am I missing?

In my hunt for what's next I've been reading a lot of books lately. A lot of books. As part of my search I decided to hunt down some of the classics in the computer science field that I'd missed over the years. First articles, then research papers, and some Alan Kay work. That led me to a book I'd always meant to read but never found the time: Mindstorms, by Seymour Papert.

You probably don't know the name Seymour Papert, but you if you are reading this blog you almost certainly know one of his greatest creations, and the topic of Mindstorms, the programming language Logo.

My first experience with computers in the early 80s was an Apple II running Logo. Though I obviously didn't realize it at the time, Logo was surreptitiously teaching me math, geometry, and Lisp. (Yes, Logo is a pure functional language). It probably set gears in motion to encourage my later pursuit of software as a career. Here's a quick example:

to spiral :size
   if  :size > 30 [stop] ; an exit condition
   fd :size rt 15        ; many lines of action
   spiral :size *1.02    ; the tailend recursive call
end
spiral 10


image from wikipedia

I haven't finished the book yet so I'll leave the review for another day. Instead I want to talk about the main thesis of the book's section on teaching (and really the main point of the book itself): How can we teach math better, and are we even teaching the right thing?

Early on Papert makes the point that children often identify with a deficiency: "I can't learn French, I don't have an ear for languages". These identities become entrenched and difficult to change, and the are reinforced by a society that is largely mathaphobic. Then he gets to the part that really made me stop and think:

It is easy to understand why math and grammar fail to make sense to children when they fail to make sense to everyone around them and why helping children to make sense of them requires more than a teacher making the right speech or putting the right diagram on the board. I have asked many teachers and parents what they thought mathematics to be and why it was important to learn it. Few held a view of mathematics that was sufficiently co-herent to justify devoting several thousand hours of a child’s life to learning it, and children sense this. When a teacher tells a student that the reason for those many hours of arithmetic is to be able to check the change at the supermarket, the teacher is simply not be-lieved. Children see such “reasons” as one more example of adult double talk. The same effect is produced when children are told school math is “fun” when they are pretty sure that teachers who say so spend their leisure hours on anything except this allegedly fun-filled activity. Nor does it help to tell them that they need math to become scientists— most children don’t have such a plan. The children can see perfectly well that the teacher does not like math any more than they do and that the reason for doing it is simply that it has been inscribed into the curriculum. All of this erodes children’s confidence in the adult world and the process of educa-tion. And I think it introduces a deep element of dishonesty into the educational relationship.

quote from Mindstorms by Seymour Papert. emphasis of last sentence in the original text.

This really made me think. Why did I love math and so many kids don't? Was it genetic? (unlikely) Was it a family member? (probably) Was it a good teacher? (certainly). We can't depend on happenstance to make children who like math. When a kid asks the question "Why should I learn math?" what do we tell them that isn't doublespeak? Surely we have a better answer than 'to be able to check the change at the supermarket'. (itself a largely irrelevant task today)

Well, I can't answer this for everyone, but I want a solid response when Jesse one day asks me the question. My best response so far: Math lets you understand things and make things happen.

Your response?

Every day or so I read another blog post (or ranting comments) about how BlackBerry could be rehabilitated, or how Nokia could restart Maemo and build the ultimate smartphone again. Things came to a head after Jolla announced their first phone for sale. Surely this phone with an amazing user interface will vindicate the N9?! Amazing technology plus a killer UI? Marketshare is theirs for the taking!

I’m sorry; but no. Most people don’t understand how a smartphone platform works. Simply put: there will not be any new entrants to the smartphone game. None. At all.

Obligatory disclaimer: I am a researcher at Nokia investigating non-phone things. I do not work in the phone division, nor do I know any internals of Nokia’s phone plans, or Microsoft’s after the acquisition of Nokia’s devices group is complete. I hear about new devices the same way you do: through leaks on The Verge. This essay is based on my knowledge of the smartphone market from my time at Palm/HP and general industry observations.

A few new Android manufacturers may join the game, and certainly others will drop out, but we are now in a three horse race. The gate is closed. I’m sorry to Jolla, Blackberry, the latest evolution of Maemo/Meego/Tizen, whatever OpenMoko is doing these days, and possibly even Firefox OS. No one new will join the smartphone club. It simply can’t happen anymore. You can’t make a smartphone.

There was a time when a small company, with say a few hundred million dollars, could make a quality phone with innovative features and be successful. This is when ‘successful’ was defined as making enough profit to continue making phones for another year. In other words: a sustainable business, not battling for significant marketshare. Those were the days when Palm could sell a million units and be incredibly happy. The days when BlackBerry had double digit growth and Symbian ruled the roost.

Then came 2007. It might be over-reaching to say ‘the iPhone changed everything’, but it certainly was an definitive event. The 1960s began in January of 1960, but ‘the sixties’ began when the Beatles came to America in early 1964. Their arrival was part of a much larger cultural shift that started before 1964 and certainly continued after the Beatles broke up. I would personally say the sixties ended memorial day of 1977, but that’s just my opinion.

The Beatles appearance on the Ed Sullivan show is a useful event to mark when the sixties began, even though it’s really a much fuzzier time period. Steve Jobs unveiling the iPhone in 2007 is a similarly useful historical marker. Everything changed.

Data networks

The first big change was data networks. In the old days there really wasn't a data network. Previous phones were about selling minutes and, to a lesser extend, texting. carriers didn’t really care about smartphones. They didn’t push them or restrict them. As long as you bought a lot of minutes the carriers didn’t really care what you used.

There were no app stores back then, just a catalog of horrible JavaME Tetris clones at 10 bucks a pop. I owned a string of PalmOS devices during this period. Their ‘app store’ was literally boxes of software in a store which you had to install from your computer. No different than 1980s PCs. While my Treo had access to GSM, it was merely a novelty used to sync news feeds or download email very slowly.

Around 2006 the carriers 2G and 3G data upgrades finally started to come online. Combined with a real web browser on the iPhone you could finally start doing real work with the data network. This also meant the carriers became more involved in the smartphone development process. Clearly data would be future, and they wanted to control it. Carriers request features, change specs, and pick winners.

Carrier influence means you can’t make a successful smartphone platform without having strong support from them. This is one of the things that doomed webOS. The Pre Plus launch on Verizon should have been huge for Palm. Palm spent millions on TV ads to get customers into the stores — who then walked out with a Droid. Without having strong carrier support, all the way down to reps on the floor, you can’t build a user base. To an extent Apple is the exception here, but they have their own stores and strong existing brand to leverage against carrier influence. Without that kind of strength new entrants don’t have a chance.

The cost of entry

Another barrier to entry in the smartphone market is the sheer cost of getting started. A smartphone isn’t just a piece of hardware anymore. It’s a platform. You need an operating system, cloud services, and an app store with hundreds of thousands of apps, at least. You need a big developer relations group. You need hundreds of highly trained engineers optimizing every device driver. The best webkit hackers to tune your web browser. A massive marketing team and millions in cash to dump on TV ads. You need deep supply chains with access to the best components. The cost of entry is just too high for most companies to contemplate.

To continue with webOS in 2011, I estimate HP would have had to spend at least a billion a year for three years to become a profitable platform — and that was two years ago. The cost has only gone up since then. There are very few companies with the resources. You already know their names: Apple, Samsung, Google, and Microsoft. All vertically integrated or well on their way to it. You aren’t one of these companies.

Access to hardware components

Smartphones need good hardware to be competitive. With the 6 month cycles of today’s marketplace that means you have to access to the best components in the world (Samsung), or have such control of your stack that you can optimize your software to make do with lesser hardware. Preferably both.

Apple has the spare cash to secure a supply chips and glass years in advance; you do not. If Apple has bought the best screens then your company has to make do with last years components. This compromise gets worse and worse as time goes on, making your devices fall further behind in the spec wars.

Retreat to the low end

A common solution to the component problem is targeting the low end. After all, if you can’t get the best components then maybe you could build a decent phone out of lesser parts. This does work to an extent, but it limits your market reach and opens you up to competition at the low end. You are now competing with a flood of cheap Android devices from mid-tier far-east manufacturers.

Even if you OEM hardware from one of these low-end manufacturers you are now in a race to the bottom. Your product has become a commodity unless you can differentiate with your user experience. That requires the telling potential customers about your awesome software, which requires a ton of cash. Samsung spends hundreds of millions each quarter on Galaxy S ads. This path also requires an amazing UI that will distinguish you from your peers.

A disruptive UI

Even with an paradigm shifting UI you’ve got to overcome all of the difficulties I outlined above. Most people in the wealthy world have smartphones already, so you not only have to convince someone to buy your phone, but to leave the phone they already have. Your amazing UI has to overcome the cost of change. Inertia is a powerful thing.

Most likely, however, your new platform won’t have such a drastically different interface. Smartphones are a maturing platform. A smartphone five years from now won’t feel that different than today’s iPhone. Sure, it will be faster and lighter with better components, but it will still have a touch screen with apps, buttons, and lists.

Unless you’ve figured out how to make a screen levitate with pure software you won’t be able to shake up the market. Google Glass is the closest thing I can think of to a truly disruptive interface. Adding vibration effects to scrolling menus is not.

No hope?

So does this mean we should give up? No. Innovation should continue, but we have to be realistic. No new entrant has any chance of getting more than one percent of the global market. That could still be a success, however, depending on how you define success. If success is being profitable with a few million units, then you can be a success. You will have to focus on a niche market though. Here’s a few areas that might be open to you:

Teenagers without cellphone contracts. Make a VOIP only phone. Challenge: you are now competing with the iPod Touch.

Point of Sale systems. Challenge: this is an enterprise only pitch and they have long sales cycles. You might be dead by then. They also don’t care about user experience, so your awesome UI doesn’t matter. Small to medium businesses will use apps on standard devices like iPads, so you are back to where you started.

Emerging markets: half of the world is buying their first smartphone. This is an opportunity if you can get in fast with cheap hardware, but now you compete with FirefoxOS.

Mozilla is targeting emerging markets where last generation hardware is more likely to succeed. Even so, Mozilla is working very closely with local carriers to ensure success while facing down competition from low-end Android devices. They also have the advantage of being a non-profit. Their ultimate goal is not to become a profitable phone company, but rather keeping the web open and free. This is probably not a viable option for you, and even Mozilla may be too late to follow this path.

The sad truth

Smartphones are a rapidly maturing product. Soon they will be pure commodities. Just as I wouldn’t suggest anyone build a new line of PCs or cars, smartphones are becoming a rich man’s game. Unless you start with a few billion dollars you have no hope of making a profit. Maybe you could follow CyangoenMod’s approach of building value on top of custom Android distros, but even that risks facing the wrath of Google.

Sorry folks. There's plenty of room to innovate elsewhere.

I'm tired of hearing people talk about how we need a new pipeline to bring oil from Canada to Texas for processing. They say we need to do this for the US to have "energy independence". This is bullshit. Anyone who claims this has no idea how global commerce works. Oil is a fungible commodity so whether Canada sells their oil to the US, China, Brazil, or Switzerland makes no difference. Let me explain.

 

Global commerce is a like a bathtub. Imagine a bathtub filled halfway with water. The US is a one end, China at the other. Other countries are at other spots. Now imagine what will happen if you pour a gallon of water in at the US end: it will be higher for a split second and then the water level will even out through the entire bathtub. If you pour the gallon in at the China end the same thing will happen. Because the water can freely flow throughout the bathtub, and because all water is the same, the bathtub will have the same level regardless of where you add more water.

Global commerce is like the bathtub. When we are talking about products that are uniform, such as natural commodities like rice or oil, and there are no barriers to trade, then the product will flow uniformly throughout the world. Adding more oil to the world's supply will lower the price for everyone. Removing from the supply, or increasing demand, will increase the price for everyone. All oil is the same and can be shipped anywhere so it is called a fungible commodity. It doesn't matter who Canada sells their oil to. It goes in to the global pool and raises or lowers the price for everyone.

So now we come back to energy independence. Energy independence sounds like a nice goal, but what does it really mean? This is about an oil pipeline, not all possibly energy supplies, so we are really talking about oil independence. So what does that mean? Does it mean that we have energy in case China decides to keep their oil?

As we just discussed, oil is a fungible commodity. If China 'keeps their oil' it means they are telling chinese oil manufacturers to sell oil only within the country instead of on the open market. By definition suppliers want to sell wherever they can get the best price, which is why the global market evens out for fungible commodities. If China imposes such a domestic rule then they are telling their own people not to sell for the best possible price. Thus China is hurting it's own industry. Chinese oil manufacturers are making less profit than they could otherwise.

If China 'keeps their oil' just means they increase their consumption, well that is no different than any other country increasing their demand. The price will rise globally. It won't help us anymore than if we got the oil directly from Canada. If somehow processing Canadian oil closer to home saved 5% on costs then that oil would be sold on the open market to get the best price, not just in the US. It's a global commodity, remember. The price will rise or fall for *everyone*. Building a pipeline provides no advantage to the area the pipeline is built through. You can't be independent from a global commodity without hurting yourself.

But what about jobs?

I have also heard the claim that this will bring more jobs to the US. That is true. Even if the price is global it would be better to have the work done in the US instead of other countries, right? According to this article at CBS News

analysis suggests that Keystone's job-creating potential is more modest. The U.S. State Department calculated last year that the underground pipeline would add5,000 to 6,000 U.S. jobs. One independent review of Keystone puts that number even lower, with the Cornell University Global Labor Institute finding that the pipeline would add only 500 to 1,400 temporary construction jobs. The authors of the September report also said that much of the new employment stemming from Keystone would be outside the U.S.

Transcanada itself cast doubt on its employment forecast when a vice president for the company told CNN last fall that the 20,000 jobs Keystone would create were temporary and that the project would likely yield only "hundreds" of permanent positions.

So, only a few hundred new permanent jobs. It seems like there are far better ways of creating jobs than digging a 1700 mile trench.

 

Please send feedback and comments to my twitter account @joshmarinacci instead of on the blog. Thanks!

There's been a ton of talk lately about several mobile operating systems and their problems, such as language restrictions, fragmentation, and anti-competitive practices. It's never a good idea to talk bad about your competition, so I'll take this opportunity to simply say a few things about the webOS (the OS that powers Palm's Pre and Pixi phones) that you might not know.

As always, I am writing this as Josh the blogger. These are my opinions alone and do not reflect the opinions of Palm Inc.

  • webOS devices are part of the web, not tethered to a desktop computer. You install apps through the web. You your data is backed up to the web. OS updates come through the web. Your address book is a merged view of your contacts living in the web. You never have to sync to a desktop computer. I know some Pixi users who have never once plugged their phones into a computer, because their phone is already a part of the web.
  • The webOS treats it's users like grown ups: they can install any apps they want. What if the app duplicates a built in app? Fine. What if the app isn't in the on device catalog? Fine: you can install apps from the web or beta feeds without any restrictions and do the marketing on your own. What if the app hasn't been reviewed, came from my cool programmer friend, and might hose my device? Well, if you enter the developer code into your phone then you've accepted the risk and can install any app you want. There's a whole community of people making cool but unauthorized apps. They are called the Homebrew community, and Palm encourages them. You're an adult. You can make the decision of what to install on your phone.
  • The webOS lets you use any language you want to develop apps. While Palm doesn't provide tools for languages other than JavaScript, C, & C++, there are no restrictions against using any other language. Our new PDK gives you a clean POSIX layer with direct & standard access to input (SDL), the screen (OpenGL), and device services (API bridge). There's nothing stopping you from porting a C# compiler or a Lua interpreter. Developers are free to use whatever tools they wish. The results are what matter. Good apps are good apps.
  • The webOS doesn't have fragmentation. All webOS devices run the same OS, regardless of form factor. They are all updated over the air, for free, in all countries and carriers. This means that 99% of webOS devices have the current version of the OS within a few weeks. There is no fragmentation of the operating system across devices or form factors. This lets developers focus on making great apps, not waste time supporting 18 versions of the OS.
  • The webOS is built from the DNA of the web. Yes this includes using HTML, JavaScript and CSS as the primary application development layer, but it's more than that. I can just start typing to have my question answered by wikipedia. The address book contains your contacts that live on the web. If my wife changes her Facebook profile photo, my phone is automatically updated. I can write an app that links to other apps through Javascript calls. The web is about connections to the people and services you care about, not just HTML pages. So is the webOS.

At Palm we care greatly about the end customer experience. We are also developers, so we care greatly about the developer experience. And most importantly, we don't see the two at odds. Happy developers create great apps that create happy customers. It's a win, win. That's why we are doing everything we can to make happy developers. We don't always do everything perfectly, but when something is broken we do our best to fix it and be transparent. It's how the web works and it's how the webOS works.

So, as a developer, I hope you'll think about the benefits and freedoms of the webOS, and consider it for your next mobile application.

references

I know IFRAME, I know. We've had a good run. You've tried hard and back in the day you were somethin' special. The way you could bring in content from any domain was nothing short of amazing, and you certainly took out the trash when you bumped off FRAMESET. But that was then and this is now. A lot has changed in the past few years. CSS and AJAX are really hitting their stride and you just can't hack it. I'm willing to overlook a few margin bugs, but this?! Well this is simply the last straw.

We took a big chance on you. It's time to step up to the mobile platform and you blew it. We're making ebooks with fantastic interactive content. Tons of pages of web content that need to be pulled into a beautiful navigation frame. When people think of embedding a page they think of you: the mutha'effin' IFRAME! The 'I' used to stand for 'Internal', but now it just stands for 'Idiot'. You just blew it.

First you blew it on iOS with that whole two fingered scrolling thing. Seriously? Two fingers? WTF were you thinking?! Then on webOS you rendered perfectly thanks to an embedded web view back end. Sounds great except you forgot one tiny detail: you don't support any @#$! touch events. Your parent window can handle them just fine but you think you are too good for them. You can dance and sing but no one can touch you. You know what the TouchPad is? It's a touch device. Touch is even in the damn name. What the hell were you thinking? And don't even get me started on Android.

And finally, iOS 5. Your one last chance. Stylable with CSS. Proper event bubbling so that single touches work. Should be great. Your swan song. But no! You always expand to fit the content. Always. 100% of the time. Useless After all we've been through together. After all the good times and bad, this is how you repay me?!

IFRAME. You are dead to me.

(ps, just to show you we are serious, we've already built a beautiful prototype with Enyo 2.0, Ajax, and some clever CSS. Half the work for twice the power. Good riddance to you.)

 

I've heard a lot of noise recently about these new fangled smartphones and tablets not replacing 'real computers', especially since the announcement of many new tablet products, including the HP TouchPad. That they are just expensive FaceBook machines. I've also heard people say that there's no room in the market for more devices: iOS and Android will take up the market and leave nothing for anyone else. It'll be just like the PC wars again!

Well... no. We definitely are going to see a huge shift in the industry over the next couple of years, but there will not be just one or two OSes controlling the market. And laptops won't be obliterated by tablets any more than TV destroyed the movies and radio. We won't see Mac vs PC again, or desktops vs Apple IIs. 2014 won't be like 1984.

First a disclaimer. These are my opinions, not the opinions of my team or employer. I work in Developer Relations. I have no knowledge of long term HP strategy, nor do I have any influence on it. This is simply the ramblings of an long time computing observer.

Tablets are no substitute for 'real' computers

Let's tackle these issues separately. First the claims: 'tablets suck for real work', or 'I would never use one. They are too limiting', or 'They are only for content consumption'. What are we talking about?

By tablet computers I mean things like the TouchPad or the iPad. These are devices which run a non-general purpose OS. There is no exposed filesystem. Apps are sandboxed and safe. A PC is a desktop or laptop running a general purpose OS like Windows, Mac OSX, or full Linux distros. Regardless of the form factor (touch vs keyboard), these are fundamentally different kinds of devices. Now the claims:

Tablets are too limited compared to a real computer. Yes the current generation of hardware is limiting, but it's going to get better; and fast. My top of the line computer less than 10 years ago had a 400mhz processor with 64MB of RAM, no GPU, and 8 GB of slow disk storage. Pretty much all tablet computers far exceed this already, and will soon support printing, directly controlling hardware in your house, and be first class citizens of the network (assuming Apple ever lets you jettison iTunes from your 'real' computer). They will all get better, and quickly. Especially when there is competition.

Tablets suck for real work: Yes, they are primarily designed for content consumption and tasks that require typing a paragraph or less. But guess what: that's a lot of stuff. In fact that's what 90% of people do 90% of the time on their computers. Most people don't write more than a paragraph at a time on their real computers. Most people surf the web, check Facebook, place games, pay their bills, and write a few short emails. A tablet device that can do 90% of what they need with less fuss and less cost is a big deal. A really big deal. Half of people could never learn to drive before the automatic transmission was invented. Yes, it's that big of a deal.

'I would never use one. They are too limiting'. That's very true. If you get nothing else from this essay, I hope you remember one thing:

They aren't built for you!

These things are built for the 90% of people who don't need everything a full PC does. By definition, if you are reading this blog, then these things aren't built for you. You are a programmer or writer or artist. You need a 'real' computer. In 10 years (probably far less), you will own a tablet computer, but it won't be your only computer.

In ten years I will still have a laptop with a real keyboard, possibly a disk drive, and most certainly an exposed filesystem with regular installable apps. It will still have a command line. (bash4eva!) I'll certainly use a tablet computer as well, but it won't be my only computer. However, for 90% of people, the tablet will do everything they need. It's built for them, not us.

OS Wars

Now that we have the audience for a tablet out of the way, lets look at the OS wars. There's a lot of talk that we'll have just iOS and Android. That they have an insurmountable lead. That the market wants one boutique option and one mass market indistinguishable option, just like MacOS and Windows.

I really don't think this is the case. I don't think any OS will have more than 25% market share in 10 years. Despite the similarities, the mobile OS market is very different than the PC market. Why? Well, let's compare the world of 1984 with the world of 2011.

  • Hardware: In 80s and early 90s you bought a PC in a computer store or maybe a department store like Sears. In 2011 you buy a phone in a cellphone carrier store, or on the web. You buy a tablet computer in a cellphone store or a mass market retailer like Target. These stores really didn't exist 30 years ago. Getting distribution for a device is very different now.
  • Apps: In 1984 you bought apps on floppy disks, wrapped in boxes, sitting on a shelf in a computer store. Or maybe Sears and Toys'R'Us (for games at least). There were no 'app stores'. Today, mobile apps are almost always bought in a store provided by the mobile platform itself. It doesn't matter if a retail location wants to carry your apps or not. No one has to fight over physical shelf space. The economics are fundamentally different.
  • Advertising: In 1984 computers were mainly advertised in computer magazines and newspapers. Remember those? Those things that no one my age reads anymore? (I'm 35 by the way.) Now we read and shop online. Or on our phones. Or get recommendations from friends on Twitter. And mobile devices are advertised on television. Advertising has changed. People find out about products in fundamentally different ways.
  • Compatibility: In 1984 software compatibility mattered. Software was hard to write, required huge lead times, couldn't be easily updated, and speed was of the utmost importance. Only the biggest apps would be on more than one platform, so getting apps on your OS was a big deal. IBM went to a lot of trouble making OS/2 Warp work with Windows 3.1 apps, for the sake of compatibility. Apple created expensive Apple II plugin boards for the Mac, all for the sake of app compatibility.

    Today most of the apps we run are backed by platform independent web services. Only the client app is different. And even that is easier thanks to open standards, modern programming languages, and the web. webOS has smaller market share than iOS and Android, but we still have Facebook, AngryBirds, and about 2 million Twitter apps. And you can view all the same websites. Compatibility simply isn't an issue anymore.

The economics of mobile operating systems are fundamentally different than the desktop wars of olde. To say we are in for a repeat of Mac vs Win is like saying the two world wars were identical because they both involved Germany and had the word 'World' in their names. Well the world has changed.

I think there will not be any single OS winner. Instead it will be more like cars. Many different models and vendors to cater to different tastes. They each have their own colors, addons, and spare parts; but they all drive on the same roads (the internet) and all take the same gas (webservices). 2014 simply won't be like 1984. And that's a very good thing.

It's been a month since I posted so I'd say it's time for a rant. I've been traveling a lot lately so the object of my wrath this week is alarm clocks. Most specifically the alarm clocks in hotel rooms, but home use clocks don't get off easy either.

Alarm clocks have one purpose in life. There's only one thing they need to do to be considered a success. It's not to 'tell the time'. That's a nice bonus, but the purpose of an alarm clock is to get you up in the morning. This is doubly so for alarm clocks in hotel rooms. If you are sleeping in a hotel it's likely because you have traveled somewhere to do something, and it's also likely that you want to do that something at a certain time; hence a clock to wake you up so that you may do that something without being late and getting fired. A device which cannot reliably complete this basic task is simply a failure, and not worth being made or purchased. End.

The Bad

How are they bad? Oh, please let me count the ways. (cue evil grin of glee).

First, most clocks tack on a ton of extra features, like iPod integration. Then they massively overload these features onto a small number of buttons by using modes. Many will have a single set of buttons to set both the time and the alarm, with a switch to toggle between the modes. Modes aren't a great idea in desktop software when you have a huge screen. They are even worse on the limited user interface of a clock with a fixed LED readout. Which mode am I in?. Did I set the time or the alarm? After I've set the alarm how do I know which mode I'm in now? Did it switch back automatically somehow or do I need to press another button?

Some clocks use quasi-modes to get around these problems. A quasi-mode is like a shift key: a button you hold down to temporarily enter a new mode, then release when you are done. Not a bad idea for a computer with a full keyboard. Absolute madness on a clock where you must hold the mode button with one hand and try to set the time with the other.

Even worse, some clocks put the mode button on the front instead of the top. Clocks, typically being small, are lightweight. So pushing from the front will shove it right off the nightstand. Now you have to use your third hand to hold the clock on the table, while accomplishing the aforementioned gymnastics.

Now do all of the above right when you go to bed... when you are sleepy.. and it's dark... No wonder so many people opt for a wakeup call or use the alarm on their phones. I always completely unplug the clock just in case the guy before me set it to ring at 3am. (yes, this actually happened to me)

Now suppose this is a clock you've never used before (very likely, since every hotel bought from a different supplier). Now you have to learn how to use this particular clock. Some come with their own instruction books. It's madness, I tell you. Madness!

The Good

Only once in my life have I found a non-sucky hotel alarm clock. It was in my room at a very nice hotel in Tokyo. Here's what it looked like.

DSC00498.jpg

Simply beautiful. Two buttons to change the alarm time up or down. One button to arm the alarm and snooze. AM/PM is indicated with real words.

How do you set the time? You don't. I'm serious, there were no buttons anywhere to set the time or customize the alarm. Either the time is set via radio or there's hidden controls locked inside somewhere. Maybe they use something wireless through that little transceiver on the front. The point is: I don't have to care. The only thing I care about is setting the wakeup time, so that's all the device lets me do. They also don't put in a radio since that would require controls to change the station. If you are in an international hotel in Tokyo you probably wouldn't understand the radio anyway, so jettison the feature. Simplify, simplify, simplify.

I don't know why this clock isn't used in the US. Perhaps it's because everything in Tokyo is from the future. Perhaps in another five years will will all be enjoying alarm clock bliss. No wait.. I took that photo five years ago! Yeah, we're doomed.

The Ugly

So why do hotel alarm clocks suck so badly? I think there is two reasons. First, these devices are mass produced overseas so they cut corners wherever they can to save costs and increase profits. If you can make a clock which uses two buttons to set the time instead of three buttons, then you might save five cents. Across millions of units that adds up to a lot of money.

Second is the buying decision. I'm not 100% sure, but I suspect that electronic clocks in general have become commodity products. The guts are a single chip that costs around 25 cents, and it's probably the same chip used by everyone. So the various clock makers compete with each other on price, features, or by simply looking cool. Now, don't get me wrong. There's nothing wrong with competing on price, features, and visual design. But what suffers in this competition usability.

I think usability suffers because of how clocks are bought. When you go to the store you can see the price, features and design from outside the box. What you don't see is how difficult it's going to be to actually set the alarm on the damn thing. The buying decision doesn't include usability. And since manufacturers optimize for the buying decision, usability gets dropped on the floor. C'est la vie.

The Lesson

I don't know how to fix the economics of alarm clock design, but the moral of today's story when applied to other products is simple: when you make a product you must design for the primary use case first and foremost. In this case that means setting the alarm reliably so you can wake up in time to not get fired. Everything else is secondary.

Okay kids. Time for work. I woke up late!

For some reason the concept of Genetic Programming got stuck in my head the other evening. At midnight, after spending about four hours reading up on the topic around the web, I came away disappointed. The concept of evolving code the way genes do is fascinating but the results in the field seem to be very narrow and limiting. Thus began this rant.

This article called Genetic Programming: A Novel Failure probably sums up my thoughts best. Genetic programming is only a slight variation on solution searching algorithms. Based on my reading, most work in the field has focused on how to make systems converge on a solution more quickly, i.e.: improving efficiency. This seems wrong, or at best premature.

We live in the 21st century. We have more CPU cycles than we know what do with. Where are the systems that are wide but shallow? The ones that are really non-determinstic and will generate truly surprising results? We should be wasting cycles exploring new possibilities, not generating new solutions for known problems.

The free ebook, A Field Guide to Genetic Programming, is a great primer in the topic. I read through most of it the other night. My biggest frustration is that almost all genetic programing systems focus on evolving syntax trees, usually some form of Lisp or it's semantic equivalent. I see why people would do this. Lisp code is easy to manipulate programmatically, so evolving it should be simple as well. There are other kinds of systems using different gene encoding, such as image arrays and direct byte code. However, these appear to be far in the minority. The Field Guide has a chapter on the topic, listing several alternate systems. The fact that these systems receive a single slender chapter while the rest of the book covers syntax trees gives you an idea of how under-explored the topic is.

When I first heard of genetic programming I imagined having a sequence of simple instructions that could be mutated. The instructions would be extremely simple and limited, perhaps more simple than most assembly languages. Evolving syntax trees certainly does let you make progress quicker, but the generated solutions will be limited to the underlying tree language. Our genetic beasties will never evolve novel flow control systems, or invent a crazy kind of memory register. ASTs are great if we want to produce a human readable program as the result, but it still feels limiting.

I would like to see a system that is as open ended as possible. Create a system of small instructions of uniform length that can only manipulate basic storage and do simple math. Then give them as much freedom as possible. Let them live in a wide fitness landscape. A digital environment with a huge number of potential ecological niches. Ideally we could take this to the next step and give our digital creations physical bodies so that they may evolve targeting real world constraints. Evolving a robot's brain seems far more interesting than figuring out how to gain 10 milliseconds trading stocks. Of course we lose rapid iterations by running them in the real world, so it my be better to run them in a simulation of the real world at many times normal speed. I imagine we could build self driving cars this way, starting with bots that play racing games then upgrade them to working with real world footage from actual self driving cars.

Am I wrong? Is there cutting edge genetic programming that is truly open ended? What successes have they made?

Please send feedback and comments to my twitter account @joshmarinacci instead of on the blog. Thanks!

 

I recently wrote an amusing rant on programming languages called "An open letter to language designers: Kill your sacred cows." It was, um, not well received. If you read some of the comments on Reddit and Hacker News you see that most people think I'm an idiot, a novice, or know nothing about programming languages. *sigh*. Maybe I am.

Most people got hung up on my first point: don't store source code as plain text on disk. I thought it was innovative but relatively uncontroversial. Surely, one day we won't store source as ASCII text files, so let's start thinking about it now. I mean, surely the Starship Enterprise's OS wasn't written in plain text files with VIM. Surely! I guess I underestimated the Internet.

Perhaps Not

So why did I not spark any real discussion? First I must blame myself for writing in the form of a rant. I thought the obnoxious insults would be amusing jokes, very tongue in cheek. Alas, tone is very hard to convey on the Internet through prose. That is completely my fault. I think I made an even bigger error, though. I talked about some interesting ideas (or rather, what *not* to do) but I didn't give any solutions or go in-depth with my justifications. That is why I have written the essay you are reading now: to explore just the first point and see if it makes sense.

Engineering is about tradeoffs. Cheap, fast, and correct: pick any two. So it is with source code stored as something other than ASCII text. Any modification will require changes in the surrounding ecosystem of tools. Version control. Continuous build systems. Diff tools. IDEs. The question is whether the benefits outweigh the negatives plus the cost of change. In this essay I hope to prove to you that the benefits could outweigh the costs; or at least close enough that it is worth exploring.

What is a codebase?

A codebase is fundamentally a large graph structure. If you look at the typical Java code base you have a bunch of classes with varying visibility organized into packages. The classes contain fields and methods which are composed of statements and expressions. A big tree. Since classes can call each other in varying ways, not to mention other libraries on the class path, we get a potentially circular structure. A codebase also has non-code resources like images, as well as some semi-code structures like XML config files (I'll leave out the build infrastructure for now). So we get a big complex graph that grows bigger and more complex over time.

A good IDE will create this codebase graph in memory. This graph is what gives you things like cheap refactoring and code completion. But when you quit your IDE what does it do? It serializes the entire graph as code split across multiple files and directories. When you restart the IDE it must regenerate this entire graph in memory. Though it wastes some CPU, this system would be fine if everything from the in-memory graph was preserved and restored perfectly without any data loss. Sadly it does not. The source code can't preserve developer settings. This is stored elsewhere. It can't store a history of what the developer actually did at what time. This is stored elsewhere or not at all. I think there is fundamentally something wrong with the fact that we are converting our complex graph into a lossy data store.

Source Code Is Lossy?

Yes, I think source code is lossy. A source file must meet two opposing demands. It must be human readable and writable with as little annoyance as possible. It must also be parseable into a graph structure (the Abstract Syntax Tree or AST) by the compiler without any ambiguity. These twin demands are sometimes in conflict, and when they are the compiler usually wins. Let me give you a simple example. Nested block comments.

In your typical C derived language like Java you can have block comments delimited by /* and */. You can also use single line comments that begin with // and finish at the end of the line. This basic system is a few decades old and has the unfortunate side effect that block comments cannot be nested. The following code is probably clear to a human but will choke the compiler.

some live code
/*
first commented out code
     /* second commented out code */
more first commented out code
*/
more live code

I know what this means but it is impossible for the compiler. Of course, the compiler could start counting open and closing delimiters to figure it out, but then it might choke on a */ stored inside a string. Or the human could nest the single line comments with the help of an IDE. All of these are solvable problems with a more advanced compiler or improved syntax, but they further complicate the language definition and impose more mental cost on the human doing the coding.

The Alternative

Now consider an IDE and compiler that work directly on the graph. I select some code in my editor and click the 'comment' button. It marks that section of the graph as being in a comment. Now I select a larger chunk of code, containing the first chunk, and mark it as a comment. Internally the IDE has no problem with this. It's just another few layers in the tree graph. It can let me move in and out of the code chunks with no ambiguity because it is operating directly on the graph. If the IDE can store this graph to disk as a graph then the compiler can also do its thing with no ambiguity. If we first serialize to human readable source code then parts of the graph are lost and ambiguity results.

This sounds like a trivial example, and quite frankly it is. That's the point. This is a simple case that is hard for the current system but trivial for a graph based system. How much more work must the compiler do to handle harder problems? Here's a few examples of things that become trivial with a graph system.

  • A version control system that loaded up a graph instead of text files could calculate perfect diffs. It would actually know that you renamed class A to class B because the IDE recorded that history. Instead, today it must reverse engineer this information by noticing one file is gone and another one appeared. If you renamed several classes between commits then the diff tool could get confused. With a graph the diffs would be perfect.
  • With perfect diffs the version control system could visualize them in a way that is far more useful. Rather than a bunch of text diffs it could say: "class A was renamed to B. Class D was renamed to G. Class E was deleted. Methods X, Y, and Z were moved up to superclass R. The contents of methods Q and R were modified. Click to see details."
  • Renaming and refactoring is trivial. We already know this because the IDE does it using an internal graph. What if other tools could do that. You could write a script that would perform complex modifications to entire code bases with ease. (James Gosling once experimented with such as system called JackPot).
  • As with comments, multi-line strings become trivial. Just paste it in. The IDE will properly insert it into the graph. The language definition doesn't have to care and the compiler will work perfectly.
  • Variable interpolation in strings is a function of the IDE rather than the language. The IDE can store "for ${foo} justice" as ("for " + foo + " justice") in the internal graph. This is passed to the compiler so it doesn't have to worry about escaping rules. Any sort of text escaping becomes trivial to deal with.
  • Since the parsing step is gone we no longer need to worry about delimiters like {} and (). We can still use them in the IDE to make the code more comprehensible to humans, but some programmers might prefer indentation to delimiters. The IDE will take care of it, showing them if you wish or hiding them. It makes no difference to the underlying graph or the compiler. Here's a great example of an IDE built by Kirill Osenkov with very creative ways to visualize code blocks.

  • New Things

    Once we have fully committed to storing the graph directly rather than the lossy plain text phase, other things become possible. We can store many forms of metadata directly in the graph rather than splitting it out into separate classes or storing it outside the code repo. Now the IDE can focus on making life better for the developer. Here are a few things I'd like to see.

    • A better interface for creating regexes. Define your regex in a special editor embedded into the main code editor. This editor not only provides docs and syntax highlighting, it can store example data along with the regex. Are you parsing credit card numbers? Type in 20 example strings showing the many ways it could go wrong. The editor shows you how they pass or fail. It also stores it with the source to be executed as unit tests by the continuous build system.
    • Inline docs would be editable with a proper WYSIWYG interface. No more having to remember the particular markup syntax used by this language. (Though you could still switch to raw markdown, html, etc. if you chose). Images in docs would become more common as well. You could also select a snippet of live code and mark it as being an example for the docs above. Then your example code will never be out of date.
    • Inline unit tests. Why must our unit tests be in a separate hierarchy run with separate commands. If it is good to keep docs near the code then it seems logical to keep the tests with the code as well. The IDE could give me a list of tests relevant to the current block of code I'm looking at. I can see the history of these test and if they currently fail. I can create a new test for the current code without creating new classes and files. The easier we make it to create tests the more we will be created.
    • Edit and store non-code resources inline. Icons, vector artwork, animation interpolators, hex values for colors. This would all be stored as part of the source and edited inline using the appropriate interface. Colors can be edited with a color picker instead of remembering hex codes. Animation can be edited with a bezier curve instead of guessing at values. The icon would actually be shown visually instead of just a file path. All of these things can be done today, but they become easier and more standardized if we work directly on the graph instead of plain text. Here is an editor called Field that shows some of the possibilities.

    • Once we get away from the file being the atomic unit of code, then we can start to arrange our code visually in other ways; ways that might be more useful to the human rather than the compiler. Chris Granger just posted a video for a cool new IDE concept called the Light Table.

    • Conclusion

      I hope I have shown you that there is a wide world of new coding ideas being explored, most of them not related to the language definition but rather to how we human programmers interact with the code. Certainly there are costs associated with such a change, but I think the costs could be dealt with if the benefits are worth it, and I clearly believe they are. We can update version control systems to work with a graph instead of text diffs. We can define a standard for storing the graph on disk so that any IDE can work with it. We can create libraries for manipulating the graph, enabling others to easily create new tools. Those are all solvable problems if we decide we want to.

      Ultimately my disappointment with new programming languages, and the impetus for my original essay, is that we live in the twenty first century but we still code like it's the 1970s. I want to see our field move forward by leaps and bounds, not incremental improvements to C, Smalltalk, and Lisp. The challenges our industry faces will be easier to deal with if we aren't wedded to our current notions of how coding is done. 100 core parallelization. Code scaling from non-smartphones to global computing networks. 3D interfaces built from scene graphs and real time imagery. Ubiquitous computing and latency driven design. We have lot coming, and coming soon, but our language researchers are acting like compilers and languages are a solved problem with only a few tweaks needed. And if we, the real world programmers, are afraid to try anything too radical then perhaps the researchers are right.

      But I don't think so. The challenges coming this century are huge. We should invent new tools to solve them.