Why Choose Microsoft And Vb
Why Choose Microsoft And VbWhy are people choosing MicroSoft and Vb to develop software rather than, say, Java or some other better approach?
I think the VisualBasic discussions below apply to VbClassic only. Very few people actually get to develop applications using VbDotNet, which is a different animal.
Perhaps because most managers slavishly worship all things MS, and are unwilling to consider alternatives. Convincing managers that their religion is false is about the smallest amount of fun you can have. While good for customizing many standard applications, including SiteServer and the ubiquitous Office suite, VB as a language and as an IDE has serious pitfalls that make it a poor choice for larger developments. Microsoft's marketing-oriented development strategy focuses on new versions with more checkbox features rather than fixing the ThingsWeHateAboutVbClassic, and often seems to introduce as many new bugs as it cures old ones. -- PeterMerel
Unpleasantness not included
Sam, I've haven't flamed you or anyone here, despite what I perceive as a series of direct attacks from you. I think we have similar levels of technical expertise, I respect your technical opinion, and I'm very interested in why our experiences differ so greatly here. I continue to hope that whatever it is that has resulted in our arguing will play itself out, and that we will resume a constructive dialog.
In order to facilitate this, I've chopped out the unpleasantness we've been having and have mailed you a copy; I don't believe very much of what we've had to say for the past week could possibly interest anyone else, but if you'd like to reinstate any of it here please do. I've also toned down the color, if not the substance, of my part of the rant.
I hope you'll refute my admittedly contentious statement by exhibiting the clear reasoning and excellent engineering knowledge I've seen from you on other pages. Workarounds for the ThingsWeHateAboutVbClassic (less than 1/4 of them from me) will be a great way to focus the conversation on something constructive. More concrete explanation of your motherhood statements on ThingsWeLoveAboutVbClassic would be very interesting too. -- PeterMerel.
I've found that MS tools are great for the basic business applications that Microsoft wants people to write. Since the vast majority of programmers are writing applications for which Microsoft has a prescribed solution the tools do quite well in the market and do in fact serve their intended audience quite well. They aren't terribly amenable to really creative work, very large projects or the development of new technologies. In particular, they seem to scrupulously avoid creating or supporting generalized, reusable, abstractions. So, in summary, MS tools aren't fun but they do have a good return on investment for a wide range of common problems. -- PhilGoodwin
It is extremely impressive to see business users getting good use from very simple VB scripts. This works because MS have given good COM access to all their office toolset, and VB is wonderful glue for unskilled people. Certainly a far better tool for these people and this purpose than any other language with the exception of Python.''
On the other hand, VB has so many gotchas and unnecessary asymmetries, and its IDE is so clumsy and buggy, it's hard for me to understand why anyone in their right mind would use it. If MS weren't pushing VB then one or another simple language, maybe even one of the other BASICs, maybe something more like TCL, Python or SmallTalk, would have filled its niche. Or MS would have been forced by the market to clean the thing up.
There are many kinds of business applications where VB is perfect for the job. Why take weeks to do something in C++ (or Java) that can be done in hours or days in VB? I still use VB in limited circumstances where it is the right tool. And it is the most widely used language in the world next to Cobol, with over 3 million users. In terms of your comments on the IDE, I find it the opposite of wretched and buggy and so do apparently millions of Microsoft tool users because Microsoft has switched VC++, VJ++, Visual InterDev? to use the same IDE and people love it. The IntelliSense stuff is great. It recognizes an object as I type it and offers me a drop down list of it's methods. It fills in syntax for me. I am far more productive in this environment. I don't know how you can compare it to command line tools and think they are more productive.
-- sg
I don't think that GUI IDEs really make me any faster ... in fact, I tend to spend more time making things line up than I should. But I really do like the IntelliSense feature. I give VB one point over PINE or EMACS for that. You might look at emacs' M-/ command...
I'm not comparing IDEs with CLIs - that's a StrawMan. On the IDE, I'm closely following you on ThingsWeHateAboutVbClassic. I've used a lot of IDE's over the years, and find VB's unremarkable where it's not broken. Its resemblance to the excellent VC++ IDE is superficial. Where it does compete fairly with others - in VJ++ - it's not a contender against VisualAge. In my experience, people do not love the VB IDE, but curse at it because it's unstable and scales poorly with a large amount of source. That goes for InterDev? too.
For simple GUI stuff and MS-Office adaptors, VB is a good tool. It's where MS overextend VB by using it for enterprise apps I'm very nonplussed. -- PeterMerel
Re: They aren't terribly amenable to really creative work, very large projects or the development of new technologies. In particular, they seem to scrupulously avoid creating or supporting generalized, reusable, abstractions.
Sounds like a DomainPissingMatch to me. Many in other domains spend a lot of time reinventing things like database-like tools or roll their own GUI systems and call that "creative". I would like to see a better definition or examples of "creative". There are not a whole lot of truly original ideas out there. Also, the business domain tends not to be very conducive to "reuse" in my observation. Business rules tend to be very specific to the application. Further, they are often driven by individual personalities, such as high-level managers or marketing experiments. Reuse seems to be easier in domains that have some physical modeling component.
As much as I dislike VB in some regards, the thing that made it a revolutionary product when it came out (and Delphi copied it) was bringing RAD to Windows.
DelphiLanguage was always the superior tool. To suggest otherwise is unfair. VB simply outmarketed DelphiLanguage.
Prior to VB, one had to write a 175 line C program just to put up a window. Windows programming to the SDK was nearly impossible. MFC/C++ cut down very little of the complexity. VB allowed the average MIS people to write Windows apps in an afternoon. I know. We cut a three year backlog in MIS at Digital when I worked there by switching to VB and Client/Server and churning out good apps. And I definitely argue that you can write VERY serious real apps in VB. I wrote one. It is one of the 5 largest VB apps in the world. It is still being used at Wall Street brokerages. It takes in news feeds from 64 news feeds, allows display of headlines from any one of them (can have 64 windows up), does Natural Language Searching (all stories on "Better than expected earnings" done with antonyms and synonyms and it returns all stories also with "likely", "potentia"), real-time profiling (give me all stories on Microsoft or MSFT) when they come in and much more. This was all done in VB. We made lots of money on it. And lots of people did real-time business with it. So I completely refute the assertions above.
All that being said, I'd rather code in Java any day for most work but VB has its place.
-- sg
I think that you hit the RAD thing right on the head. But wouldn't the Natural Language stuff have been way easier in virtually any other language? VB's string parsing capabilities are abysmal and its support for abstraction is so weak that it seems like it would be very difficult to build up anything that was significantly better while also being reliable. Your accomplishment sounds all the more impressive to me because you did it in VB not in spite of it. Are you saying that VB has a bad rap and that it made your life easier? Could you have done the same project in Java? Would it have been easier? I don't know whether you can expose Perl code as COM objects but wouldn't that have made your life considerably easier? -- pg
Yes, it made my life much easier because I could concentrate on the business logic and not the software language. I could move fast. I could give them an outstanding looking UI because the market for drop-in OLE Controls is in the thousands and I could pick best of breed visual components. VB does have a bad rap. It is perfect for certain apps such as client/server front-ends taking to databases. No, I couldn't do the same project in Java because Java didn't exist then -)). But if it did, the look would have sucked with the Awful Windows Toolkit (AWT) and my customers wouldn't have liked it. With Swing, there is now a chance to make an application that looks like a real app. Why would Perl have made my life easier? I can't understand that language at all despite numerous attempts to learn it. It doesn't fit the way I do software anyway.
-- sg
You can expose Perl and Python as COM objects. Python COM facilities are in fact superior to VB ones; you can free-thread a Python COM server, and you can't free-thread a VB one. This is true in ComPlus too. Sam is right on about the improvement over Win16 C programming, but I agree again with Phil about big VB systems. A very impressive use of a very unimpressive tool, big VB goes in my book next to pole-sitting and dance-marathons. -- PeterMerel
A more prosaic reason why people choose VB is that VB developers are more widely available than Java (or other) programmers, and cheaper. Once the system is finished and the A-team has walked away, you can easily find others to come in and support the system.
The other important reason is that if a company has made a strategic commitment to Microsoft - NT, MTS, SQL Server, IIS, Office, etc. - then you have an environment into which VB fits very naturally. Perhaps individually a lot of these tools are quite poor, but once you begin working against a backdrop of these technologies VB makes some sense. Not least because you have a single source of information, training, and bug fixes.
I completely agree that VB has some very serious limitations, but you can still produce good software. There are certainly a wide range of applications you probably wouldn't choose to write in VB, but these aren't the applications most companies are interested in.
We have two very similar clients. Both are Windows NT/Office, Unix/Oracle, CICS/Cobol environments. A couple of years ago, both decided they needed to move more towards client-server for applications development. After much soul searching, one chose a Microsoft route and one chose a Corba/Delphi route. The client who chose Microsoft is still pretty happy with their decision and still aggressively following all things Microsoft. The client who chose Corba/Delphi found it too hard and seems to have given up on that strategy. They have a new team just starting a biggish Oracle Forms project.
I don't think Java is on the radar for either of these companies - should they be on the JavaBandwagon?
Good points. A reasonable view. Yes, Java should be on their radar because it is finally getting real.
-- sd
A couple of years ago (early 1998), the client-server strategy of Borland/Delphi was rather unclear even to many supporters of Delphi. Delphi has improved greatly, but doesn't really have a really strong record in that area. Still, one is much more likely to find Delphi developers with years of ActiveX/COM experience than TCL/Python/Perl programmers with similar experience in Microsoft's frameworks.
I use MSVC at work, and I currently wouldn't use anything else - for the kind of work we're doing. We make good use of the DevStudio? IDE, and SourceSafe, to manage the five to six hundred source files and so on, and "Edit and Continue" is a useful trick I haven't (yet) seen in any other C/C++ product. Because a videogame is a full-screen, fast-moving thing with a heavily customized UI, we don't generally need to go near MFC or the UI side of the Win32 API, thankfully. DirectX and the various other Microsoft-proprietary tools we're kinda pressganged into using (because they have support from hardware manufacturers) work with it, as you'd expect, and it doesn't crash too often, comparatively speaking. I don't like it, and wouldn't call it best of breed, but it's the LeastEvilThingToUse? right now, which is... similar... :}
On the other hand, when I occasionally need to write "support tools" - say, a quick app to let a level designer visually lay out the order in which the player must complete missions - the sort of task people might use VB for - I turn to DelphiLanguage or BorlandCppBuilder?. Despite using Microsoft stuff throughout the rest of the process, I still wouldn't touch VB or VC++/MFC for doing "Windowsy Apps".
It's not that you can't write good code in them, but wouldn't you rather use a tool that says, "You want to write clean code? A worthy goal! Here, I have these fine tools to aid you!" rather than one that says, "You want to write clean code? You must fight me every step of the way, foolish mortal! You must jump through these Klein-space hoops because of our need to maintain backward compatibility with our previous products that didn't support the features you want!"?
I'm not sure why people use VB, actually. I mean, for quick, simple stuff, Delphi / BC++B provide the same RapidApplicationDevelopment tools, but with a RealLanguage.
I don't want to seem like I'm harping on about Borland's stuff, but it just confuses me. Apart from the "it's made by Microsoft" factor, what UniqueSellingPoints? does VB have that would cause people to use it?
-- CanisLupus
For novice users, a GUI builder and wizards. It's also definitely a Windows program. I haven't seen a Perl or Python set up that's as good as VB at allowing a non-expert to get a GUI up and running.
The syntax is a bit more approachable than Perl, too (and I write as a Perl fan).
-- PaulHudson
This just seems to perpetuate the myth that Vb is good for newbies (See VbIsBadForNewbies)... I haven't seen Windows-based, not-still-in-alpha GUI builder stuff for Perl or Python, but then I haven't been looking for any either, so that doesn't prove anything. But regardless of that, the Borland products (and, from what I've heard, VisualAge) also have GUI builders and wizards. In fact advanced users can write their own Wizards that plug into the IDE, then distribute them for newbies to use (although there's a limit to how much they can do, from my rather brief scan of the relevant docs). So my question still stands. -- CanisLupus
The Borland products and VisualAge are not designed for newbies.
VB is designed for lesser-skilled developers, and it meets their needs very well. RAD is great, and the syntax is easy.
Pascal, Perl and Python are much more complicated than BASIC.
-- EricUlevik
Python is more complicated than Basic? In what way?
You have to get the formatting right or it doesn't work. Syntax is tricky for beginners.
Python requires the beginner to learn to indent blocks. I haven't yet seen a beginner stumble on this, but perhaps my experience is unusual. Seems like what we need to do is drop the toing and froing and try to find us some beginners to experiment on. Any academics out there interested in trying this on their subjects^H^H^H^H^H^H^H^Hstudents?
Here's the full context (from http://www2.linuxjournal.com/articles/conversations/006B.html)
You already see them. This is why Visual Basic was so hugely successful - not because it was a good medium for programming, because it's not. Don't get me wrong, I like Visual Basic, really, and I think it is one of the best successes Microsoft has had. That was because it was a ...
I find that the more I read Linus's comments everywhere, the more I lose respect for him and his knowledge (or lack thereof). He is trying to compare VB to the IDEs on Linux??? Please, I've used Linux since 1993 and what few IDEs it has suck completely and are not even in the same league as a tool like VB.
-- sg
Linus may not have tried to make that comparison. Instead, it seems he was saying VB is "a really good medium for customization", and "a great medium to the front ends for the real work". Even (parts of) Microsoft sometimes say that VC++ is the better medium for writing the "real" components.
It would be fair to say that graphical IDEs and even GUIs in general are not very important to the Linux *kernel* developers such as Linus. There are a large number of (server-oriented) uses for Linux in which a GUI is not really necessary. GUI development has been left to other groups, which started their efforts much later than the core "linux" effort.
GUI development on Linux as of late 1999 is often more primitive than similar efforts on Windows platforms, but the lead is narrowing quickly. In the last year many companies have been working to port their environments to Linux - even Borland has announced a major commitment to Linux development tools. At this time (late 1999) people looking for an environment like VB are unlikely to be satisfied by any of the current offerings in Linux.
Even if VB is bad for "programming" (which is not proven), it may be useful for "getting the work done". Not all problems require programming solutions. Sometimes, most of the problem has been solved with pre-written components, and only a little customization work is necessary.
One of the largest advances of RapidApplicationDevelopment IDEs like VB and Delphi is the "form" model of GUI programming. The programmer in VB or Delphi *rarely* needs to do *any* GUI-related "programming". Instead, one manipulates GUI elements much like one moves figures in a CAD program, while the IDE creates the GUI code. Unlike many Unix IDEs (and earlier versions of VC++), the form editors are not just one-time wizards, but allow useful modification and reuse of GUI forms. (The latest Delphi release even allows a kind of form inheritance.) Another advantage of many RAD environments is strong support for "data-bound" controls which have a rich set of default behavior.
To some people, these kinds of improvements are more important than other features of more "conventional" languages/environments. Other people's needs will vary.
I feel over emphasis on GUI programming can be harmful. It focuses too often only on the user interface and not necessarily on the actual information problem behind the GUI (I am reminded of the old IBM commercial where the web monkey says he can do a website with flames on it, but when asked about total business integration gets a blank look on his face). As an example, we have spent the last several weeks trying to design just a data model that will allow for extremely flexible periodic and umm... for lack of a better term, semi-periodic task scheduling (scheduling may vary depending on environmental factors and the regulatory or legal bodies involved, and we are unsure what may be thrown at us in the near future as the clients and agencies are making it up as they go along). We have revamped the data model several times and modifying the GUI was trivial. The point being that just because you have a GUI, does not mean you have a solution. In addition the presence of a GUI may lull the user into believing you actually do have a solution. BTW, .Net has forms inheritance but it is so cumbersome to use at this point we have not found a compelling reason to use it, by the time you get done overriding everything you needed it would have been faster to write a new form from scratch. YMMV. --pjl
I've seen a bunch of projects where non-programmers are given a few months of training in VB and put to work. The projects eventually deliver, and do not seem to be more likely to be over budget than other projects. These tend to be huge projects, developing huge programs that I would think could be done in 5% of the size if done properly. Nevertheless, the management is happy.
This seems to me to put the lie to claims that VB is not good for beginners. Over and over I see evidence that managers like it because they can hire anybody, pay them little, have them learn VB, and use them to get a project done. Does anybody have any evidence that the rate of failure of VB projects is any higher than the rate of failure of projects using other languages? -- RalphJohnson
From what I've seen, VB gets chosen because the project is dependent on some MS technology, is under a management-induced tight schedule, and there is already some sample code or component out there to do sort [some?] of what needs to be done on the project. So something gets thrown together to FakeItConvincingly and build DeadlyGuiPrototypes to meet the deadline. Then you get to the "This isn't the real one" and WeWillCleanItUpLater stage and wheee VB is suddenly your legacy infrastructure.
-- StevenNewton
Well, that's one point of view. I don't want to get pulled down in this argument again (I just filled in the stuff by request) but the above is not entirely the correct picture. There are a lot of people who use VisualBasic to create ComponentObjectModel components for their business logic in Windows DNA applications and N-Tier applications. Through the use of ADO for instance, it is easy to create data access components.
-- sg
See VbIsBadForNewbies, VbTeachesBadHabits, http://msdn.microsoft.com/vbasic/default.asp
VB bad reputation has arisen primarily because of its ease of use. New developers with very little programming experience create applications, which fulfill business needs, without a thought to good programming practices. I see this every day and with every new system I am asked to support. RAD is its own worst enemy and VB was build with RAD in mind.
-- LBK
The problem is that nobody agrees on what are "good programming practices". Managers often see dogmatic people fail to deliver and give a poor sales job of why it is allegedly "better reuse", "better abstraction", etc. Most experienced IT managers have been burnt by dogmatic people before. However, everyone agrees that getting something out the door fast is a good thing. Thus, when choosing between hot air on elusive reuse claims, and between the here and now delivery, they go with delivery. I am not saying that all abstraction/reuse claims are wrong, but simply tough for managers to verify. Further, the high-and-mighty claimants often use their techniques as job security. It requires a more expensive person to figure out the tangled abstractions. If you want to sell an idea or language to a manager or team leader, then use code examples with realistic change impact scenarios, not verbal doctrine.
EditText of this page
(last edited February 2, 2009)
or FindPage with title or text search