On my work blog I have a series of limited perspective movie reviews. These reviews, inspired by a Letterman bit, look at only one narrow aspect of a movie.

SPOILER ALERT: These reviews assume you have seen the movie.

Here’s Inception, Breaking Dawn, and Star Trek.

I watched Alien with a friend recently and was struck by [the ship computer] Mother’s display. This (SPOILER) review has the best (SPOILER) image I could find — unfortunately, green text on black is particularly susceptible to JPEG compression artifacts. In the movie, the actual display is extremely high-res (perhaps “retina”), with no pixels visible on my friend’s large screen showing the Blu-ray edition. On the other hand, the display is a green screen and fairly small. It’s an odd vision of the future.

My guess for the choice is that this was the best they could do in 1979, but I’ll try to make sense of it in the context of the movie, which is made quite a bit harder by Prometheus. In Prometheus, there are full-fledged holograms, so I’m guessing they have color displays. It was only 29 years earlier, so it’s hard to explain a display regression that wouldn’t also affect space travel technology. The only explanation is conscious choice on the part of the ship builder.

Here are our clues:

1. The computer doesn’t seem to be able to display anything other than text.
2. It can’t receive any input other than keyed in text
3. It has a natural language interface
4. The computer is offline with respect to Earth

My guess, actual Earth computers of this era are 100% speech driven with no displays. This disruptive innovation has decimated the display market.

Like now, the voice recognition requires a connection to server farm to pull off. As a hack, when you have to go offline, they give you some of the AI client-side, but can’t understand speech anymore so they slap on a display.

There’s, of course, no such thing as a display with less than retina quality as that bar was passed a while ago. However, since displays aren’t used by mainstream tech any more, they had to use a batch of small displays from some niche supplier — perhaps a line of hipster, retro digital alarm clocks.

I’ve had an interest on how people learn to program and have been thinking about the patterns I’ve seen that work. I’m particularly interested in the patterns I applied when I first started out.

I learned how to program in my junior high school’s “computer shop” class. One day we had to take a working slot machine application and alter it so that you always win. This assignment has a lot of things going for it:

1. The goal is simple to understand and remember
2. It’s fun
3. To do it, you need to read a program written by an expert
4. It’s a very small amount of code to complete the assignment, but the end result is a large system
5. There are many simple follow-on assignments that can be generated by the students

Eventually, if a student spends some time following their interests to propose and make changes, they will expose themselves to more and more of the program, generate questions, and direct their own learning. In the end, they will get a lot closer to being able to create a program like this themselves.

I am using this approach now to learn clojure. With github, we have access to programs written by experts, and crucially, a simple way to fork and change them. This has been a great way for me to learn, and it just occurred to me today that I learned this technique nearly 30 years ago.

Here’s what I’m using to learn clojure.

I’m reading Clojure Programming by Chas Emerick, Brian Carper and Christophe Grand. I’m almost halfway through (just finished the chapter on macros).

I once blogged that tech books were broken, specifically that they were too long. I got the Kindle edition of this book, so I didn’t even check the size until just a few minutes ago (Amazon says it’s 632 pages). My problem with long tech books is that most of the space is used on uninteresting reference information like tables of possible enum values, long program listings, and minute details that I’m mostly not ready for. I don’t think these kinds of books promote learning, and pointed out that the 200-page books on my shelf were also the best for learning (and most were classics).

This book, although long, doesn’t have these problems. It’s a teaching narrative, with quick repl sessions and the longer examples are still very manageable. Perhaps clojure lends itself to be presented this way — the code for generating a maze fits on my iPhone, and a repl session is an ideal way to learn a language.

After presenting the basic building blocks, the book also takes time to show you idiomatic clojure. The perfect example is the chapter on macros. When I first tried to learn clojure, I struggled to learn macros and basically hacked my way towards a simple OO implementation. At the time, I really didn’t understand macros, but I was in a self-imposed time-crunch, so I hacked something together — my final thoughts were

suffice to say, this is kind a crazy way to make something, but it sure beats not being able to make it.

Now, after this chapter, I feel like a have a solid understanding of the various macro features, and even better, a sub-section called “Common Macro Idioms and Patterns” will improve anyone’s macros, no matter what your level. There are similar sections throughout the book.

I’m using Light Table as my IDE, not so much because it’s a great IDE (it’s not yet), but because its Instarepl is a nearly ideal way for me to explore clojure. I suspect I will outgrow it when I want to make something real, but while I am just learning, it’s perfect.

Any new clojure programmer should be making an account on 4Clojure and solving problems. I’m working my way through them now — follow other users to see their solutions to a problem after you solve it (check out the top users page for good examples, or follow me for more tortured ones)

Finally, I highly recommend Chas’s Clojure Atlas, which is $5 if you buy Clojure Programming. You really have to go see it for yourself, but essentially, it’s a clojure documentation visualization and search web app — I was skeptical at first, but I could not live without it. Mostly, I use the search, which is lightning fast, but when you don’t know what you need, the visualization is key. Every documentation balloon also has a way to just see the source, which is perfect if you are trying to see well-written clojure. And, in a very nice touch, you never have to give the search box focus, typing always starts a search.

While reading Clojure Programming, I have been using Light Table as my repl for cementing my understanding. This is somewhat torturous, but one of the reasons I am using Clojure at all is because I want to ride the Light Table development wave — I think of it as an investment.

The big win with Light Table is the Instarepl — this is a repl editor tab where your code is continuously run and the values going through your functions are shown inline with your code. The first part of this video shows it in action:

[youtube_sc url=PsVJJp1XnzQ width=430]

My goal was to internalize the functional implementation of the Wilson Maze Algorithm and then to recreate it. Then, I implemented a maze solver (opting for a straight-forward recursion rather than the zipper-based solution from the book)

In both projects, the Instarepl-enabled iteration cycle let me explore a lot more than I might have otherwise. I was still learning during the maze-generation phase, so it still took a long time to get through it. By the time I was writing a solver, I was getting used to the language and its core functions, so that progressed very quickly.

The Instarepl is so powerful for learning that I have resisted installing a “better” clojure IDE.

Last night I decided to bite the bullet and start to re-learn clojure with the intention of adopting it as my web stack for personal projects. I had been curious about Light Table, so I started there.

If you haven’t heard of Light Table, it’s a new IDE concept that is best seen rather than explained:

Soon after this video, they raised money from KickStarter and YCombinator, and now we’re starting to see some progress. v0.2.0 was released earlier this month.

Light Table is really rough right now — you can see the potential, and it’s totally not fair to judge it now, but here are my quick reactions (I’m totally ignoring all buggy behavior, as that’s very expected):

The Rough

1. It’s somewhat unfriendly to start with if you already aren’t working on a clojure project. After a few minutes, I realized I really needed to get Leiningen working first, generate out a project, then use Light Table on the generated files.
2. The app is not signed, which Mountain Lion complains about — not a huge deal, but look at their website — they are projecting a nice brand and attention to details — getting this warning makes me think “side-project”. It’s easy to fix.
3. Error messages comes up in a pane that isn’t resizable and not big enough. With how good Light Table looks, this pane is out of place, and makes using it on something real very frustrating.
4. It’s slow in ways that are unexpected (like saving a file)

The Polished

1. Keyboard-oriented commands
2. Surprisingly good text-editing
3. The instarepl integration is slick — as is the in-editor form evaluation
4. Very nice looking — which is part of the reason I’m picky on the more rough parts.

In the end, it was Light Table that gave me the push to go back into clojure, but I wonder if I can stick with it. The other options are worse (for me) — I can’t imagine using Eclipse, I don’t know Emacs, and the simpler editors don’t have any repl integration.

Top two reasonable feature requests

1. Let me highlight a form and execute it
2. Some better way to show errors (probably don’t try to put it off to the side right now)

On my Atalasoft blog I wrote that I thought programming job applications should become more portfolio oriented, and

that means working code that I can run, and access to all of it. Probably the best thing is a running website and a github repository. If the software is hard to run, then a video walkthrough or screenshots are acceptable substitutes.

To learn more about what I want this to be like, I am starting to prepare a portfolio for myself.

One issue is that it’s important to decide what license to apply to it. If you don’t decide, then the default license is all rights are reserved, and the code isn’t very usable by anyone else. Since this code is meant just to show others what I’ve written, I guess it could be ok, but I actually don’t mind others using the code.

Another issue is that I intend to post code for projects that will be for sale (iPhone apps). If I put a permissive license, like BSD or MIT on it, then I run the risk of anyone being able to compete with me with my code and my permission.  But, not open sourcing real code would be against the whole point of making a portfolio. Fake code doesn’t represent programmers well.

I think Zed Shaw has the right idea about using GPL, not so much the why, but in what ways GPL helps authors.

Using GPL, I get these benefits

1. Use of the code requires attribution
2. You can’t put GPL code in the App Store
3. I can still grant BSD licenses on a case by case basis, and perhaps only on portions. To do so requires the developer to get in touch with me
4. Likewise, I can still choose to sell or give away commercial licenses, if I am contacted.

To me, github and the entire idea of a portfolio is to make code more social. GPL helps maximize that.

A few weeks ago, I tweeted:

Today, I was wondering how easy that would be, and spent about 10 seconds in google to find that Congressional staffer IPs have been outed by Wikipedia for editing their boss’s pages:

Wikinews contributors have discovered that members of the United States Congress or members of their staff have recently been making questionable edits to Wikipedia.

[…] In one instance, Wikinews found that someone with one of the IP addresses, 143.231.249.141, began to edit the Wikipedia article for Steve Austria, the Republican representative for Ohio’s 7th congressional district.

[…] Another individual, with the IP address 75.187.63.132, also removed the allegations of plagiarism from Austria’s article in February. The individual removed what they called “Politically Motivated BS” from the article of Deborah Pryce.

To confirm, I put the first IP in an IP Locator tool and got this:

From here you can figure out an IP range to target, and then it’s trivial to serve them different content (perhaps giving them a taste of what SOPA IP blocking would be like). I leave that as an exercise to the reader.

To be effective it needs to be done by sites that Congressional staffers actually depend on or on enough smaller sites to get media attention.

I believe that making a commitment public helps you stick to it. So, because I want to make more of my private code public on github, I am treating each Sunday as “Pushday”.

On every Sunday, I am going to push something, no matter how small, into github. If I have nothing useful, I will write something new. My only restriction, is that the push must be useful (a bug fix, new feature, a minimal project).

Today, I am taking one of the JavaScript files from my pet project ASCIIMatic, and making it available under BSD. ASCIIMatic takes simple descriptions of diagrams, translates them into dot, runs it through the dot interpreter to get a set of drawing instructions, and then draws the result in ASCII art. The vision is to make it easy to include UML diagrams in your source code comments, but it has a long way to go to do UML. Right now, it can do a some simple box and arrow diagramming.

Today, I pushed ascii-drawing.js, which implements a simple ASCII drawing surface with draw line, rect, and text commands.

It is available under the asciimatic-scripts project on github.