hn-classics/_stories/1996/9229434.md

10 KiB

created_at title url author points story_text comment_text num_comments story_id story_title story_url parent_id created_at_i _tags objectID year
2015-03-18T23:58:14.000Z Why I am called "the Father of Visual Basic" (1996) http://www.cooper.com/alan/father_of_vb.html adamnemecek 116 80 1426723094
story
author_adamnemecek
story_9229434
9229434 1996

[Source](https://www.cooper.com/alan/father_of_vb.html? "Permalink to "The Father of Visual Basic"")

"The Father of Visual Basic"

Why I am called "the Father of Visual Basic"

Mitchell Waite called me the "father of Visual Basic" in the foreword to what I believe was the first book ever published for VB, called the Visual Basic How-To (now in its second edition, published by The Waite Group Press). I thought the appellation was an appropriate one, and frequently use the quoted phrase as my one-line biography.

During the 1980s, my business consisted of inventing software and then selling it to publishers. In 1986 I adopted Microsoft Windows as my platform of choice. Not only did it do all of the expected GUI support things, but it had a unique and extremely desirable feature: using its dynamic link library (DLL) feature, you could create tools that configured themselves dynamically. The instant that I learned this I knew that Windows would have a huge and successful future. I learned one other very important fact about Windows at that time: its shell program was terrible.

In my spare time I immediately began to write a better shell program than the one Windows came with. I called it "Tripod." Microsoft's original shell, called MSDOS.EXE, was extremely stupid, and it was one of the main stumbling blocks to the initial success of Windows. Tripod attempted to solve the problem by being easier to use and to configure. But it wasn't until late in 1987, when I was interviewing a corporate client, that the key design strategy for Tripod popped into my head. As this IS manager explained to me his need to create and publish a wide range of shell solutions to his disparate user base, I realized the conundrum that there is no such thing as an ideal shell. Every user would need their own personal shell, configured to their own needs and skill levels. In an instant, I perceived the solution to the shell design problem: It would be a shell construction set; a tool where each user would be able to construct exactly the shell that he or she needed for their unique mix of applications and training. Instead of me telling the users what the ideal shell was, they could design their own, personalized ideal shell.

Once I had that vision, the particulars of the design fell into place with relative ease. There would be a palette of tools, and the user would be able to create "forms" and populate them with instances of the tools. The toolset would include standard controls like listboxes and pushbuttons, but would also have special, shell-specific varieties, like listboxes that automatically showed the contents of a directory.

I began work on this new version of Tripod, and within a couple of months had a nearly complete, working prototype. I used C exclusively. One of the features that emerged during this period was the idea that the interface would be completely manipulable by drag and drop. The user could stitch two controls--I called them gizmos--together by right-clicking and dragging from one gizmo to another. A visual arrow connected them logically, going from an event at the first gizmo to a method of the second gizmo. Ultimately, Microsoft discarded the arrows, but the event/method model remains.

Because I was in the business of inventing programs and selling them to publishers, I began to show Tripod around the industry. Many companies in Silicon Valley saw it, but few expressed serious interest. However, in March of 1988, I showed this prototype to Bill Gates, and he immediately saw its potential. He declared that it was "cool" and that it would have significant impact across their entire product line. Bill said he wanted to buy it, and over the next few months we hammered out a deal. Because the name Tripod had had so much exposure, we promptly changed it to "Ruby." Meanwhile, I put together a team of skilled programmers to build a release-quality program.

The team consisted of Mark Merker, Gary Kratkin, Mike Geary and Frank Raab. The first thing we did was throw out my prototype code and start over. It had grown to over 25,000 lines of C code, and although it contained many valuable ideas, the code itself reflected its role as a test bed for different ideas. The whole team worked hard for the next 18 months to eventually produce Ruby. The product was vetted by Microsoft's quality assurance team, and we shipped golden master to Redmond in early 1990.

Here is a picture of the Ruby Team, taken sometime in the Spring of 1989. From left to right, Frank Raab, Mike Geary, Alan Cooper, Gary Kratkin and Mark Merker.

The Ruby product embodied many significant advances in software design, but two of them stand out as exceptionally successful. As I mentioned, the dynamic linking capability of Windows had always intrigued me, but having the tools and knowing what to do with them were two different things. With Ruby, I finally found two practical uses for dynamic linking, and the original program contained both. First, the language was both installable and could be extended dynamically. Second, the palette of gizmos could be added to dynamically.

Ruby came with a small language, one suited only for executing the dozen or so simple commands that a shell program needs. However, this language was implemented as a chain of DLLs, any number of which could be installed at runtime. The internal parser would identify a verb and then pass it along the chain of DLLs until one of them acknowledged that it knew how to process the verb. If all of the DLLs passed, it meant that there was a syntax error. From our earliest discussions, both Microsoft and I had entertained the idea of growing the language, possibly even replacing it altogether with a "real" language. C was the candidate most frequently mentioned, but eventually, Microsoft took advantage of this dynamic interface to unplug our little shell language and replace it entirely with QuickBasic. This new marriage of language to visual front end was static and permanent, and although the original dynamic interface made the coupling possible, it was lost in the process.

From early on in the design process, I pushed the idea of making the gizmo palette dynamic. I envisioned a product where third party vendors could write their own gizmo DLLs and users could add them to the product in the field without needing to recompile. We defined an interface whereby Ruby would interrogate nearby executable files with a query message. If the file responded appropriately, Ruby knew that it was a cooperating gizmo and proceeded to request its icon to display in the tool palette. This interface eventually became known as VBX. As far as I know, it was the first practical use of the dynamic linking facilities of Windows outside of the operating system itself. Its remarkable success vindicates the faith of both Microsoft for providing it and of myself for finding a practical application of it.

Because Microsoft owned exclusive rights to Ruby, they could do with it as they pleased. The original intention was to ship it with Windows 3.0 as a new, more powerful and sophisticated shell, much like the one that accompanies Windows 95 today. Instead, Microsoft decided to ship Windows 3.0 with a shell that looked almost exactly like the shell that came with OS|2, a product Microsoft owned at the time. The decision was made to delay shipping Ruby and to convert it from a shell construction set for all users of Windows, to a visual programming language for professional programmers by adding QuickBasic. At first, I was very frustrated by Microsoft's decision, and argued against it. However, I was impressed by the power of the eventual product, and soon became an enthusiastic Visual Basic supporter.

During all of the time that I was working on Ruby, I was under a tight non-disclosure agreement with Microsoft, and could tell no one about what I was working on. For a period of almost four years, I kept silent, even though I knew that Ruby would change the programming landscape. Shortly after VB's release, my friend Mitchell Waite telephoned me to ask whether or not I was the Cooper mentioned in VB's about box. I confessed that it was me, and he invited me to lunch so that he could hear the full story firsthand. We met in San Francisco and I related to him the same story I have just told you. When I was finished, he looked at me in amazement and pronounced "That makes you the father of Visual Basic!"

I have two young sons, 9 and 10 years old, and although I was instrumental in their creation, and remain a big part of their lives, they are independent-minded people in their own right. As I watch them grow in their own way, and make their own decisions about their lives, I know what it really means to be a father, and Mitchell's phrase strikes me as more appropriate everyday. I created VB in the same way that I created little Scott and Marty. I stand by as the proud father of VB as it grows and matures and creates a culture all its own.

In May of 1994, at the Windows World conference in Atlanta GA, Bill Gates awarded me one of only seven Windows Pioneer Awards for my part in making Windows a success through the creation of Visual Basic.

BACK


Copyright © 1996, Cooper Interaction Design
Last updated April 22, 1996
Talk back to me!