Josh On Design

Book Updates

Mon Apr 16 2012 19:05:36 GMT-0700 (PDT)

Building Mobile Applications with Java Using GWT and PhoneGap

I'm happy to announce that my new book Building Mobile Applications with Java Using GWT and PhoneGap has been published in both print and ebook editions. While I love having a print edition, the ebook Kindle version, at $9.99 is half the price for the exact same content. Sure, you can't write on it with a marker, but the convenience and price is well worth it.

If you didn't catch it in one of my earlier blogs, Building Mobile Apps w/ Java, GWT, and PhoneGap is a shortish book (~80pgs) that gives you the good stuff and none of the fluff. GWT and PhoneGap are two great open source tools that, combined, let you use Java to make apps for non-Java platforms. This good gives you everything you need to know, starting with building a simple GWT app and compiling it for iOS, Android, and webOS. After we get familiar with the tools I'll walk you through some 3rd party libraries that make your apps feel more native. Then we will finish up with a 2D video game using the accelerometer and a physics library.

My goal was to give you everything you need to get started in as short a time as possible. You are busy people who need to get back to coding, so I don't want to waste your time. I think the finished work is right on target.

You can buy it here as well as download the source to the projects.

HTML Canvas : A Travelogue

I have also updated my self published app-book on HTML Canvas. It gives you a gentle walk through of what Canvas, how to use the APIs from drawing to pixel pushing, and then shows you how to build a simple game with 2D sprites and particle effects. The book also uses an experimental form of interactive code where you can change the values of variables in examples then see how the graphics update in real time.

I call this book an EverBook, meaning updates will always be free. The book itself is an app so if you already bought just check in your app catalog for the update. I've fixed a bunch of bugs, improved performance, and fleshed out a few sections. Also, stay tuned for a few more interactive features I've got up my sleeve.

You can buy the book here. $4.99 for iOS and $0.99 for webOS. (Shoutout to my webOS peeps!)

Sacred Language Cows Part 2: we can rebuild it. We have the technology.

Sat Apr 14 2012 10:48:40 GMT-0700 (PDT)

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.

An open letter to language designers: Kill your sacred cows.

Mon Apr 09 2012 06:39:34 GMT-0700 (PDT)

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.

A Roku April Fools

Mon Apr 02 2012 13:13:36 GMT-0700 (PDT)

If you saw my tweet about porting Chrome to the Roku, I'm afraid it was, indeed, an April Fools joke. I didn't actually rewrite Chrome in a TV scripting language. However, I did build something cool.

When you build software you have to map between two things. First is the representation that you develop with: your code, your graphics in photoshop, your CSS.. whatever it is. It's the thing you actually manipulate. Then you have the actual visual representation of the thing you are building: the app running on a real device, the page in the browser, the executing game.. whatever it is you are actually making. I believe software improves if we can minimize the distance between those two representations.

I suggest you watch Bret Victor's amazing presentation on the topic. It's long (1hr) but completely worth it. I have been a believer in this philosophy of minimizing editing distance for some time, but Bret explains it better than I ever could.

But back to the Roku

The Roku is very easy to develop for, but it still requires writing some code, turning it into an app, and installing it into the device. While not hard, it can be annoying. It also increases the distance between the editing and viewing representations. So, I decided to build a Roku power-up in Leonardo Sketch.

If you are new to my blog: Leo Sketch is an open source vector drawing tool I've been working on for a while. It can export to SVG, PNG, PDF, and JavaScript. The Roku power-up will export your current drawing into a Roku app, then compile and launch it. It is just a static image on the screen at this point, but it's a good start. In the future you will be able to add behavior and animation to the graphics. The Chrome April Fools hack was just a screenshot of Mac Chrome I had lying around, exported to the Roku through this plugin.

Leo Sketch Power Ups

Now you might be wondering what a Leo Sketch 'power up' is. It's a new kind of plugin system I'm working on, currently only available in an experimental branch. (the 'powerup' branch, if you want to try it out). Powerups are like plugins except they only have an effect when you explicitly activate them. This solves a lot of problems with traditional plugins, plus it enables a few new interesting things. I'll cover powerups more in a future blog. For now, just know that they will be awesome, and Leo Sketch will soon be exporting to far more than static image files.

Stay tuned.

Why Do We Waste TVs on Video?

Wed Mar 28 2012 09:05:55 GMT-0700 (PDT)

For Christmas Jen and I finally bought a TV after four years of distraction-less living. We finally decide it was time after countless evenings watching Hulu on my 15" laptop. We were adamant, however, that we would not buy cable. We just want a better way of watching Hulu, NetFlix, and a few other sites. To make that happen I bought the latest Roku device, Angry Birds edition.

If you aren't familiar with it, the Roku is a small box you attach to your TV with HDMI. It runs special apps that stream content over the internet and can display full HD content. The box itself is quite nice. It's super tiny, makes no noise, and uses a bluetooth remote instead of infra-red. You can also side load content from a USB stick.

For basic streaming of video from Hulu or music from Pandora the Roku works quite well. I wish the interface was a bit prettier and had smoother animation, but it yes the job done with minimal fuss. The apps is where the device has it's most potential but also it's greatest failure.

I have long been a fan of putting apps on a TV, especially when tied to an internet based store. The concept seems so obvious that I have to assume Apple is working on this (unless they decide to just stream everything through your iPad). Apps are a good way to view video because the content provider can customize the experience, but that is just the beginning.

For most people, the nicest display in their house is the TV. It is usually centrally located and has comfortable seating. And yet we only watch video on it. This seems like a waste. Such a beautiful high resolution screen should be used for much, much more. Dynamic artwork. Video calling. Interactive picture frames. Music visualization. And of course games. The potential is endless.

So why hasn't it happened? Honestly, I don't know. The technology has been ready for a couple of years. Roku and Apple can sell their devices at a profit (or at least break even) for under $100. I think the device makers are too focused on the lure of video. That's where the sexy business model is. They all dream of being the next cable company. The company that sits between you and the content, exacting a per-use toll. This is also the *hardest* part to do. And while they waste time dicking around with video streaming rights they ignore the potential of other uses for a beautiful large screen attached to the internet.

But I digress. Back to the Roku.

The Roku has it's own app catalog (called the Channel Store) where you can get both paid and free apps. Unfortunately the selection is meager and the interface is horrible. It's a table of rows, each showing a picture of the app. When you choose an app you see a details screen where you can purchase it. This interface simply won't scale. There is no searching and few categories. The details screen has no ratings or screenshots, just the 'cover art'. And the selection of non-video apps is horrible. A few bad games and radio apps.

I'm not sure why the Roku is like this. They've solved most of the hard parts: initial setup, in app payments, device navigation, OAuth association with online services. They just don't have the apps. App development itself is fairly easy. You must use their proprietary BrightScript, but it's easy to work with. The SDK is just some command line scripts that install right to your test device. They clearly took a few pointers from webOS on how to make development easy. My only suggestion would be switching to JavaScript (and making the native sdk public).

The other thing that makes me wonder is that the features of the device haven't changed much over the past few years, and their development process seems slow. They announced their 3.0 SDK about a year ago but it only just went final, with fewer features than expected. They have Angry Birds running but only allow native development access (C + OpenGL, I'm assuming) for special developers. They promised to open it up to everyone, but nine months later they still haven't. For a startup this seems slow.

There is also a few apps that I really expect to be present and aren't. You can stream photos from FaceBook and listen to Pandora, but there is no built in app to stream music, movies, or photos from your desktop computer. Given that their main competitor, Apple, did this from day one I'm not sure why it's absent. The few 3rd party apps which do this are horrible! This is especially surprising since I would think that streaming MP3s from a network drive would be the first thing people in the open source community would do. BTW: I did try Plex but it doesn't do music. The other MP3 apps I found were amazingly slow and ugly.

So, things brings me to three questions that I can't answer:

Why is Roku the way it is? Are they focusing on other things (better content deals)? Are they understaffed? What's up?
Is there any interest in an app to stream music from your iTunes lib on your desktop (it would require a single click server on the computer). I'd love some help on it to make it non-ugly.
Am I wrong about using modern HDTVs for non-video purposes? Is there simply no interest in this?