Chapter 16. .NET and the Coming Revolution

for RuBoard

Organizations bloated with inefficient processes produce piggy , sluggish software.

Steve McConnell [1]

[1] McConnell, Steve. After the Gold Rush . Redmond, WA: Microsoft Press, 1999. Page 67.

NOTE

I've included a discussion of .NET in this book because Microsoft has announced that SQL Server will include support for .NET's Common Language Runtime in its next version. Even if this wasn't the case, it makes sense to get up to speed now with .NET. It's coming, and it's coming very soon.

At the time of this writing, the .NET Framework and Visual Studio.NET have not yet been released. Some of the details may have changed between the time this was written and the present.


I've had this feeling at least three other times. It usually goes away eventually, but sometimes it lingers. It's not a pleasant feeling. It's really one of exasperation, of isolation, of incredulity. Sometimes the sensation makes me look around and ask: Has the whole world gone mad? How could we have gone so wrong?

The first time I can remember feeling it was when I was introduced to user -interface programming on an IBM mainframe. I walked into a colleague's office only to find the entire team crowded around his terminal. "Come here, come here!" one of the guys said excitedly, "Look at what Neil's done!"

Neil had built a spreadsheetand on a dumb terminal, no less. Because the terminal was essentially a display device for the computer in the data center, this was no mean feat. To execute program logic, one had to submit the screen to the mainframe, let it generate a new screen, and await results. This meant that Neil's program couldn't do something as simple as, say, scrolling around on a spreadsheet using the arrow keys or updating a formula result when its referenced cells changed. No, the Submit key had to be pressed each time the screen was to be repainted. Each screen was essentially dead: The terminal would get a screen and display it, the user would type some things onto it and resubmit , and the whole screen would be sent back to the mainframe for further processing. In many ways, it wasn't unlike today's Web browsing model.

I came away from the impromptu demo seriously underwhelmed. You have got to be kidding, I thought. Surely there's a better way to build a spreadsheet for such a powerful machine. My little PC's spreadsheet is an order of magnitude better than that mainframe concoction will ever be!

It was a feeling I would experience againthat of being astonished at the nonsense people will put up with to get ill-fitting or poorly chosen technology to do what they want.

The second time the feeling came over me was in May of 1990. I will never forget it. It was a perfect spring day in the mountains of southwest Missouri when a package arrived for me from Microsoft. I picked up the box at the receptionist 's desk and looked it over. I shook it a bit. What could it be? I wondered. There could be a thousand different things in there!

Back in my office, I ripped the outer shipping box to pieces and tossed it aside. I yanked out the shipping paper and manifestthey flew behind me in a frenzy. I picked up the box inside, shook off the Styrofoam packing and held it up to the light. There it was in all its wondrous, effervescent glory : the Windows 3.0 SDK!

I opened the box and dumped its contents on to my desk. I will build a Windows app, I thought. I'll build one right now!

I had watched Windows over the years and was particularly excited about the 3.0 release. Microsoft had combined the Windows, Windows 286, and Windows 386 lines into a single product, and had published a uniform API for writing apps for it. The display and fonts were smoother, the stark MS-DOS Executive had been replaced by the friendlier Program Manager. At long last, Windows seemed like more than just a toy. I decided it was time to see what the Macintosh-inspired user interface was all about, and I would use the SDK to build my first GUI app.

So I installed the software and quickly located one of the sample applications. It was a simple little program, really, a multiwindow text editor, similar to Notepad in terms of complexity. I fired up the Microsoft C compiler and compiled the sample. A few minutes later, it had finisheda whopping 80,000 lines of code! Why do we need so much code for such a simple app? I wondered. My worse fears were soon confirmed as I loaded the source into a text editor. What appeared before me was some of the most repulsive code I'd ever seen. Header file after header file, after header file. Message loop after message loop, after message loop. One level of indirection after another. Not really procedural code, but not object-oriented either. What a huge mess, I thought. There has to be a better way.

Over the next couple of years I kept looking for that better way. I looked at lots of products from lots of vendors . All had the same flaw: They all wanted you to wade through thousands of lines of code to produce a Windows app of even modest complexity. To be fair, some of them began generating much of this code for you, but you still had to wait while tens of thousands of lines of code were pored over by a multipass compiler. And God help you if you had to modify any of that generated code. It was some of the ugliest gobbledygook the programming world had ever seen.

Unfortunately for those of us creating those early Windows apps, this Rube Goldberg-way of building things came with the territory. It was the state of the technology at that time. We had no choice but to work with it. In earlier days, if a DOS-based technology was poorly conceived or difficult to work with, we'd simply not use it. So you don't like Lattice C and Panels? Fine, use Turbo Pascal. You don't like database management in Turbo Pascal? No problem. Use Clipper or Quicksilver. Many DOS tools had completely different programming paradigms , and if you didn't like one or it was ill-suited to your task, you could just use something else. Somewhere along the road to Windows uniformity we lost our sense of taste regarding programming tools. Everything turned to dog food, and we just let it happen.

Just about the time I'd given up on my quest to find a reasonable way to build Windows apps, along came Visual Basic. It changed everything. Although far from perfect, Visual Basic made great strides toward that ideal I'd been chasingnamely, that simple apps ought to be simple to build, regardless of the operating system, and that apps of greater complexity should be only linearly, not exponentially, more difficult. Over the years, tools like Delphi and PowerBuilder improved on the Visual Basic model, and rapid application development (RAD) came into its own. My original disdain for the tediousness of early Windows development had been well founded. The success of RAD tools had vindicated me.

The third time I had the sensation was when I was first introduced to system administration on UNIX. Thanks to regular and repeated corruption problems with SQL Server on OS/2, my team was forced to migrate a large system off of it onto Sybase running under Solaris. I had only thought that administration was primitive and unnecessarily difficult on OS/2. For me, UNIX redefined unnecessary convolution. I was stunned to learn that the progenitors of UNIX actually expected people to manage critical line-of-business apps with arcane OS commands and cryptic tools that looked like they'd been put together by a couple of graduate students intent on unleashing a torrent of unbridled obfuscation on the world.

Like the C programming language, I discovered that UNIX has been assailed by short-sighted neophytes, that every CompSci graduate since Dyson had played pin the tail on the donkey with it, cheerily tacking on one disjointed feature after another, until it was about to collapse under its own weight. I wondered: Do you people really manage systems this way? Who could keep up with all this? Who would want to? This is way too much complexity for what it is. We're not landing on the moon here; we're managing a database!

Over time, the OS vendors themselves realized this shortcoming and began to try to put a friendlier, more systematic face on UNIX. The first to do so successfully was IBM with its AIX offering. Shortly after it came out, the other vendors followed suit. Soon, UNIX was an order of magnitude easier to install, use, and administer than it ever had been. Today, it's a mature OS offered on a number of platforms by many different vendors. In my opinion, it's still not as easy to use as it could be, and I doubt that Linux will supplant Windows as the dominant desktop OS anytime soon, but things are much improved over yesteryear. My astonishment at its needless complexity has subsided to a large extent.

The fourth and most recent time I experienced the sensation was when I saw my first complex Web application. I had just taken over as the CIO of a small Internet-oriented software development company when the CTO gave me a two- hour tour of the company's source code. He covered not only our products, but also the then-current, state-of-the-art in Web developmentHTML, JavaScript, cookies, and so forth. I sat there in silent bewilderment. The old feeling was back. Surely no one would go to this much trouble to build relatively simple applications. Surely no one would use such primitive, ill-fitting technologies to build critical software.

Sure they would. They certainly had before.

To begin with, I was stunned at how primitive the development tools were. There seemed to be just two varieties: the do-it-all tools that built entire Web sites but came at the expense of cookie- cutter blandness and an annoying imprecision, and the do-it-yourself tools that basically consisted of someone's idea of an HTML-oriented Notepad. There was little middle ground, and technology fragmentation and competing standards made the situation all the worse.

I was also stunned at how weak and inflexible much of the technology itself was. I was disappointed in HTML as a language, in its general intransigence and lack of power. I was shocked that people were willing to go back to the days of running production apps under an interpreter and of having syntax errors show up in live code. I couldn't believe that they'd be willing to give up the visual development model that had made Visual Basic so popular or that they would stand for tools that forced you to hand-code anything of any complexity.

Moreover, I couldn't help but notice the enormous amount of effort that had gone into working around the Web's deficiencies. No one thought of state management? No problem. We'll handle it through cryptic URLs, cookies, and hidden fields. So we underestimated how much people would miss interactive content? Not to worry. We'll write interpretive scripts that run under the browser (perhaps different ones for each browser). We'll create spiffy UI controls in Java, C++, VB, or some other language and download them to the user's machine, and, to deal with the long download times that will then result, we'll cache these controls on users' machines without any sort of version management or upgrade path . To deal with the possibility of malicious code, we'll take a step backward and go back to application-based security. We'll add security mechanisms to the Web browser to supplement those of the operating system. Because, technically, everyone using a Web server is the same operating system user, we'll move the security and authentication mechanisms for these controls to the browser itself. And when we're done, we'll present a user-interface experience that's perhaps half as rich as what people already enjoyed long before the Web came into vogue . We'll literally spend years coming up with one workaround after anothermany necessitated by shortcomings that should never have existed in the first place.

Because the world had settled on a markup language as the primary tool for building programs and had embraced a document-centric view of software, we were being forced to give up many of the hard-fought gains we'd spent years achieving: object-oriented programming; active, vibrant user interfaces; client-side intelligence and state management; network domain-based security; the speed and stability of compiled rather than interpretive code; readable, supportable programs; code reuse; centralization of application binaries; and so forth. I was astounded that people were willing to build critical applications using clunky text files produced by a mainframe-style, submit-and-generate interface. I thought we'd left that model behind because we discovered it didn't work very well. I thought we'd outgrown it.

As I sat there that day, it became apparent to me that, thanks to the Web, user interfaces had been dumbed-down a great deal, that applications had become less (not more) usable, and that developing software that was powerful, user-friendly, and extensible had become exponentially more difficult. In the narrow-minded interest of internetworking, it seemed the advent of the Web had set the entire software industry back a good two to three years in a number of areas, particularly with respect to applications development and user-interface design.

So, since that time, I've been looking for an answera technology or set of technologies that would make building simple Web apps easy and that would make building more complex apps only linearly more complex. I've been looking for technology that's fully object-oriented, and that lets me use inheritance, encapsulation, and polymorphism to my heart's content. I want something that's compiled, not interpreted; that catches my typos and syntax errors at compile time, not at runtime; and that runs at native code speed.

I want to be able to use one language for everything. I don't want to have to build pages in one language, controls in another, and scripts in yet another. I want to have to master just one language, and I want it to be orthogonal and systematic enough to be worth mastering.

I want to be able to build as rich a user interface as I can conceive. I don't want to be limited by my tools. I want my tools to enable me, not hinder me, so that I can focus on what it is my apps are supposed to do, not on the ugly details of making it happen.

I want a tool that takes care of state management for me, but that's still based on HTTP and connectionless application design. I want a tool with a rich suite of data-bound controls that can display themselves in a Web page without my having to generate HTML from a database or otherwise manually populate them.

I want a tool set that allows me to build Web pages visually, similarly to the way that RAD tools work. I want to drop a button onto a form, double-click it, and attach some code to it. I don't want to have to think about form submission or form variables ; I want to code to objects and let system-level software take care of the rest.

I want a tool that's not language-centric, that lets me select from a wide range of programming languages without losing functionality or running into weird cross-language data conversion issues. If I want to build a class in one language, and someone else wants to inherit from that class into another, I want the technology to make it happen.

I want a tool that lets me develop any kind of application I want. I don't want to have to use one type of tool for GUI building and another for system-level development. I want to be able to build any type of app I need tofrom a console application, to a service, to a Windows app, to a Web appwith a single tool. And I don't want a least common denominator approach. I want the technology to be powerful, easy to use, and extensible on every platform it supports.

I want the safety and security of an advanced framework around my apps. I want to use technology that manages resources for me, that keeps me from accessing memory I shouldn't, and that generally lets me focus on the business problems my applications are designed to address, not on the hair-splitting details of how it all happens behind the scenes.

I want a technology that lets me build multitier applications that are lightweight, scalable, and easy to build. I want a technology that allows me to exchange data easily with applications and code that I did not write.

I want a tool that's reasonably backward compatible with the existing code base out there, that will preserve my investment in the apps I've built thus far, and that will allow me to easily find programming talent that's already skilled in it.

In short, I want everything. I want to revolutionize the way that applicationsparticularly Web applicationsare built.

Fortunately, somebody out there has already thought of all this and has been working on it for some time now. And fortunately, that somebody is Microsoft.

for RuBoard


The Guru[ap]s Guide to SQL Server[tm] Stored Procedures, XML, and HTML
The Guru[ap]s Guide to SQL Server[tm] Stored Procedures, XML, and HTML
ISBN: 201700468
EAN: N/A
Year: 2005
Pages: 223

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net