Shebanator

Elephant Still In The Room

•02Apr07 • Comments Off

A couple of months ago, Steve Jobs posted his open letter on DRM to the web and I posted Jobs on DRM: The Elephant in the Room in response. It got me my very first set of Apple fanboy comments, which was exciting. Today, of course, Apple and EMI announced that they would start selling DRM-free tracks at a 30% markup. I want to congratulate Apple and EMI for taking this step. As someone who has purchased a fair amount of music through the iTunes Store, I’m happy to get the DRM-free tracks and the higher resolution, and I will undoubtedly be upgrading my existing purchases to the new format.

Going back and rereading my post, I’m really glad I focused on the video issue. Otherwise I too might have gotten hit with the dreaded John Gruber “Jackass of the Week” title. I thought it worth noting that Jobs did in fact address the video DRM issue at the announcement, and his point of view won’t please the anti-DRM forces in the world. Here’s one choice quote from Jobs:

Video is pretty different from music right now because the video industry does not distribute 90 percent of their content DRM free. Never has. So I think they are in a pretty different situation, and I wouldn’t hold it to a parallel at all.

He is basically saying that video DRM is OK because people are used to from DVDs. Not a very compelling argument, as it completely ignores all the questions about fair use.

Finally for the conspiracy theorists out there, could the timing of the Apple/EMI announcement be related to this news that came out the same day and got buried? (Tip of the hat to Paul for sending me the link…)

Posted in Dynamic Media
Tags: Apple

Planes, Trains, and Automobiles

•02Apr07 • 1 Comment

DHH of Rails fame recently posted to the 37signals blog about not getting the need for “offline web applications”. Although he didn’t mention any one such framework specifically, it seems likely he was talking about Apollo, Slingshot, Firefox 3.0’s offline capabilities, and so forth. The gist of his argument is laid out in his first paragraph:

The idea of offline web applications is getting an undue amount of attention. Which is bizarre when you look at how availability of connectivity is ever increasing. EVDO cards, city-wide wifis, iPhones, Blackberry’s. There are so many ways to get online these days that the excitement for offline is truly puzzling. Until you consider the one place that is still largely an island of missing connectivity: The plane!

Now I have a lot of respect for David and for the products that 37signals has created, but it seems to me like he has made a couple of glaring errors in his analysis.

The first error is his supposition that the plane is the only place where people aren’t connected these days. I can understand how someone who lives and travels in high tech urban areas could make that mistake, but as many commenters on his blog have pointed out, we are far from universal connectivity in the industrialized world, and much of the world is even farther behind. And even where there is connectivity, hills, tunnels, concrete walls, and interference can wreak havoc on reliability and performance. I have no doubt that the trend worldwide is to more and more wireless access, and someday we may get to the point that David thinks is already here. But I don’t believe that we’ll be at the point where we have ubiquitous, reliable access for a long, long time.

The second is the supposition that Apollo, Slingshot, and so forth are all about offline web applications. I don’t think supporting purely offline applications is something most people are all that interested in. The benefits of the offline support are really about making applications that work in occasionally disconnected mode. The disconnect could be because you are on a plane, but it is more likely because your wireless disconnected for a while do to some sort of reliability glitch.

Furthermore, as David Young of Joyent points out, the benefits of RIA frameworks like Apollo and Slingshot aren’t just about being “offline”. They are really about bringing the benefits of web application programming to the desktop. David captures those benefits quite well, though of course his post is very Slingshot-centric. Although there are some huge differences between SlingShot and Apollo, most of what David writes applies equally well to Apollo. (See how I’m FUDing you again, David?)

Posted in Rich Internet Applications

Why Apollo?

•29Mar07 • 4 Comments

I normally don’t like to do those "me too" sorts of posts Microsoft folks seem to specialize in, where you just say "look at this great article my coworker wrote". To me, its always seemed like a rather distasteful way to do PageRank/TechMeme manipulation. But Mike Chambers has written a really good article on the rationale behind Apollo, so here I go emulating bad behavior…

While I’m passing on Apollo links, here are a couple of shorter articles I also liked:

Richard McManus and John Milan argue about online desktop apps vs. offline web apps. I don’t really agree with either side, but its a good read.
Pasz.com has an article on things to like about Apollo from a day-to-day development point of view.

Posted in Rich Internet Applications

Invasion of the dynamic language weenies?

•26Mar07 • 7 Comments

Hacknot has published a contrarian paper on Python, Ruby, and other dynamic languages called “Invasion Of The Dynamic Language Weenies”. Its an interesting read, with the central premise being that dynamic language partisans (like me) haven’t empirically proven any of the benefits they tout. I think this is a fair criticism, albeit one taken to a ridiculous extreme in this article. I do find it odd that he spends so much time pointing out the lack of empirical evidence and the use of biased and/or anecdotal evidence on the pro-dynamic language side of the debate, but then turns around and makes exactly the same mistakes on the con side of the argument:

Actually, I had trouble imagining how it might be true even within limited domains. Though I’ve principally used Java for the last 10 years or so, and C/C++ for five years preceding that, I have a basic familiarity with Python, having written a few utilities here and there with it. Reflecting on those experiences I could see no basis for such a startling claim to code brevity.

In other words, “I can’t imagine it and haven’t experienced it, therefore it must be false…”

Can dynamic typing result in a reduction in code volume of 80 to 90 percent? It seems highly improbable to me. Suppose I had a piece of Java code and went through it removing all the type qualifications. Would that reduce the code volume by 80 to 90 percent? No, I don’t think so. Maybe there are other omissions that dynamic typing would make possible, such as obviating adapter-style classes and some interfaces. But even including such omissions, claiming an 80 to 90 percent code saving seems a bit rich.

He dismisses actual studies where people have compared static and dynamic languages as being overly biased, then does a “mental exercise” to prove his own side of the argument.

On the whole, no matter how hard I tried, I simply could not convince myself that dynamic typing and runtime code modification, either individually or in concert, could produce a code base that was “10 to 20 percent” the size of its static equivalent. Either the quote was inaccurate, had been taken out of context, or Deibel was engaging in some fairly outrageous marketing hyperbolae.

Again, “I can’t imagine it and haven’t experienced it, therefore it must be false…”

I recall doing maintenance and extension work on a system written in C containing approximately one million lines of code. To build that entire system from scratch took several hours. But that didn’t mean that every test/debug cycle we performed was punctuated by that same delay. There were large parts of the code base that we were not involved in changing, and they were built into libraries once at the beginning of the project, and thereafter we just linked against them. The net result was that in each test/debug cycle we were compiling only a small fraction of the code base, then linking against the pre-built libraries. This took seconds, not hours. It’s part of basic build management when working with a static language that you only recompile what you have to. The DL weenies would like you to believe that a burdensome compile/link time is an unavoidable downside of using static languages when in fact, it is not.

“This wasn’t true on one system I worked on, therefore it is universally untrue”

I could go on, but you get the idea. So here’s my challenge to hacknot: you seem awfully certain about things. Why don’t you back up your side of the argument with some hard and fast empirical data of your own?

Posted in Dynamic Languages