Mike's Classic Cartoon Themes and Images has downloadable music from cartoons old and new Link via [Boing Boing]

The unbelievable thing is that I remember, like, all of the cartoons that debuted from 5 years before my birth to those that debuted when I was in Junior High. All of them. Wait... “unbelievable” isn't the word...“pathetic.” Yeah, that’s the word.)

Jon Udell's walking tour / GPS / Google maps screencast is absolutely stunning. I have GPS / photo montages locked up in proprietary software (DeLorme mapping software), but this is incredibly inspiring.  I haven't read his links on how he actually built it -- I can't wait to start doing something similar for the Big Island of Hawaii.

 This link does a good job of detailing the steps necessary to sell on Amazon, which basically boils down to “get a UPC and a barcode: [Cool Tools]

 [T]he PyCon 2005 keynote session Python on the .NET Platform on Wednesday March 23rd will hopefully coincide with the release a much more complete implementation.  Via [Cook Computing]

Jim Hugunin has been MIA for months. I talked to John Montgomery a few weeks back, who swore that Hugunin was still alive and active. (I got so worked up in the discussion with Montgomery that I said “If you don’t put a Python syntax shell together for Monad, I will!” and he responded “Promise?” Yeah, that’ll teach me. On the other hand, I have to say that writing a shell is terribly appealing to me – it’s about the most pragmatic thing a language geek can do.)

I was just looking through my server logs to try to see what kind of searches were bringing people on the site. Instead, I saw a whole bunch of inbound links from a particular high-level domain that apparently teaches people how to play poker. Doesn't make sense; I like poker, but there's no way this blog should be a poker-player's destination. It turns out that I am being "referral spammed." Some blogs automatically publish lists of referrers (that is, inbound links that have been followed). If I were to be do so, I would be publishing links to this particular poker playing site and thus driving up its PageRank.

I find it interesting that I haven't yet been discovered by the comment spammers, and my referral spam appears to be limited to just this one high-level domain. I imagine that once you get on a "vulnerable" list, it's all over... If so, this would argue for the efficacy of "nofollow." Presumably, if you managed to implement "nofollow" before getting on a list, you might not be marked as vulnerable.

Engadget columnist Ross Rubin declares the death of pen computing.

The premise of the column is that pen computing doesn't add enough value. There is value the article claims in diagramming and forms--but this just isn't enough to justify the expensive of providing one. Just use a separate digitizing pad if you must …. reminds me of a comment Howard Elias made last night at the DEMO Innovation dinner. He was being recognized for his contributions in introducing the first multimedia PC in 1991 at DEMO. At the time he was challenged: Why does a computer need sound? It was a good question at the time. Never much of a gamer myself, that's what I thought at the time too. But ten plus years later it seems out of place….I was still a laggard in terms of having a microphone equipped computer. At the time, I made the mistake of correlating the value of a microphone with speech recognition--which didn't work for me well enough to be useful. But now with VoIP and apps like Skype my view has changed. I want a microphone with all my computers so I can talk with people. No speech recognition required. I wouldn't buy a notebook or Tablet without a microphone--or better yet a microphone array--today…. Via  [Incremental Blogger]

Additional insights in the original post, but the point about the microphone is so spot on that it’s worth highlighting. The delay between early adopters and majority, the difference between the expected use (by the early adopters) and the killer app, the critical mass necessary before the killer app could be created, and even the way that the implementation evolves (the first mike on a computer I ever used was something that came from a Radio Shak tape recorder, then came the era of the cheap plastic mike, and now we're in the era of the noise-cancelling headset and array mike).

At this point, I think we know that writing per se won't be the killer app of the Tablet PC (I've written entire columns on the Tablet and even I mostly write using a keyboard). I'm going to say the same thing is true for drawing, even though I am vastly less competent to talk about what appeals to professional graphics people. I still think that the day Word supports standard proofing marks (not just ink comments, but “Yank this...reverse this order...insert text here”) is the day the Tablet becomes mainstream. (A day that will almost certainly coincide with the day that one can create an Excel formula in ink!)

On the other hand, I also feel that the real killer app of the Tablet is something that we early adopters haven't anticipated. My current suspicion is that we're too focused on static aspects of “pen and ink,” that the things we think about today are too focused on X and Y coordinates, when the great advantage of the stylus over the mouse may very well be that it provides a much richer data stream -- not just X, Y, and time, but pressure and tilt.

My latest for DevX, on developing an ink-based Wiki, is now available.

I was thinking about the near-future day when the guy in front of me on the plane not only lowers his seat into my lap five minutes into the flight but does so while beginning a six-hour conversation on his cell phone or VOIP connection. Are small but potent electromagnetic pulse generators forbidden on commercial flights? I mean if you can't use them in front of row 10 or whatever lest the compasses in the cockpit point backwards, I would totally understand. But, you know, the cell phone thing is going to be really annoying.

For me, the highlight of MWA was insinuating myself into the Arcs of Fire project. I'm not 100% sure that I can start talking about what I'll be doing, but I expect to get some clarification on that soon.

In insanely great coolness, the Arcs of Fire Website contains ink-based discussion forums, apparently powered by Community Server. In my opinion, this is a huge step forward in the ink-on-the-Web experience (sorry if I've missed other ink-based forums...).

Oh, and the Tablet PC party at Varnish was excellent. I've been to way too many conventions to get excited about finger-food and an open bar, but the party was filled with really interesting, really positive people. And sake cosmopolitans? Them's tasty!

In a previous post, I mentioned Indigo's "A-B-C" programming mantra as one of the technology's greatest strengths. "A-B-C" stands for "Addressing, Binding, Contract" and is Microsoft's way of teaching the concerns of connected systems:

• Addressing: Where can I find the service?
• Binding: How is the service expressed across the wire?
• Contract: What is the information exchange of the service?

Are there other concerns in connected systems? Of course. But "A-B-C" is a great pedagogical device for approaching the programming model.

“Contract” is the service-oriented version of the API -- the developer's concern. “Addressing” is where the service lives on the network and is the administrator's concern. “Binding” is how the service is configured to show itself outside the process -- will it be over SOAP, MTOM, etc. Most likely the administrator's concern, but not entirely outside the realm of developer concern.

Why do I think this break-down of the model is important? Because it's very, very teachable. I see “A-B-C” as being crucial to one's initial experience with the technology. And I increasingly have come to believe that one's initial experience with a technology is more crucial than generally acknowledged to the technology's long-term acceptance. 

My concerns about Indigo stem from the medium- to long-term complexity of the programming model, especially to the extent that the Indigo model conflicts with the CLR model. Did the failure of the EJB model stem from its inherent complexity or its relatively harder learning curve? If the former, then Indigo may face similar challenges. If the latter, Indigo seems to be on firmer legs.

In general, I'm quite impressed with Indigo. I like all sorts of things about it. But I have some doubts...

Indigo presents a programming model that is quite different from that of the CLR. The CLR's programming model is what you might call “classic OOP.” Object's become instantiated with a call to their constructor, and when no longer needed, memory is automatically reclaimed and resources are explicitly reclaimed by the class. Every field has a visibility modifier specifying what other modules can and cannot access that field. There is a Common Type System that promotes interoperability.

These three issues (object lifecycle, visibility, and typing) are all different in Indigo. While there may be additional issues that are also different between the CLR and Indigo, these are the big three. These are very fundamental issues; I think it's fair to say that they represent different programming models.

The great mistake of J2EE was that it presented a different programming model from “plain old Java.” J2EE had needless complexity and that's something that Indigo has clearly avoided (Indigo's greatest strength may be the “A-B-C” programming mantra). Nevertheless, it seems that with Indigo we have one programming model for in-process (CLR) and another model for out-of-process (Indigo). Is this necessary? Is the difference between in-process and out-of-process so fundamental, like the change between single-celled and multi-celled life, that entirely different models must be used?

Or could Indigo have done a better job creating a unified programming model? I'm not saying that the CLR's current model is “right.” In fact, every application faces issues of versioning and external dependencies and these issues, it seems to me, are essentially the same issues as connected systems. It's just that they don't necessarily crop up the very first time the app is run. Perhaps the time has come to evolve the notions embodied by the CLR.

If it develops that “CLR projects” and “Indigo projects” diverge in complexity and approach in the same way that “Java projects” and “J2EE projects” diverged in the late 90s, the .NET programming community could be crippled in the same way that the Java community was.

Jonathan Edwards gives a demo of subtextual (17 minute stream), a programming language that is very close to the type of graph-structured language that I've been imagining for the Tablet PC. The main difference is that he's figured out how to cleanly allow his language to have cycles, which stymied me. He has a manifesto with which I am in complete agreement, although I'd probably emphasize different things. For instance, he seems to emphasize “copying” while I'd probably emphasize “linking” and he seems comfortable using a tree-like representation of the program while free positioning in X,Y space is an important part of the experience I envision (hinted at in the DAGDraw image).

 John Montgomery muses “Every day members of the press get to write about their interactions with Microsoft -- often interactions with me. What would happen if I blogged about my interactions with them?”

Naturally, as a potential target for his evaluations, I’m against it.

Actually, I wish there were more criticism of the software development press (as in critiquing, not as in “MSDN sucks because it doesn’t cover Linux!” or the knee-jerk reaction from one of John’s commentors that “The press is a bunch of liberal hacks!” – a criticism that really doesn’t seem very relevant to a discussion of InfoWorld, eWeek, and DDJ). You would be amazed at how rare it is to receive a thoughtful consideration of an article, or an editorial theme, or a direction. For instance, those who read my blog know how much I love the Tablet PC. Although I don’t write about the Tablet PC very much in my SD Times column, when I have, I’ve been over-optimistic about its reception. But no one’s ever written a letter to the Editor saying “Come on, Tablet PCs won’t dominate laptops! They’re too expensive, there’s no software, and they don’t have the marketshare to support independent development!” Too bad.

But what a lot of people don’t understand about the press, even the very insular world of the SD press, is that certain things that look stupid are part of the process. For instance, I had a conversation with Jack Greenfield last month about Software Factories where I pushed him to define what he undoubtedly considered fundamental concepts while he clearly wanted the conversation to be at a higher level. I suspect that if he were to blog my astuteness, I’d come in fairly low. But I’m very comfortable with the questions I asked him, because industry-wide advances in software productivity don’t come from grandiose schemes, they come from details. Similarly, if I were to discuss COmega, I’d definitely circle around the details of “chords” quite a bit, while another journalist might breezily accept “Cù makes concurrent programming easy!” [ … snip an entire rant on concurrency, type systems, and other insanely important areas where there’s a huge gap between platitudes, academic theory, and industry practices…]

My second article on Pynk (my ink-based Python interactive console) is now available on DevX.