Sodium DreamsA Conversation Between Me and Seven Solaris Boxes
- Me: Hi, there! I need to manage user accounts across all of you.
- Solarae: Ha ha ha, good luck, fucker.
- Me: Aha! But I have a secret weapon. Kerberos!
- Solarae: Gahffffffk! Nooo! I refuse!
- Me: Dammit. I said, "KERBEROS!"
- Solarae: Mrfgk. Fine.
And if it looks anything remotely like a 7” iPhone, I’ll eat my hat.
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.
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.
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.
Verizon Expects You to Bend Over and Take It
I bet you still can’t wait to drop AT&T, citing reasons such as “lousy coverage,” or “slow downloads”, or “screw you, Ma Bell.” But you know what? These decisions are all trade-offs. There’s no magical carrier that offers excellent coverage everywhere you need it, and supports your favorite phone, and offers reasonable pricing. You make a choice based on which network meets most of your requirements.
Of course the recently publicized news about Verizon’s charging for accidental data use shouldn’t come as a surprise to anyone. In fact, I’m surprised that there isn’t news about more wireless providers employing the same tactics. [UPDATE: Seems like AT&T does the same thing. As an iPhone customer, I wouldn’t have noticed.] It’s well established that carriers charge a 4900% markup on text-message costs. Until there was a huge public outcry, every carrier regularly ate up an additional fifteen seconds of your voice minutes with redundant voicemail instructions.
We know the carriers are money-grabbing robber barons that treat customers with hostility and contempt. Stop whining about wanting to switch to the carrier that supports the right handset or has the best coverage. Voting with your wallet in this case is pointless because some greedy carrier is going to have their hand in it no matter what. The carriers won’t change for anything short of a revolution.
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.
A Subversion filesystem has its data spread throughout various database tables in a fashion generally understood by only the Subversion developers themselves.
Why text messages are limited to 160 characters
Via marco:
Via Rocketboom:
Alone in a room in his home in Bonn, Germany, Friedhelm Hillebrand sat at his typewriter, tapping out random sentences and questions on a sheet of paper. As he went along, Hillebrand counted the number of letters, numbers, punctuation marks and spaces on the page. Each blurb ran on for a line or two and nearly always clocked in under 160 characters. That became Hillebrand’s magic number — and set the standard for one of today’s most popular forms of digital communication: text messaging. “This is perfectly sufficient,” he recalled thinking during that epiphany of 1985, when he was 45 years old. “Perfectly sufficient.”
While that’s a cute story that makes for a good article, it sounds like the real reason for the 160-character limit was more because the data channel’s packets had 128 bytes available for this sort of use and they restricted the character set (to a subset of 7-bit ASCII, I believe)
While the story may feel apocryphal, or even embellished, the typewriter exercise was crucial usability testing. Had someone not taken the time to count the number of characters in hundreds of messages, engineers would have simply said, “we can fit 128 ASCII characters in 128 bytes. Simple. Done. Next.”
It is very much like one of Andy Hertzfeld’s stories of the development of the original Macintosh at folklore.org. Bill Atkinson was developing drawing routines for QuickDraw and thought the functions for rounded rectangles would be too computationally intensive for the CPU. Steve Jobs wouldn’t hear it, insisting that “rectangles with rounded corners are everywhere!” He pressed the matter, taking Atkinson for a walk around the block pointing out every rounded rectangle he saw. It turns out that when Atkinson wrote the code, he was able to optimize it to the point that rounded rectangles drew almost as quickly as plain ones.
The point of this aside is that usability very often requires creative engineering solutions. When a system has certain hard limits, the trivial implementation imposes those limits directly on the user. Any creative limit pushing has a big impact on a product’s ease-of-use.
Simple is hard. Easy is harder. Invisible is hardest.
— Jean-Louis Gassée (via brier via lkm)♥
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.
