Feb 9

A Conversation Between Me and Seven Solaris Boxes

Jan 28
And if it looks anything remotely like a 7” iPhone, I’ll eat my hat.

— I hope you like the taste of wool, Mr. Stein

Jan 20

Cupertino Kremlinology

In preparation to try my hand at Apple prognostication, the standard disclaimers apply: I have no inside information, I am engaging in idle speculation, and I am fully prepared to eat my words. Okay. Let’s get started.

I’m not interested in what unreleased hardware will look like, since it’s safe to say anything designed by Apple will be simple and breathtakingly beautiful (as usual), and will solve the associated design challenges with kick-you-in-the-pants obviousness.* The interesting question I keep coming back to is whether a tablet device will run the iPhone OS, and by extension, run iPhone apps.

First of all, since the rumored tablet would presumably have more in common with an iPhone than your mom’s MacBook—multitouch screen, accelerometer—it’s safe to say it would not be running Mac OS X. Apple has already created a mobile version of OS X—the iPhone OS. Furthermore, it’s clear that Apple has designed Cocoa Touch from the beginning to have enough headroom to grow into a device with a larger screen. (Which might explain why the SDK took so long.) Evidence of this includes the UIWindow class, which exists even though iPhone applications display only one window. I bet Cocoa Touch on the tablet will allow multi-windowed applications.

I would also wager that the device would be able to run existing iPhone apps without any trouble. I’m almost positive, however, that they won’t run full screen. App developers have spent too much time optimizing their UIs so widgets are relatively finger-sized. The interfaces simply won’t scale without usability problems.

Given that size is less of a constraint in a tablet device, I expect the hardware to be powerful enough to support multitasking. This, combined with the presumption that the tablet would run iPhone apps at their native size presents an interesting UI possibility. I envision a dashboard-like layer where a limited number iPhone apps run as widgets on the tablet.

Pages of widgets

Picture this: iPhone apps launch on a translucent layer where a pair of widgets run side-by-side on the screen. A simple swipe will switch between pages of running apps that don’t fit on the first screen—just like having multiple pages open in Mobile Safari. Capping the number of simultaneously running apps is as simple as limiting the number of pages in the widget layer.

Apple would be crazy to launch a device without the momentum of the App Store behind it, and the only way hit the ground running would be to let existing iPhone apps run on a tablet. In the end though, Apple has spent far more time thinking about these problems and refining the solutions than all of the armchair product-designers and rumormongers combined. I may be wildly off predicting the app switcher, but it’s a fairly safe bet that whatever we see next Wednesday will blow us away.

* I won’t speculate on text input other than saying that I don’t expect to see Inkwell, Mac OS X’s pen input software, anywhere near this thing. Considering there’s no page dedicated to Inkwell on Apple’s website, it’s easy to guess how Jobs feels about this technology.

Dec 15

There’s a Price for That

Wolfram Alpha, the hilariously useless search tool, has an API. What sets it apart from Google, aside from choking on input every once in a while, is that Alpha’s API costs money.

You can get your first 1,000 requests for as little* as $60 a month! It’s only eight cents per additional request beyond that! But wait! There’s more!

If you’re a “student, hobbyist, or individual developer,” 25,000 requests will set you back $1,200. (Seriously folks, that’s $0.05 for every search.) If you’re a small or medium business, though, you’d better be ready to part with two grand for the same level of access ($0.08 per request). Never has market segmentation been so blatant. They also don’t tell you how to get your nickel back if the query was a dud.

Somehow I don’t think an API that has more in common with a casino slot machine than a scientific research tool is going to take off.

The pricing model I’m excited about is 280 North’s Atlas beta program. Here’s a slick web app for building slick web apps, and they’re not afraid to charge for a beta. No one has the balls to charge for beta these days, but these guys decided that $20 is a perfectly reasonable price to pay to test drive an online Interface Builder. And it is resasonable—reasonable enough that I wish I had a good reason to try it out.

I’m glad people are starting to move away from the broken economies of the ad-supported web. Both companies understand that in more and more cases, successful web ventures need to charge in order to be profitable. The trick, however, is to have something people are willing to pay for.

* That was sarcasm.

Nov 13
Sep 25

Half a Be

or, the sad truth of the eternal present tense.

Now that we’ve all either upgraded to Snowy Leopard or are patiently awaiting Windows 7, let’s extend a moment of silence for the operating systems that didn’t make it.

Inciting text for hopeful developers can still be found in the Amazon.com review of Programming the Be Operating System. While the review carefully—and, in retrospect, with good reason—avoids any claims of longevity, it makes no frivolous assertion of the powerful features of Be’s erstwhile chef-d’œuvre:

There’s not yet a big market for creators of programs that run under the Be operating system1, but its special capabilities may prove irresistible to experiment-minded programmers.

In 2001, Be, Inc. dissolved—it ceased to Be—but Amazon’s rosy marketing prose continues to remind us of good things long gone. Indeed, certain parts of the OS still have no equivalent in today’s systems. I studied their file system in great detail because it was so far ahead of its time. But the Internet does strange things to radical ideas. Some creations are buried and long forgotten because they are too novel, only to resurface when we’ve grown the capacity to comprehend their grandeur.


  1. I can’t describe the BeOS with any justice, so just check it out on Wikipedia or GUIdebook

Sep 11
A Subversion filesystem has its data spread throughout various database tables in a fashion generally understood by only the Subversion developers themselves.

— Thanks, guys. That makes me feel great about my data.

May 4
Oct 30
Simple is hard. Easy is harder. Invisible is hardest.

Jean-Louis Gassée (via brier via lkm)

Sep 22

Should a Computer Science Degree Require Learning C?

Just to add to the discussion started by Bijan and picked up by Marco:

The first programming language I learned was Logo. Being seven at the time, I had no idea I was using a functional language. I didn’t care what was going on under the hood—I just liked being able to write programs that turned my Apple II screen into a phosphorescent spirograph.

Over the next ten years I programmed in BASIC, VisualBasic, JavaScript, C, a little bit of C++, and Java. I thought that the differences between languages were just syntax.

Once I started taking college-level CS courses, I began to get the differences between languages. I was in over my head taking an Artificial Intelligence course as a freshman, and using Java didn’t make writing A* search any easier than using C. But when the professor told us to write a program to simulate how a robot might rearrange stacks of alphabet blocks, and told us to use a funny little logic programming language called CLIPS, suddenly everything was easy! I could represent the world with rules and facts, and I didn’t need to worry about pointers or objects because they didn’t mean anything in a world where everything was an alphabet block. The only things that mattered in this world were concepts like “move” and “on-top-of.”

That was my first exposure to a situation where matching the language to the problem made a huge difference. Yes, I could have written the program in C. But it would have taken ten times the effort to get the same result.

Over the course of four years, I was introduced to functional and logic programming. I programmed in machine code. Yes, machine code—I spent a week flipping DIP switches with the tip of my pen, implementing multiplication and division algorithms in the Z80 instruction set. I’m not a good programmer simply because I learned C. Yes, some of my courses happened to use C, but it was learning about computation at all different levels of abstraction that really made me a good programmer.

My computer science professors weren’t teaching specific languages, they were teaching different ways of thinking about problems. Now, if I’m writing for speed and efficiency, I use C. If I want to do rapid prototyping, I use Python or Java. And if I’m building a simple embedded system, I might not use a programming language at all, I might just burn state transition tables into an EPROM.

We need to be careful not to dictate which languages to learn. Why should someone learn C instead of Pascal? Who gets to say it’s better to teach Lisp than SML? If the answer to why we should be teaching C is, “it was good enough for me so it’s good enough for you and here’s a nickel, kid, buy yourself a real computer,” we need to seriously ask ourselves where the new ideas in computer science are going to come from.

While the trend of dropping C in favor of Java or (shudder) C# is turning some schools into nothing more than flavor-of-the-month clubs, requiring one specific low-level language is no better. Sure, if I had to chose a single language that would teach students as much about computation as possible, it would be C. But the best computer science programs teach concepts, not languages. Graduates need to understand pointers, recursion, automata, regular languages, and computational complexity, and this is best done by exposing students to a number of different languages that excel at each of those concepts.