Kartick's Log

Thoughts on the Android Design Guide

2012-02-16T16:16:00.002+05:30

Google (full disclosure: my employer) put out a design guide for Android, on the lines of Apple's Human Interface Guidelines. Here's what struck me about it. A + is for things that are good, and a -, well, for things that are not.

- I'm surprised at the guideline that actions be placed at the top of the screen, because they are hard to reach, which is all the more important on oversized screens like the Galaxy Nexus.

- In addition to the global back button Android has always had, there's now an Up button like on iOS and (surprise) both can behave differently. To me the global back button is confusing and just broken. Even worse is having both. Just get rid of it and let apps control navigation.

- Some of the feedback to gestures isn't right. For example, when you scroll past the end of a list, it glows, rather than bouncing as on iOS. I can guess why the Android team chose that, but it doesn't change the fact that it is the wrong kind of feedback. The whole point of direct manipulation touch interfaces is that they present an illusion of touching the content directly, and a physical action (moving the content) warrants a physical reaction like bouncing, not a reaction of a dissimilar kind, like glowing or beeping. Another example is that the tilting animation when there are no more pages, which is a total non-sequitor:

- It's good that Android moved to an iOS-like home screen that pages rather than scrolls. Paging is better for the usual reasons — it gives you information in increments, rather than forcing you to keep track of what you already saw vs. what you didn't. When you scroll, you have to keep track of the last read item as it moves. Keeping track of a moving object is tedious by itself, but you also have to scroll till it just goes off the screen, while taking care not to let unread stuff go offscreen. Paging is a more automatic version of scrolling that relieves you of this tedium. Further, with paging, you can form a memory like "Twitter is on the 3rd home screen, at the top-right" which is harder with scrolling because things don't have fixed vertical positions on the screen.

But Android still retains its drawback of alphabetical organization, which means that the icons all rearrange themselves when you install an app. You lose your memory of where something is, both consciously and muscle memory. The Gallery app was the last icon on the first home screen, but when I installed Facebook, it no longer is. Things that you know where to find become lost and you have to keep searching for them again and again.

On the other hand, the alphabetic system helps you find any app, even infrequently used ones, which get lost all the time on iOS because you don't know where they are. Spotlight helps you find an app only if you know a good part of its name, while with an alphabetic system, you can find an app by knowing only its first letter. For example, I installed Seesmic, a Twitter app, but later forgot the name, except that it starts with S. Spotlight won't work for that, but Android's alphabetical system does.

But finding frequently used apps is more important than finding infrequently used apps, since you use the former more often, by definition. So the iOS system is better than Android's alphabetical one.

In addition, Android's two-level home screen is unnecessarily complex, with some icons on the home screen and others in an applications menu. A single list as in iOS is simpler and better. That doesn't prevent you from creating shortcuts to websites, contacts, etc and putting them on the first home screen. iOS already allows that for web pages, and it could trivially be extended for other kinds of shortcuts like contacts.

Besides, Android's two-level hone screen precludes use of folders. Folders on the Android home screen don't make sense, since the home screen is supposed to hold shortcuts, and putting shortcuts in folders defeats the point of shortcuts. Folders make sense for the apps list, but are not available there.

+ I like the recommendation to "use non-neutral colors sparingly and with purpose. " The focus nowadays seems to be on the content rather than the UI of the app itself.

+ It's good that Android lets me set a font size globally. I set my desktop browsers to use a minimum font size of 16, though I'm in my twenties and can see perfectly well, just because it's more comfortable to read (try it!). With the move to native apps, we sorely need something like that, and Android finally delivers. I don't know what the impact on UI layouts will be, when everything is dynamic. Maybe it's not much, since developers can't assume a specific screen size (unlike on iOS) and so the layout has to be dynamic anyway. Web pages with a minimum font size of 16 mostly work fine, so the cost can't be high, and I'm happy to impose that cost on apps, because comfortably readable text is more important.

+ I was skeptical about the onscreen home button controlled by the OS rather than the hardware home buttons that iOS and Windows Phone 7 use, because there's no tactile feedback. But I was surprised to find that it actually works better way, and that there's three kinds of feedback: it glows, and the phone vibrates, which you can both feel and hear. It's less effort to press this on-screen button than the iPhone home button. And it's a smoother, more consistent system where you do everything on-screen. iOS is jarring in that way, requiring you to move between the screen and the hardware home button. Physical buttons are the way of the past.

- The multitasking button lets me jump effortlessly between apps. Partly this is because it's visible, whereas the task switch gesture on iOS is a gesture -- there's nothing on screen to indicate it. But more importantly, it's one tap instead of two, and tapping on the screen is less effort physically. The result is that on Android it feels like I'm moving directly from one app to another, whereas on iOS it feels like switching from one app to the "system" (even if it's the double-tap switcher) and from there to the other app.

But I think the Android multitasking button is too much of an intrusion into the current app. On a small screen, you want to dedicate as much space as possible to the app at hand rather than providing buttons for switching apps. Besides, it's confusing (even for a geek) to have an app switcher along with an in-app tab switcher, both visible at once.

If you get rid of the multitasking button and the back button (see above), you're left with just a home button, and that doesn't justify a whole horizontal bar, not on phones and certainly not on tablets, where it wastes a lot of space and looks ugly. Maybe the home button can reside in a corner of the screen, perhaps next to the time, signal strength and other indicators and notifications, and leave the rest of the space for apps. In other words, move the status bar to the bottom of the screen (like it is on Android tablets), put the home button at the left, at 48 x 48, and keep the rest of the status bar at its current height (25 pixels). You can disagree with this specific solution, but the more important point is: the global bar that Android puts at the bottom of the screen doesn't make sense.

- I don't know why they redefined long press to enter a data selection mode.
1. I want to act on one item, like marking an email spam, more often than entering a selection mode where I can act on many items.
2. Modes are confusing because, by definition, things behave differently. If you can act directly on one item, you shouldn't have to enter a different mode. Long-press on iOS and pre-ICS Android fits the bill perfectly (as does swipe to delete a row in an iOS table view).
3. What do you do when you're done selecting? You want to perform some action, which the guide says should appear at the action bar at the top of the screen. Why not near the item(s) selected, where it really belongs? That way, it's clear which email will be marked as spam, and it works better on tablets, where users may not notice something change far away from the thing they are interacting with.
4. If you want to enter an edit mode that lets you select and act on multiple items, since a mode is global (it affects the whole UI and not just the item you long-pressed), it's logical that the trigger to enter the edit mode also be a global action not associated with any particular item. That is, you should enter edit mode by pressing a global control, like the edit button on iOS table views, and not by long-pressing one item. In fact, since iOS table views are a standard view and are therefore used across tons of applications, users know how to edit items in any table view. Android should also come up with a standard OS-wide multi-select mechanism.

+ They've fixed a problem that developers had where notification icons were not visible on some phones because the status bar color was, ahem, "enhanced" by the OEM and turned out to be mostly the same as the icon. The guide has a solution: "Notification icons must be entirely white. Also, the system may scale down and/or darken the icons."

+ The design calls for a minimum tap area of 48 pixels, more than the 44 the iOS HIG does. I guess this is because some Android devices have fewer pixels per inch than even the 320x480 iPhones.

Ultimately, all this is secondary. I would like Android to be as beautiful as iOS, and I don't see this design guide achieving that goal without, for example, even better first-party apps, a culture of high user experience standards, moving away from too much configurability, etc.

While I find the Galaxy Nexus to be on par with the iPhone (finally!), Android isn't yet as good as iOS, purely in terms of software. I'll be much more interested in going through the design guide when that changes, since I ultimately care about the results, as a user and a developer.

Examining the integrated model

2011-12-22T10:21:00.002+05:30

I've heard for almost a decade that the fact that Mac OS X runs only on Apple hardware makes for a better user experience. I hadn't really understood why or stopped to think about it, so I did that now, and here are some ways it helps.

Lion's fullscreen mode is amazing. The three-finger swipe makes it easier to switch between fullscreen apps (or spaces, for that matter) than to switch between windows. This is a tremendous achievement, since the traditional full-screen mode makes it harder to switch between apps, and so full-screen is not used much, except for movies and presentations. Besides, Lion's full-screen mode makes the Mac more of a distraction-free device like the iPad, making it pleasanter and more relaxing to use. It also makes better use of screen space, which I never have enough of on my 15-inch Macbook, let alone on 13- or 11-inch Macbooks. In fact, one could say that Lion's full-screen mode lets us have these small laptops in the first place, without severely trading off comfort or productivity. Finally, smaller laptops are lighter, more portable and cheaper. All this is made possible because of Lion's full-screen mode, which is practical to use only because of the three-finger swipe.

This requires a trackpad that supports three-point touch, is sensitive enough, and big enough that you can comfortably swipe with three fingers. There are other multitouch gestures in Lion; three-finger swipe is just an example. The point is that it doesn't make sense to build multitouch gestures into the OS without hardware that makes it convenient enough to be useful or vice-versa. Otherwise, you just get a meaningless item on a checklist. Windows PCs suffer from this perennial chicken-and-egg problem.

Apple can add dedicated hardware buttons for things like Mission Control. Again, how easy it is to use something often determines whether it makes sense in the first place.

Macs don't need you to install drivers for things like the webcam, extra keys on the keyboard, the infrared remote control, etc. Drivers on Windows are not well integrated into the OS and feel like a kludge, they don't show up in Control Panel, they need to be separately installed and updated, they make the system slower, clutter up the system tray (I don't need an icon for my webcam any more than I need one for my hard disc), come with bundled crapware apps, and generally don't work anywhere as well as on the Mac. I remember when I switched to the Mac a few years ago that everything worked without all this detritus. It was a "less is more" moment for me.

Apple can add hardware capabilities like WiFi Direct to enable features like AirDrop. In retrospect, isn't it backward not to make use of physical proximity to send files more easily?

Apple has eliminated support for obsolete hardware to simplify and improve things for users. For example, Apple has been using EFI for years, while most PC hardware is stuck with BIOS. EFI boots faster and from hard discs bigger than 2.2TB. Similarly, Lion requires a 64-bit CPU. This is easy since Apple hasn't shipped a Mac with a 32-bit CPU in years. Whereas Windows 8 still has to support 32-bit CPUs. When I read that to boot from a 3TB hard disc, you need 64-bit Windows (which of course requires a 64-bit CPU) on a system with EFI rather than BIOS, it makes me angry. Why does this stuff have to be so complex? Why should someone configuring a machine with a bigger hard disc for their movies have to get their hands dirty with all this arcane stuff? Why can't the damn thing just work? Computers are broken in many ways, and getting rid of legacy stuff, as with this example, simplifies things for users. This is much easier when you control both the hardware and the the software.

Mac USB ports provide extra power for iPhones to charge quickly (1100mA compared to the 500mA maximum under the USB 2 spec) [1]. Similarly, Macs can wake up when accessed via WiFi, not just Ethernet.

Internet recovery is built in to the firmware on recent Macs, so if you have a hard disc that's somehow been wiped clean, you can boot off Apple's servers and run the installer, rather than having to boot from a DVD (you may not have a DVD or a DVD drive). A Mac can no longer get into a state it can't recover from, and this is possible only because Apple controls the firmware.

OS X doesn't need to handle an endless variety of hardware, including broken ASUS stuff.

The bottom line is that if you're in the business of making the best user experience, the integrated model is the way to go.

Footnotes:
[1] For that matter, I wish Apple supplies 100W power via the Thunderbolt bolt on the Apple Thunderbolt Display, so that you can plug your Macbook or Mac Mini into your Thunderbolt Display with a single cable for charging, video and data. When your data cable supplies all the power you need, you don't need another cable.

Similarly, iPads should use a Thunderbolt port so that you can plug it in to a Thunderbolt Display and have it charge while using the external monitor (and maybe even a keyboard and mouse), or plug it into a Mac and have it charge (iPads need 10W, and Apple's USB ports supply only 5.5). It doesn't make sense for Apple to have two different connectors that both support data, power and video.

Simplifying the Mac Branding

2011-11-14T22:00:00.001+05:30

Since the branding for Apple's current Mac line seems to have evolved organically, starting with the iMac in 1998, I wanted to see if we can overhaul and simplify it, so that it stays fresh and relevant for the future, rather than being an artifact of the past. Of course, we want to retain its distinctiveness, and minimize unnecessary change.

The iPhone is an excellent brand name. It's distinctive, while fitting in to the overall Apple brand (the "i") and being minimalist, by just adding one letter. It stands for Apple's quality and esthetic, products that are simple and beautiful, without a bunch of half thought-out features or tacked-on ornamentation.

To begin with, let's use Mac as the backbone of the brand family. It's distinctive, and so doesn't need an "i". Come to think of, isn't it weird that Apple sells some iMacs and some plain Macs? I mean, wouldn't it be odd if Apple sold an iPhone and a plain Phone?

Since more people buy Mac laptops than desktops, let's drop the "book" from the MacBook and make that the default. Let the desktops have a qualifier, instead.

So, here are the new names, on the right, with the old ones on the left:

Macbook Air -> Mac Air

Macbook Pro -> Mac Pro

Mac Mini -> Mac Desktop Mini

iMac -> Mac Desktop

Mac Pro -> Mac Tower

Notice how the laptops have clean, simple names. I cringed when I first heard of "MacBook Pro". Why did Apple throw away such a sleek and modern Powerbook name for this clumsy one? Well, this rebranding fixes that.

I also like that the Mac Mini and the iMac have similar names in the new scheme, reflecting their similar nature — desktops rather than laptops or workstations. I think the Mac Mini should have all iMac features and vice-versa, except for the built-in monitor.

I think this cleaner, modern branding will stand Apple and the Mac community in good stead for the next several years, and reflect the attention to detail that makes the platform what it is.

Is the Android Back Button a Good Idea?

2011-11-10T16:05:00.000+05:30

For some reason, the Android back button is topical again. Christopher Du Rietz and John Gruber both say that it's a bad idea. I've thought so, too, an year and a half back, but I wanted to see if anything changed since then, or if my thinking evolved. So, let's look at arguments for and against the back button.

Arguments For the Back Button:

Consistency: No matter what screen you're on, there's almost always a previous screen to go back to, so it makes sense to have a standard button for it, for the same reason the browser has a back button, or iOS devices have a home button. Don't leave it to apps, because they could handle it differently.

In addition to consistent in-app navigation for all apps, you also want to use the same system to navigate out of an app as you use to return to the previous screen within the app. On iOS, you navigate within an app by using the on-screen back button, but when you reach the top level of the app, you have to use the physical home button to navigate out. This feels like apps have rigid boundaries rather than things flowing together smoothly. Android back button navigation feels more natural.

In addition to navigation within an app and navigation out of an app to the home screen, you also want consistent navigation across apps. This is important since Android apps blend together smoothly by invoking each other. In fact, apps on Android are composed of activities, one for each screen, which can be invoked from other apps. For example, the compose screen of an email app is a different activity from the inbox. Activities from different apps intermingle smoothly into an activity stack, to the extent that you navigate between apps without noticing it, and the back button is critical for this. When you click on a link in an email and decide to tweet it, you have an activity stack consisting of Email -> Browser -> Twitter. Pressing back from Twitter returns to the browser, and pressing back again, to email. This kind of seamless navigation requires a back button independent of a particular app.

This kind of smooth navigation between apps is much better than on iOS, where each app is a world unto itself, and there's a lot of friction in moving between apps. So iOS apps have to have in-app browsers for accessing links, with different functionality and interfaces and you sometimes need to tap the Open In Safari button, whereas Android apps just launch the browser, which works better.

So, to summarize, back button navigation is consistent for:

in-app navigation, no matter which app you're using.
navigation out of an app to the home screen.
navigation across apps in an activity stack.

Tactile feedback: Well-implemented hardware buttons, like on the iPhone, are easier to use than on-screen buttons. Unfortunately, many Android phones squander this advantage by using capacitive buttons (like on the Nexus S) or by using OS-controlled on-screen buttons (like on Ice Cream Sandwich/Galaxy Nexus).

Arguments Against the Back Button:

It's not labeled: On-screen buttons can be labeled to tell the user where he's going to go if he clicks the button. It should be obvious why that's better.

Intra vs inter app navigation: But there's a deeper problem — it could take you to different places depending on where you navigated from, which could even be another app. John puts it well:

Here’s one thing I don’t like about the Android Back button that I’ve never seen a counterargument for: it presumes that you, the user, remember the activity stack. If you turn your phone on and you’re looking at a web page in the browser, if you don’t remember what you were doing immediately before opening the web page you’re looking at, you have no idea where you’re going to go if you hit the Back button. Could be another app, could be another web page, could be the home screen. And if hitting the Back button takes you somewhere you didn’t want to go, there’s no Forward button to reverse it. It’s like leaving a breadcrumb trail in the dark — you have to remember where the breadcrumbs are because you can’t see them. Drove me nuts.

By contrast, iOS back buttons always navigate to another screen in the same app, and so are less confusing. Yes, that means that apps have rigid boundaries and some friction switching between them, but it also means that the back button is less confusing, because it never takes you to another app or to the home screen.

Back or Up? Forget for now that the back button can take you to another app. Assume it takes you elsewhere within the current app. But where? Most people would say that it takes you back to the previous screen within the app, the one from where you came. But that's not always true. Here's an example: from the home screen, open Evernote. It starts by showing you the last opened note. Press back. Where do you expect to go? The home screen, right? But it actually takes you to your list of notes — a screen that you've never seen before and isn't therefore in the activity stack.

And no, Evernote's not doing anything wrong. They could "fix" it by always opening the list of notes and forcing you to navigate to the note, so that the back button takes you back to the previous screen, but that would make it less usable.

The real problem is with the back button, which sometimes behaves like the browser's back button by taking you to the previous screen in the activity stack, and sometimes like iOS's back button by taking you one level up in the app irrespective of history. It should just make up its mind and do one thing consistently.

Doesn't work well with long press app switching: We've seen how the back button can take you back in the activity stack or to a brand new screen. But it gets worse than that. It can take you to another activity stack. Yes, Android has multiple activity stacks. If you were to navigate from the home screen to Evernote's list of notes, and then to a specific note, then press the home button and go to Google Maps, you have two activity stacks:
Home -> Evernote list of notes -> Evernote note
Home -> Google Maps.

Now, while in Maps, you can long press the home button to bring up the list of apps, and tap Evernote, and it shows you the note you were viewing. Now what do you expect the back button to do? One might expect it to take you back in the current activity stack (Evernote's list of notes) or to the screen you came from (Maps). This is confusing. But it's even worse — it does both. It first takes you back in the same activity stack, to the list of notes, but when you press back again, it takes you to the previous activity stack, to Maps.

[Actually Evernote has one more level of hierarchy, but I'm eliminated that for simplicity — it doesn't change anything here.]

It makes you go in circles: Christopher explains:

If I get a mention on Twitter and open up the Android Twitter app to check it out, I’m (naturally) sent directly to the tweet mentioning me. Ok, so I want to get back to the main timeline, what do I press? The answer is: you can’t. Pressing the back-button, which is the only real candidate for this action, will take you wherever you where before seeing this screen, which in this case was the home screen, exiting the app. Hmm, so how do I get to the main timeline? I have to open Twitter again, showing the same tweet I saw before and now press the back button, and it will take me to the main timeline.

Notice that the user's going around in circles: A -> home screen -> A -> B. I've had the same experience with other apps. Obviously, it's stupid and irritating to go around in circles. Why on earth can't I go from A to B without going elsewhere, returning to A and then going to B?

Doesn't work well with modal screens: If the user's writing a review in Google Maps and presses the back button, what does it do? The user has no clue, because it's not labeled, and doesn't even make sense in a modal screen, by definition — you want explicit Post Review and Discard buttons. But you can't remove the global back button; it's always there, whether it makes sense or not.

Learning curve: Android back buttons have a learning curve because you have to remember that some controls are on-screen and some are off-screen.

So, to summarize the problems with the Android back button:

Users don't remember the activity stack.
The back button can take you to another screen in the same app or to another app.
The back button takes you to the previous screen in the app, except when it takes you to a screen you never visited.
It can take you to another activity in the current activity stack, or to another activity stack, or both.
It makes you go around in circles.
It doesn't work well with modal screens.

This is way too much complexity. I couldn't understand or predict the behavior of the app button (despite being a programmer who builds mobile apps) and resigned myself to it behaving arbitrarily, taking me where I didn't want to go, and having to find my way back to where I did want to go. iOS's back button works like a charm, in comparison. The price of rigid boundaries between apps and friction in switching between apps is small in comparison to this massive confusion.

A Comparison of Web OSs

2011-11-10T10:41:00.002+05:30

Many web-like operating systems exist or have been announced, and I found it useful to compare and classify them, from most web-like to least, in the order below:

1. Chrome OS: This is perhaps the most web-like operating system in that it doesn't have its own API. This is rare, and the obvious downside is that things that can't be done on the Chrome browser can't be done on Chrome OS at all. This is a big limitation because, if something can't be done on a browser running on a traditional OS like Mac OS X, you can always write a native app, but when native apps don't exist, being restricted to HTML APIs is a far more severe limitation.

2. Mozilla's Boot 2 Gecko is similar to Chrome OS, but they plan to define new APIs as needed for their use cases (like a smartphone) rather than saying, "There's no HTML API? Then you can't do whatever it is you're trying to do." In that sense, it's user-experience-driven, rather than technically-driven, and Mozilla plans to try to standardize new APIs they propose.

3. Slightly more impure is Palm webOS, where there's no goal to standardize their APIs. It's a proprietary system built using Javascript/HTML/CSS.

4. One step further down in terms of being pure web-like is Windows 8, which like webOS defines proprietary APIs, but accessible from multiple languages: Javascript, C#/.NET and C++. This probably means that the APIs are defined in C++, with bridges to Javascript and .NET. Does that mean APIs will be defined in the lowest-common denominator of these supported languages, rather than making use of all of Javascript's features? Will there be an impedance mismatch if you're writing an app in HTML/JS, because an API defined for Javascript is always going to be more natural to use from Javascript?

Tizen (driven by the Linux Foundation, Intel and Samsung) falls in the same bucket as Windows 8, with APIs that can be invoked from HTML and from C++ apps.

5. Finally, the least web-like OSs are the traditional ones, like iOS, Android and Mac OS X. There are third-party toolkits like PhoneGap or Appcelerator Titanium that let you write apps for these platforms in HTML, but these expose only a subset of native functionality, and define their own API rather than bridging to the native API. By which I mean: on Windows 8, a particular API is going to be essentially the same no matter which language you use it from, whereas Titanium APIs are different from the underlying iOS and Android APIs. Obviously, this is not an ideal situation.

In practice, first-party support makes all the difference — if you're building an iOS app, you'd probably use Cocoa Touch rather than Appcelerator. But conceptually, they are similar to Windows 8 in that the real API is defined in C++, and then bridged to other languages in some way.

So, that's the classification, from most web-like (1) to the least (5).

Re-examining the Mac desktop line

2011-11-10T06:05:00.001+05:30

On the news of the Mac Pro's rumored cancellation, Marco wrote a perceptive blog post examining various changes Apple could make to the Mac Pro, concluding:

It’s impossible to significantly change the Mac Pro without removing most of its need to exist.

That set me thinking about the iMac, and whether it makes sense to pay a lot of money when you'd probably be happier with a laptop and an external monitor for not much more money. To make this concrete, I configured a few machines on the online Apple store, so that we can compare prices.

(This is a subjective exercise, and if you disagree with some of my choices, I'd encourage you to try it out yourself to see what conclusion you'll reach. Please post it in the comments.)

For the iMac, I wanted the biggest possible hard disc (2TB), since you can can never have enough disk space. The cheapest iMac with that disc cost $1649, but then there was only a $200 increment for the 27-inch, and given the huge difference the extra screen space makes, I chose the 27-incher, for a price of $1849.

I then tried to configure a Mac laptop with an external monitor. For the monitor, I chose a 1920x1080 monitor with an LED backlight, DisplayPort input, and height, pivot, tilt and swivel adjustments, for $200 -300, conservatively rounded up to $300. These monitors have sizes between 21.5 and 23 inches and are not made by Apple (I don't consider that important). I didn't choose a larger monitor, like 27 or 30 inches, since those are very expensive (the price difference is much more than the $200 difference between the 21.5- and the 27-inch iMacs above).

For the laptop itself, I chose a 15-inch Macbook Pro, since I'm told you need dedicated graphics for animations (like Expose) to run at high frame rates on big external monitors. I chose the biggest possible hard disc (750GB) and the high-res screen. The cheapest Macbook Pro with these specs costs $2049, or $2349 with the monitor.

I also wanted to see how the Mac Mini compares. I chose the cheapest one (2.3Ghz), bumped the RAM to 4GB and chose the biggest hard disc (750GB) for $849, or $1149 with the same monitor. Of course, you get only a dual-core CPU on the Mini unlike the quad-cores in both the iMac and the Macbook Pro.

So, this is the bottom line:
iMac: $1849
Macbook Pro + monitor: $2349
Mini + monitor: $1149.

Notice that the Macbook Pro with the external monitor costs only $500 more than the iMac. If I'm ready to spend $1849, I'd rather spend $500 more for the enormous convenience of a laptop. I mean, $1849 is very expensive for a desktop. For that much money, I'd expect a laptop, and I can have one, for only $500 more (including an external monitor). Or I'll save a lot of money by going for the Mac Mini with a monitor for $1149.

I don't see what purpose the iMac serves. Apple should get rid of it.

Otherwise, they should eliminate the differences between the Mac Mini and the iMac, so that an iMac is just a Mac Mini with an Apple Thunderbolt Display in one box. Specifically, both the Mac Mini and the iMac should have

an option for a six-core CPU, specifically the Core i7-3930K, so that you can have six cores without paying a lot for a Xeon/Mac Pro. This is all the more important if the Mac Pro is cancelled.
a 4 or at least 3 TB hard disc, by default, with an option to downgrade. You can never have enough hard disc space. Use a desktop-class hard disc for increased space, lower cost and better performance. Who cares if it's an inch bigger? It's a desktop, after all. (Similarly, I'd like an option for a 1TB disc in the Macbook Pros.)

There are also other changes I'd like to see across the entire Mac line, both laptop and desktop:

At least 8 USB ports on all machines, so that you can connect a keyboard, mouse, phone, iPad, external disk, flash drive, dual-link DVI adapter (which requires a USB port for power), etc. It's 2011. Why should you have to hunt for USB ports? If there isn't enough room on the Air, add microUSB ports. While we're at it, make all the ports USB3 ports.
An option for a 140ppi display across their entire range, and specifically, a 1080p display on the 15-inch Macbook Pro. Eventually, of course, I want retina displays everywhere.
You should be able to configure any Mac (except the Air) to have both flash memory and a hard disc, so that you never again have to choose between performance and capacity. The flash memory could be used as a boot volume, or as a cache for frequently accessed files, or as swap space (in which case, can we decrease the amount of memory without significantly impacting performance?). A small amount of flash is cheap — the Apple TV comes with 8 GB for $99, so that flash itself must be significantly cheaper.
Get rid of the DVD drives, or at least make them optional.
Two Thunderbolt ports, so that you can use two 24-inch monitors without daisy-chaining. Two 24-inch monitors are much cheaper than a 30- or 27- inch monitor.

Summary of the talk on the Metro UI in Windows 8

2011-10-02T19:01:00.000+05:30

This is a summary of Microsoft's excellent talk on the Metro UI in Windows 8.

Metro-style Design:

Metro is all about content, not chrome, and an immersive. Every pixel on screen is for content, and none for chrome, whether the app's or the OS's. Metro apps are full-screen all the time (except when the user snaps two apps together).
In particular, the touch version of IE 10 shows web pages full-screen. Microsoft expects this to provide a better browsing experience than the non-touch skin of IE 10, even when you're using a mouse and keyboard.
Text occupies a primary role in the Metro UI. It provides the structure of the app, rather than just being content poured within a structure created by other visual elements.
Whitespace is important -- it provides room for the UI to breathe, rather than having it all squeezed together.
Metro apps are highly consistent and use the same typographic grid. It's not jarring to switch from one app to another. The title is in the same place, with the same font, with the same padding on its side, etc.
Users swipe from the edges of the screen to reveal hidden UI.
The left and right edges are reserved by the OS. The left edge is to switch apps, and the right one is for "charms", like Start, Search, Share, etc. Your app can use these to search, share, etc.
The top and bottom edges do the same thing — reveal the app bar's hidden UI (called the app bar), overlaying the content. The edges of the screen are most convenient for users to reach with their fingers.
Put only the most commonly used controls on the canvas, like play in a music app. Put the others in the app bar. Don't worry that users are not going to discover these. They are, since it's consistent between apps.
Be great at doing only some things, rather than mediocre at doing many.

Fast and fluid:

Make the UI fast and fluid. No jerky movements. A fluid interface is one where everything comes from somewhere and goes somewhere.
Don't map touch gestures to mouse gestures, like press and hold -> right click. Design for the medium. To drag an icon from one screen to another, current touch systems behave as if you were dragging and dropping stuff using a mouse, by having the content scroll when you reach the edge of the screen. But if really design for touch, you expect to use another finger to scroll the content underneath.
Microsoft tried to reduce modes in the UI. To drag something, you don't have to enter a special drag mode, like with iOS — you just drag.
Zoom should not just magnify the same content -- it should show content at a summary or detail view suitable for the zoom level. For example, zoom out on the home screen, and the tiles become icons. Zoom out on a calendar and you see a month view. In other words, zoom should be semantic rather than optical. Users should also be able to act on the content differently at the new zoom level. For example, move whole home screens around rather than tiles within them.
You can slide a tile slightly downwards to select it. Again, you don't need to enter a mode to be able to select things.
Don't create a separate UI for mouse-and-keyboard — the same UI should work well in both modes. Standard controls do.

Snap & scale beautifully:

Apps can specify that they support only certain form factors, like 11.6 inches and above.
Windows 8 supports screens with different DPIs -- so should apps. In particular, you should provide vector art or, not as ideal, assets at three sizes: 1024 x 768 (the minimum Windows 8 supports), 1366x768+ (widescreen), a snapped view and, optionally, a portrait view.
Windows 8 is landscape-first (unlike the iPad, which requires apps to support both orientations). After all, landscape is required for laptop and desktop screens.
A snapped view should be the whole app and not a gadget kind of thing.

Use the right contracts:

Similar to Intents in Android. Let two apps work together without each knowing the other.
The three important contracts are share, search and pick.
Share:

opens the chosen app in a side pane that disappears once the sharing is done, so you don't lose your context.

Apps can identify themselves as being able to be the target of a share action for certain formats of data -- text, photos, etc.

It's not just for social networks/email type apps -- meant for also a translator app, a notes app, a Read It later kind of app. It's not just sharing with people, but also with an app, like an image editor.

Search:

Searches opens its UI in the right pane and searches data from the current app, with suggestions (with photos). When the user taps a suggestion, that item appears in the main pane, in the app.

In the right pane, the user can switch to another app to see results from that app. That way, you can search for something in multiple apps while moving fluidly between them.

Not meant for "find in doc" -- use your own UI.

Picker:

lets you pick, say, a photo from a cloud service (or another computer on the LAN) just as conveniently as a local file. No more downloading a file to attach it to an email, and no more cluttered filesystem.

similarly, if your app has content, you can implement the source part of the picker contract to let other apps use that content.

bottom-line for all contracts: Don't create an in-app UI to do what contracts can do.
The settings charm has a section at the bottom for system settings, and the area at the top is for app settings. Also put Help and About there. Don't build your own settings UI.

Invest in a great tile:

A tile is not an icon -- show content from the app.
Tiles create an emotional connection by showing the user their kids' photos, for example.
In some cases, users don't need to open the app to see the weather, for example.
Tiles have a single touch target -- no controls
You can choose from one of multiple templates -- not fully customizable. But there are almost 20 templates, so there's lots of flexibility.
Pick a template, and supply text and images, and the system handles the rest.
Tiles come in two sizes: small and an optional large tile.
You can pin a specific item from an app to the home screen, resulting in a deep link to that content within the app. Examples: a specific person from a social network app, a city from a weather app, a particular feed from a feed reader
In practice, as a user, you end up finning your favorite content from each of many apps -- the start screen becomes a kind of global dashboard for the things you care, across apps. Once you use this, everything else will feel antiquated.
It makes the start screen more personal, and lets people jump to the part of your app they care about, in addition to getting at-a-glance information from the start screen without opening your app.

Alive with activity:

Live tiles let you have a news app that actually shows the news on the start screen.
The idea is to make the OS alive with activity, the way the web is always changing, and unlike a desktop with static icons.
The start screen lets you put borders between groups of tiles. Like a folder, but it doesn't hide stuff in the hierarchy. You can name groups if you want to (we sometimes find it hard to come up with appropriate names for folders).
Tiles can show a number or glyph at the bottom-right corner, say to indicate the number of unread mails.
Tiles can also animate between two states, like a text and an image.

Notifications:

An app can put up a notification for urgent stuff, like calendar. Notifications slide in from the bottom-right of the screen.
Notifications appear no matter where the user is -- start screen or other apps.
There's no junk drawer for missed notifications. If it's important, update your tile.
Notifications remain on screen for only a short time. The user can throw them off screen, or turn off notifications per-app or globally.
Notifications also have templates, like tiles.
Require the user to opt-in before displaying notifications.

Live tiles and notifications can be updated:

when your app is running
at a scheduled time (alarm)
via push notifications. This is how apps like weather, news, Twitter update themselves constantly.

Roam to the cloud:

Your app is running only when it's visible on screen, and gets about 5 seconds to save its state before its process is suspended. Auto-save, don't prompt the user.
Most users login to Windows with a Windows Live ID. Doesn't have to mean Hotmail; could be Gmail via OpenID.
Every app gets space in the cloud for state, settings and a small amount of user data.
Use these to make it seamless for the user to move between devices. Sync the last listened to track, the last read page, or the level completed in a game.
OS settings are also synced.
If you want to sync more user data, you need to build your own service (easily) using Azure.

Metro Style Design Principles:

Pride in craftsmanship
Be fast and fluid
Authentically Digital
Do more with less
Win as one

Other:

Windows 8 natively supports multiple languages as first-class citizens: HTML/JS/CSS, C#, Visual Basic, and C++/C. You get tool support for all these languages.
The Visual Studio templates make it really easy to build a top-quality Metro app. Just configure a few properties and hook up the template to a data source.
The only way to kill apps is to go to the classic UI and open Task Manager.
Windows ships with a touch Dvorak keyboard
You can make more money making Windows apps than iOS apps, because of the reach of Windows.

File Coordination in Mac OS Lion

2011-08-14T12:04:00.000+05:30

With Lion, Apple again did what it does best — solving problems that we've gotten used to working around for so long that we forget are problems.

But before that, it's interesting to quickly trace the evolution of file access. Initially, files were held captive to the machine they were stored on. Then came the cloud, as web apps, but it was a separate world by itself, so you had to choose between the cloud on one hand, and the convenience, power, and complexity of the filesystem on the other. Dropbox and its ilk unified the two to some extent, providing a filesystem and a web interface to the same data (and mobile apps, too).

Now Lion builds this into the system, and provides an API for apps to use, as opposed to Dropbox, which has to work with apps that don't use its API. That was necessary for Dropbox's success, for sure, but the more interesting question is: can do you better if you can get apps to use your sync APIs? Enter File Coordination, Autosave and Versions, new APIs in Lion. Here's how they provide a better user experience than Dropbox:

Documents are automatically saved to iCloud, and when iCloud changes are synced down, the document on screen automatically updates.
Files are autosaved periodically and when another app wants to access them. For example, when you drag a document to Mail, it's autosaved just before being attached.
Writes are atomic -- other apps don't see inconsistent state, as long as they use file coordination. This works for packages, too. (Packages are directories that are presented to the user as a single file, like a .app.)
Operations on giant directories are atomic as well, provided again that all apps accessing the directory use the file coordination API. If an app tries to move a directory that contains a file another app is reading or writing, it will wait for that app to finish whatever it's doing. Similarly, an app that wants to read or write something deep in a directory that's being deleted is asked to wait till the deletion finishes, so that it doesn't do a partial read, or write into a file that will be subsequently deleted.
When one app has a document open, other apps aren't allowed to write to it and overwrite the first app's changes. If the other app goes ahead and writes to it, because it's running on a different device, or because it doesn't use the file co-ordination APIs, the UI updates immediately. The latter is currently possible, with FSEvents, but far simpler with file coordination.
Apps handle open documents being renamed or moved. This is currently possible with file reference URLs, but many apps don't use them correctly. File coordination may make it easier for apps to do the right thing.
Versions snapshots files periodically so the user can easily go back in time.
When you have a conflict, the system informs your app of the conflict and lets it resolve it. After all, the app is in the best position to do so, because it understands its document format best. This is not possible in the Dropbox world.
When an app wants to resolve the conflict, that file access is prioritized below other writes, so the app merges the most up-to-date version.

It's interesting to see how much better you can do when you control the stack and can get apps to adopt your APIs.

Dynamic Layout in UIKit

2011-08-13T18:53:00.007+05:30

UI elements can be laid out in two different ways:

Top-down, where parent views determine child views' size. This works well for fixed-size interface elements like toolbars. Cocoa supports this kind of layout well, both at the framework level and as nibs that can be laid out graphically.
Bottom-up, where child views' size affects parent views' size. This is needed for dynamic layout, where you don't know the content ahead of time, or how much space it needs on screen. For instance, think of a news article — the headline can take one or two lines, and the article text needs to be positioned based on where the headline ends. Dynamic layout requires that a view's size is determined by its content, and superviews' size by their children's. HTML supports this natively, but not Cocoa.

As an aside, it's interesting that Android supports both — a view's size can be defined to be small enough to just fit its content, or expand to take up all available space.

So here's how we do dynamic layout in Cocoa. These took me a month to figure out, so you'll hopefully save that time.

1. Avoid changing your size in layoutSubviews. Since doing so triggers another call to layoutSubviews, that’s an easy way to produce a layout cycle, where layout happens over and over again. Sometimes it’s infinite, and sometimes it converges and stops eventually, but that kills performance, making the app slow to respond to user actions, making the scrolling jittery, etc. Instead of changing your size in layoutSubviews, override setBounds and setFrame to set it to the right value to begin with.

This is a special case of a more general rule — you never want a case where multiple objects all directly set a given view’s size. Because then the size of the object will be unpredictable, and you can easily have layout cycles. Only one object in the entire app should be able to set a given view's size. And it's best to have that object be the view itself. If a view’s size depends on factors that are not known to it, pass that information in (or define a delegate) and let the view compute its size, in setBounds/setFrame, and override the passed-in size, rather than some other object doing the math and setting the size on the view.

Then anyone can invoke [view sizeToFit] on the subview and let it compute its size. Or invoke view.bounds = CGRectMake(view.bounds.origin.x, view.bounds.origin.y, randomSize.width, randomSize.height). randomSize can be any size, which is ignored by your view’s setBounds, as discussed above. But sizeToFit is a cleaner way of doing this.

2. If you have constraints on the parent (like maxWidth), make sure you propagate them down the hierarchy automatically. We had a bad bug where setting the maxWidth on the parent would behave differently from setting it on the children -- one of the two caused an infinite layout loop.

3. Another consequence of UIKit being designed for static layouts is that that parent views’ layoutSubviews methods are called before children’s. If your parent view’s depends on the child view’s layout, you want the child’s layoutSubviews to run first (just in case it changes its size). To do this, you define a CALayer subclass, override layoutSublayers, and invoke UIView’s layoutSubviews bottom-up.

4. Trick to catch layout cycles: If a view’s layout depends on its children, you want to assert that the converse is not true, because that can cause a layout cycle. Have a rule that says that such a class’s layoutSubviews cannot change the frame or bounds of subviews. In addition to manually doing this, you can automate this check, by creating a list of children that need layout, before and after the parent is laid out, and assert that the “after” list does not have any additional views. This catches a finite layout cycle, too.

5. Override sizeThatFits on your dynamically laid out container class to invoke sizeThatFits on subclasses and sum it up. You should define this to conform to the UIView API, just in case some class you don’t control decides to invoke this function. But don’t depend on it yourself. In other words, make sure that the parent view’s layoutSubviews does not depend on the child view’s sizeThatFits, because then you’re exposing yourself to a bug where the child view has a bug that causes sizeThatFits to return a different value than is actually enforced by the class in layoutSubviews or setBounds/setFrame.

Instead, the parent should ask the child to lay itself out (see point 3 above) and then measure its actual size.

6. sizeThatFits is broken in some standard classes. We used a category that defines saneSizeThatFits in UIView that just calls sizeThatFits, and we override saneSizeThatFits in specific UIView classes that are known to be broken. Our code never invokes sizeThatFits; it always invokes saneSizeThatFits.

Resolution-independence on iOS and Mac OS X

2011-07-24T18:39:00.001+05:30

As we wait for an iPad and a MacBook with a high-res display, indications are that Apple will go with a resolution that's twice (actually, four times) the existing one. The argument is backward-compatibility — apps built for the iPad will look no worse on the iPad 3, since the new resolution is a multiple of the old. Otherwise, graphics will have to be resized and will look worse.

Note that the basic UI — fonts, view sizes and positions, etc — is unaffected, thanks to the virtual, hardware-independent co-ordinate system used by UIKit, and that positions are specified using floats. So apps see a 320 x 480 pixel grid even on the iPhone 4, which has a 640 x 960 screen. If your app draws a rectangle of width 100, it doesn't need to be updated to draw a rectangle of width 200 to maintain its size [1]. Fonts and system views are automatically drawn at the higher resolution.

The only problem is artwork. Low-resolution artwork is drawn on the iPhone 4 by mapping each pixel in the image to four pixels on screen. This way, it looks no worse than on the iPhone 3GS. Whereas if the iPad 3's resolution were not an integral multiple of the iPad 2's, you'd have to interpolate the image, causing blurriness, which means that apps built for the iPad 3 will look worse than on the iPad 2, rather than identical or better.

I think this a bad decision. I want the iPad 3 to have a 300ppi display, so that I can't distinguish the pixels and it looks almost as good as paper. I don't want to print stuff any more, just to make it easy to read, and that won't happen if the iPad is stuck with a 2048 x 1536 display.

Instead, Apple should build a 300ppi display, and pay the price of slightly blurry apps for now. And Apple can show iPad 3-optimized apps above existing iPad apps in the app store, so that users are more likely to use those, and developers are more likely to upgrade their apps.

I don't want to sacrifice the future for the past.

[1] Assuming you use UIKit rather than the lower-level Quartz or Core Animation APIs.

Understanding and Optimizing UIKit Rendering

2011-07-22T08:39:00.005+05:30

This is from the WWDC 2011 and 2010 talks, API documentation, a bit of experience, advice from others, etc. I’m not an experienced iOS engineer by any stretch of imagination, so if you find any mistakes, please add comments. Thanks. I made these notes for myself, and I then figured that others may find it useful, so I’ve shared them.

Each view has a backing layer, which contains an image of the view, excluding subviews. The view's contents are rendered onto the layer when the view is added on screen. Whenever the view needs to be drawn, the system tries to use the GPU to composite the layer onto the screen rather than asking the view to render its contents again, which requires the CPU.

Offscreen Rendering

The biggest bottlenecks to graphics performance are offscreen rendering and blending -- they happen for every frame of the animation, and can cause choppy scrolling.

Note that the layer itself is effectively an offscreen buffer, but that's not what we're referring to here. Sometimes two or more layers needs to be composited into an offscreen buffer, which is then composited onto the screen, as opposed to the normal flow of compositing layers directly onto the screen.

For example, this happens when you set a mask for a view. The entire view hierarchy needs to be rendered onto an offscreen buffer or, in other words, the layers for all these views need to be composited into the buffer, on which the mask is applied. Then the buffer is composited on screen.

The Core Animation Instrument has an option to detect offscreen rendering, as well as blended views. If an offscreen buffer is going to be needed, see if you can at least cache it between frames of the animation, by calling [layer setShouldRasterize:YES].

Make sure that you don't enable rasterization of a view without a good reason, because you might force offscreen rendering (slow) when it's not needed.

Other optimization techniques

Flatten your hierarchy: See if you can flatten your view hierarchy. If your view has subviews A and B, and B has subviews B1 and B2, see if you can eliminate B and add B1 and B2 directly as subviews. Flattening your view hierarchy means that there are fewer backing stores, so you save both space and time, including on the GPU.

Consider drawRect: If you can't flatten your view hierarchy, Apple recommends that you use subviews to create your layout rather than drawing each item individually in drawRect.

However, there are cases when you should go the drawRect route and draw stuff manually, using Core Graphics, NSString’s drawInRect, etc.

One trick is to create subviews but not actually add them to the superview. For example, if your view needs two labels and images, create the UILabel and UIImage objects without adding them to the superview and, in your drawRect, invoke UILabel's drawLabelInRect and UIIimage’s drawInRect (never invoke drawRect).

Or create your view hierarchy, invoke [view.layer renderInContext:context] on the root view, and throw away the view hierarchy.

Whichever of these three techniques you use, you have a backing store that effectively holds the view and all its subviews together instead of having separate backing stores for each view, or, worse, having a separate backing store for each view *and* one for the view hierarchy (if you call setShouldRasterize). This saves memory and time, both on the CPU and GPU. In particular, your view hierarchy is composited together before animations, rather than for each frame.

Create an image directly: Create a UIImage or CGLayer (which is cached better on GPU), and draw whatever you want into it.

The downside of this technique over the drawRect one (above) is that you're eagerly creating your backing store, whereas drawRect is invoked only when the view is added to a window. But if that’s not a consideration, this is simpler than the drawRect solution because instead of defining a UIView subclass, defining drawRect, and have the system invoke it to render your view into a layer, you create an image directly.

Scroll view callbacks: UIScrollView works by updating the contentOffset every 1/60th of a second. If your UIScrollViewDelegate takes longer than 1/60th of a second, you’re guaranteed to drop frames.

This is different from Core Animation, which runs smoothly on GPU even if the CPU is busy.

iCloud, Google and Lock-in

2011-06-12T08:49:00.014+05:30

Disclosure: I work for Google.

So far I've heard the term cloud used to mean web apps, but Apple redefined it to mean storing your data on the internet but accessing it through native apps. That vision is indeed compelling. Native apps have a far better user experience than web apps. In particular, the app is always available locally, as is all your data, and you can edit it without waiting for the network. Sync happens behind the scenes, as it should. This also means that they work offline.

And then there's Apple's penchant for exceedingly high-quality and emotionally satisfying interfaces. Just look at the MobileMe Sign In page, with the cloud slowly emitting small, delicate white puffs of data that get absorbed gently into the iPhones and iPads in the background. Steve Jobs overuses the term, but this really is magical (watch it in HD, by clicking on the Youtube logo):

But there's a fly in the ointment. Just visit me.com on your Android phone and you'll see this:

Notice that it tells you how to set it up on your iPhone, when you've visited it on your Android? I'm having trouble deciding whether this is arrogance on Apple's part or just gross negligence. They should have at least put up a screen saying, "Sorry, MobileMe doesn't work on your device."

Maybe it's Apple preference for building something absolutely great for 90% of their users rather than something merely good that everyone can use, as John Gruber puts it (he phrases it better, but I can't find the reference now). That works great for hardware and software. If 10% of mobile phone users find the iPhone too limited in some way, that's not a problem at all — they can buy other phones. Better to thoroughly delight 90% of your users. But this strategy totally fails for cloud services.

I won't use an email service that I can access from only some of my devices. The same applies to other kinds of data like calendar, contacts, notes, documents and photos, for that matter. If iCloud continues in MobileMe's footsteps, it'll be as interesting to me as Ping. Which is to say, not interesting at all. Except perhaps as a demonstration that Apple still doesn't understand how to build an internet service, despite the superficial UI delight.

At another level, none of this is surprising. Apple makes its money from hardware, so I wouldn't be surprised if they look at iCloud just as a way to keep iOS compelling in the cloud department. Whereas Google makes nothing from sales of Android or Chrome OS devices, and in fact gives the OSs away to drive traffic to their internet services, where they make all their money. So it's not surprising if Google cares deeply about giving you access to your data from all your devices, whereas Apple doesn't.

I do think Apple's strategy, if this is it, is narrow-minded — that most Apple users have non-Apple devices, and letting them use iCloud on these devices makes iCloud and therefore iOS more useful to users, not less. But I don't know if Apple's focus on building a wonderful product for the majority of users rather than a good one for everyone prevents them from seeing that. Maybe it's the innovator's dilemma.

So, if I have to choose between an elegant interface and access to my data from all devices, I'll choose universal access. Which means using services that, at a minimum, have web apps that work on all platforms. Even a desktop web app works on phones running Android, webOS, etc.

One step better is an internet service that provides a native app for at least some platforms, in addition to the desktop web app. Simplenote is an example.

But I'd like to not have to choose between a top-quality interface and being able to access my data everywhere. The gold standard is probably Evernote, with native apps for all the popular platforms — iOS, Android, webOS and even Mac OS X.

[1] Third-party apps are not good enough. I won't use iCloud if I can access it from Android or webOS only via a third-party app.

The Grand Unified Theory of Computers

2011-06-06T16:21:00.001+05:30

Disclosure: I work for Google.

It didn't take long after we learnt of Microsoft's ambitious Windows 8 plans — to unify tablets and computers — for the Mac blogs to declare that it won't work. Tablets are so different from PCs in many ways, the thinking went, that you can't build an OS that provides a good user experience on tablets while retaining backward compatibility with desktop Windows apps. As John Gruber puts it, the iPad has succeeded because it has eliminated complexity; not because it has hidden it.

Except that that's not true. The iPad hasn't eliminated complexity; it has just moved it elsewhere, onto the PC. Since a Windows 8 tablet is intended to replace both the iPad and the PC, the question is not whether a Windows 8 tablet is more complex than the iPad, but:

whether a Windows 8 tablet is more complex than the combined complexity of the iPad and the PC, and the sync between them, which it most likely isn't, and,
whether the extra complexity of the Windows 8 tablet stays out of the way when you don't want to deal with it.

For example, John points out that Excel running on the Windows 8 tablet does not autosave new documents and exposes the user to the filesystem. The fact that the Windows 8 tablet can run Excel doesn't increase complexity because, if it couldn't, what would you do when you need the full power of Office? You'd use Office on your PC, and deal with the filesystem anyway. How does it hurt to do so on the tablet? It's just a different box into which you plug in your mouse, keyboard and monitor. In fact, it's simpler, because you don't have to synchronize your documents between the devices.

This is the fatal flaw in John's argument — he's confusing moving complexity around for reducing it. And when you don't need the complexity of desktop Office, nothing prevents you from using a simpler app that does not expose the filesystem. Microsoft, or someone else, could make such an app, just like Apple did with iWork for the iPad.

My Android phone hasn't become more complex just because I installed a file manager app. It doesn't come in my way when I don't use it. And the same argument holds for the filesystem on the Windows 8 tablet. John is confusing being freed from having to manage the filesystem with being prevented from doing so even when you want to.

Then there's touch. Sure, apps designed for the Windows 8 tablet will be used in both touch and non-touch modes. But that's no worse than the status quo, where apps have to built twice — once for the tablet and once for the desktop. (I'm ignoring phones in this entire discussion.)

Another big factor is that legacy Windows apps are not designed to quit when the OS asks them to, when the system is low on resources, while apps built using the new Windows 8 APIs can presumably do so. Again, the OS can work around this, by reserving say 90% of the CPU for foreground apps, so that background apps don't slow down foreground apps, but they are not starved for CPU, either, so your music continues playing as you work. Similarly, legacy apps can be limited to consuming some fraction of the system memory, say 2 GB out of 3, so that they can't break the tablet experience by hoarding all the memory. If you open too many legacy apps, they might end up paging to disk, but it won't affect tablet apps built using the new Windows API because they have their own region of memory and are never paged out to flash.

Again, that's no worse than a PC. It doesn't make sense to fault a device that gives you the simplicity of a tablet and the power of a PC, for giving you the power of a PC, so long as it doesn't come in your way when you don't want it to.

If all this has a cost, and the Windows 8 tablet lasts only 6 hours on a charge rather than the 10 the iPad does, that's again a good compromise if you end up buying and managing one less device.

I see no reason why the Windows 8 tablet can't be the best of both worlds while continuing to run legacy apps. But even if you disagree with the legacy apps bit, even if you believe that apps have to be all rewritten for Windows 8 tablet, the weaker form of the above argument — that a single device can function both as a tablet and a PC, or a phone and a PC — is compelling. It means that we have one less device to buy and manage.

Where Apple's 30% policy went wrong

2011-05-29T22:32:00.004+05:30

Disclosure: I work for Google.

Is it fair for Apple to demand 30% of all subscriptions on iOS? They obviously deserve something, because they've built a low-overhead purchasing platform, which increases the number of transactions. In other words, some (many?) of these transactions wouldn't have happened were it not for Apple, so they arguably deserve a cut.

On the other hand, if I've made up my mind that The Economist is worth reading, and paying for, Apple can't claim credit for that. If I were to subscribe using my Chromebook rather than my iPad, does it mean that Google deserves a cut?

Apple's policy is fair if the increase in volume of transactions compensates for the 30% cut. Unfortunately, we don't have numbers for this. I doubt even Apple does.

Besides, there isn't a single number. It varies based on the type of content (I'll pay for music videos, but not for news), the format (I'll pay for a newsmagazine over a newspaper, because the former usually gives me the big picture), the quality of the content (I'll pay for The Economist over a tabloid), the user experience of the app (I'm inclined to pay for in-app content if the app is stable and fast and the user experience is frictionless, unlike, say, the New York Times app) and a lot of other factors. So there isn't a single answer that applies to everyone.

Given this lack of certainty, if Apple wants 30% of all money made in my app, the onus is on them to demonstrate unambiguously that the frictionlessness of in-app purchase brings in enough money to compensate for their cut. Since they haven't, and given the obvious conflict of interest Apple has here, one can't fault developers for concluding that Apple is putting its own interests above that of the iOS ecosystem as a whole, and concluding that the 30% cut is a land grab, almost like a car manufacturer demanding 30% of your salary for driving to a job interview in their brand of car.

Of course, Apple is free to do whatever they want, but that's like saying Volkswagen is free to put giant "Fuck You!" signs in their showrooms. If Apple is appropriating revenue generated by third-party apps, those people have less of an incentive to work on their platform. For example, I'm considering whether to move out of iOS development. This hurts everyone — Apple, developers and users.

Instead they should have done one of two things:

Reduce their cut to less than 10% for "content" rather than app features, like sync functionality in a notes app or a level in a game. Content is what you can consume on non-mobile devices — a traditional computer, TV, paper, etc. Of course, there'll be some gray areas, but it's better for Apple to give a fair deal in obvious cases than not to, at all. The less the cut, the easier it is to convince people that the increase in transactions compensates for it, and so, less the controversy.
Allow apps to use their own purchasing systems. Sure, Apple's system has the better user experience, but it would be hypocritical of Apple to force people into using it for that reason. If Apple cares so much for user experience, they should enable in-app purchase at no charge for apps. Otherwise let apps use whatever payment systems they want to.

One thing that should not change is the policy that publishers can't charge iOS users any more than what they charge for the same content elsewhere. Or that they shouldn't automatically be given users' personal information to sell.

iPhone 5 Wish List

2011-05-16T15:00:00.002+05:30

Here's what I'd like in the iPhone 5:

a 4.5-inch screen at 300+ ppi.
It should sync and stream media from multiple devices without the user having to bother about the difference.
It should work as a PC with an existing Bluetooth keyboard and mouse, and an existing monitor, maybe with an adapter that costs $99 or less. After all, the iPhone has more than enough power to run a browser on a big screen.
A sane version of iTunes that periodically rescans your media directories and automatically keeps its library in sync, and has a one-click transcode function.

Windows Phone 7 — Promising Yet Frustrating

2011-05-16T14:29:00.003+05:30

I used a Windows Phone 7 phone (HTC HD7) for a week as my only phone, and here are some thoughts. The UI, called Metro, is a tremendous accomplishment — nothing like iOS or Android. It's so smooth and airy and almost organic. In contrast, the iPhone feels rigid and sterile. Animations, for example, are even smoother than on the iPhone. There's an extreme emphasis on reducing all unnecessary UI elements, and lavish use of whitespace. If you think iOS is minimalist, prepare to be pleasantly surprised.

Text occupies a primary role in the Metro interface. You'd never think that text can be so beautiful and that it can structure a UI so delightfully rather than just being content placed within a framework formed by other elements. Then there's the full bleed, where content goes to the edge and past it, as if you were looking at a just one part of a UI that's bigger than the screen.

It's authentically digital. I'm sure the Metro designers had the iPhone in mind when they say, "don't try to be what it's NOT". Another great principle is that transitions between screens are as important as the screens themselves. It feels so responsive and alive.

Not that it doesn't have its rough edges. Some widgets look terrible, for example, the toggle switch, or the action buttons at the bottom of the screen. You can't quickly navigate to a contact whose name starts with S, say, in the contacts app. I also found some basic navigation and usability issues. Once I selected an album to play and browsed to other albums and artists, I couldn't return to the playing album, or find out which song was playing. I did notice that the currently playing screen seemed to be the left of the main screen in the music app, but I couldn't find it later. Another time I was able to reach it by pressing the back button from some other app (the home screen, I think).

Metro is also tremendously wasteful of screen space. Everything is unnecessarily big -- the tiles on the home screen, the contacts in your phone list, song titles in the music app... Simple tasks require navigating to multiple screens, and you see less on any single screen. The HD7 I used has a big 4.3-inch screen, but it doesn't feel any bigger than the iPhone, because the UI squanders all that real estate. This is the biggest problem with Windows Phone 7 — it sacrifices too much function in pursuit of form, as elegant as it may be.

Then there are the mundane problems -- the app store wasn't available in my country (India). It's irresponsible to sell a phone for Rs. 30,000 ($660) without enabling the app store. If I can't use apps, I have to use the browser, which is terrible. It's not even touch-optimized in the most basic way -- the combined address/search bar (yay) is too small to hit. I often have to try several times. The browser sucks technically too, with hardly any HTML5 support. And the default search engine, Bing, can't be changed. Which would be okay for me (though I work at Google) if Bing worked well. Unfortunately it doesn't, at least not in India. I used Bing as my default search engine on my desktop for a couple of months, and I almost lost the ability to find things on the internet. I wouldn't buy a phone with such a broken search experience.

Upgrading the phone is also a pain. The sync app is not available outside of the Mac App store, and it's bad and keeps crashing or eating up 100% CPU without doing anything useful for a long time. Then it didn't let me upgrade the OS, telling me that there weren't any updates. After wasting a lot of time on phone with the semi-informed HTC support, the solution turned to be reinstalling the sync app. This is almost like the old and buggy Windows days. If I have to call customer support to figure out how to upgrade my phone, there's a good chance I wouldn't want to buy a Windows Phone 7 device the next time.

Then there are most elementary and frustrating hardware issues that remind us that HTC is not Apple. You need to use the physical button to take a photo, but you need to press it so hard to get it to take the photo that the phone shakes and most of my pictures are blurry. This is so frustrating on such a high-end phone. It reminds us of a major drawback with the non-integrated Windows Phone 7 and Android strategies -- the hardware vendors continue to surprise us in finding new ways to screw up up basic functionality. I can't imagine this problem occurring on an iPhone, which is what I'm returning to, from the elegant yet semi-functional Windows Phone 7 world.

Why I Prefer Native Apps on iPhone

2010-12-30T20:21:00.028+05:30

I often use the iPhone task switcher to move between apps — the one that you get by double-tapping the home button. I found yesterday that the first three screens of apps on that list were all native apps. I find myself using more native apps on my iPhone as time goes by. I stopped to think why, and it turned to be interesting.
If I want to use a great web app on iOS, where do I find it? There's no Mobile Webapp Store, no place where I can find web apps specifically built for the iPhone or the iPad. I often end up using desktop sites — sites that are built for a big screen and are not touch-optimized. These are utterly crappy to use on the iPhone. I'm not saying that there are no great mobile web apps. But when there's no way to discover them, the end result is the same. And that sets up a vicious cycle — it doesn't pay to build a web app, since most users wouldn't use it, going instead to the (native) app store.

Then there's the iOS convention of having a clean, clutter-free UI with only the most commonly used features, rather than the overload of interface junk that you see on the web. The factor that matters the most in the apps vs. web apps discussion may not be a technical matter at all.

Finally, native apps are fast because they don't have to be loaded across the network. And they store your data on the device, too, in addition to the app itself, so they load instantly. Saying that web apps can be offline-enabled is missing the point. They're often not. Maybe it's because if you're building a native app, you get offline functionality by default whereas, for a web app, you have to figure out how to enable offline and get it to work. Whatever the reasons, the existence of the API means nothing if apps don't use it.

OPENGL

The conventional wisdom is that it's technically possible to build a native-quality HTML5 app. Apple has certainly built one. But think of all the thoughtful little things that go into a great UI, like icons that may look small but have a bigger touch area, icons that glow when touched, or the rubber band-like bounce effect that tells you you’ve scrolled to the end of a list. Or the intricately choreographed and non-linear animations for something as simple as a page transition.

Are these even technically possible in web apps? WebGL isn’t yet supported in iOS or Android. Sure, it will be, but I’ve been hearing for years that web apps will soon be competitive with native apps. I’m not holding my breath.

FRAMEWORK

So if many of the iOS interface effects require OpenGL, there are surely some that don't? How many web apps implement these, at least? Zero?

As Faruk Ateş astutely points out, when you're building an iOS app, you're not starting from scratch. You're starting with the Cocoa Touch framework, which is built to enable the top-notch user experience of iOS. For example, if you want to make an icon glow when touched, to give the user feedback, all it takes is one line of code:
button.showsTouchWhenHighlighted = YES;
How many web app frameworks are designed to build this kind of top-quality interface, and that too so easily?
To use web apps on iOS is to discount everything that makes the platform wonderful.

CONSISTENCY
Native apps also have a look-and-feel consistent with the platform. Not just the widgets, but also the UI design patterns. For example, when there are too many tabs to display on screen, the others collapse into a More tab that you tap to see the hidden tabs. There’s also an edit control that you can tap to customize tabs, by dragging frequently used tabs out of the More tab, so that they are visible all the time. Another convention, in certain situations, is to put settings behind the main screen, and put an i icon at a corner to flip the screen.
The cross-platform nature of web apps works against being consistent with a particular platform. A mobile web app tries to provide the best user experience not just to iPhone users, but also to users using Android and maybe Windows Phone 7 and their ilk. And when you try to do that, how is it possible to be consistent with each platform? Put differently, if you were to create a great iPhone web app, wouldn’t you want to open it up to Android users?
It’s possible, of course, to build a web app specifically for iPhone, but if you’re doing that, you're losing out on the main advantage of web apps, which is cross-platform compatibility. Why not instead build a native app?

INCENTIVES
Native app developers also have an incentive to sweat the details, not just because they can charge money, but also because they attract more users, since the App Store lets users easily discover, rate and compare apps.
Finally, native apps are first-class citizens on iOS. Even if you create a home screen icon for a web app, tapping on that icon when the web app is already running will reload it, whereas you can instantly switch back and forth between native apps. Further, native apps also have their own entry in the task list (that you get when you double-tap the home button), so you can instantly switch back and forth.
(Disclaimer: I work for Google.)

Why Physical Buttons Suck

2010-03-06T12:46:00.005+05:30

I was thinking about hardware buttons on Android phones and iPhone, and I realized that most of them sound good initially but actually worsen the user experience.

The biggest user experience failure is the menu button:

It takes more actions to do frequently performed tasks. For instance, whenever I open Maps, I have to press the menu button followed by search rather than directly tapping on a search button. Searching is the main reason I use Maps, and it's objectively worse to move it one click away. The same goes for compose in Gmail. Cramming a little more content on screen while moving these extremely frequent actions one click away is plain stupid.
It moves actions offscreen, which is bad in the same way that command-line interfaces are worse than GUIs, for most people. Show the user what he can do right there on the screen. And since every screen has different actions on it, you never know what capabilities are present.
It's harder for new users to learn, when there are so many buttons to press. I was initially confused and slightly stressed out, being a geek and all, and my mom was more stressed out when I ask her to use my Android phone — what button do I press? Why should anyone put up with this?

Then there's the back button, which, as it's name says, takes you to the previous screen. iPhone, of course, uses an on-screen button for this:

There are several problems with a physical button:

It's a proxy for a screen in the UI, and requires the user to remember what the last screen was. For example, if I'm reading a mail on my Android, pressing back takes me to the inbox unless, for instance, I reached this mail by a search. Instead of requiring the user to remember this context, show it on-screen. I want to go to my inbox, not back, forward, or sideways.
It's not clear, at least to me, whether it's a back or an up button. Does it take you the previous screen, or one level up in the information hierarchy of the application, without regard to history? Windows Explorer's up toolbar button comes to mind. For instance, if I go from my friend list to a friend X, and from there to a mutual friend Y, back takes you X, whereas up takes you to your friend list. If the button were labeled, like on the iPhone, this ambiguity disappears.
There are some screens where it's not clear what the back button does. When you enter something into a text field, does a back button press save it, or prompt the user what to do? It may make sense for gmail, where the user may expect autosave from having used gmail on the desktop. Whereas I was surprised when the SMS app autosaved, which I was not used to on my previous phone. So, it's not clear to the user what the button does, since it's not labeled, and worse, potentially inconsistent from app to app.
Android lets you move from one app to another without going through the home screen, by long pressing the home button. In that case, should the back button take you to the previous screen in the current app, or the globally previous screen? I find that it does the latter, but it's confusing. For example, I switched from Calendar to SMS via long press on the home button. I had an unread SMS, so it took me to that message, and I pressed back to go to my list of SMSs ("inbox"), but it took me to Calendar. Whereas if I had navigated to the SMS app from the home screen rather than by long press, back would have taken me to my message list. So this inconsistency is another argument against a back button.
Once again, it has a learning curve. The first hour of my Android experience was frustrating, since I seemed to be getting stuck all the time with no way to navigate out of the current screen.
You have to move back and forth between the screen and physical buttons, which breaks the flow and does not lead to as fluid an interaction as on the iPhone.

I haven't used the search button much, but I wonder if it's a global search or app-specific search. If it's the former, it's jarring since you don't want to perform global actions from within an app. If it's the latter, what about apps that don't support it, like perhaps games? Will users come to know of this as the button that sometimes works and sometimes doesn't?

Hopefully at some point Android will catch up with the iPhone's ease of use, convenience and fluid interaction.

Update: Added another reason why back is inconsistent when you switch apps using long press.

Disclaimer: I work for Google.
Image credit: Apple.

The "all you can do is send a message" model isn't enough

2010-03-01T16:09:00.003+05:30

I came across a post by Jonathan Rees that I couldn't understand, but after several re-readings, it made sense, and it's an interesting point — the "all you can do is send a message" model, a.k.a the actor model, isn't enough.

First, some background, if you're not a programming language geek: many languages support message passing, which is like calling a method but different in that the receiver can define a catch all method that traps all unresolved method calls. Ruby, for example, calls this method_missing. This is different from Java where a class has to specify at compile time what methods it defines. Message passing is obviously more powerful, since it lets you implement things like proxies for RPC, access control or object persistence that can transparently decorate any object without knowing its interface.

The "all you can do is send a message" model rules out any other way of interacting with an object -- instanceof, object identity (that is, comparing pointers) and, of course, fields, which anyway can be looked at as synactic sugar for methods.

With that background, the aforementioned post says that this model, despite seeming to be more powerful since it lets objects control and customize all interaction with them, is actually less powerful since you can't deal with unknown objects in a safe way. For instance, if you're building an OS or runtime and implementing file I/O, you can't check paths against an ACL in a safe way. You can access the string object, but who knows if it's a nefarious imposter that returns one value when you check its value, and another when you actually access the path? You could store individual characters in the string in an array of your own, but who knows if the character objects are themselves safe? To generalize, you can't have any scenario in which you load untrusted or partially trusted code into the same process and attempt to enforce a reasonable security policy. Examples of these being a Javascript interpreter in a browser that allows script to access the same domain but not others, or an OS that uses sandboxing rather than hardware-supported processes.

The only way out is to have an instrinsic notion type of an object as something visible to clients, independent of the behavior (methods). There must be a builtin instanceof operator or function as part of the language itself, and a way to compare pointers to see if they point to the same object.

Once you have this notion of the type of an object independent of its behavior (methods), methods don't need to be defined as part of the object; instead they can be defined as independent entities and hang off the object type. That is, an object is merely a map of key-value pairs, with an associated tag or type. Methods can be defined outside the object, and found based on the types of the arguments (multimethod dispatch). And you can build the language all the way up from that.

Thoughts on the Go programming language

2010-03-01T12:49:00.000+05:30

Some random thoughts on Go, the language from Google.

Why does it require mandatory type declarations, rather than inferencing types like Haskell and C#? A type system that precludes higher-order functions sucks.

Untyped constants are good, but an option for dynamically typed variables would also be good. I'm all for detecting errors as early as possible, and having variables be statically typed (with type inferencing) as a default is not something I'm going to argue with here, but not providing an option for dynamic typing just amounts to curtailing flexibility and resulting in programs that require 200 lines to do what better languages let you do in 20. Once again, prioritizing safety over expressiveness is fine as a default, but only as a default. Only an omnipotent designer can say that there's no situation in which dynamic typing is useful. Or if you're designing for idiots. Paul Graham puts it much better when he talks of the three reasons languages have restrictions.

While we're still taking about types, why not have infinite-precision math? Why do you want to bother about the size of an integer except in hotspots?

The distinction between statements and expressions is also traditional, but doesn't buy you anything but verbose code.

The language uses things that we are forbidden from using, as mere programmers. This is a bad attitude for a language to take, because if the language needs something, chances are programmers would find it useful, too.

The notion that some types are passed by value and others by reference is also incredibly clunky. Simpler is to pass everything by reference, and as an optimization, say that object identity is not preserved for certain types.

In summary, Go is not clean. There's no central philosophy, no single metaphor or abstraction (everything is an object, or a list, or a process, or that things are evaluated only when needed). This is just a hogde-podge of C++ and Java with various random ideas thrown in. It ends up being better than C++ and maybe Java, but that's a low bar for language design.

The Ideal Taskbar

2010-03-01T12:01:00.005+05:30

Reading about Windows 7's taskbar changes, and an insightful article on window and app switchers in general, I noted down what I would want from such a thing, which I refer to as "taskbar" for lack of a better name. Think of it as the dock if you prefer.

To start with, the taskbar should unify:

Apps that have some windows
Apps that have no windows open
Apps that are not running but are important to the user

All these apps should be displayed identically, rather than having some squirreled away in a quick launch area, and others in a notification area (and yet others having to display empty windows). The user shouldn't have to deal with the difference between starting an app and switching to it.

Further,

If an app has multiple windows, each window should have its own entry in the taskbar, so that the user can switch directly between windows without going through a two-step process of first selecting an app and then a window. This makes the app a combined app/window switcher. It's not "pure", but more practical — if the user is working on two documents at once, each of them is important enough to be shown as a first-class entity. It's simpler, too. The first few days of using the Mac were frustrating when I had two Firefox windows open, but no visible and obvious way to reach the second one.
What about tabs? They are somewhat similar to an app with multiple windows. That is, it's inconsistent that if I open a new window in Chrome, it gets its own taskbar entry, but not if I open a new tab. I can easily imagine Word opening multiple documents in tabs rather than windows. The taskbar should list the things the user is working on without regard to the details of how they're presented. And if each tab gets its own taskbar entry, with a label and even a spinner for a browser, what need do we have for tabs within windows, since we in effect have a tab bar in the taskbar?
Each taskbar entry should be labeled. An icon isn't always enough to disambiguate apps or windows.
Alt-Tab should just cycle between the entries of the taskbar, which are both apps and windows. Why define some other semantics? Keep the shortcut's behavior consistent with the visual representation. Gone are the Mac's Command-Tab vs. Command-` distinction.

If the OS launches apps when needed, shouldn't it shut them down when they're no longer needed, like Android does? Why should users have to bother with the idea of quitting background apps, any more than they bother with context switching or virtual address spaces?

In fact, my Dock isn't a list of apps I'm working with; it's merely a list of apps some of which I haven't used for weeks and haven't bothered to quit. In other words, it's an arbitrary list. Instead, show a list of the most recently used N apps, as Android does (when you long press on home). And if an app has multiple windows, show multiple entries.

Update: Linux, as usual, lags behind. I'm sure they will copy this by 2015.

iPad: computing re-imagined, and openness

2010-01-29T15:48:00.013+05:30

After I watched the iPad keynote and the Reality Distortion Field wore off, I was a little underwhelmed. It wasn't clear that the iPad lived up to Jobs's claim of being significantly better in a few key areas. It just seemed like a giant iPod Touch or a computer with a small screen and without a keyboard.

But then I realized I was looking at it all wrong. Being used to laptops on one hand and phones on the other, I was comparing the iPad to these two, and so obviously all I could see were limitations. That makes as much sense as dismissing the iPhone as an underpowered computer. Rather than look at the iPad from the perspective of a laptop, I decided to look at its advantages:

It's more portable — smaller, thinner and lighter.
The form factor is beautiful. It's just an elegant piece of glass. Even my Macbook Pro seems clunky by comparison. Why shouldn't computers be so beautifully designed rather than merely utilitarian?
It has a very long battery life. Even taking the 10 hours claim with a grain of salt, it's much better than laptops. I'm sure it will be an incredible relief from devices that need to be plugged in practically all the time. And in countries like India, with frequent 8-hour power cuts, a long battery life makes all the difference.
3G: Having an internet connection of its own rather than relying on an external source like WiFi is great, because you are connected on the go, and at home when you have a power outage. I thought that the iPad will be carrier-locked, given Apple's history with the iPhone, even in markets like India where few phones are locked. But when Apple is establishing a new kind of computing device, it only hurts them to restrict it that way, and set a precedent that's bad for everyone except the carriers.
Multi-touch: I haven't used the iPad yet, but I'm sure it's very satisfying to directly touch objects rather than going through an intermediary like a mouse. Plus who knows what advantages multi-touch has? For example, zooming and panning in maps seemed much better than on a computer, with a keyboard and mouse. There will be a gold rush of user interface advancements in the new paradigm.
It has a high-resolution screen (132 pixels per inch).
It's cheaper than most laptops.

But the interesting things are not what it has, but what it doesn't. To start with, you are free from malware of all kinds — virii, worms, spyware, keyloggers, trojan horses and bots. The existence of so many terms is itself a sad state of affairs for the computer industry. Any technology that doesn't just work by itself and requires users to learn and carefully follow a big list of dos and don'ts is broken. Apple just fixed computing. The iPad is a safe computer for everyone.

In addition to being malware-free, it doesn't become slow over time, you can't corrupt it say, by deleting files you're not supposed to delete, and so forth.

And it's simpler — no overlapping windows. One thing at a time. You never have many windows on screen at once, you don't position them, there's no notion of which window is focused, and so forth. One thing at a time. No menu bar, either. Let the app decide how to present its UI, rather than forcing a hierarchical menu layout on everyone. There's no notion of running vs. closed apps, and so no dock or taskbar to switch between running apps. And no notion of running apps without a visible window that you reach from the system tray or status bar.

I'm exhilarated at the idea of not dealing with windows, menus, a dock or taskbar, and a system tray that apps can hide in, and the idea of manually quitting apps. Very simple. One thing at a time.

You don't spend your time positioning windows. There aren't zillions of options to twiddle. In addition to being simple, the iPad is an administrivia-free computing experience.

This is the New World of computers.

The iPad runs the same apps as your iPhone. If you think about it, why shouldn't your computer run the same apps as your phone? Just because it has a bigger screen?

Some people wish that it ran Mac OS X rather than iPhone OS. But the latter is more lightweight and so is faster and results in a longer battery life. It's also more secure and simpler, doing away with the overlapping windows paradigm. And it does away with cruft that accumulated in Mac OS X.

The final, and most serious, concern is that the iPhone/iPad platform is not open. As Alex puts it eloquently:

The thing that bothers me most about the iPad is this: if I had an iPad rather than a real computer as a kid, I’d never be a programmer today. I’d never have had the ability to run whatever stupid, potentially harmful, hugely educational programs I could download or write. I wouldn’t have been able to fire up ResEdit and edit out the Mac startup sound so I could tinker on the computer at all hours without waking my parents. The iPad may be a boon to traditional eduction, insofar as it allows for multimedia textbooks and such, but in its current form, it’s a detriment to the sort of hacker culture that has propelled the digital economy.

But the proof of the pudding is in the eating. If openness and tinkering and being able to do what you want without permission are important, that will ultimately reflect in the apps. Competing platforms should have better apps. And this is already happening. When I read that the best mobile Gmail experience is on Nexus One (Disclaimer: I work for Google), and Google Maps navigation and Google Voice are not available or not as good on the iPhone, I think that's the end result of the mismanaging the platform. If I were Apple, reading that the Nexus One is a better phone than the iPhone for people who heavily use Google apps would have scared the hell out of me. Mac OS X isn't any worse an OS to access Google services, and Chrome lets you access Bing as well as it does google.com.

So, if openness is important, and the iPad isn't open, good old-fashioned capitalism should sort it out, giving us competing tablets based on Android, Chrome OS or some other OS that are better in ways that matter to users, while building on top of all the genuine advances iPad makes. I don't think that the future is dystopian at all.

Why the GPL turns away many contributors

2009-07-05T12:17:00.003+05:30

Interesting article that points out how the GPL turns away many contributors, since people are more likely to contribute to a project if they can reuse their work in any project of their choice.

The popular Subversion source control system’s liberal license enabled Sofa, a commercial software business to contribute value to the community with its extremely polished, award-winning client application. Meanwhile, the newly popular distributed source control systems presents three major choices: git, Mercurial, and Bazaar. All are restricted by the GPL-license, and therefore none is likely to inspire development of a Versions-caliber client.

GPL is for people who are either ideologues or don't want commercial vendors to profit by building on their work, while failing to realize that they add value in areas that may be important to users but where the open-source community sucks, like UI design.

How many buttons should a phone have?

2009-07-05T11:41:00.004+05:30

Apple's genius of simplicity gave us a phone with just one physical button. Whereas the Android phones have many more:

This set me thinking -- what's the right number of buttons for a touch-screen phone to have?

We obviously need a home button, for multiple reasons: returning to the home screen is something we do all the time, and you want to do it at one shot rather than backing out from a deep hierarchy step by step. Also, you need at least one button controlled by the OS, to move out of a hung app.

The back button that Android phones have is also useful, because that's also a frequently performed action, for which a hardware button helps, and you wouldn't want each app to express the same idea in slightly different ways. And, importantly, Android lets you move from one screen to another without regard to what apps they are part of. For instance, from Email, you can click on Attach to launch Gallery, then click on an image or video to see it full-screen. Pressing back takes to the gallery view, and pressing back again takes you back to email. Since each app controls the screen entirely without regard to the context in which it's invoked, you need a physical back button to transition between screens without regard to which apps they are from. I always find it jarring that on the iPhone, if you're deep within an app, you can progressively come out of the hierarchy by tapping the button at the top-left, but only till you reach the app's main screen. The system should not enforce such a strong separation between apps -- going back is a general action that makes sense from the main screen of an app, and between apps as in the Android example above.

I hate the menu key on Android phones. Better to put the actions right there on the screen where the user can see it. The first hour or so of using Android was very frustrating to me, since I seemed stuck, with no way to navigate out of the current screen. In addition to having a smoother learning curve, or rather none at all, putting the actions on screen saves one button press — the set of available actions isn't hidden from you till then.

Some actions are so frequently used that putting them one level of indirection away is plain wrong, in that it takes the user more clicks to do the same task. If there are too many actions to show on screen at once, take the user to a second screen. Which is what the menu is, to some extent — you see only content on screen, till you press the menu button, at which point you see navigation. It would be more intelligent to mix and match content and navigation, showing the most important ones from each, and take the user to a second screen with additional content and actions.

Unfortunately, it looks like most Android phones will be stuck with a menu button, for compatibility and other reasons.

Then, Android has the green and red buttons, to make a call and to end it. Not being a heavy phone user, I would prefer on-screen keys for these. Having fewer buttons reduces the cognitive load and makes the phone easier to use as a data device.

Update: The same goes for the trackball. It's just not needed. I have fat fingers, and I click on links in web pages without trouble. The trackball makes it slightly harder for developers because widgets should now handle a touch mode (where there's no focus) and a non-touch mode.

JSON is beautiful

2009-07-01T15:34:00.003+05:30

It's human-readable rather than binary, is concise and doesn't make you blind like XML does, and maps cleanly into programming language data structures like arrays and dictionaries. In fact, it's defined as a subset of one (Javascript) and is code as well as data.

XML is a depressing example of the momentum of standardization, when a second-rate choice is made.

Hope it becomes a universal communication and data interchange format.

Once binary JSON is defined, the performance issue goes away, too.

Year of Linux on the Desktop

2009-02-04T12:25:00.002+05:30

2020 will definitely be the year of Linux on the desktop.

Debit and Credit Card Security

2008-10-30T20:03:00.002+05:30

Some random thoughts on how you might design more secure Debit or Credit cards, some of them obvious:

Support alphanumeric passphrases rather than pathetic PINs. Force this on the banks by passing a law that does not hold the account owner liable for PIN misuse for a month when a card is stolen.
Require a PIN for every transaction . Yes, a shopkeeper can have a malicious card reader that stores the password, but this at least guards against casual pick-pockets.
Use one PIN for purchases made on the card, and another at the ATM. That way, a malicious card reader at a shop enables the shopkeeper to make purchases on my behalf, but not withdraw cash directly.
Have an option for the bank to send me an SMS and email for every transaction so that in the event of a fraud, I'm notified in seconds.
Allow me to use ATMs without physically carrying the card. Instead I can enter a password. If I don't carry my debit card all the time, that's less of a risk.
Many people use a credit card in addition to a debit card because it's safer, in that you can dispute a fradulent transaction more easily and, even if it's resolved to your favor, you don't have to pay the money first and get it back later, like with a debit card. Because of this, people carry a debit and a credit card, which is less secure than carrying only one card. Eliminate this by saying that if the bank gives X days to report a fradulent credit card transaction, it should give at least the same time for the owner to report a fradulent debit card transaction. And, as soon as you dispute a transaction, the bank must immediately and automatically refund the money while it resolves the dispute, after which it might withdraw the money again. With this, many people won't have to carry their credit cards every day.

Function Argument Passing

2008-10-30T19:54:00.002+05:30

Javascript's function argument passing is nice. Every function has an implicit variable named arguments that holds all the arguments, and the function declaration is only a shorthand. To look at it differently, with varargs and optional parameters, a function in effect takes a single argument which is a hashtable (or list, if keyword arguments are not supported). If every function takes the same single argument, why make the programmer declare it? Define an implicit variable named arguments. Then what do you put in the space traditionally used for function arguments? That can become a shortcut, so that you can access an argument by its name rather than as arguments.name.

iPhone: The Dream Ends

2008-09-22T10:22:00.002+05:30

Apple rejects another app, this time a Gmail client for "duplicating functionality". Never mind that it offers a better Gmail experience than the bulitin mail client -- conversations, archiving, starring, etc. Previously, Apple rejected a podcast download app, and the tethering application NetShare that lets you use your iPhone as a modem. As Harry McCracken put it, "Way back when, if software distribution for the Mac had been handled via a Mac App Store with a don’t-duplicate-Apple-products policy, Photoshop might have been refused distribution on the grounds that it was too similar to MacPaint."

Looks like my open-source friends were right -- in a world where everybody is either incompetent or untrustworthy, having a single gatekeeper is crippling. The iPhone isn't a platform but Apple's playground where you play on Apple's terms. It's the perfect example of Treacherous Computing, where your computing device is controlled not by you but by others for their own ends.

I no longer see any point in buying an iPhone, let alone programming it. Android's openness should provide a refreshing alternative to the iPoliceState.

Disclaimer: I work for Google.

WiFi Stupidity in India

2008-09-18T10:27:00.003+05:30

So the imbeclies running the show in India want to outlaw open Wi-Fi. This ignores the view that open WiFi may be a good way to get internet access to a large number of people in a poor country. And why should every user get his own DSL line? It's just a waste of resources.

Not to mention that this does nothing to stop terrorist attacks. Meanwhile, the terrorists will just use a phone booth or a postal mailbox. Why is it that every political system seems to be controlled by jackasses?

Fuck You, Big Content

2008-09-17T23:23:00.002+05:30

So our elected thugs are enacting a draconian legislation that, depending on whom you ask, mandates ISP filtering, turning off internet access for pirates, interfere with fair use, further erode privacy on the internet, and so forth. And all this is being done in secret, with no draft of the proposed legislation till it's signed by the various countries. As if the existing anti-circumvention laws - that effectively say that you're not the owner of a device that you paid for - are not enough. Here's a big Fuck You from my side, Big Content. Your obselete business models won't last long, even if you bribe the goons holding public office. The internet is basically a mechanism to move bits from one place to another, and enacting laws to stop this will be as useful as commanding the river to stop flowing.

Perhaps we'll end up with a repeat of the Prohibition where people will show the finger to the government and do what they want. As Larry Lessig so eloquently puts it, we can't kill the instinct the technology produces, we can only criminalize it, and there's a whole generation that rejects the very notion of copyright, and believes the law is nothing more than an ass to be ignored. No law that goes against what a large number of people want to do has a chance. Copyright is doomed in the medium to long term.

iPhone: Think Again

2008-09-13T10:39:00.003+05:30

The worst-case scenario plays out with the iPhone: Apple rejects an application because it competes with the desktop version of iTunes. John Gruber writes:

If you only find out at the end of the development process that your app has been rejected — not for a technical problem that you can address but because Apple deems the entire concept to be out of bounds — then who is going to put serious time and talent into an iPhone app?
...
Let’s be clear: forbidding “duplication of functionality” is forbidding competition. The point of competition is to do the same thing, but better.

Fraser Speirs, developer of Exposure, the highly regarded Flickr client for the iPhone, writes:

I will never write another iPhone application for the App Store as currently constituted.
...
You have to wonder if Apple wants the App Store to be a museum of poorly-designed nibware written by dilettante Mac OS X/iPhone OS switcher-developers and hobbyist students.

The whole point of the iPhone is that, in addition to having a first-rate browser, it's the first serious application platform. Earlier phones were just phones, but the iPhone is a computer that lets you install applications to do whatever you want to do. An iPhone with a crippled application market is far less useful.

Democratizing Moviemaking

2008-09-03T14:50:00.004+05:30

Fascinating Wired article on the Red movie camera:

It delivers all the dazzle of analog, but it's easier to use and cheaper—by orders of magnitude—than a film camera. In other words, Jannard's creation threatens to make 35-mm movie film obsolete.

Just as with the computer revolution, making the means of production affordable enough for a wide audience could spark a revolution. When it costs less to make a movie, you can afford to make films that appeal to a narrow market. We'll have a fascinating long tail of films of various kinds, from intellectual to artistic to political, rather than the current insipid fare.

Scalable Language Design

2008-08-15T12:10:00.005+05:30

Let's say one wanted to design a powerful language that would be widely used, from servers to the desktop to mobiles. How would one go about this? The exact set of abstractions doesn't matter -- most programmers are stuck with Java or C++, especially on the client, so any decent language will be a step up for them. So if one wanted to design a language for wide use from servers to the desktop to mobiles, how would one go about it?

First, don't insist on a VM. VMs may be useful in some circumstances, but there's no reason all execution must happen in a VM. Moreover, VMs don't work well on resource-constrained devices like mobile phones. Also there's a versioning dependency on the VM which can change incompatibly from release to release, breaking software. And the huge size of VMs has its cost as well. So any language that aims for wide use should compile to native code. If you come up with a first-rate VM, great. But don't insist everyone use it. Support both native and virtualized execution.

Second, the language should be open-source. And I mean, the canonical implementation should be open-source. In 2008, I doubt there's room for a not fully open language that wants to be widely used.

Finally, by default prioritize power, or programmer productivity. As Paul Graham puts it, "In language design, we should be consciously seeking out situations where we can trade efficiency for even the smallest increase in convenience." But if you just do that you'll end up with a language that's unacceptably slow for many applications. Would you like your web browser written purely in Ruby? I wouldn't. The solution is not to remove powerful but slow language featuers, resulting in a crippled language -- that's a false dichotomy. The 80/20 rule shows us the way -- the customary mechanisms of the language must prioritize power over speed, but you should have more optimized and less convenient mechanisms available for the hotspots. So by default, the language should be dynamically typed, but if you want you should be able to declare either the interface of a type (as in a Java interface or an Objective-C protocol) or the implementation type (subclass of Foo) or even the exact class. By default everything is passed by reference (and basic types are objects) but as an optimization you'll be able to declare that for certain types, object identity doesn't have to be preserved, in which case the compiler can do a pass-by-value optimization. Objects are just syntactic sugar for closures, but if you use the standard object mechanism, the compiler may be able to eliminate the dynamic binding and inline the call. Array lookups are by default bounds-checked, but there will also be an unchecked access mechanism that you can use in critical inner loops. By default, objects are garbage-collected and memory integrity is guaranteed, but you can use a different memory pool with manual release, and pointers to muck around with memory. Arrays are resizable (and dynamically typed), but the language also has a fixed-size fixed-type array. And so forth.

I disagree with the idea that it's not possible to design a language that's a joy to program in and is simultaneously fast enough.

Where the heck is my flying car?

2008-08-01T23:22:00.002+05:30

If you're a programming language aficionado, life is hard. You learn powerful languages like Ruby, Python, Haskell, etc, but many times you have to use C++ for "real" work, like it or not. From one point of view, it's depressing.

But if you step back and look through a long enough timeframe, there's been significant progress. When I was in high school, the default language was C++. By the time I graduated from college, the default moved to Java, which was a big improvement. Java is even the native API for Android. And iPhone and Mac OS X use Objective C, which is a dynamically typed language!

The thesis seems to be that the mainstream is not doomed to second-rate languages. It evolves, though perhaps not as fast as some of us would like. And since the high end of programming languages hasn't moved much in the past couple of decades, if not longer, if this trend continues, one day the average programmer will be using a very powerful language.

Java is the new C

2008-08-01T22:29:00.003+05:30

Till recently I thought of JVM programming languages as a bad idea — that the JVM didn't really offer much for a dynamic language implementor. That may be true technically. But if technical factors were all that mattered, we'd all be programming in Lisp, Haskell or Ruby. While a lucky few may get to use the powerful languages, most of us can't, for valid reasons. Because the software we have to interact with is in a different language, or because the company has a ton of internal libraries that have to rewritten for each new language, and maintained. This is the case at Google, for instance.

Programmers fall into three levels here. At the top are the lucky few who can use whatever language they want, and at the bottom are the unwashed masses who'll use whatever language the other guy is using, but in the middle are those who want to move up the ladder but can't. Anything we can do to decrease the barrier of adoption helps the second group, and eventually everyone. And it's not as if having a lot of users hurts the language.

Currently, moving to a new language means learning the language itself, and then its libraries. What if we remove the second component by leveraging, say, the JVM standard libraries? Java, like it or not, has become something of a de-facto language, which means there a lot of people who are comfortable with JVM libraries, so if we offer the prospect of a better language without having to learn brand new libraries, maybe that will be more widely successful than a blank slate approach?

There are also other advantages, like more easily being able to invoke other components written in Java or writing performance-sensitive parts of the program in Java. One of the complaints against dynamic languages is performance, and instead of writing performance-sensitive pieces in C, one can write them in a much higher-level but still reasonably fast language. Besides, the interface between the dynamic language implemented on the JVM and the Java language (say, the Jython-Java interface) will most probably be orders of magnitude cleaner than the equivalent C interface, like the Python/C interface.

Java not only has a lot of users, but it could serve as the substrate for other, higher-level languages. In that sense, Java may well end up being the new C.

Busting the Macs-are-now-as-cheap-as-PCs Myth

2008-07-28T13:13:00.004+05:30

We've been repeatedly reading on Mac users' blogs about how Macs are now as cheap as PCs, but most of them make the mistake of configuring a PC to be as identical to the chosen Mac as possible. That's just stupid. You should configure both systems to be as close to your needs as possible. Who cares if the Mac has Firewire 800 if you're not going to use it?

So here's my list of requirements:

Laptop.
CPU powerful enough to play 1080p video, which means a Core 2 Duo at 1.8GHz.
2 GB RAM.
7200 RPM hard disc if possible, otherwise a big 5400 RPM disk (where there's no concrete requirement of bigness).
If possible, the system should be able to drive a 30-inch monitor at 2560 x 1600.

So I head to Dell India site (I live in India) and end up with a VOSTRO 1510 Laptop (n-Series) with a 1.8 GHz Core 2 Duo, 2 GB memory, 15.4" widescreen 1440x900 display, 160 GB 7200 RPM disc, a combo drive, a 256 RM Nvidia GeForce 8400M GS, an intergrated 1.3 megapixel webcam, Wireless-N, and no bluetooth for about Rs. 38,000 (Indian rupees).

The Apple India store doesn't let me configure a machine online; I have to pick one. The cheapest Macbook costs me Rs. 50,000, and it has only 1 GB RAM. The guys at the local Apple store told me I could bump the memory to 2 GB for approx Rs. 1000, and the disc space to 250 GB for another thousand or two rupees. So I end up with a Macbook with a 2.1 Ghz Core 2 Duo, 2 GB memory, a 5400 RPM 250 disc for something like Rs. 52,000. Note that the disc runs at only 5400 RPM as opposed to the Dell's 7200 RPM. If I were to configure the Dell with a 5400 RPM 320 GB disc (bigger than the Macbook's), its price would actually drop by a couple thousand rupees. Also the Macbok can't drive a 30-inch monitor at full resolution. So let's compromise with a 1920x1200 video output. Still it's Rs. 52,000 for the Macbook vs. Rs. 38,000 for the Dell.

How does the Macbook compare to the Dell? A slightly faster CPU (2.1 Ghz vs. 1.8 GHz) (which I don't need), a slower (5400RPM vs. 7200 RPM) disc or a smaller one (250GB vs. 320 GB), ability to drive only a 24-inch monitor at full resolution instead of a 30-incher (this is important to me), Firewire (which I never used), Bluetooth (did you try transferrring a hundred MB over bluetooth?) Or for the sake of comparison let's add Bluetooth to the Dell for less than a thousand rupees. Still it's Rs. 52000 for the Macbook vs. Rs.39,000 for the Dell. I'm sure that among the amazing skills Mac users have is the ability to compare two numbers. So tell me, isn't that a significant difference? Or if I insist on the ability to drive a 30-inch monitor at full resolution, I'll end up with a Macbook Pro at Rs. 89,000 as opposed to Rs.39,000 for the Dell -- more than twice the price.

OS X may actually be worth the money, but let's say that outright. Don't make stupid claims that a similarly configured PC costs as much as a Mac because for many people the Mac will have things you don't care about.

The Fallacy of Choice

2008-07-28T09:32:00.002+05:30

Interesting piece from the Linux Hater's Blog, via DF:

[The vast majority of users] don't care about a particular choice, and actively do not want to have to make a choice. They just want things to work. They will take "working" over "choice" in an instant.

Spot on. The Linux community seems to look at choice as a mantra that will fix everything wrong with the OS, but choice is no good when all the options are broken. The basic problem with the Linux community is that they are incompetent at UI Design, and no amount of choice will fix that.

Furthermore, any developer will tell you that each time a new layer of "choice" is added, the possible number of configurations multiplies. This means more untested configurations, more bugs, and more brokenness.

Linux still has a long way to go.

Case-Sensitive Filesystems

2008-07-25T20:25:00.003+05:30

I've never been able to understand why the Linux filesystems are case-sensitive. Assuming you don't want to create files whose names differ only in case, the only result of a case-sensitive filesystem is error messages saying essentially that you used the wrong case. And that's just irritating, with no plus side. A well-designed interface minimizes errors. Maybe it's not a coincidence that both OS X and Windows use case-insensitive filesystems.

Yes, I know that NTFS is case-sensitive, but since the only documented way to access it is through win32, it's practically case-insensitive, unless you use you use your computer as a Unix server using Services for Unix. By practically case-insensitive I mean that you can open a file by typing in the filename with the wrong case from, say, the console.

This madness extends to web servers like a virus. Web servers should not return 404s for URLs with the wrong case. That's sheer madness.

The Autoupdate Sin

2008-07-21T11:05:00.003+05:30

It pisses me off when applications, and even frameworks like Growl, put up dialog boxes saying a new version is available. Well, what are you telling me for? If the new version has some security fixes, update silently! If not, do whatever the hell you want to! Don't keep nagging me with this trash. Software should take care of itself rather than whining.

Content Protection Scumbags

2008-07-21T10:47:00.003+05:30

The PC industry is committed to providing content protection on the PC —ATI.

Translation: The PC industry will screw its paying customers by denying them the right to play content they paid for on a device and using software of their choice.

There are other instances of the industry working against users. For instance, when the Sony rootkit came out, Symantec Antivirus wouldn't classify it as malware because it's from Sony. PC Magazine didn't run an article about it for quite some time, if ever.

Just like the world at large, the PC industry is a bunch of scumbags who will kill their grandmothers if it adds to the bottom line.

The Ideal ISP

2008-07-20T17:15:00.002+05:30

Many ISPs in India make you choose between a slow unlimited connection and a faster one with a data limit of a few gigs. The ideal would be that, no matter what your plan, traffic on port 80 is not subject to any speed limit until, say, 1 GB of data has been transferred. Also, the user should have an option where P2P traffic is given a lower priority than other traffic throughout the ISP's network, but it doesn't count towards the data transfer limit.

Hiding the Program Lifecycle

2008-07-20T17:05:00.002+05:30

One idea from Android that I wish desktop OSs implement -- automatically shut down applications as needed. Why deal with something when the OS can? Mac OS X already does this to some extent, where most apps don't shut down when the last window is closed. Why not take this one step further and close them when the system runs low on memory? And the user mostly needn't know when this happens, since it's done only when the app has no windows open.

The OpenMoko Train Wreck

2008-07-20T08:13:00.003+05:30

Hilarious demoing the OpenMoko, which the FSF claims is iPhone-class. I wish it were. Open-source contributed a lot to the world, but some of its more extreme proponents discredit the whole movement when they go too far.

Freetard Propaganda against the iPhone

2008-07-19T11:13:00.004+05:30

Clarification: I use and love a lot of open-source software, and even work on one full-time (Google Gears). "Freetard" is meant to refer only to the more extreme elements in the community, not all open-source folks.

From FSF:

iPhone completely blocks free software. Developers must pay a tax to Apple, who becomes the sole authority over what can and can't be on everyone's phones.

It can actually help to have a central gatekeeper, for security. The root cause of the Windows malware pandemic is that, well, people can write malware and there's nobody to check. Anti-malware is not the solution — the best antivirus software in one test let through 32% of virii. Warnings about software installation don't help, since people are conditioned to click Yes to any prompts, and that's our fault, as an industry — by writing software that puts up unnecessary dialog boxes, we have trained people to click Yes blindly. And "educating" users is fundamentally a bad idea. Why force users to become security experts when you can outsource that to a central gatekeeper, in this case, Apple? Any technology that doesn't work by itself and forces users to learn a complex set of dos and don'ts ("or you will be sorry later") is totally broken.

Apple's approach is obviously not perfect, but for most people it's an improvement over the current "leave the users to their fate" system.

iPhone exposes your whereabouts and provides ways for others to track you without your knowledge.

I thought the iPhone prompts you when an app wants to use geolocation. And that is actually useful — I'd like to know if a friend is within a few hundred meters, for example. In fact, if you use a cell phone at all, the network has to know where you are so that it can route your calls to you. Maybe you should stay home and communicate using carrier pigeon?

iPhone endorses and supports [...] DRM, and won't play patent- and DRM-free formats like Ogg Vorbis and Theora.

I actually like my media in patent-encumbered formats like MP3 or AAC, since they work on my existing mobile phone and on my mp3 player, and on all my computers, without installing additional software, and I can email them to friends.

iPhone is not the only option. There are better alternatives on the horizon that respect your freedom, don’t spy on you, play free media formats, and let you use free software — like the FreeRunner.

The Angry Drunk put it best: HAHAHAHAHAHA!. Wait, let me catch my breath. HAHAHAHAHAHAHAHA!.

The whole problem with "free software" advocates is that they don't understand (or refuse to recognize) that there are many dimensions to the issue. Not just "free" or "non-free", but things like, say, user experience. Does the software let users get things done in a timely manner and have a happy time doing so? Lots of open-source software is broken. The last time I installed Linux for a friend [1], I had to edit /etc/X11/xorg.conf just to get the GUI working. By comparison, Mac OS X is a joy to use. It's so smooth and fluid an environment it appeals to you at a very deep level and you're just happy and grateful to use such a work of art. OS X is joy.

Whereas a lot of "free software" is free as in syphilis.

How can anybody have such a narrow one-dimensional worldview where it doesn't matter whether something works for its users or not; it only matters whether it adheres to some ideology? This is amazing. I just can't understand how some people are wired.

[1] Actually he was my enemy.

TrainWreck++

2008-07-18T12:58:00.002+05:30

Some things in life are so strange that you wonder if it's some kind of Lynchian alternate reality or a bizarre joke. Case in point: C++0x. Go ahead; read the wikipedia article. No programmer ever woke up and said, "C++ is such a simple language. We need to add more stuff." Honestly, what is wrong with these people? How can any sane person graft even more language machinery into C++? The mind boggles! Some things in life are beyond understanding.

Here are some quotes to commemorate this occasion:

C++ is an octopus made by nailing extra legs onto a dog. —smalltalk.org
Programming in C++ is premature optimization.
Think of C++ as an object-oriented assembly language. —guile mailing list
Life is too long to be an expert at harmful things, including such evilness as C++ and Perl. -Eric Naggum

Non-JavaSchools

2008-07-17T14:04:00.003+05:30

Reading Joel Spolsky's JavaSchools reminded me of the discussions I sometimes used to have with professors in college -- that they should teach Java (when they were teaching C++), and that they should teach Python (when they were teaching Java). Some of us have higher expectations of college than merely learning the fad of the day -- you should learn the best, and for programming languages the best is a language that allows you to be more productive, which you will use one day as languages slowly evolve. So what languages would a real CS education teach you? Here's my list:

Javascript/Scheme -- for closure-based programming (No, not the ES4 monster, but core Javascript, as in ES3). Or perhaps Smalltalk.
Haskell -- for lazy evaluation.
Erlang -- failure containment. Divide the program into modules, with no shared memory, and have them communicate using message passing. That way, a failure in one module is contained there.

Most definitely there should be nothing about C++ or Java.

Open Source and Innovation

2008-07-14T18:25:00.007+05:30

A long time back I used Fedora Linux 1.0 for almost an year. It was a terribly, terribly broken OS, but that was not the worst part — it was the community. How could anybody not spit at that steaming pile of dung they call an OS? How could anybody have such abysmally low standards that they tolerate and worse, happily use a piece of technology that's so broken? I was quick to conclude that, bad as the OS is, with such a “community” , Linux is doomed. John Gruber's Spray-On Usability resonated deeply with me, and as long as I was forced to use Linux, I would read this post every month or two and avoid breaking into tears as I wrestled with the OS. Finally, when I got my own computer, I installed Windows on it and it was a breath of fresh air.

Fast-forward several years. Linux improved a lot, and now I work at a company where Linux is our backbone. I'm a multi-platform citizen, equally comfortable with Linux as with Windows, and can get around OS X. As I re-read Spray-On Usability for the umpteenth time, one idea leapt out at me: "There’s an old engineering adage: “Fast, good, cheap: pick two.” (Where “fast” regards development time, not performance.)" If you solely consider user experience, Linux can't hold a candle to OS X. But, if you don't want to or cannot pay a thousand dollars for a laptop, Linux could offer a fairly serviceable, though not spectacular user experience, more or less in the same league as Windows. They could do this merely by copying OS X and Windows, as they have been doing all along. In fact, till recently I was thinking open-source is all about copying, not innovation [1]. In a way that's true, if you consider the usual meaning of innovation as building something that works better for the user. But remember, a Macbook is a month's salary for a huge number of people in the world. I thought of saying developing world, but then I stopped myself -- it's the world at large. Not yet a "market" in the narrow sense of a bunch of people you can milk for money, but users. Apple, for all its beauty, is a profit-driven company. It doesn't care about you unless you have a thousand dollars [2]. Whereas open-source principles, like the ideals behind any great revolution, are truly grand. Judging by the rate at which Linux is improving, one day it could be a fairly decent OS for a large number of people. Whole societies could use affordable technology to become more productive and escape poverty [3]. So far the revolution hasn't happened, but it may, some day. Operating systems don't exist in a vacuum. As John points out, on the continuum between free and wonderful, OS X occupies the high end and is slowly becoming cheaper. Linux is free, and is slowly becoming good. As that happens, it could mean a lot to a huge number of people. Open-source's innovation is not that it's better, but that one day it could be a more economical way to bring good enough technology to a large number of people. And that is noble.

[1] I'm referring to user-level open-source projects, not developer-level ones like, say, Ruby or Python or gcc.

[2] Yes, the Mac Mini is cheaper, but after using a laptop, who would want to go back to a desktop?

[3] Affordable technology also includes pirated copies of Windows.

Undock Madness

2008-07-14T18:21:00.002+05:30

Before I remove my Thinkpad from its docking station, Windows requires me to click on Start->Undock or press a button on the dock that does the same thing. As far as I'm concerned, undocking is equivalent to unplugging the power adapter, ethernet cable, USB keyboard and mouse and external monitor. None of these steps by itself requires an advance notification to the OS. Why should the combination require me to tell the OS what I'm going to do?

Constructors are a bad idea

2008-07-10T12:21:00.005+05:30

Effective Java begins by talking about the drawbacks of constructors: they do not have names to distinguish each other, they have to create an instance of the object (and not use a cached object), they have to create an instance of the class (and not a subclass or a proxy for remote calls, access control, etc). Instead of making programmers work around the deficiency of the language, it will be good if the language has no notion of constructors or a new operator; instead classes should have a static method named new (or something else if it's more appropriate for a particular class) that returns an object. Perhaps an allocate operator can be added (in place of new) that returns an unitialized object, and which can be invoked only from within the class.

So you have static factory methods as the default, with the flexibility they entail. And if you want full factory objects, as long as they have a new function with the same signature, it will be easier to retrofit them into an existing program. Moreover, if you have dynamic scope, it can get even better, because the factory instance doesn't have to get passed around everywhere.

The Ideal Language

2008-06-24T16:15:00.008+05:30

This is the language I would design today. I haven't used Lisp, Joy, Forth or APL, so I may miss something there. But here's an ideal language that's reasonably close to the mainstream:

No compulsory type declarations, with type inference for early error detection.
Everything passed by reference. A type can specify that object identity doesn't have to be preserved, in which case pass-by-value optimization can be done. But that's just an optimization; the conceptual model is that everything is passed by reference.
Closures (functions that can access the enclosing lexical environment)
Anonymous functions (functions that don't have a name)
If objects are supported, they should be just be syntactic sugar for closures.
Varargs and apply
Pattern-matching for function calls and variable assignment. This proves incredibly convenient in Haskell.
Everything is an expression.
Optional dynamic scoping to set global-like variables for a call (and subcalls).
Finding functions in a correct module based on the arguments a la OO.
Modules as objects that can be passed around.
Definitions (of functions, variables, etc) are executed. A file consists of statements of code, not definitions. Some of these statements when executed may end up defining functions in the current module.
eval
No braces; use indentation to control nesting.
Garbage-collection.
Tailcall optimization.
Threading: In addition to kernel threads (to exploit multiple cores), the language should support co-operative threads hosted within a single kernel thread, because sometimes you want multiple flows of execution without the non-determinism of arbitrary preemption. These are preempted only when they make a blocking call, like I/O or sleep() or an external call (to C or the hosting language) or by an explicit yield(). Since these don't run in parallel and are not preempted, they should be implemented purely in userspace with very fast switches. They can be used as a substitute for generators. The language also has a inter-thread messaging-passing system, like Erlang.
Modules (or packages or namespaces): what would a module's interface consist of? A bunch of exported functions, since a function is the only true abstraction we have. (Everything else is on top of functions.)
Lightweight build system -- no need to "compile" code before running it. Compilation really is optimization (in addition to linting), and so it should not be forced.
Optimization philosophy: The language should aim to maximize programmer productivity. If you have a performance problem, you should be able to use sacrifice productivity for performance, as an explicit decision and incrementally. The core language should not be designed for performance. Some optimization techniques might be type declarations, non-garbage-collected allocation pools, pointers within an unsafe block (as in C#), etc. Similarly, while the usual list should support resizing, insertions and deletion, like Python's list, there should be a fixed-size typed array that you can use when performance matters. The language should also have a Strongtalk-like VM that gives maximum performance with minimum effort, for dynamic code. But it should also compile to machine code if desired.
No silent arithmetic overflows. Integers are either infinite-size, like in Python, or you get an OverflowException.

Windows is a Ghetto

2008-05-15T17:05:00.004+05:30

Switching back to Windows after a half year of significant OS X use, it struck me how backward Windows is compared to OS X. There are many points one can make: Windows boots slower. Application installation and management is a mess, and the start menu used to organize applications is unneccesary. The UI is merely serviceable, instead of delicious. The latest version of the OS is a step back. There are hardly any good applications bundled with the OS. There are zillions of settings, and most defaults are wrong. The APIs are badly broken. Integration between the OS and hardware is bad (example: when I use the hardware switch on my Thinkpad to turn off WiFi, Windows tells me it can't connect to my preferred wireless network). Mandatory file locking gets in your way all the time. The third-party application community is a huge wasteland.

Perhaps the worst thing about Windows is not that it's broken, but the realization that you're living in a mindless system where the overlords don't care. That is incredibly soul-killing. Windows is a ghetto. Leave.

Where Windows Shell is Better Than Linux

2008-04-23T15:47:00.003+05:30

You can launch a document directly from the shell, like this:

C:\data>test.html

Linux forces you to decide the appropriate program yourself: firefox test.html. OS X is midway between these: open test.html.

When you launch a GUI program, you don't have to suffix an & to let the shell continue executing.

Both these choices make it a better shell for normal use. Frequent tasks should be easy to do.

Cream for Windows -- Broken

2008-04-23T13:37:00.003+05:30

I tried the Cream text editor for Windows for a few days. If you're not familiar with it, Cream is a configuration of Vim that uses the standard shortcuts like Ctrl-S rather than the brain-damaged :wq. I thought this would be the best of both worlds -- a good Windows text editor that also works on Linux, so that expertise I build up on Windows will be useful on Linux. Unfortunately, Cream is broken. Here's what bugged me in the last few days, in no particular order:

Litters directories with .swp files, and they are frequently left behind when Cream quits. This makes it bug me the next time I open these files. Also the "OMG swap files are leftover!" message requires me to scroll down to read text before the dialog box pops up. Lame.
How do I tell Cream to put the swp files somewhere else? Why, by editing some stupid config file, in the grand Unix tradition. A half-assed Windows port.
When you search for something, the find dialog box loses focus so you can't dismiss it by hitting Esc.
When a search fails, the status line says: Pattern not found: \v\Cfoo. What the hell is the \v\C. Don't give me any vim nonsense.
I haven't figured out how to right-click a file and open with Cream. The launcher (vimrun) is a batch file that doesn't take arguments or something.
When I drag and drop a file onto the Cream window, either on the tab bar or above, it sometimes replaces an existing tab, with no obvious way to disable it.
Ctrl-W doesn't close tab.
Broken copy-paste: Selecting text implicitly copies it to the clipboard. I have no problem with being able to middle-click to paste selected text, and in fact I like this, but breaking the standard behavior of Ctrl-C and Ctrl-V is inexcusable.

Conclusion: a half-assed Windows editor. Uninstall.

Worms, please use HTTP

2008-04-06T13:31:00.001+05:30

I sometimes wish all worms and malware communicated through HTTP. Then, once firewalls no longer have to block non-http traffic for security, programmers might break free of the tyranny of HTTP. Server-initiated communication without polling. In-browser chat clients that use SIP. Support for arbitrary application-layer protocols implemented in Javascript...

And, once that happens, it will be a little easier to move to something like SCTP that overcomes TCP's limitations -- have multiple logical channels within one connection without head-of-line blocking. Unordered message delivery. Multihoming, so that downloads are not broken when you switch from a wired to a wireless network connection...

A secure platform at last?

2008-04-06T12:06:00.002+05:30

The iPhone has an interesting approach to software installation -- you can install only apps that Apple certifies. At one shot, this eliminates malware of various kinds -- viruses/worms, trojan horses, spyware, adware/nagware, rootkits...

The PC approach is to detect malware on your PC. Even if you did not have to do your research and install anti-virus and anti-spyware and rootkit detectors and what-have-you -- that is, even if first-rate anti-malware came with the OS and worked invisibly without bothering you, it's a costly arms race that we're losing. When tested with new viruses, the best antivirus software let through 32% of them. Not to mention that anti-malware constantly consumes resources, an especially serious problem for mobile phones.

If we can't reliably detect malware on the PC, can we prevent it from getting installed in the first place? Hence the usual exhortations about not downloading or installing stuff. But that doesn't work. People will click on anything that looks interesting, partly because bad software has conditioned them to click Yes to any prompt that appears, and partly because "given a choice between dancing pigs and security, users will pick dancing pigs every time". But why should users have to become security experts, in the first place? Any technology that doesn't just work by itself and requires you to learn and follow a set of dos and don'ts is broken.

So if we can't reliably detect malware once it's installed, and if we can't and shouldn't require users to decide what's harmful, the alternative is to outsource this decision-making to people who are actually capable and interested in doing it. The iPhone is one model, where Apple decides what's good for you and what's not. The problem with this is that power corrupts -- the gatekeeper decides what's good for them, instead of what's good for you. Apple doesn't allow anti-DRM tools on the iPhone, even for fair use -- the right to play media that you paid for on a device of your choice.

How about we allow the user to decide whom to trust? Have multiple certification authorities --services that tell you if a given application is harmful. The user gets to decide which one to use. Have the OS speak an open protocol to the certification authority, so that anyone can roll his own. When you install an app, the OS contacts the service of your choice, sends it a hash of the application package and asks if it's safe. That way, you have security and control.

A certification authority can use many ways to detect malware. For instance, they can run the app through the top 20 antivirus tools. They can run the submitted app in a virtual machine and run the antivirus software from the host OS. They can have a list of all syscalls the app makes and look for suspicious disk or network activity... Basically why do the dangerous job of malware detection on your desktop?

Certification services can go one step further than security. For example, insist that the app follows Human Interface Guidelines for consistent, decent user interfaces (the iPhone SDK license agreement mentions this). Weed out multiple me-too softwares that do nothing different. One of the nice things about the Mac software market is that there are fewer apps for a given task, but they are high-quality. What if you could check a High-quality Apps Only option in your system preferences and have it weed out the train wrecks?

Imagine how much better things could be if malware of various kinds were gone. That would also eliminate spam.

Application Installation 101

2008-02-22T12:28:00.002+05:30

Just having switched back from OS X to Windows, or rather unswitched, as I installed a couple dozen applications it struck me how much more streamlined the process is on OS X. More often than not, you just drag a .app file to a folder on the hard disc, and you're done. All dependencies are in the package itself. The best installation procedure is one that doesn't exist at all. Would you like it if you download a PDF file and you're about to view it, but, no, wait a minute, you can't -- you have to go through an involved "installation" process before you can open it. Same is the case -- you want to run an application, and the OS should get out of the way and let you do it right away without further ado. Anything else is Bad Design.

On Windows many installers ask you whether to put an entry in the start menu, and where. And I have to go back and move the start menu folders outside the Programs folder. In OS X, there's no need for a start menu to manage -- your applications folder is so clutter-free that you can use it as a menu of applications. This is because apps appear as individual files (bundles) that launch when clicked. After all, what's the most common thing to do to an app other than to launch it? [1] Since the applications folder is so clean, you don't need a separate hierarchy of shortcuts to applications. Which also means there's no start menu to manage or questions to answer about where you want shortcuts created. And if you want to organize applications, because they're self-contained, generally you can just drag the .app file to a different folder without breaking the app.

As Paul Graham put it:

What would Apple's next product look like if you replaced Steve Jobs with a committee of 100 random people? Windows.

The Linux people blow it, as well -- I don't want to deal with a package manager. There's already a way to organize files, and it's called the filesystem. I want to "install" an application the same way I "install" a PDF file -- copy it to the filesystem. Don't make me go through a different process. And what if the app you want to install doesn't exist in your distro's repository? That has happened to me more than once. Or it exists but is called something else because of some idealogical or political storm in a teacup that you care nothing about? Besides, package managers sometime get into an inconsistent state where they demand you repair them before you do anything else. And sometimes the repair doesn't work. Not to mention that in the grand Linux tradition of fragmentation, different distros have different package managers, which means knowledge you pick up on one distro doesn't serve you on another. This is a problem with the whole idea of multiple distributions, but if application installation did not use package managers, you wouldn't have to deal with differences between them.

The open-source Unix argument here seems to be to eliminate duplication of files, but I'd much rather solve the problem with more memory and marginally more disk space. In fact, that may be part of the reason the Linux approach is bad -- they optimize for the wrong thing -- system resources instead of user experience. [2] But then, since when is Linux known for a solid user experience?

On OS X things work so smoothly that you don't realize how much better it is till you start using Windows or Linux.

[1] There's also a Show Contents option when you need it.
[2] Maybe that's an artificial tradeoff to some extent -- with ZFS, since files are checksummed, duplicate copies of libraries in different applications can be merged on disk, and the OS can use the checksum to load only one copy into memory. But even otherwise, I'd much rather install more memory than "install" applications.

SIP Dreams

2008-02-22T11:35:00.002+05:30

One day, in an ideal world, the phone networks will implement SIP gateways so that from any computer you can make a SIP call to 9903949391@airtel.com to reach me, and it won't cost you anything more than it does today to make a call on Google Talk or Skype (read: free), and it won't cost me any more than it does to receive a call today, which is nothing. Or there will be no such thing as the "phone network" -- only a data network that carries SIP sessions between computers of different kinds... And, in an ideal world, Microsoft would make its specifications open, too :)

Horizontal Interfaces

2007-05-27T19:46:00.000+05:30

Do you scroll vertically much more often than horizontally? If so, you need more vertical space. And widescreen monitors make the problem worse. To make efficient use of vertical space, move the taskbar or dock to the side of the screen. Ditto for toolbars when possible. I put my website's navigation bar on the side rather than across the top for the same reason.

Unfortunately, many applications won't let you put toolbars on the side of the screen. I wish that changes. And I want a window system that puts window decorations -- the title bar, close, resize and minimize buttons -- and menus, toolbars, the tab bar, and the status bar on the side of the window or desktop rather than the top. The top and bottom of windows and the desktop should contain nothing, except perhaps the window border. I wish someone implemented this...

Crystallization of a Style

2007-05-08T22:28:00.000+05:30

Alan Kay makes a fundamental categorization of languages -- some are the crystallization of a style, with a core principle that describes them intellectually and around which everything else is built, and others are the agglutination of features, made by sticking together features from different paradigms -- the secondary colors of programming. This prompted me to make a list of the crystallization-of-a-style languages I know of, with the definining characteristic:

Lisp: everything is a list
Smalltalk: everything is an object
Haskell: be lazy
Joy: organize the program as a composition of functions; we don't need parameters
Forth: manipulate the stack explicitly rather than using local variables
APL: apply operations on arrays
Erlang (at a higher level): organize the system as a set of loosely-coupled tasks that communicate only by message-passing

(I haven't used most of these languages, so I could be wrong.)

newlisp - a breath of fresh air?

2006-09-19T12:02:00.000+05:30

I originally posted this on infogami, but since infogami seems abandoned, I'm reposting it here.

Newlisp is an exciting new Lisp dialect. Here's what I find interesting about it:

Reasonable library - networking (HTTP, TCP, UDP), XML-RPC, database, regex, HTML, XML, Unicode, OpenGL... (I don't know how other dialects compare here).
Portable - the download page lists binaries for Windows, OS X (PPC), Linux and other OSs.
Good documentation.
It "puts the fun back in Lisp".
Seems more accessible.
newlisp seems to undergo "very active development. newlisp quickly closes the gap from the other Lisp dialects. Its code is open (GPL) and looks well managed, the documentation is detailed and tidy, and the implementor is open minded for new ideas and improvements."
A Lisp-1 (one namespace for functions and variables; no need to #`)
Conservative Memory Requirements.

I don't like it that undefined symbols are treated as nil.

There's a FAQ and a comparison with other dialects (among others) on the newlisp site (which runs newlisp).

I'd previously wanted to learn Lisp but was put off by the lack of libraries and the platform-dependency. I'll try out newlisp sometime. It might well end up bringing Lisp to a broader audience.

Use WebDAV, not FTP

2006-06-10T22:37:00.001+05:30

WebDAV	FTP
+ simpler, better performance: no need to open and close TCP connections for each transfer, one request is enough to start transfer, pipelining, no need to login, stateless
+ based on HTTP (more widely used, no need to install separate FTP server, no separate port)
	- transmits passwds in clear
+ update notifications (spec in progress)
+ locking
+ versioning
+ file properties
+ ACLs
+ partial writes
	+ FXP

My Definition of Functional Programming

2006-05-13T15:32:00.000+05:30

Functional programming is a style that uses:

Pattern-matching
Variants
Enforced immutable state
Lazy evaluation

Of course, not every language may support all of these.

Healing the Object/Map Divide

2006-05-13T12:46:00.000+05:30

An object (or, more precisely, its state) is just a map where the keys are strings from a certain grammar. Many languages allow attributes to be dynamically added and removed. Consider removing the restriction on the keys - allow any object, not just a string [1]. Then we don't need the object/map divide! [2]

Ideally a language should define the '.' operator in terms of []: obj.attrib = obj['attrib']. That is, every object is a map, and attribute access is just a special case of map lookup with a different syntax, where you specify the attribute name as an identifier rather than an arbitrary experssion that could be computed at runtime [3].

Yes, with this generalization, the '.' operator won't be able to access all attributes (but only what it can access otherwise - where the keys are strings that are valid identifiers). But this is a reasonable state of affairs.

This would be beautiful. We'd be getting rid of one whole language feature - attributes, as different from entries in a map.

[1] Python accepts only strings for the keys, but any string will do - not just valid identifiers.
[2] There may be a need for different implementations optimized for different cases, but we don't need different abstractions.
[3] Javascript has this equivalence.

Last Updated: 18 May 2006

Cloaked Methods

2006-05-13T12:16:00.000+05:30

In a dynamically typed language, a method invocation can result in a NoSuchMethodException (or whatever it's called). One can define a method that throws the same exception. Then the object will appear to callers to have no such method at all (unless reflection is used). Is there any use for an explicitly thrown NoSuchMethodException? Surprisingly, yes:

method_missing, of course, has to throw this exception when forwarding fails.
Undefining inherited methods that aren't appropriate for the derived class. This will allow inheritance to be used in situations where the derived class is not a subtype of the base. (Yes, for this to work, clients should not assume that inheritance implies subtyping.) Such a thing can't be done in statically typed languages because calls to non-existent methods don't result in an exception; violations are caught at compile-time.
An example use would be a hierarchy where only cloneable classes (appear to) define a clone method, irrespective of the parent's cloneability.

Explicit self is a good idea

2006-04-24T23:52:00.000+05:30

In Python, a method must declare the self argument explicitly, and all attribute accesses must use the self. prefix. I think this is a good idea:

A method is basically a function that takes a reference to an object. I'd like the syntax to reflect that. Explicit is better than implicit.
An explicit self scales better to the no-distinguished-object style (where the self argument is syntactically treated similar to other arguments). This would be useful for multimethods.
It distinguishes between local and instance variables. So do instance variable declarations, but at the cost of not allowing instance variables to be dynamically created or deleted.

Yes, this does make refactoring harder, but I think it's worth it.

Last Updated: 01 Nov 2006.

Proprietary Software

2006-03-20T21:20:00.000+05:30

An article on open-source software had this delightful statement:

For decades software was “proprietary”...

Makes you smile... open-source seems to have finally arrived :)

Serves them right!

2006-02-28T14:48:00.000+05:30

See the connection between Vodafone blocking Skype, and taking a £28b hit? The assholes deserve it!

I hope the other clowns learn before they kill themselves, inconveniencing many people in the process.

Interesting Languages

2006-01-28T12:07:00.000+05:30

Here are some interesting languages:

Joy - A language where functions have no formal parameters
Forth - where there are no local variables (?)
Icon - which has a notion of failure of any part of computation
APL - in which you can write a program to simulate shuffling a deck of cards and then dealing them out to several players in four characters -David Given

Last Updated: 17 Feb 2006

Boo vs. C#

2006-01-26T14:15:00.000+05:30

Here

The Joy of Continuous Testing

2006-01-18T14:30:00.000+05:30

I did a project last semester that consisted of building a small object database in C#. We had testcases for every aspect of externally observable behavior. This was the first project for which I used unit tests, and the payoff was tremendous. The most remarkable advantage is the incredible confidence I had in my code; I could make any change and know instantly whether it broke something. Moreover, when things broke that shouldn't have, it alerted me to the presence of bugs I might not have discovered otherwise because I wouldn't have tested for them. Another nice result is that the tests define what it means to have a working program. (We finally ended up with almost a 50-50 distribution of code between tests and the main system.)

Function Invocations

2006-01-18T02:04:00.000+05:30

This post was originally intended to be about syntax, but turned out to cover far more ground. Perhaps this is because syntax matters a lot!

Ruby allows you to remove the parenthesis around function arguments; you can invoke a function like this:

copy file1, file2

Surpisingly, this turns out to have far-reaching effects:

cleaner, simpler syntax (fewer tokens). (In particular, enclosing within parentheses a block that's a function argument is ugly. Groovy had to make an exception to the syntax for this case, which Ruby doesn't have to.)
a very clean model for properties (without need for Python-ish descriptors)
a clean model for operator overloading
unification of statements and functions ( print, loop, throw and catch are functions)
higher-order operations are more convenient. In particular, this matters for domain-specific languages, like Rails.

For instance:
attr_accessor :age

or:
scaffold :committee

In Python, the syntax dog.bark returns a bound method; I prefer the simpler syntax to be an invocation because, as I see it, inovcation is a more basic part of the notion of a function (or method) than binding it to an object. To get a bound method in Ruby, you say:

barker = dog.method :bark

But once you get the function, inovking it requires:
barker.call

rather than Python's:
barker()

I don't like it that Ruby doesn't allow me to do:
barker()
or even just:
barker
I think this aspect of Ruby could be improved. On the whole, though, I prefer the optional-parentheses model.

A further change in syntax is to remove the comma, too. After all, why type characters that aren't necessary? And presto! we're in the S-expression-land of Lisp (and the somewhat similar syntax Haskell has). Which brings all the power of macros. It seems true that all roads lead to Lisp. (You may not travel all the way, and that's a different matter, but be clear where the power lies.)

This is as far as I've come to accepting Lisp's syntax, which has been the biggest reason for me not to use the language. Have I invalidated my excuse?

Last Updated: 17 Jun 2006

Operator Overloading in Ruby

2006-01-13T19:18:00.001+05:30

Update: Looks like I was wrong. See the second last comment.

The best implementation of operator overloading I've seen (next to Lisp's ;) is Ruby's - you just define methods named ==, <, etc. The C++ mechanism is really ugly - they just go for more syntax, like the operator keyword. Python's is better, but still ugly - you define methods named __eq__, etc.

The beauty of Ruby's system is that there is very little language support for it. In Ruby,

Characters like ==, = and ? are allowed in method names and other identifiers
Methods can be called without () at the end; simply give the arguments after the method name

So you can do this:

if dog.hungry?
    dog.eat biscuit
end

Since + is a valid method name (and numbers are objects), you can say:
puts 3.+7

The only support Ruby gives for operator overloading is to allow the dot to be removed. The rest of it follows automatically from the power and flexibility that's already there.

I find a model that says, "the operator + maps to the method +" to be more straightforward than one that says, "the operator + maps to the method __add__". So + and .+ is just the operator/method duality - when you look at it as an operator, it's +, and when you look at it as a method, it's .+ .

Incidentally, the very same power simplifies properties (things that look like instance variables but are backed by methods) - a read of a property dog.age is just a call to the method age with the parentheses removed, and a write is a call to the method age=. How elegant!

With a no-distinguished-object style (where the self argument is syntactically treated similar to the other arguments), unless you have prefix syntax, mapping a+b to +(a, b) is little more of a syntax transformation than mapping it to a.+(b). But there's a transformation going on in both cases, so I suppose there isn't much difference. And I would still prefer overloading + by definining a function named + rather than __add__ (or another name).

Last Modified: 13 Jun 2006

Safety in Dynamic Languages

2006-01-12T19:34:00.000+05:30

A very interesting post:

James Gosling has recently been putting his foot in his mouth when it comes to dynamic lanaguages.

The arguments are nothing new, and ones that have been proven false time and again . What strikes me as amazing though, is that even at the very top of the ladder, they still think that the compiler is a safety net.
"the truth is actually that safety
is freedom (eg. a good safety harness
and rope give you the freedom to climb
a mountain"
If you aren’t unit testing, then the only thing the rope is going to be good for is hanging yourself. If you really think the compiler is going to be your safety net, then please don’t join me on my next project.

Freedom has nothing to do with the false sense of security that the compiler gives you.

I quoted it verbatim here because the link doesn't seem to be working.

WEBrick as a WebDAV server

2006-01-10T19:35:00.000+05:30

I wanted a WebDAV server and since I'm interested in Ruby, I installed WEBrick. There's a gem for this server that's a WebDAV server, so I installed it. One absolutely beautiful thing about this server is the paradigm of mounting servlets at specific points in the URL namespace. Wow!

When I tried to connect, I got 403 Forbidden errors and after some time realized I needed to enable directory listings. That's counter-intuitive for a WebDAV server. Anyway, I figured out I had to pass a FancyIndexing option to the server, so I did that. So I ended up with a browseable server.

I was pleasantly surprised to learn that this server worked with IE's Web Folders (Tomcat didn't.)

After some time I realized with a shock that my files were world-writable! What an unsafe default! Anyway, I looked for an option to make it read-only and was even more surprised to find that one didn't exist. So I hacked into the source and after spending quite some time understanding it and deciding how to change it, I put raise HTTPStatus::Forbidden statements in the "dangerous" methods.

For a while I was happy, till I found the server very slow to respond at certain times and from certain systems on the LAN. I don't know whether this is a problem with Webrick or not.

And the server gave up on files with certain characters ('&' being one of them) in the filename, spewing exception stack traces on the console. This would cause Windows Explorer (with the first-rate NetDrive tool) to abort the entire copy, and Nautilus to copy whatever files it encountered till that point. Not acceptable.

So I'll have to switch away from Webrick as a WebDAV server, though I'll continue to use it as a HTTP server.

In fact, I'll switch from the WebDAV protocol to FTP; it's extremely inconvenient that there's no way to switch from a HTML UI to a WebDAV tree UI. This is more important to me than whatever features WebDAV has over FTP.

Mounting in NTFS 101

2006-01-10T18:26:00.000+05:30

It seems to be a little known fact that NTFS supports mounting like Unix - a directory can be mounted at another directory within an NTFS volume (called a junction point). But the tools to do this are not available in the base install of Win XP and require an external tool, like Junction Link Magic. Keep in mind that the mount point must be on an NTFS volume; the mounted directory can be on FAT32.

If you want to refer to a file rather than a folder, create a hard link. (If Microsoft had the design sense to follow the Directories Are Also Files principle, we'd be able to create a hard link to a directory and wouldn't need junction points. This was partly pointed out to me by my friend.)

If you want to mount an entire volume rather than a directory, use Computer Management. The mounted volume then doesn't need a drive letter.

In the reverse direction, you can create a drive letter that refers to a folder, using the SUBST command.

Phew! I really wish Windows used the single-filesystem model of Unix!

We need a webdav:// URL scheme!

2006-01-10T17:22:00.000+05:30

When browsing a remote filesystem, it's more convenient to use a filesystem browser UI rather than an HTML directory listing. Unfortunately, if the protocol used is WebDAV, there's no way to effect a switchover from a HTML UI. This is because URLs that point to WebDAV shares use the same http scheme and are therefore indistinguishable from HTTP URLs. Neither can you follow the URL to see what's on the other side (in fact, the method (pun intended) of following the URL is itself different based on whether you want to use the WebDAV protocol; you do a PROPFIND instead of a GET). So if a particular resource has to be opened as a WebDAV resource, the browser must be explicitly told.

To this end, the IETF wants to introduce a new MIME type, application/davmount+xml, that instructs the web browser to open a (specified) resource in a WebDAV filesystem browser. So a webpage that wants to link to a WebDAV resource must link to this mount request document which in turn specifies the location of the resource.

The alternative is to use a webdav:// URL.

Here are the problems I see with the proposed spec:

Webmasters must create these mount request documents, and every point in the WebDAV filesystem hierarchy needs its own mount request files. So the webmasters may have to create a lot of these files used just for redirection. Or dynamically generate them. Neither is appropriate for a task that can be done using something as simple as a URL with a different scheme.
A new scheme would be useful when a user types a URL into a client program. Presently, clients use ad hoc solutions. For instance, Internet Explorer's Open box has an Open as Web Folder option that you must check to use WebDAV. A webdav:// URL would be more straightforward.
The proposed spec requires another round-trip to the server.

You can use a data URI (thanks Julian Reschke for pointing this out) and that will handle problems 1 and 3. But it will still be unwieldy; would you prefer a URL that encodes:

Content-Type: application/davmount+xml

<dm:mount xmlns:dm="http://purl.org/NET/webdav/mount">
<dm:url>http://www.example.com/user42/</dm:url>
<dm:open>inbox/</dm:open>
</dm:mount>

or this:
http://www.example.com/user42/

True, you don't need a new scheme, but that doesn't mean you shouldn't have one, given that the alternative suffers from the above problems. WebDAV is a different protocol from "plain" HTTP (it introduces new HTTP methods), and if we don't use URL schemes to identify protocols, what are the schemes there for? Why needlessly complicate things?

Nautilus did the right thing and went for a dav:// scheme. Konqueror uses webdav://

Last Updated: 12 Feb 2006

Wow!

2006-01-07T10:42:00.000+05:30

I found a couple of articles yesterday that made me all excited. The first is about extracting video from brains! Scientists apparently showed videos to cats and extracted them from their brains. You can see the extracted images below the orginal ones from the video. How much has science progressed...

The second is actually far more interesting - the US govt. is investigating a hyperspace engine! Wow!!! I didn't think this would happen in my lifetime... But even the theory it's based on is controversial, so it's far from certain it will work out. But if it does, it would be truly revolutionary... Welcome to the 24th century

Keyboard Shortcut Hints

2006-01-06T00:30:00.000+05:30

Yesterday my friend was using my system and I noticed him closing tabs in Firefox by middle-clicking. That immediately reminded me of this shortcut, which I was actually using an year ago and somehow forgot. I was clicking on the tab followed by clicking on the close button (no, I don't like Tab X). And then I realized that almost all of us use keyboard shortcuts less often than it benefits us. Why don't the apps give hints when the user frequently performs a gesture, especially a multi-step one? If the user was interacting with an app using the keyboard, then switches to the mouse and back to the keyboard, that can be a good time to give a shortcut hint (a balloon that says, for instance, press Ctrl+R to reply). Of course, the hint should not be given everytime...

Remote Desktop and SSH

2005-12-26T23:28:00.000+05:30

I use Remote Desktop to connect to my new Windows box over the network, and it's a very pleasant experience. For starters, it's very fast - whether the client is on Windows and Linux - to the point where it feels like a local session. X/SSH, on the other hand has an irritating lag for each click (but maybe it's a problem with my X server on Windows). Remote Desktop gives you your start menu & desktop icons, you can optionally export local drives to the remote system so that you can directly open and save files (as opposed to saving them on one system and moving them using sftp/scp - and having to re-authenticate yourself), sound played remotely comes to the local system, and printers can be exported. Remote Desktop preserves your earlier login sesssion rather than creating a new one.

It may be de rigueur (at least in some circles) to diss Microsoft, but there's no denying that they create more usable solutions that the open-source bigots.

Last Updated: 18 Mar 2006

Could the Web Go Paid?

2005-12-26T23:14:00.000+05:30

Quite a bit of content on the web today is available at no charge, but is ad-supported. With many people installing ad-blockers (or their admins doing it centrally), this revenue stream is bound to take a hit. Will that drive a shift to micropayments?

Runtime-checked Exceptions

2005-12-26T19:40:00.000+05:30

Checked exceptions in Java are a big pain in the ass. Partly as a result, no other major language (C#, Ruby) supports checked exceptions the way Java does. But this checking actually has a use - it ensures that the set of exceptions thrown by a method is well-specified and enforced. Otherwise, if a method throws exceptions its callers are not prepared to handle, they'll break.

Is there a way to check exceptions that doesn't suck? Consider a language where by default a method is allowed to throw any exception and checking is done at runtime. This will ensure (respectively) that the checking doesn't become a pain when you don't want to use it, and you won't need try/catches for exceptions you know (or think) won't be thrown. That way the complaints against Java-style checked exceptions are handled. If an exception specification violation does occur at runtime, the only reasonable way to handle it (as far as I can see) would be to throw a specific exception meant for this purpose (something like UnexpectedThrowableException) that wraps the original exception.

So the real question is: is this wrapping useful? I think so - it's important to have an explicit contract (of what exceptions can be thrown) and enforce it. A module breaking its contract seems very different from expected exceptions (file not found, etc).

The only major language that implements something like this is, surprisingly, C++ (except that an unexpected throw causes program termination by default).

More surprisingly, this has a close parallel with type checking - Java's compile-time exception checking is like static typing (all potential violations caught at compile-time, but at a huge cost), having no checking is like weak typing (violations go undetected), and C++'s runtime exception checking corresponds to dynamic typing (violations are detected at runtime and cause an exception). To the extent this comparison holds, there should be exception checking, assuming there should be type checking. Static exception checking, like static typing, seems to be more trouble that it's worth. So should we go for dynamic exception checking?

Is this useful enough in practice to warrant language support?

Java Web Start - the forgotten option?

2005-12-25T13:23:00.000+05:30

All the buzz nowadays is about web applications. Accompanied by criticism of the browser as a lame UI. Projects are underway to remedy this - Mozilla's XUL (but it doesn't use the OS's native widgets), Microsoft's XAML, etc.

But there is another option available today - Java Web Start, which allows applications to be launched from the browser. Yes, it's different - the apps run on the client. But they have the same advantage as a web app - installation isn't needed - and several more:

Apps run outside the browser window, which may sometimes be better (from a UI design standpoint).
Apps can be configured (by the developer) to launch from a local cache while doing a background check for an updated version (which runs the next time onwards).
They can run in an offline mode.
They can have access to the local filesystem (if they're signed and the user trusts the signer).
They can optionally be launched from a desktop shortcut.
You can code in Python (Jython), Groovy, Nice, Java, or any of the other languages that run on the JVM. Whether this is an advantage depends on the people and the task at hand.
The Java libraries are far more extensive than those of Javascript.
The load on the server could be reduced, and some of the client's resources can be used (which would otherwise probably go unused).

Did you notice that this pretty much describes a traditional desktop application?! But with the advantage of a web-based one! Web Start blurs the distinction between a local app and a remote one. It would be very interesting to see (Java) apps being distributed this way.

Web Start is certainly not a replacement for AJAX, XUL, XAML, etc, but it seems to be a valuable tool to have in your toolbox.

With Javascript supporting canvases, you can probably have a rich UI within a web page, by drawing custom controls. That's an interesting idea; I wonder if it's workable and worthwile... but the other advantages of Web Start remain.

Blame the W3C, not GWA

2005-12-15T22:10:00.000+05:30

So Google Web Accelerator drew flak again. Some people say that what matters is not the HTTP spec but what people are actually doing. In that case, what are the specs there for? I'm reminded of the Windows 95 introduction, when they found that Sim City had a bug - it used memory right after freeing it - but still happened to work under DOS but crashed under Windows. "They reported this to the Windows developers, who disassembled SimCity, stepped through it in a debugger, found the bug, and added special code that checked if SimCity was running, and if it did, ran the memory allocator in a special mode in which you could still use memory after freeing it." Is this where we want to go? Not me, atleast.

Then there's more flak for dropping X-Moz: prefetch. But once again, X-Moz: prefetch is not part of the spec and Google may have had a good reason for dropping the header, so I wouldn't blame them. After all, who says you have to use what Mozilla does? Aren't standards there for precisely this reason?

Granted, GWA breaks (part of) the web we have. But that doesn't mean you can blame Google for it. Agreed, there are reasons why you might want to perform destructive ("unsafe") operations through GETs - lack of POSTs in links, lack of nested forms, lack of a way to mark a URL as being "unsafe", lack of a standard prefetch header... All these are gaps in the HTTP/HTML standards. The W3C may have been sitting on its ass for years without handling these issues. So blame the W3C. Not Google.

Interestingly, the HTTP 1.1 RFC (2616) says that "the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval". Convention? Why on earth is this RFC documenting a convention? Does the C++ language standard suggest that variable names be in lowercase? What is this - a convention or a requirement? Everyone seems to base their arguments on the view that the RFC forbids unsafe GETs, but if it's only a convention... Boy, we are on thin ice.

In any case, I wouldn't blame Google for this mess.

Code as Configuration

2005-12-14T18:24:00.000+05:30

I used CherryPy sometime ago. I found that to configure the server, I had to edit the source code. I initially repelled at this idea, but then I found that the (Python) code was as transparent as a config file. Why have a config file if the source code is as easy to work with? And far more powerful, of course. For instance, I think you can change the server process priority in the "config file" (by calling Win32). This is yet another benefit you get from using a more powerful language.

Microsoft's HTML Marvel

2005-12-14T17:58:00.000+05:30

I use HTML for my documents (when plain text won't do) and so I needed a good HTML editor. I used Mozilla Composer for a while but it sucked big time. There doesn't seem to be an easy way to move rows within a table; drag and drop creates a nested table. (How stupid!) And what is extremely irritating is that you can't right-click a file and open with Composer. Moreover, the look-and-feel made me slightly uncomfortable. So I tried Frontpage 2003. I was wary because previous versions of Microsoft apps generated horrid HTML. But I found to my surprise that Frontpage generated clean, simple HTML. (Surprisingly, Frontpage by default cleans by Word's bloated HTML.) And the user experience was a million times better.

All this reinforces the view that open-source software, by and large, has terrible usability. Also, Microsoft's apps are better than they get credit for - sometimes far better.

Static Typing

2005-12-06T16:30:00.000+05:30

I now realize that it's possible to have dynamic typing together with the early checking associated with static typing. So I no longer agree with this post.

Static typing has gotten a bad rap, and many languages don't support it. While requiring every variable to have a type declaration is certainly harmful IMO, optional type constraints can sometimes be useful. When I write Python code, I sometimes write explicit type checks (generally for debugging, but I leave them in after debugging, for the same reason I leave assertions in). I wonder if such checks are common enough that they warrant a more succinct syntax...

Last Modified: 2 Mar 2006

Birds of a Feather

2005-12-06T15:29:00.000+05:30

I noticed that people who use the most powerful languages - Lisp, Ruby, Python - tend to prefer the best OS (more than other people) and their writings are more insightful. Is it just a coincidence?

Drowning in Abstractions

2005-12-04T23:06:00.000+05:30

I wanted to use Zope as a WebDAV server. I spent a couple of hours wading through the shitload of abstractions that Zope is, figuring out how WebDAV serving works. No success. I'm not surprised that all the attention nowadays is with Rails, CherryPy, Django, etc.

And then there's Twisted - which has powerful and complex abstractions, too, but not so complex as does Zope. It tries to do only one thing - be a framework for servers.

CherryPy is even simpler - it's a framework for HTTP servers, and nothing else. Its source code is simplicitly itself - it's easier to understand than Tomcat's documentation.

See the pattern?

I don't know if Zope goes overboard on abstractions. But there's another, more important issue here: a HTTP server (like CherryPy) will probably be simpler than something that's a HTTP/FTP server-cum-object-database-cum-templating-system-cum-what-have-you (like Zope). Good modular design will probably result in CherryPy + Cheetah/Kid + SQLObject rather than Zope. Not only does the latter approach increase what you have to learn before you can do something simple but you may not need the additional functionality. You can end up unravelling the mess and get little in return.

There's another advantage here. A lean and mean component has a higher chance of getting used in more higher level frameworks and to that extent becoming a standard for the small part does it does but does well. CherryPy, for instance, is used as the HTTP server in both Subway and TurboGears (with the other components of these frameworks coming from elesewhere.) This benefits everybody.

Insist on small, powerful and orthogonal tools. Not Zope but Webrick or CherryPy.

Inefficient & Impractical

2005-11-23T21:30:00.000+05:30

I had to photocopy some papers for an exam and I found that out of a stack of papers I needed everything except ones titled Efficient Blah Blah and Practical Yadda Yadda. Hmm... everything except the efficient and practical stuff... Does that tell you something about academia?

A Formula to Create the Mona Lisa

2005-11-23T21:13:00.000+05:30

Yesterday I was reading something on "Software Engineering" that talked about improving productivity and it struck me that a lot of academics miss one critical point about building better software: use powerful languages - Ruby, Boo, Python, Lisp, etc. Most academic writing seems to be colored by the assumption that languages are largely interchangeable... But then papers don't seem to be judged much by how useful they are.

Some people hold formal methods as a potential source for improvements in productivity. But I'm skeptical. If you could describe a piece of software completely enough for the formal methods to work, it seems to me you could make it bug-free in the first place. Software is the most sophisticated creation of our civlization. And formal brings to mind rules and procedures and protocols. That doesn't seem to go down well with creating sophisticated systems. Maybe I'm ignorant here and there's some breakthrough just around the corner. Possible, but I'm not holding my breath.

I think that the greatest source of increase in productivitiy in the near future will be better languages. This, of course, is already happening, with the shift from C++ to Java. The most respected hackers - the most productive people - seem to be using the most powerful languages. Do they use formal methods? Doesn't seem that way to me. A better answer would be Lisp or Ruby.

A lot of the material on Software Engineering makes me feel like throwing up. They talk about methodologies and processes and what have you, but do they even mention conceptual integrity? Taste? You'll probably learn more about building software by reading Paul Graham's essays than from the tomes on "Software Engineering". (Is it just a coincidence that the former is orders of magnitude more interesting than the latter?) A lot of "software engineering" seems to miss the point that building software is an art. True, it's engineering, and it's science, but it's also an art. There is certainly a place for methodologies and processes, but it's also crucial to have a masterful designer with a keen sense of taste. To have people who care for the software they're building. All the comparisons of building software to erecting buildings, and the conclusion of that line of thought, I think, paint only a partial picture. Try comparing building software to painting the ceiling of the Sistine Chapel as well, and then you get a complete picture. Today's software engineering sounds like giving a formula to create the Mona Lisa.

Firewalled

2005-10-29T19:47:00.000+05:30

After using my computer all day, this evening I was fed up and went for a walk. On the way, I happened to think of the end-to-end refresh problem with transparent HTTP proxies and of Children of a Lesser Python. And then I suddenly noticed the beautiful trees lining the road, the setting sun, the subtle yet vibrant orange sky and the cool breeze. That reminded of the extremely tender love story I'd watched a few days ago. I thought, wouldn't it totally change the quality of my life if I had a lover? There's so much more to life than virtual machines and HTTP GET requests - relationships, love, travel, nature, friendship... How many sunsets had I missed doing programming?

True, if you don't have an interest that sometimes occupies you completely, your life is not worth living. But if all you have are such interests, your life isn't worth it, either.

I realized that Python VMs could be a little slower or faster and guess what? The world will pretty much be the same.

Unfortunately, I have a couple of projects due in a month, so I'll have to return to the same old word of bits and bytes. Atleast for now. Sigh.

(Institutions like IIT may be highly regarded for providing first-rate education. But they go too far, making academics the only thing in your life.)

First Love

2005-10-24T11:44:00.000+05:30

I fell in love yesterday. Went to the city (Mumbai) and found a beauty there. Hailed a taxi and got her to my room comfortably. She's great - Athlon 64, 1 Gb memory, hard disc with NCQ, DVD-writer (dual-layer), 17-inch LCD, 4.1 speaker system... I run Win XP 64-bit edition.

Glad to be rid of Linux after three months of hell. Windows certainly does have its problems, but it's usable...

After so many years, I have a system to call my own. I don't have to share it with anybody and I decide what OSs and apps to run. Yesterday was one of the highlights of my life so far...

I only hope my next lover is human ;-)

Modules and Singletons

2005-10-16T01:09:00.000+05:30

I was in a design patterns class the other day, and singletons were being discussed. The instructor said that the classic example of a singleton is a window manager. That set me thinking - if you aren't going to have multiple instances of it, why should it be a class? Couldn't it be a module? Probably the answer is that you do want multiple implementations of a window manager; you just don't want them instantiated at once. I can imagine a system where you instantiate one implementation (subclass) of WindowManager at startup and use that till shutdown without being able to instantiate another. If you're using a crippled language like Java, you can't think beyond this.

But if you're using Python, new avenues open up. You can represent each window manager by a module and dynamically decide which one to import. As long as the modules are interface-compatible (in the sense of the contract, not the narrow syntactic sense of the same list of methods [perhaps this is part of the reason why python does not have an explicit notion of interfaces, because what can be checked is a small part of what must hold]), everything works. You could get a module object and access members of the module using the usual dot operator. Interestingly, what makes this work is that modules are objects (in the sense of having attributes that can be callable); they just happen to be managed automatically by the language rather than needing to be taken care of by the programmer. So the question is not exactly do we use objects, but: do we want to take care of these objects explicitly or leave it to the language? Obviously, leave it to the language when possible. One more case of an abstraction allowing us to forget some details and so save work.

You could also do this using import as. (Till now I didn't understand why anybody would want to import a module using a different name.)

Python seems to have very powerful abstractions and a lot of hooks where you can change things.

OS-wide Context-sensitive Autocomplete

2005-10-03T01:00:00.000+05:30

If the GUI toolkit keeps track of which strings were recently seen and autocompletes across apps, a lot of copying and pasting would be eliminated. This would only require change in the text box widgets' implementation and not in any apps. Apps could choose to listen for autocomplete events from the GUI toolkit, but they can remain blissfully ignorant. There should be a security restriction that ensures apps don't see all autocomplete choices, but only the selected one (once a selection is made).

The Trouble with Latex

2005-09-29T18:59:00.000+05:30

I had to write Latex for a class assignment, and I hated every second of it.

You have to write complicated markup, and making a mistake yields unhelpful error messages. Latex seems bad at recovering from errors to process the rest of the document. Atleast worse than HTML browsers. Latex makes document preparation seem like compiling a program - and that's a lot of effort. No wonder Latex is not so popular as a general-purpose document preparation system.

The problem is actually not that the markup is complicated but that the tool lacks a WYSIWYG interface. Let's approach this situation from the other direction - what if a powerful format used by a WYSIWYG word processor (think Word) were text rather than binary? Then we'd have the best of both worlds - the ease of use of a WYSIWYG editor with the power of editing the file directly when needed. Ease of use and power need not be mutually exclusive. This is similar to the config file mess with Linux - the problem is not the file format but the lack of a GUI.

And Latex is print-oriented as opposed to say, HTML. To what extent does these for-print aspects make it worse for screen-oriented (or web-oriented, if you will) use? I don't know.

Whether or not such an interface could be developed to expose the full power of the underlying language, it can atleast support the commonly used parts, avoiding the need to code unless you have advanced needs. Nobody wants to hand-write markup when it's avoidable.

But how effectively can a WYSIWYG interface be developed to an existing file format instead of the other way round? (See Ronco Spray-On Usability) Given that most uses of the file format (if it becomes successful) will be through the GUI interface, we should optimize for the common case and design the file format based on the GUI rather than the other way around. Perhaps OpenDocument is the conclusion of this line of thought.

Are there any WYSIWYG interfaces to Latex? Lyx seems to be one. (I haven't tried it yet.) I haven't found any other. (Abiword can save as tex but can't open the saved files. (And it embeds a redundant XML copy within the tex file.) KWord gives an ominous "some formatting will be lost" message on save and fails to open the saved files, too.)

So what do we use for normal document preparation? I would not use Latex since it seems to have only one WYSIWYG editor. When HTML doesn't suffice, perhaps OpenDocument is the best option - it's designed for a GUI rather than the other way around, and it's manually editable (XML) (though the XML could have been clearer.) That seems to be best choice we have.

Analog Fortress

2005-09-18T19:47:00.000+05:30

I read Digital Fortress the other day. The story is gripping and even touching, but Dan doesn't know a thing about cryptography, and little about computers. Here are some corrections:

1) Time is proportional to key length ^ 2:
The book talks of keys 10k bits long, a million, and a billion. That's a joke. Nobody uses keys that long. At the claimed brute-forcing speed of 100 billion keys per hour, to try about all 2^10K values of a 10K bit key, it takes 2.27e+2992 millenia! By then the sun would have burnt out.

2) So Brute force doesn't work. NSA-proof encryption programs are a dime a dozen.

3) ZIP, AFAIK, is a compression/archiving format, not an encryption format.

4)You can't beat remailers the way the novel describes. Sure you can mail the mystery recipient a program, but he wouldn't be dumb enough to run it for you.

5)NSA uses Pascal? Ho ho ho! (Nobody uses it anymore, not even universities.)

6)You don't "upload" firewalls. Uploading means saving a file to a server (generally a web or FTP server). You run a firewall, or launch it, or execute it, or deploy it; not upload it.

7)Virus infection doesn't happen when you try to crack an encrypted file by brute force; it happens only when you run an unknown program.

8)If the machine was a quantum computer, it could try all keys simultaneously, so why does it take so long?

9)The trick of encrypting Digital Fortress with itself doesn't work. Sure you could do it, but nobody will be able to decrypt it even he had the key, because there's no decrypting program available. The analogy with the safe is flawed - a safe needs only a key combination to open, whereas decryption requires not only a key but also a decrypting program.

If there was a decrypting program available in unencrypted form, it could be reverse-engineered and the secret algorithm would probably be revealed.

Dan needs to take a CS101 course before he writes any more computing-related novels.