John Lindal’s Blog

Lisp

While driving to work this morning, I finally separated out what has been bothering me about Lisp. Functional programming proponents tend to make a big deal about avoiding side effects because it avoids long range coupling between functions and it makes list iteration trivially parallelizable. This is good for program maintenance and effective utilization of all the cores in a CPU.

Side effects are eliminated by avoiding (1) global variables and (2) functions that modify their arguments.

Point #1 is relatively easy in any language (except assembly), but it does require discipline, since global resources like files and databases are in principle always directly accessible, even if an encapsulating interface exists.

Point #2 is very difficult/painful in strongly typed languages like C++ and Java but very easy in untyped languages like Lisp, Perl, and JavaScript, mainly because untyped languages make it very easy to return a heterogeneous list of values/objects.

This is what has been bothering me about Lisp in the back of my mind: a list is the most natural return value, both because the syntax is simple and because most standard functions operate on lists. A homogeneous list is fine, of course, but a list of heterogenous values is terrible because (1) it is hard to remember what is returned in each slot and (2) without compile time checks, modifying a function to insert a new value into the returned list creates a maintenance nightmare. You have to manually find and update every use of the modified function, and if you miss one, you have a subtle bug.

How can we avoid all this trouble? Using a map instead of a list alleviates the problems because (1) well chosen key names are easier to remember and (2) most of the existing uses of the function probably will not need to be updated because they do not care about the new value and the original values will still be accessible via the same keys.

Unfortunately, working with maps (or hash tables) in Lisp is a lot messier than working with lists. In Perl and JavaScript maps are part of the language syntax.

The Future of UI is not boring

Scott Berkun’s tangent off John Gruber’s wistful piece about the Apple Newton is flat out wrong. The future of UI is here already, and it is anything but boring. 10/GUI was announced several months ago, and SixthSense has been under development for a while. Both have the potential to revolutionize how we use computing power. The former replaces the ubiquitous desktop mouse, while the latter makes the iPhone seem antiquated and clunky. While neither will be available by Christmas 2010, gestures are invading our computing experience. Apple continues to execute on its long-term plan by introducing more and more gesture recognition in every new model of laptop and mouse. Designers who are not already thinking about how to effectively use the expressive power of systems like 10/GUI and SixthSense will probably find themselves out of work by 2020.

Avatar

The game has changed.

I was very skeptical when I read that James Cameron was out to out-Lucas George Lucas. I don’t believe it’s possible, but only because every game changing quantum leap up has the same general effect of blowing the public’s collective mind. But there is no question that Avatar has now changed the game in exactly the same way that Star Wars did thirty years ago. Audiences will not put up with 2D summer blockbusters much longer.

The story is certainly not as sweeping in scope as Star Wars, but Cameron deserves credit for at least thinking up an entire continent instead of only a few square miles of jungle. The characters were all stereotypes, and they died in the standard order, but they were still well done and served the purpose of making as deep an emotional impact as possible. As far as I can tell, that was what Cameron wanted: amplify the impact of watching full 3D by giving the audience characters to whom they can readily respond.