The question is not, "Why is there Visual Basic." The question is, "Why did Visual Basic use BASIC, and not some other language?" (See BasicLanguage.)
I'm sure Sam will have a better reply, but I think one of VB's strengths is in the number of things you don't have to learn to start using it. When someone loads VB and starts hacking away, they don't have to learn anything about make, compilers, linkers, editors, COM, or the grizzly inner workings of WIN32s at first.
You get this advantage of having to learn fewer things by giving up some of the freedom we Unix-heads like. I like being able to choose my editor and my make and my compiler (and getting them to all play nice together), even with the sometimes painful cost of having to choose my editor and my make and my compiler (and getting them to all play together). To me, the advantages outweigh the drawbacks. But there are many programmers who legitimately don't see it that way. And within certain constraints for project size and subject to issues like internationalization (the last time I looked, a difficult problem in VB), VB is the perfect environment, even though it's a very imperfect language. -- WayneConrad
Thanks for the feedback, Wayne. I think I explained myself poorly. I realize that one of the main strengths of VB is exactly as you say - but this strength has nothing to do with the Basic part of VB. It didn't have to be Visual Basic, it could be VisualFoo?. So my question was, really, why basic when there were so many better designed languages out there that you could have wrapped the framework around (my python example is, of course, misleading because of the timeframe, but others would suffice). So now when you want to do non-trivial things in VB that don't already have a known solution through components, you have to fight the language design, to some degree. I really should have been less-inflammatory in some of those sentences as well. I'll come back and clean it up. Definitely *not* looking for a language war. I don't think I am at all unusual in my belief that Basic, like Cobol [CobolLanguage], was one of the early general language experiments that turned out to have large design flaws. This doesn't in any way imply that one can't do useful work in it - just that this may be harder than it needs to be! My curiosity stems from thinking that MS had a chance to start with a clean piece of paper, as it were - and made a choice that I (and others) find puzzling. -- still curious (perhaps I should set up a home/name page) -- curious
You're right, I answered the wrong question. And nope, I have no idea "why BASIC," other than that it was the lucky genome to survive in that ecological niche. -- WayneConrad
Well, Basic was a language that appealed to the target audience - occasional and non-professional (purely in the sense of not making a living from) programming. Lots and lots of people had some experience from playing around with Basic on HomeComputers?, and found it non-threatening. I'm sure Bill was thinking about VBA even at that stage as well.. -- BurkhardKloss
Possible reasons for MicroSoft to base VisualBasic on Basic:
I've been told that Microsoft was itself surprised at the popularity of the first versions of VisualBasic which had not been a strategic project before then. With a success on their hands, they had the wisdom to follow up on it as best they could. This wasn't easy as the underlying engine (in assembler) did not meet the portability standards they were then becoming accustomed to. -- WardCunningham
Ok, one more before I go: Why start with Basic? By which I mean, Basic was such a horribly brain damaged language --- I understand that MS has addressed some of its more spectacular failings when designing VB, but why start there at all? Was it because of the companies history with Basic? They could have done the same
MicroSoft did have a history with Basic as it was BillGates' first product way back and he has always had a fondness for the language. As for why, see further below.
thing with other languages - I understand that they probably couldn't make it fly with a functional language but there were many, many, options. So now you have a situation where strictly as a language, ignoring the components VB is pretty yucky compared to, say python or perl (even with the warts); but much more useful for many tasks on a windows box because of the polished interaction with the components. I really don't understand the logic behind this -- AnonymousDonor
There was no Python in 1989 and 1990. Maybe there was Perl. But I would argue that Perl is much more yucky, especially to the audience they were trying to reach. The history is this: AlanCooper developed the Ruby prototype in 1989-1990 and showed it to Microsoft. That's the visual part. The language part, Thunder, was developed in concert with us in the TeamLinks group at DigitalEquipmentCorporation. You have to understand what the Windows world was like at the time to appreciate the logic: 175 lines of boiler-plate C code just to put a darn window on the screen! A cryptic Windows 3.0 SDK and lousy tools. This was a big paradigm shift. Open up VisualBasic and hey you got a window (form) for free! Well, now I can concentrate on my actual application! This played well in MIS shops where they had back-loads of work and Joe MIS could learn VisualBasic in a day. Basic is not as brain-damaged as people think. For this kind of programmer is the easiest path and the most logical one.
I'm sure Sam will have a better reply, but I think one of VB's strengths is in the number of things you don't have to learn to start using it. When someone loads VB and starts hacking away, they don't have to learn anything about make, compilers, linkers, editors, COM, or the grizzly inner workings of WIN32s at first.
That's the ticket. This isn't aimed at UNIX heads. This was aimed at making Windows 3.0 development easier. No more SDK (make, compilers, linkers, etc). They don't have to know or care about hundreds of Windows messages and message loops. They just double-click on the window and write easy code.
I've been told that Microsoft was itself surprised at the popularity of the first versions of VisualBasic which had not been a strategic project before then. With a success on their hands they had the wisdom to follow up on it as
They weren't. It took off like a rocket. With the development of VBXs, literally thousands of shops sprung up to deliver off the shelf custom drop in controls and it just took off. I remember leading an MIS department at DigitalEquipmentCorporation and having apps that took 1-2 years to develop. We adopted a RAD philosophy with VisualBasic and cranked these out in 1-2 months each. VisualBasic was the first and best RAD tool. Delphi came along later and arguably improved on it (although why anyone would code in Pascal is beyond me). This was an exciting evolution in Windows programming - from SDK to the visual world to the component world. Then in VisualBasic 5.0, they completely re-wrote the whole product from scratch on top of the ComponentObjectModel. Since then, it has become a formidable enterprise tool, where now, in the upcoming VisualBasic .NET, all gloves are off. Threads? Sure. Pointers? Sure. Exception Handling? Sure. The tradeoff has always been how do we stop these simple programmers from shooting themselves in the foot vs. how do we give the power programmers real powerful and real stuff. On the whole, I think they balanced it well.
So well, that, in fact, there are large commercial applications written in VisualBasic. I wrote one of the three largest VisualBasic applications in the world: NewsPartner? for Windows in 1993 that is still being used on Wall Street - 64 simultaneous news wire feeds into 64 windows, natural language processing, profiling, etc. We wrote TeamLinks. There are many other examples. But the best mark is the 3 million plus corporate MIS programmers that have flocked to this and built real solutions to real problems in 1/100th the time it would have taken in C++. And if you're just trying to get data out of a database and present it visually, this is the tool.
-- sg
Ok, I should have posed my original question more carefully. I am glad to hear that MS is continuing to add power to VB (aside, does anyone else see a trend there - e.g., DX was absolute crap for the first few iterations, pretty good now, same thing with many of the MS apps). Anyways, I appreciate that a *lot* of people have done useful work in VB, many of the non or unskilled programmers. This target market is often different from c++ crowd...
So I will try and distil what parts of my curiosity have not been addressed here:
In my earlier comments, I mentioned python/perl. I didn't mean that these were options for MS at the time - just that they were examples of languages with similar core functionality (i.e., they address the no compile/test cycle, etc.) similar target (glue languages), but far more expressive power in the language. In fact I have heard claims (I have no experience in this) that python on winX has nicer COM handling than VB. I don't know how relevant this is. :)
At the time MS was looking at VB, didn't REXX [RexxLanguage] exist? (memory is fuzzy, as this is waaay out of my field). I am certain that there were many toy/academic languages that could have been used for inspiration, if not implementation. (Yes, REXX was around at this time. REXX 1.0 was released in the early 80's)
My feeling is that VB makes it harder than it needs to be to do some things, just because of the underlying language design. This is, of course, not going to be noticed by the legions of non/unskilled programmers that pick it up to do a little glue work, as they don't know any better. Please note that I am not claiming that these are the only people using VB.
My contention is that you could have all of the stated benefits of VB, with a better core language.
My question is: Why didn't this happen?
The above comment about MS all ready having a basic interpreter might very well be true, especially if the idea that they were surprised by it's success holds.
I guess my optimistic side is looking for a reason that doesn't involve marketing decisions overriding technical considerations :)
: My feeling is that VB makes it harder than it needs to be to do some things, just because of the underlying language design.
It would be nice to know what you're thinking of here. It strikes me most of what's left of Basic is just SyntacticSugar on a fairly generic late 80s programming language. The weirdest thing about VB is that it doesn't have inheritance. But that's a more recent decision as VB wasn't OO back in the day. (Most people were using C rather than C++, too.)
But seriously, given that MS would want to use something vaguely familiar to programmers, I can only imagine four possible alternatives : a kind of simplified C-like scripting language (like maybe Javascript today), a Pascal, a Cobol, or (more left-field) a kind of HyperTalk imitation. Given that casual programmers would probably be put off by C-like syntax, Pascal was very much Borland's flagship, Cobol carries more ugly baggage than Basic and that HyperTalk might not have appeared "serious" enough; and given that Basic was a flagship MS product and that it was part of MS culture; its hard to see why they would have chosen anything else. It's also hard to see that there was anything wrong with the decision. How do any of Basic's (alleged) weaknesses really get in the way of using it in the niches for which VB was intended?
-- PhilJones
Some historic perspective for a history question:
As we all know, BillGates started MicroSoft with BASIC in '76. BASIC was popular on (8-bit) personal computers available to hobbyists in the late 70's; most home computers came with some version of BASIC burned into ROM. Like... Apple II (AppleTwo), CommodorePet, Commodore 64 (CommodoreSixtyFour), and TRS-80.
In the late 70's, CP/M was popular among small businesses and do-it-yourself hobbyists. It ran on 8-bit Intel 8080 (or Zilog Z80) processors, and a fair amount of business software was available for it. Most CP/M boxes did not come with a native language (other than assembly!), but a number of languages were available, including several flavors of BASIC (MBasic from Microsoft, Cbasic from ?), FORTRAN (from Microsoft & others?), PL/M (a PL/I [PliLanguage] clone from DigitalResearch??), COBOL, Pascal, dBASE-II (& FoxBase?, etc), etc, etc, etc...
In 1981, IBM & MicroSoft introduced the IBM-PC - essentially a 16-bit replacement for the 8-bit CP/M systems. Intended for the home / hobbyist market, it used audio cassette tapes for "mass" storage, and included MicroSoft 16-bit BASIC on ROM, like most other "toy home PCs" of the time. Floppy drives (and the floppy drive controller card) were high-priced optional extras. Every copy of PC-DOS / MS-DOS sold included a DOS-aware version of MicroSoft BASIC "for free".
As the one common language available on all MS-DOS machines, I'm sure you can see how BASIC would become popular for quick and dirty utilities and simple programs. Lots of people also wrote significant business systems with it. (Would you rather that they used COBOL? ;-)
With BASIC widely proven to be easy to use and popular on MS-DOS, why wouldn't they use it for drawing screens with the Windows extensions to MS-DOS? It's not like a good BASIC IDE would prevent programmers from using C, Pascal, PowerBuilder, or any other language of their choosing.
Contributors: JeffGrigg
WhyVisualBasic? Perhaps its ease in demonstrating TheArtOfComputerProgramming. A mid 90s published book, called "The Art of Programming in VisualBasic", written for the VB3 audience in the last century, was still mentioned with fond memories a few years back. More recently, this book is listed in a 2006 MicrosoftExcel course offering, alongside with 2005 published books. There is an ethereal simplicity to the VbClassic language that is so mesmirising.
It's similar to the fondness for HyperCard, where conceptual simplicity + power + ease-of-learning are net maximized in a way that happens only once in a blue moon. I miss many of it's attributes also when futzing around with goofy web interfaces trying to make it fit the vision in an executive's head.
See also: WhatIsWrongWithTheGeneralVisualBasicApproach, CoordinateVersusNestedGui