One of the things everyone loves about Visual Basic is just how easy it is to get an application up and running literally in minutes. MS has done their best to have prebuilt objects controls that do everything from stick a web browser in your app to create a data report to show a progress bar to run a timer.
Because of these ready-made components, people love to prototype applications in Visual Basic. The IDE is such that you can practically drag and drop your way to something every bit good enough to show off to the boss. Heck, there's an "application wizard" where simply clicking "Next" until you're able to click "FInish" gives you a feature complete copy of WordPad. What's neat is how many times people make a prototype in VB, then decide simply to add a few features that actually require programming, and call it a finished product.
This isn't always bad. When it involves things like the MS Internet Control, this quick turnaround time can be good. I've always likened VB to the glue between real applications. When your app is basically marshalling parameters between apps, VB is absolutely perfect.
When someone is using the Data Report or a data-bound field (textbox, combo box, etc), it isn't. Why? Quite simply, it's tough to customize one of these "make an app in seconds" controls that MS likes to dole out. Same story when you try to customize a control you bought from a commercial vendor for use in your VB app. To save time and money and to get in on deadline, VB programmers often succumb to settling for MS-level functionality in lieu of the extra programming required to add the desired functionality that would require that they start from scratch.
How does this effect web programming? Well, with ASP.NET, those "prototypes" are going to come to the web. VB.NET and ASP.NET allow people to essentially code in VB or C# (a great language in and of itself) and the IDE can make the pages for "uplevel" (read: IE) and "downlevel" (read: not IE) browsers for you. You create something called a "Windows Form" using .NET controls (like the datagrid) in an IDE very similiar to the VB 6 IDE. The MS magic does the rest.
I don't think anyone's going to say assembler is a better programming language than C when it comes to getting today's tasks done, but I do think this attempt to simplify can go too far. I doubt you'll find a single programmer who knows both C and machine langauge think that it hasn't been to his/her advantage. I think the VB IDE can lull people to the point that they're never curious to learn what's underneath. When what you're not learning is, say, SQL when you're creating data reports (versus bytecodes when coding C), I think this has to be a negative.
It's not that a good programmer can't program everything from scratch in .NET, it's just that people think testing in IE's good enough* might be a little more prevalent in your web world than they've even been before. And I think MS is going to push this "IE-first, and IE-only's good enough" approach in much the same fashion that they push VB today. Coding for IE-only will give the ASP.NET on the web the same "advantages" VB has over C++ in the client-side today. Why worry about losing 1% of your potential customer base when you could've made a wholly new application in the time it'd take to reach 99%?
(*) "They can just go to Windows Update and get the latest version if the page doesn't work, right?" -- which brings up an interesting question -- guess what the page looks like if you visit using IE 5.1 on Mac OS X? :^D
posted by ruffin
at 11/12/2001 06:48:00 PM