Serial killer or programming language inventor? via [BoingBoing]

I got 7/10.

Oh, my favorite demo of the whole show was one I got on a bus ride! Steven Burns showed me the Longhorn Shell, which advances the "pipes and filters" pattern of UNIX by piping not text streams, but object streams! So, for instance, you can grab all the currently running process with a ps command (well, get/process is the "real" name, but alias get/process ps works), and then because what's being streamed are real objects and not just text streams, you can filter it with an arbitrary query against an object-specific property (ps | filter handlecount -gt 400) and then pump that into different formatters: ps | filter handlecount -gt 400 | tableformatter or ps | filter handlecount -gt 400 | xmlformatter or ps | filter handlecount -gt 400 | listformatter or ps | filter handlecount -gt 400 | FullGuiFormatter (I'm handwaving at what the real "full GUI formatter" command is, but I saw it work).

You know, rendering a GUI transition with AfterEffects is very nice and all, but sysadmin scripting: priceless.

Borland was showing Delphi for .NET at the PDC. BorCon is next week: you might want to bring your credit card.

At one of the CLR evolution talks, I disagreed with the prevailing notion that serving the needs of the current language community should be of paramount concern. To me, interop trumps language fidelity. It is only via interop that minority programming languages can enter the corporate market. Crown-jewel software is always so complex that it constitutes its own domain; the idea that the Bus Factor (the number of people whose death in a bus run-down would be catastrophic to the company) can be minimized by using a majority language for the crown jewels is largely an illusion. The problem isn't the crown-jewel software, it's the other stuff, the administrative interfaces, the reporting functions, the integration bridges, that are legitimate arguments against the use of minority languages in corporate environments.

So the argument goes, "Well, the current language enthusiasts demand the fidelity or they won't have the opportunity to create the crown jewels in their unique way." But my argument is that adoption is driven by the young. It's the kids who are just entering the marketplace who are going to do something astounding; it's the kid who doesn't give a fig about language fidelity who's going to combine X with Y in a way that gives his or her company a real competitive advantage. Software advances not by theory, but by the unexpected consequences of implementation. The ultimate success of the .NET platform depends upon how pragmatic it is to combine trail-blazing components that exploit some unique expressiveness of a minority or domain-specific language with the support and infrastructure components of the more mainstream "homesteading" languages.

For the past two years, convergence has been the theme in Microsoft languages. Visual Basic .NET was a significant break from VB6 and is a very similar experience to programming in C#; Managed C++ gained the use of visual forms design; everything worked inside Visual Studio .NET. The theme of Whidbey at the compiler level is that the languages are diverging -- VB.NET will have unique things (edit and continue), C# will have unique things (closures), and C++ will have unique things (deterministic finalization). As you can see, these divergences are to the service of the languages' core audience (VB.NET: programmer experience, C#: language expressiveness, C++: control and performance).

There are other things, most notably generics, that will be shared across all languages. One of things that I was very interested at the various discussions of CLR evolution is the concern that the unification necessary for interop (what I described immediately following the BoF as a concern for the BCL, but which really extends beyond that) may impede innovation in languages: it may be the case that every language can agree to the existence of an int but with concepts such as IMap<K, V>, it's not as sure a thing.

...as the drunks say, you can't fall off the floor. Anyone offering content free gains an advantage that can't be beaten, only matched, because the competitive answer to free -- "I'll pay you to read my weblog!" -- is unsupportable over the long haul....In a world of free content, even the moderate hassle of micropayments greatly damages user preference, and increases their willingness to accept free material as a substitute." via [The Start of Fee]

I'm afraid he's right. I do two things to make my living: craft words and craft software. Both careers are severely threatened. Ironically, one of the reasons I dropped out of college was because I could make money crafting software. What did I leave behind? Dual majors in Marine Biology and English. I apparently have a poverty-seeking gene.

One thing that few people have mentioned is that offshoring is a great threat to independent software developers. In the past, I've always subsidized my writing by contract work, but the short engagements that I've specialized in are flowing offshore at an amazing rate; in the past year, every single small contract negotiation ($5-$20K projects) has revealed that I'm competing against offshore resources. All the offshoring press discusses big IT resources and high-quality teams, but there's another story, which is the lower-quality teams that are threatening the independent software crafter. Open Source may be a challenge to ISVs, but independent software consulting is almost certainly doomed as a way to make a living wage, at least in urban areas.  

I just visited Text America's PDC Photoblog and saw Don Box's face smiling out at me. I wonder how to make photo blogs more useful. Thanks to those of you who posted photos. via [The Scobleizer Weblog]

This is why I ended up generating FOAF from Outlook the other day. My thought is that photoblogs become much, much more useful when tied to an easy annotation system that asserts XML-based metadata, perhaps FOAF and RDF, perhaps something else (one of the gajillion WinFS schemas discussed at the PDC?). Equally, once you've licked this problem, you don't just have a photoblog tool, you have a foundation for a generally-useful tool:

It's in the nature of BoFs (Birds of a Feather sessions) to be frustrating. No sooner does the ice break than the proctor comes in and announces that the last bus to the hotels leaves in 10 minutes. Oh well...

The "Alternate Programming Languages" BoF gathered a great group, but I'm afraid that 60 minutes was patently unworthy of the stories to tell and questions to ask. After going around and getting a sense of the group, we talked mostly about two questions, one predictable ("Does the CLR inhibit dynamic languages?") and one less obvious, but ultimately perhaps more important: "Does the Base Class Library taint languages?" Or more generally, if you accept that a class library implies patterns and programming models, is this terribly jarring to people programming with different patterns and programming models?

I don't think we reached a consensus and I'd be suspicious of whether the group was a representative sample of the user community anyway! In the group, people mostly voiced a pragmatic acceptance that you might have to deal with different programming models and it's not a big deal. I'm not sure I agree, but I certainly enjoyed the conversation.

strenuous "We have not -announced any time for new Tablet PC O's: Havens gone to the Allchin tape to confirm or deny.

Blogged on a Tablet PC

Just got confirmed that my security problems having my code deploy as "smart clients Tiepin a web Page) is a known problen in The current Tablet SDK. Thank God-I was, like, "Gee, maybe I done -understand smart clients." Patched in The 1.7 SDK coming in beta RSN.

Blogged on a Tablet PC

Just got a demo of the new "Dos" shell in Longhorn. Its a great idea, hugely scriptable and based on unix-typecommand piping. But instead of text being piped, You get real objects, pumped to You asynchronously, Beautiful piece of code.

Blogged on a Tablet PC

I won't be at the PDC until tomorrow morning, but sitting at home hitting "Get news now..." reveals that information about the Whidbey release of Visual Studio is beginning to appear: http://www.asp.net/whidbey/ 

Talk about creeping featuritis: there I was working on adding image annotation to my ink-based blogging tool when... Well, who wants to alpha-test an Outlook 2003 Contacts to FOAF generator? If you don't know what FOAF is, this isn't the release for you. Lemme' know if you want to try it out. This is just an Outlook->FOAF->FOAF registry bridge; it's not ink-based and it doesn't have any image annotation features.

This is what it looks like:

And it generates something like http://www.thinkingin.net/foaf.rdf.

By the way, Outlook 2003 is easy to program for.

Motorola Mpx200 Smartphone for $150 with new AT&T Wireless account, $299 otherwise.

Smart: utility software linked to a hardware device. The Migo is a $150 128MB USB chipdisk. That's about a $100 premium over what at first glance appears to be a similar device. But the Migo has a custom driver that grabs your Outlook settings, your Favorites folder, etc. Now, let's just say that you wrote a utility program that allows you to zip up your /Local Settings folder and carry it around with you. Think you could sell it for $100 and say "Just use it with your $50 chipdisk"? Of course not. You might get a handful of registrations if you made it $30 shareware. But probably not.

That's why it's a good idea to learn about .NET Compact Framework and SPOT.

I hard-coded a link to InkPositive into the tablet blogging tool I've been hacking on in the evenings and Scoble picked up on it. Here's the deal: I want to do a community site dedicated to Tablet PC software, not hardware. But the site has to be optimized for the Tablet PC, which means there has to be a lot of ink-y stuff on it. I've got that wired -- I've got usable prototypes of an ink blogging tool and an inked discussion board (I'm getting SecurityExceptions when I try to do a "smart client" style Web Install of the client-side editing tools, but I'm sure I'll figure that out) , and the solution I'm working on for adding links to inked blog items should enable me to pull off an ink wiki.

But what I've had difficulty doing is finding a community framework that allows for the type of layout customization that I absolutely need. I've played with both the ASP.NET Community Starter Kit and DotNetNuke and neither fits my mental "object model" of a community framework, leading to the temptation to roll my own. The mental tension between "Login management is, like, four ASPX pages and then Bob's your Uncle," and "You've got to be nuts to consider reinventing the wheel" has kept me paralyzed for five months.

Anyway, InkPositive is a secondary priority behind an educational resource that I'm hoping to roll out soon that I think will be extraordinarily useful and that might (just might) generate enough income to pay for the time invested.

 A silence falls across the room as I realize that Joel has written something I disagree with entirely. via [The .NET Guy]

I’m with Brad “.NET Guy” Wilson on this. Joel compares exceptions to gotos and not just with the obligatory “considered harmful” phrase, but by comparing them to “gotos sprinkled throughout your code.” Now, I don’t think that Exceptions-As-Know-Them are the ultimate solution, but comparing them to gotos and invoking “Go To Statement Considered Harmful” is a particularly poor choice. Most people think that Dijkstra damned gotos because they introduce multiple entry points into a code block (i.e., they allow spaghetti). Not at all. In fact, what he complains about is that a goto makes it “terribly hard” to know the state and history of a program’s execution (“we can interpret the value of a variable only with respect to the progress of the process….The unbridled use of the go to statement has an immediate consequence that it becomes terribly hard to find a meaningful set of coordinates in which to describe the process progress….” ).

With exceptions as implemented in Java and .NET, this is precisely not true. One of the most common complaints when teaching Java or .NET exceptions is “Why are my variables out of scope in the catch (or finally) block?” The reason is precisely that during exception handling, the history of the program is effectively guaranteed to the beginning of the exception scope and the stack-trace gives you most of the information you need to determine the location in code and history that led to the error (what Dijkstra calls the “coordinates” of the program). It’s true that without catching the exception in a debugger that lets you walk up the call stack, you can have some difficulty determining when your error was produced (e.g., the exception doesn’t tell you that the invalid value came from the 23rd position in your array), but in general, structured exceptions