Shebanation

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 by Andrew Shebanow at 12:56 PM | Permalink | Comments (4)

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 by Andrew Shebanow at 11:50 AM | Permalink | Comments (7)

Ryan Gregg has done a nice little hack (and I mean hack as a compliment: the program was small, easy to create, and darn useful) to embed Adobe Reader’s ActiveX control within a Vista/Outlook 2007 Preview Handler. So now you can see what those PDF attachments in Outlook 2007 look like without all that double-clicking. The nice thing about his handler is that it works with Outlook 2007 on XP unlike the FoxIt Preview Handler from Tim Heuer - very handy for me as I prefer to run XP in Parallels. Plus you don’t have to deal with all that FoxIt stuff :-)

I should warn people that the ActiveX control’s UI wasn’t designed to work with small amounts of screen real estate, so those with smallish laptops might want to wait for a better solution to come along…

Posted by Andrew Shebanow at 09:49 AM | Permalink | Comments (2)

As pretty much everyone who reads this blog knows by now, Adobe recently announced Apollo, our runtime that brings web applications to the desktop. I’ve been reading a lot of what has been written and I’m generally happy with the things people have been saying - most people seem to “get” the value of Apollo and are at least intrigued by the prospects it opens up.

The people who write less enthusiastically about Apollo generally bring up a few things I want to talk about:

1. Apollo competes with WPF - this meme is attractive to journalists because its easy to write a sexy story about a war between two large companies. The reality is less confrontational: Apollo is designed to bring web applications to the desktop, and WPF is designed to bring Web-style richness to the Windows programming model. Both approaches have advantages and disadvantages, but they don’t really compete with each other: you probably aren’t going to see a lot of HTML/Flash developers adopting WPF, and you probably aren’t going to see a lot of .NET/Win32 programmers adopting Apollo. Different design centers, different audiences. The only way the “battle” metaphor would make sense is if all programmers and all applications had exactly the same set of platform needs. Apollo’s can succeed even if WPF proves to be extremely popular, and vice versa.
2. Apollo is no big deal because its “just a mashup” of existing technologies. Its true that Apollo does leverage and depend heavily on existing Web technologies: Flash/Flex, HTML/JavaScript/Ajax, and PDF. That is actually Apollo’s greatest strength: it provides a way to integrate all those technologies into a common programmng model that also leverages the host platform. No one has ever built anything that brings together web technologies in this way, and its a lot harder to do than calling it “just a mashup” makes it sound.
3. Apollo is closed source and proprietary. Its true that a number of the pieces that make up Apollo are closed source, but how important this is will vary from developer to developer, and the story around Apollo alternatives is generally even worse.

Lets go into that last bit a little deeper. In the last few weeks, a number of other companies have been announcing frameworks, runtimes, and/or other products that are also trying to bring the web to the desktop, leveraging the Apollo publicity to their own advantage (more power to them - just good marketing as far as I’m concerned). I’ve also been reading the coverage of these tools and find it interesting to compare and contrast the features and openess of these platforms:

• First up is Dekoh, a product that is trying to build a desktop application engine on top of a Java server. Its an ambitious project, and one that is putting a lot of weight on the fact that it is the open source alternative. I think its great that the source for their runtime is freely available, but how does the company that makes it make money? That isn’t at all clear right now. But one thing that they have revealed is that the product relies on a centralized “Dekoh Network Service” for identity, sharing, and so on. The bottom line is that with Dekoh, you are making your application dependent on a closed source, propietary Dekoh service that will own and leverage information about your users and their data. To me, that doesn’t really seem ‘more open’ than Apollo, where the runtime is free and there are no required dependencies on any web services.
• Next is SlingShot from Joyent and Magnetk. I love Ruby on Rails, so this product is very interesting to me. They basically have taken the all-in-one desktop server approach of Locomotive and turned it into an application runtime. Its a great idea, and one that opens up a lot more power to the local application than Apollo. Downsides are a lot of potential security issues (no sandbox?), the fact that the entire source of your application is distributed to the world whether you like it or not, and the fact that it is limited to Ruby on Rails applications. More disturbing, though, is that it sounds like Joyent will be charging a royalty for distributing applications based on their runtime unless you are a customer for their hosting service. Maybe they just plan on charging a flat fee for the SDK. Either way, this is much less open than the Apollo model where the SDK and runtime are both free of charge.
• Some have argued that Yahoo! Widgets is also an Apollo competitor. I don’t really get the comparison, but even if you do think they serve similar needs, the fact is that Yahoo! Widgets is just as closed source and proprietary as Apollo, if not moreso (since Apollo has open source components like WebKit and Tamarin).
• Finally we have FireFox 3. Not really in the same category as the others, since its still fundamentally a web browser and it is nothing but vaporware at the moment. The offline mode and local data store features sound nice, and the open source credentials for Firefox are unimpeachable. But at the end of the day the integration with the host platform is going to be very limited compared to the other things being discussed in this context.

So there you have it: four Apollo competitors. One truly open but serving a different set of needs, the others with significant openness concerns. In this company, I think Apollo’s model is pretty darn attractive, but your mileage may vary.

Posted by Andrew Shebanow at 10:55 AM | Permalink | Comments (10)

So I’m reading Laughing Squid (which I love) and I see an article about the Microsoft Research TechFest that just happened. I’m scrolling through all the pictures and what do I see:

OMG, Microsoft is keeping cats in cages and doing experiments on them! I always knew they were evil but this is beyond the pale!

Turns out this is really something much more innocuous and rather cool: the Assira CAPTCHA solution.

Not only is it a clever idea, but it actually helps find homes for pets via a partnership with petfinder.com. Nicely done!

Posted by Andrew Shebanow at 09:44 AM | Permalink | Comments (1)

Interesting post from Charles Petzold about why he structured his book Applications = Code + Markup they way he did: with code-based examples first and then XAML-based examples towards the end.

When I read the book, I immediately remarked on the structure and wondered several times while reading it whether or not it made sense the way he did it. I found his article very helpful in explaining why:

The more I explored XAML on my own, the less I seemed to know. How do panels work? Why were some properties bindable but others were not? Why were some properties animatable but others were not? Why do those properties called “attached properties” seem to be in the wrong place? Why can you specify an event handler for children in a parent’s tag? What happens when modifying an existing control with a template isn’t enough and you need to write a custom control with keyboard and mouse handling and drawing?

Of course, answering these questions for myself required a lot of exploration. XAML is not as simple as it first seems. XAML required a whole intrastructure in WPF that involves layout mechanisms, dependency properties, routed events, and other features. It became quite obvious that most WPF programmers would want a familiarity with this infrastructure. Most WPF programmers would also want to gain a facility for working with this infrastructure. This can only be achieved in code.

Just one example: If you see an attached property in XAML — such as Grid.Row=”2” — it really doesn’t make a lot of sense. You’re specifying a property of the Grid panel within a child element of the Grid. If you look at the syntax in code, however, and you’re given an explanation of what’s going on behind the scenes in the context of alternative syntax, then attached properties make perfect sense.

I made a decision to tackle a lot of the WPF infrastructure very early in the book. I have an early chapter on dependency properties and a chapter on routed input events. I show how to write custom elements and custom panels comparatively early in the book. Many of my sample programs contain Window constructors that create and intialize elements and controls, which is a job that is eventually taken over by XAML, but doing it in code is something that every WPF programmer should know. Some stuff — such as defining a template — is incredibly painful in C#, but my book shows examples of that as well, and I hope the reader later comes to appreciate the relative simplicity of doing it in XAML.

He also gives a hint at a WPF feature that never saw the light of day:

I kept a close eye on one very special feature: the ability to embed C# code in a stand-alone XAML file and have it run in the browser. Although this feature was hinted at a bit, it never became real. If it had become real, I might have gone this route — or at least seriously considered it.

Is this where the WPF/E mini-CLR comes in?

Posted by Andrew Shebanow at 03:06 PM | Permalink

Om Malik and others have reported on Jive CEO David Hersh’s speech at Etel, where he claimed that IM applications will never migrate off the desktop.

I’m a little mystified by the argument, at least as presented by Om (I haven’t seen an actual transcript or slides for the actual talk):

1. Real Time with IM:
   Real time communication and collaboration are great, no doubt about it. But who says you need to be in a desktop application to achieve those things? Is there some special magic in XMPP, SIP, and Jabber protocols that makes them unimplementable in a VM environment? Of course not, and here is the proof: Adobe Acrobat Connect lets you chat, do VOIP, and more all within a web browser, using Flash. Jive’s own products implement these protocols in Java, which was also a VM environment last time I checked.
2. And then there is the familiar user interface!:
   Again, Flash-based user interfaces are incredibly rich. AJAX-based experiences have come a long way as well. What exactly is the special sauce in desktop IM programs that makes their UI unamenable to the RIA experience? As Om himself points out earlier in his article, if you can do Buzzword or Adobe Remix that way, surely the IM experience can be handled in the same manner…
3. Future full of features:
   Again, what is it about IM as a desktop application that makes it more amenable to new features than an RIA implementation or an AJAX one? Many people think that RIA environments are more productive places to program than the old Win32/Apple worlds. They certainly aren’t less productive.
4. Mobile goes the IM:
   This is a non-sequitir. How mobile IM clients are written will have little or no effect on whether desktop IM applications survive. Besides, mobile platforms could offer IM services based on Flash Lite or J2ME.

I suspect that David Hersh’s argument may actually be a lot simpler than presented by Om. He may just be saying that IM applications won’t ever be predominantly browser-based. But if that is what he’s saying, then my answer is: so what? If the future of IM is as an Apollo app, a Widget/Gadget, or some other such technology, why does it matter how those applications get onto the desktop? They are still going to be built on Web technologies, not on traditional “desktop” APIs.

Posted by Andrew Shebanow at 11:42 AM | Permalink | Comments (2)

Apple’s own Jens Alfke has written a great piece on patent law as compared to copyright law. As a bonus, it also makes fun of Mary Bono. Highly recommended.

[Update 03-02-2007] I had to fix the URL in the post. Somehow Textile preview in TextMate did the right thing with the curly quotes, but the Textile engine used by our version of MovableType did not. Jens - curly quotes in URLs - seriously? Plus, I misspelled Mary Bono's name.

Posted by Andrew Shebanow at 11:00 AM | Permalink

Ted Leung has posted blog entry provocatively titled : Adobe wants to be the Microsoft of the Web and Scoble has picked up on it.

In Ted’s post, he worries about the issues around Flash being sourced from a single vendor:

What is not appealing is going back to a technology which is single sourced and controlled by a single vendor. If web applications liberated us from the domination of a single company on the desktop, why would we be eager to be dominated by a different company on the web? Yet, this is what Adobe would have us do, as would the many who are (understandably, along some dimensions, anyway) excited about Flex? Read Anne Zelenka’s post on Open Flash if you don’t think that Flash has an openness problem. I’m not eager to go from being beholden to Microsoft to being beholden to Adobe.

Despite the title of his post, this isn’t an unreasonable worry. Its unfortunate the title is so sensationalistic¹, though, because Adobe will never be the next Microsoft, and furthermore, we don’t want to be. There is a huge difference between Microsoft’s business model, which is about using the web to drive sales of their underlying monopoly products, and Adobe’s strategy, which is to give away technology that expands the web and sell tools around that technology. If you don’t believe me when I tell you this is a huge difference, I suggest you take look at the revenue numbers for both companies yourself.

I think a big part of the fear of Adobe being a single source vendor comes from thinking about Flash Player the way people think about Windows: if Flash Player becomes the dominant runtime for RIAs, could Adobe hold everyone hostage by charging money for the Flash Player or doing something else equally obnoxious? The answer is, quite simply, no. Flash is an important format for the Web today, but a big part of the reason why its successful is because the Player is free (as in beer), it is installed on the vast majority of desktop computers, and it just works wherever it is installed. If Adobe held Flash Player hostage, the Web would just route around the damage by picking some other format that didn’t have the same restrictions.

Same thing goes for Apollo, only more so. Apollo isn’t just about Flash, it is also about Ajax. If Adobe tried to hold Apollo hostage in some way, developers would just move their Apollo apps back into the web browser.

So that is my logical answer to the question, now let me give you a more emotional argument: Adobe would never try to abuse the dominance of Flash Player because it simply isn’t that kind of company. I’m not saying Adobe has never made mistakes (e.g. Sklyarov), and Adobe certainly has no aversion to making money, but at its core Adobe is the most ethical company I’ve ever worked for, of any size. (Yes, I worked for both Apple and Microsoft previously - there is no comparison.) Holding the Web hostage is something that I believe is completely against Adobe’s values. I realize this leaves me open to charges of naivety, but so be it.

Update 3-03-2007: On being closed source

Michael Coté linked to this post with the comment that it was a “Reply to Ted’s post on Adobe and being a closed source vendor.” While I certainly can’t argue with that characterization, it does make we want to clarify something: when I discuss Adobe’s likely actions, I’m doing it under the assumption the status quo will stay just that: the Flash Player will remain a closed source product, and that the SWF format will continue with its existing license. But that doesn’t mean that I’m arguing for the status quo, or that the status quo can’t and won’t be changed. I know that people like John Dowdell (who are much more involved in Flash Player efforts than I am) have been thinking long and hard about the way forward for Flash Player and Apollo, and have asked many questions publicly about the benefits and costs of opening things up more. Thus I think its fair to say that change is quite possible. I personally would welcome steps in this direction but don’t really have much involvement with that part of Adobe.

¹ Then again, who am I to criticize other people’s sensationalistic titles?

Posted by Andrew Shebanow at 10:43 AM | Permalink | Comments (9)