Knowing .NET

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.

My latest column, on interviewing at Microsoft and laziness, is up at SD Times.

According to David Intersimone, Delphi 1.0 launched 10 years ago today at the Software Development conference. We’re currently evaluating Delphi 2005 for this year’s Jolt Award for “Languages and Development Environments.” Other finalists are: CodeRush, Eclipse, IDEA, JBoss AOP, Python, RealBasic, and Sun Java Enterprise Studio.>

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.