Slashdot Mirror
Microsoft Remains Firm On Ending VB6 Support
An anonymous reader submits "CNet reports that
Microsoft is remaining firm an ending support for VB6, despite a petition
and many requests from its developer community.
If only VB were a F/OSS project instead of a proprietary customers could be assured of continued support as long as there was demand.
Are there any good F/OSS implementations of VB out there for customers to migrate to? One can only hope that enlightened groups like
the Agility Alliance would warn about the risks of using such software that can be end-of-lifed even while they're in heavy use."
I know this will get modded Troll, but if you just look at these 3 simple points, you will see the VB has a lot to offer modern programmers.
1. It is faster to develop an application in VB than any other Language
Microsoft has built in a number of wizards to make building complete application templates with a few clicks. I have built (and sold) many applications which took less than 4 hours to develop - these include a webbrowser, email client, contacts database, file searching tools and a image viewer.
If I had tried to do this in C, C++, or even java it would have taken weeks.
2. Visual Basic is more secure as a language
There are NO pointers to worry about and all low level stuff is handled by the windows VBRUN.DLL's. This makes VB applications MORE secure than any other application, because it is physically impossible to get buffer overruns (the cause of 98% of all security problems)
3. You earn more money using VB
Face it - as much as we all like using Linux, there simply are not that many jobs available for C/Linux coders. Most of the jobs are for large corps or government and they almost always go with Visual Basic for the client and Java for the servers.
You shouldnt ignore Visual Basic as a language, and it definitely doesnt make VB coders any less skilled than C coders - if anything, I think we are a little stronger, as we have the courage to admit that we like this 'toy language'
From the petition against Microsoft's decision:
"By providing a new version of a COM-based Visual Basic within the Visual Studio IDE, Microsoft will help maintain the value of its clients' existing code, demonstrate its ongoing commitment to the core Visual Basic language, and greatly simplify the adoption of VB.NET by those that wish to do so."
Supposedly the beefing up of VB was in response to the industrial capabilities of Java. Ironically, if MS alienates enough developer partners by cutting of support for VB 6, those folks may end up heading toward Sun or IBM anyway.
I Want To Believe
MSFT has VBA (VB for Applications) that is being used by many people that I know (Word Processing, Spread Sheets, Geographic Information System, etc). Does the decision to stop supporting VB6 impact VBA?
S
If Microsoft wants to appear serious about having customers develop decent code, pulling them off VB 6 is a good start.
A person becomes a good programmer through education and lots of experience. A good programmer can write good code in virtually any language. (Conversely, a weak programmer can write Visual Basic code in any language.) This cry for "keep our precious VB6" sounds suspiciously like the whining "because C is too hard!"
There is still one valid reason for keeping it alive, however. Many people are still writing code for legacy hardware that isn't capable of running the .NET framework. And to that end, Microsoft's decisions should not automatically mean an increase in Intel's stock price. But wanting Visual Basic to last forever simply because they don't want to learn a better language is not going to gain my sympathy.
John
Many moons ago, I got called in to put out fires in a project that had a DOS based computer in part of the feedback loop of an industrial cutting machine. If the feedback wasn't fast enough the loop would open and things would break.
The software was written in QBASIC, which had just recently come out. I needed double precision (32 bit) integers for the control loop. QBASIC had this type built-in. Problem was that when I switched to 32 bit integers the program ran about 1,000 times slower and things in the real world got broken.
I couldn't figure it out. After carefully checking and re-checking my code, I did an assembly level debug. Turns out the brainiac billionaires at Microsoft had decided to "save" about 10 minutes of programming time by using floating point double precision for all their 32 bit calculations, even though 32 bit add and subtract were either already part of the machine language instruction set or took just two or three instructions at worst case. Instead, for every math operation the 32 bit values were converted to double precision floats, the calculation was done in floating point and then the answer was converted back to 32 bits. To make matters worse, the hardware didn't have a floating point co-proccessor (because the designer knew that no floating point calculations were needed) so all the floating point stuff was done in software emulation. Of course, there wasn't a word or a warning about this in any of the manuals.
Once I figured out the problem (morons had written the 32 bit integer support) I was able to write my own 32 bit routines in QBASIC that were 100's of times faster than Microsoft's built in routines, even without dipping down into assembly and taking advantage of the carry flag.
Quick Basic indeed! If it were any quicker it would be running backwards.
We don't see the world as it is, we see it as we are.
-- Anais Nin
I know that the parent _must_ be a joke, but I must indulge! ;-)
.NET) all to be SIGNED. This doesn't matter if you're only using integers for (bitwise AND/OR/XOR/NOT) binary operators, but for alot of other instances, I'm sure you can think of several, UNSIGNED integers would be nice biggrin.gif. ... End If with a signed integer. ... } with an unsigned integer
1. VB has the option to enable or disable automatic integer overflows and array index bound checking. In some instances it might seem like a good thing to have these turned on, however, you don't always need to. Lets say for instance, it's all internal, meaning, you know the size of your array, pretty static environment, but it auto checks all this for you. That right there is 'OVERHEAD'! Because in a client for something, you might need to check these things, you might not, but better to check them manually than to needlessly do so automatically for instances when it's not necessary.
2. VB forces a function to be Public (Program Wide) inorder to multi-thread it or even point to it (what limited pointer access VB does have). In C++ I can point to any function, sub routine, public/private/protected/virtual/static/extern, YOU NAME IT! Obviously you can't retrieve the location in RAM to something private from outside of a class without a property, but atleast I can point to a function within a class in C/C++!
3. Along the lines of #2, since VB only supports 'AddressOf' pointing to a function in the rare chance an API might use it, you can't use 'AddressOf' in your own code to 'CALLBACK' to a Sub/Function of your own program (keeping in mind 'AddressOf' only works on 'Module Public' Subs/Functions). There's indirect ways to 'CALLBACK' to a VB sub/function (SetWindowLong) and filtering wMsg(s) sent to that window. However, that requires API, and C/C++ supports 'CALLBACK's natively!
4. VB forces all integers (however many bytes they are 1, 2, 4, possibly even 8 byte integers in
Example: Instead of saying If x 400 Then
I could simply do: if (x > 400) {
How/Why? Simple, normally the binary form of a negative number is 0x80 - 0xFF, or 0x8000 - 0xFFFF, or 0x80000000 - 0xFFFFFFFF. So when the number isn't signed, it's actually alot greater than the highest possible signed positive value.
Example: signed 1 byte integer -128 50 rather than if x 50. Yes I'm aware you can toggle that sign bit, however, why bother if you don't have to in a better language blink.gif?
Since C/C++ don't have built in bound checking on arrays, unsigned counters are very handy! If the lowest value is 0, and all arrays start with index 0, you can 'safely' assume the minimum bound index is 0, thus, you don't have to check your counter for being 'less than 0'. You only have to check 1 bound, the maximum, so your counter doesn't request an index 'out of bounds'.
5. One thing I like about C/C++ is I can define a constant array, even by a custom struct or "User Defined Type" for you VB people. In VB the best you can do is make a string with a delimitive value like a comma "1,2,3,4,5" and once the program starts Split() it tongue.gif.
FireBot mentioned you can use resources in VB! True, that you can, but you still have to use API to retrieve from a resource, and this is all about using only 'standalone' functionality of the languages (I know there are VB functions that retrieve resource information, but even they boil down to API).
6. With C/C++ I can actually use REAL STRINGS! I have a choice of Unicode (2 bytes per character) or ANSI (1 byte per character). In VB it's strictly Unicode, and you have to use this annoying conversion method built into VB to convert Unicode into a "Byte Array". Can we say 'OVERHEAD' yet?
7. There's several APIs VB cannot use, because it'll crash the VB IDE, such as Create Thread. Even if you follow the specs on using it, proper use still crashes the VB IDE...