At the D9 Conference in early June, Steven Sinofsky, president of the Windows division, gave the public its first glimpse at Windows 8. A striking “Metro” interface similar to that of the Windows Phone 7 OS, which features bold typography and large active icons, was featured in the presentation. This interface should work wonderfully with touch-screen tablets, which ought to have enough resolution to allow active icons to actually communicate useful summary information, and the finger swipe is one of the more intuitive and easy user interactions.

Whether the interface will work wonderfully with mouse and keyboard, though, is not as obvious. In 2003, when Microsoft launched its first OS for pen-based tablets, it made the mistake of treating the pen as if it were a mouse. Buttons were no bigger despite obvious issues with parallax, and menus cascaded at right angles despite ample evidence that radial menus were faster and more accurate for pens. I fear that it’s making the same mistakes in reverse in its eagerness to jump on board the touch-sensitive tablet craze (a craze that I suspect will be in decline by the time Win 8 ships).

I hope that Microsoft doesn’t forego the advantages of keyboard and mouse in its desktop operating system. I don’t like trackpads and I have no intention of buying a touch-sensitive monitor. (I could be tempted into buying an Windows-integrated Kinect, at least when the hardware doesn’t need six feet of open floor space, works in a room with a window or two, and can recognize gestures of the hand and fingers readily. The Kinect SDK, by the way, is now available for non-commercial projects.)

Perhaps it was the recent ratification of the C++0x standard, the forthcoming announcement of the Accelerated Massive Parallelism technology, or Sinofsky’s background as one of the architects of the original Visual C++ and Microsoft Foundation Classes, but the use of C and C++ as mainstream development languages was one thread of the development story. The other thread was the promotion of JavaScript and HTML5 as the technologies most likely to be used in developing Windows 8 applications. C#, VB, F# and the CLR were not discussed.

The silence was probably largely an oversight. While Silverlight has not caught on and may not have the brightest future, it’s simply inconceivable that Microsoft is going to abandon C# and .NET. Having said that, it seems fair to point out that it was also inconceivable that Microsoft was going to abandon Visual Basic 6 developers, and yet that’s how many VB6 developers would describe what happened.

While the initial cries of outrage seemed a tempest in a teapot, Microsoft flubbed the response. Instead of reassuring the community, what emerged bore the ominous hallmarks of “message control”—the equivalents of “I have nothing to tweet on that matter” and even a somewhat peevish tone at the demands for reassurance, as if it was unreasonable that developers fear having the rug pulled from beneath their feet.

But it’s not unreasonable. Developers who have bet their careers on Microsoft technologies, who put their reputations on the line in support of Microsoft promises and explanations, and who are somewhat nervous about Microsoft’s across-the-board loss of market share, have every reason in the world to be concerned that Microsoft might do a radical course change on Windows programming. For a decade, Microsoft has promoted technologies that have either not shipped at all (WinFS, Longhorn) or fallen short of its promises (ASP and ASP.NET, the W*F technologies (like Windows Presentation Foundation and Windows Workflow Foundation), and the Dynamic Language Runtime).

So now, when Microsoft speaks of programming desktop applications with “JavaScript and HTML5,” it’s not unreasonable to ask questions. Not only does Microsoft not control either HTML or JavaScript, MS is not even first among equals in those technologies. As I said in my recent column “Waking up with JavaScript,” ECMAScript is an increasingly important language, has obviously won the battle of browser-based client languages, and has an excellent shot at becoming more important on the server.

As a desktop language, though, it has no history, few libraries and no advantages. As a forward-looking language, not only does it not have a built-in concurrency model, it is also likely to be hard to parallelize, given how easy it is to manipulate state across very wide scopes (shared mutable state being the enemy of concurrency).

“JavaScript and HTML5” don’t get you much further than the presentation layer. C and C++ work at the systems level. The question is what fills the gaps in between. The .NET Framework seems to be the perfect answer, but if so, why the silence?

One answer might be that two C-language families in a stack is company, three is a crowd. Even though C# is, from a language design standpoint, much better than JavaScript, perhaps that’s become irrelevant; perhaps C# has become the Betamax to JavaScript’s VHS (Google it, kids).

Larry O’Brien is a technology consultant, analyst and writer. Read his blog at www.knowing.net.