The first beta of Microsoft’s new LightSwitch development environment should be available on MSDN about the time you read this. LightSwitch was code-named “KittyHawk” during its incubation (using Microsoft’s proprietary GratuiToUs capitalizatIon algorithm) and is the basis for the “return of FoxPro” rumors that have been kicking around recently. It is not, though, an evolution of the FoxPro or xBase languages, but rather a new Visual Studio SKU that produces applications backed by either C# or Visual Basic and deployed on either Silverlight or the full .NET CLR. It does, however, embrace the “data + screens = programs” concept of programming that was so popular in the late 1980s.

This is, in some ways, an indictment. A Rip Van Winkle who fell asleep at the launch of Visual Basic 1.0 and woke at the Silverlight unveiling would be unlikely to guess that 20 years had passed. Apparently, programming is still the realm of an elite group that cannot quickly produce small- and medium-sized data-driven applications, and does so using hard-to-use tools that require a lot of repetitious, boring, error-prone work.

It seems the solution to this is a tool that hides as much code as possible from the power user or newer developer. Even if you buy that argument (and I’m not at all sure that you should), why should you believe the “this time we got it right” assurance that applications written by newcomers will not be fragile, poorly structured and unable to scale?

The answer to the scaling part of that question is Azure. Microsoft is pushing the message that they are “all in” to cloud computing, and LightSwitch can use Azure to host your data, your application, or both. The LightSwitch code-generation process takes care of paging, caching logic, data validation, and other sorts of code that, no doubt, can cause trouble, especially for less-experienced developers.

On the other hand, scaling is no different than any other hard problem in software development—a trade-off that was logical at one scale may not be a good choice at another scale. It’s not impossible to have an application that can scale without the developer directly addressing issues of lazy evaluation, data aliasing and so forth, but it’s a crapshoot.

Microsoft emphasizes that LightSwitch is built on the .NET stack, not an alternative. When an application “grows up” and is considered for department or enterprise deployment, professional developers can open a LightSwitch project in one of the more advanced Visual Studio SKUs and continue working. That’s the great promise of LightSwitch: You don’t have to decide between an easy-to-use database-oriented language and the more mainstream programming languages.

The backing by the major .NET languages is a key differentiator between LightSpeed and PHP, its true competitor. Microsoft has finally woken up to the perception that the IIS Web Server and .NET stack is difficult for beginners and casual developers, as well as for quick-and-dirty applications. LightStack and IIS Express (a version of IIS 7 that fits better in security-conscious corporate environments) aim to bring back what was arguably Microsoft’s greatest advantage: It owned the technology that trained a generation of developers.

The development world is far more fragmented now, but PHP is closer than anything else to delivering the “gee whiz” that was part of the appeal of GW-BASIC.

PHP, though, is far behind the curve after the casual stage. Data integration, debugging and coding environments for PHP are comparable to what Microsoft was shipping in 2003, and in regards to concurrency, testing or coding standards, PHP is even further behind. And while I’ve seen beautiful object-oriented PHP code, it’s far more common to see teetering monoliths of imperative code swathed in dense thickets of HTML markup.

Not that LightSpeed apps will seem any better at first glance. LightSpeed does nothing to address separation of concerns and modularization, testing, refactoring, or incremental development. Hideous imperative monolithic pages are built, one easiest-thing-to-do conditional at a time. But at least refactoring an app or a section of an app into a faster-to-evolve professional structure is more of a possibility when the foundation is the CLR and a first-class .NET language.

One of the big issues unaddressed in the demos and keynotes, though, is the extent to which LightSpeed can continue to exist in a development ecosystem. Once modules are carved out and refactored, and the code is evolving in Visual Studio and the interface is evolving in Expression Studio, what happens to the original LightSpeed application and its developer? Can he or she continue to actively participate while remaining in the LightSpeed environment and evolve his or her skills?

Despite Microsoft’s repeated assurances that “users are going to love these apps,” the rectangular table-oriented screens have a, let’s say, minimalist aesthetic. They can be skinned, but apparently not by end-user designers. Support for IronPython, IronRuby and F# are no-brainers and, ultimately, LightSpeed will need to support HTML and not just deploying to browsers via Silverlight.

My overwhelming reaction to the LightSpeed announcement was that here was a classic Microsoftian “Version 3 is going to be awesome!” product. I just hope I don’t need to go to sleep for 20 years in order to see it.

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