Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

VB gurus no like VB.Net 2

Status
Not open for further replies.

SpiderBear6

Programmer
Sep 17, 2003
422
AU
I recently read an article which was discussing "the extreme lack of interest by experienced VB developers for VB.NET". It goes on to say...

"My concern is that VB.NET is failing. This worries me greatly, because I'm one of the many programmers who have built a successful career largely on programming in Visual Basic. Because VB.NET is the future of Visual Basic, if VB.NET fails, so will Visual Basic. If Visual Basic fails, so will the careers of many VB programmers."

I don't agree with this, cause VB and VB.Net while yes syntaxically they are very similar, they are miles apart in functionality.

And further, it says...

"VB6 is already a RAD language. VB.NET does not significantly improve on this."

Vb.Net may not vastly improve on this sure (there as some new nice points about it), but surely you can't say that there is no point moving to Vb.Net because of this.

"VB6 is far easier to learn than VB.NET. This is primarily because VB.NET is so object-oriented that the numerous VB programmers with hobbyist or power-user backgrounds have considerable trouble learning it."

Sure Vb.Net is so object-oriented, but that's a good thing. It would probably do the "hobbyist or power-user" good to start learning to program this way. Their programs may not be as buggy and hopefully they would stop putting all of the code (business logic and all) in the forms.

"VB6 has better performance. After two years, I've concluded that VB.NET programs don't perform any better once they've started up and they take far longer to start up than VB6 programs."

This is an interesting point. One of the main claim to fames of Vb.Net (and the .net languages) is that they perform better. The Just-In-Time compile is a pain because it can take a while (only the first time) but that's what the users remember and forever brand it a slow app.

"In addition, VB.NET programs require a far more powerful PC than do VB6 programs just to run at all."

This I agree with, but it will be good when the new versions of Windows come out because they will include the .net framework.

"VB.NET is so large that a working programmer does not have the time to learn it."

I don't agree with this... I don't think VB.Net is that hard to learn once you grasp a few basic concepts. So this also means that a working programmer should forget about ever learning something new because it may take them a while? If that were the case, we would all still be writing COBOL.

"VB.NET is missing some critical components, such as a decent grid, a masked edit control, and so on."

What's wrong with the datagrid? It's not bad once you get used to it. The built in controls are far better than those of VB6. There are standard third party controls I always get when I use VB6 - TrueDBGrid being one of them.

"The overwhelming memory requirements of the .NET Framework make it impractical to use the VB6 ActiveX components because that would just increase the already large memory requirement."

So use .Net components.

"The considerable system requirements of .NET programs are a stumbling block in its adoption.
The advantages added to VB.NET mainly help advanced programmers. For example, inheritance is not useful to the many VB programmers who are unacquainted with object-oriented programming and don't write classes. Ending DLL Hell is useless to a programmer who has never written a DLL in VB."


This letter appears to be written by a VB programmer who has never written a class module in his life.

"VB.NET is not the language VB programmers wanted. It is the language that C++ programmers felt VB should be."

It's closer to the language I wanted, than VB6 is and I am a VB programmer.

Do other people share this view? I have been a VB programmer for years and have only just moved over to Vb.Net - am part way through my MCAD. I still write programs in VB 6 though.

Anyone like to share their views?

The whole letter can be read at:


:)
 
You get this regardless of the platform. There will always be people who see new releases as an unneccessary waste of their time. Just as there will always be people who launch headlong into the new functionality without care or concern for any backwards compatibility issues that may arise (me puts hand up and looks sheepish)

Not being a VB or VB.NET developer (although I did write an ActiveX control once) I can't give any insight into the particular details. But having been a Domino developer since R3 (now R6) I've seen a lot of changes, a lot of people objecting to said changes and a lot of those people eventually coming around. It's new and different, therefore - for whatever reasons - some people will act a little xenophobic towards it. Give them time.

[sub]Never be afraid to share your dreams with the world.
There's nothing the world loves more than the taste of really sweet dreams.
[/sub]
 
Thanks for your comments, dwarfthrower. I guess you will always get people who are resistant to change... even change for the better.
 
Not being a Poweruser or a hobbyist but someone who writes apps that make doing aspects of my job easier and faster I really can't speak to the comparisons of VB6 and VB.NET. But having been a user of many VB6 apps I do see where VB.NET has improved.

1) MultiThreading - VB6 from my understanding didn't allow or made multi-threading extremely difficult. VB.NET has multithreading and it is a snap to use, Even I have written so me multithreaded apps.

2) Yes .NET isn't everything that VB programmers wanted nor is it everything C++ programmers wanted. VB.NET is more of a compromise between what VB.NET programmers wanted and what could be delivered.

3) .NET bring more functionality to web apps than was possible through asp. The codebehind in asp.net pages brings some of the samepower and flexibility to webapps that typically was only available through desktop clients. With many more companies moving to zero footprint web apps this makes it possible to do more, and more easily do things through the web.

4) XML - with more and more applications moving to the use of webservices and xml .net makes the use of XML and XML transforms somewhat simple.

5) .Net apps require more system resources. This is the way of computing. I don't know many applications written today that would work on a system 6-8 years old. If they did they probably push the capabilities of the machine. The relationship between software and hardware has helped each other as faster hardware becomes more affordable companies write software to make use of these systems which in turn causes hardware to become faster. How many people 5 years ago would have thought you could get a home PC 3GHZ machine with 1GB of ram for 2K. How many people thought they would ever use this much power.

6) .NET is not hard in my opinion for beginers to learn nor is it difficult for power VB users to learn. I have seen asp programmers easily adopt to VB.NET as well as VB6 users embrace the new capabilities of VB.NET.

The original article sounds like it was written by someone who is unwilling or unable to move forward with technology. Technology changes and if we as engineers and developers can't change with technology then we get left behind. .NET is not anything that someone willing to put forth some time and effort won't be able to grasp.


"Shoot Me! Shoot Me NOW!!!"
- Daffy Duck
 
Just my own commentary since I had to learn VB.Net and C#.Net recently.

I hated working with VB6 with a passion unrivalled by the hottest firey depths of ....

The components had inconsistent properties, the OO was a hack, DLL Hell, the fact that the GUI was really just a text file instead of code, and it was slow despite being compiled.

Then we look at VB.Net.

Yes it is a memory resource hog, an empty VB.Net form on my system eats up about 14,000k of the memory to have it open. But then, .Net apps are not compiled machine code, they are interpreted. For example, Python eats 10-14,000k for a form (using the tKinter library), a Java example I threw together uses a comparable amount (I think around 12,000k but don't quote me).

Slow? Maybe if we were running it on our P2 333, the last machine I had that Java ran slow on. But VB6 ran slow on it too.

But then it has it's strengths.
Consistency. toString(), text, array indices, and on and on.
OO that handles everything except multiple inheritance, which I can live with.
A better IDE :p
Threading.ThreadPool.QueueUserWorkItem - it doesn't get much easier than that :)

The arguments from the letter above sound a great deal like the early arguments when the field started going OO. Why bother, needless waste, we don't need this stuff it will just confuse people.

About my only complaint concerning VB.Net is that they created these things called datasets that work like hacks. I recently had to remove them from a piece of code because I spent three days rewriting all the threading, all of the synchronization, everything, only to find out that the dataset would still burp and spit out duplicates just in a straight loop with no threading etc. But thats ok, shaved a lot of memory and file access times off by going straight XMLDOM.


Anyways, just my thoughts. I hated VB6 but actually like VB.Net. Though I can see myself spending some more time shortly getting into C#. I just wish someone would get around to rewriting Python.Net...

-T

[sub]01000111 01101111 01110100 00100000 01000011 01101111 01100110 01100110 01100101 01100101 00111111[/sub]
The never-completed website:
 
I think there are really two different factors at work that keep so many VB programmers from moving to VB.Net.

One is that there are so many very bad VB programmers out there to start with. The language is highly accessible to users, with a low learning curve to getting some sort of results at all - mostly simple form-automation and little more, which is all that is needed to make Access-like applications. To go beyond this there is a wealth of code samples to crib from, and this is how many make their move to things beyond those little form-apps.

The other is that it appears very clear to me that VB.Net was developed by C heads at Microsoft, who started with the CLR and IL and "sorta, kinda" reverse-engineered it back into a very VB-like syntax. Whenever they got stuck trying to figure our how to convert a low-level feature in VB syntax, they punted, falling back on something like what they'd already developed as C# syntax or what felt comfortable or natural to them. The result being abominations such as .toString() and so on along with major structural changes to the object models of the various widgets a programmer manipulates in VB.

Both of these things mean the masses of VB5/6 programmers are having a tough time making "the jump to light-speed."

This feeds on itself. Since a lot of VBers "program" by stitching together example code fragements, they're stumped until a wealth of useful fragments are there to exploit. Since so many are sitting on the sidelines, very few fragments are being published (compared to earlier VB incarnations).

My point is not to denigrate VB programmers as a class. I'm simply stating that its relative accessibility (compared to C/C++/C# or Delphi, or ...) means there are a LOT of VB5/6 programmers, but many of them are relatively inexpert.

You can see this same phenomenon exaggerated when you look at scripting languages. VBScript is about twice as bad as VB in this regard, and JScript/JavaScript programmers as a crowd are many times worse than that. Just check out the respective forums here and form your own opinions.

There are weak practitioners in any programming language. The disadvantage (advantage?) VB and other low-cost-of-entry languages have in this regard though is just that low cost of entry.

Add to this the almost entirely unwarrranted "makeover" of language syntax in VB.Net (no, I am not talking about zero-based arrays - that's been the default in VB for years anyway) and you have quite a roadblock to adoption.

And .Net performance certainly does stink. It is akin to Java in this regard, and in my benchmarks VB performed better back when it was interpreted than VB.Net does under the CLR. But that's just the cost of doing business today, .Net is here to stay for awhile.

Between idiocies like XML and going back to intepreters, well I hope the fad passes before I retire. Long live binary code and binary data!

;-)
 
I read the original article too, and I agree with all the comments made so far.

Yes, it's hard to learn, but MS has done a good job with their compatability namespace, and many existing VB programs can run unchanged. By the same token, there are many many badly-written VB programs out there that will need to be rewritten.

By far, the biggest learning curve is the .NET framework. From what I've seen in the VB.NET forum here, the majority of the new users should crack a book or two and learn the framework. I've found that almost everything I've needed to do as a programmer has been available in the framework in one fashion or another. So many questions that could have been answered by a perusal of the docs (but an answer of "RTFM" is considered rude!)

The interesting thing to watch will be the MS-Office developers. The next version gets launched at the end of October, and will feature heavy use of XML, WebServices, and .NET. I can hear the screams now...

Chip H.


If you want to get the best response to a question, please check out FAQ222-2244 first
 
You're sending chills down my spine.

I'm a VB6 programmer who just convinced his boss to buy the MS Visual Studio .NET, primarily because I've heard that the C++ editor was the best, and we need to write plug-ins for a plant control system in C++.

I'm a little ticked because from reading and from hearsay I've heard that .NET was like freaking cheesecake compared to stale toast, and now you guys are telling me that it's even slower and a bigger resource hog?

Where is the justice!

-----
The death of dogma is the birth of reason.
 
chiph makes a good point re. the new Office release. So far I've only begun looking at Windows SharePoint Services (the STS replacement) and it uses quite a bit of .Net functionality. I've seen a number of tidbits on Office and .Net, but I haven't installed Office 11 (preview) itself yet to peer under the hood and see what's in store for (former?) VBA programmers.
 
I'm a little ticked because from reading and from hearsay I've heard that .NET was like freaking cheesecake compared to stale toast, and now you guys are telling me that it's even slower and a bigger resource hog?

I think it depends on what sort of VB programmer you are/were. If you're the kind of person who is saying "why doesn't VB do this in a more object-oriented manner", then .NET is like manna from heaven. If you're the type of VB developer who wants tighter integration with MS-Office, then .NET will seem like a bunch of unnecessary complexity.

One of the things I've grown to realize over the years is that there's a lot of really bad VB programmers out there. The kind that never use Option Explicit, Dim all variables as Variant, use data-bound controls (and wonder why they don't have as much control over them as they'd like), and so forth.

I think the population was getting better as a whole as time went by, but there was always a new generation taking up the tool, and making the same mistakes all over again. Partly because the help-file didn't have good examples, and partly because the RAD aspect of the tool encouraged it.

Chip H.


If you want to get the best response to a question, please check out FAQ222-2244 first
 
There are a lot of really bad programmers out there, period. But of course, most of them are beginners, and we can all forgive beginners for being bad at something at first, can't we?

It’s the one’s who have been in the business for over two years and they still don’t know the basics.

Then there are the people who are teaching themselves and moving up the ladder and getting better with every passing day.

Then there are those who are natural-born computer programmers, but they don’t seem to be good for much of anything else.

I'm looking forward to learning more about .NET and C++.

I'm just hoping that it lives up to its promise and that I didn't fall for yet another shiny new Microsoft marketing scam.


-----
The death of dogma is the birth of reason.
 
I saw the article when it came out. I see addendum has been added.

I've gone through agreeing with Joel on this, to disagreeing, and more recently back again (well, 3+ years is a long time in paradigm years). The problem here is less about .Net as it is the whole "web services" concept as it has become known. Much like EDI, I think it will achieve a degree of acceptance and application in niche areas dominated by some "WalMart-like" 800 pound gorillas (U.S. Feds, some automakers, other governments and large manufacturers, etc.).

But it is really off-topic. The thread is about the low rate of acceptance of VB.Net by VBers, and perhaps more specifically "what is your reaction to this letter on the subject and my annotated excerpts from it?"

My own reaction is still that: VB.Net is perfectly good, but MS grossly miscalculated if their aim was to bring a very substantial fraction of VB6 programmers over to .Net this way, and MS could have offered a cleaner less radical transition.

Personally I like where Borland is going with Delphi and .Net (preferably including an ongoing multi-platform commitment via Kylix). I could be much happier if they had stepped back and chosen a richer Algol descendent than Pascal though before starting to add on the arms and legs of extensions. I'd also be happier if they had a bit larger developer market- and mind-share with Delphi/Kylix.

I'm deviating here as a suggestion that VB6 programmers disenchanted with VB.Net take a look at alternatives before swallowing C# hook, line, and sinker. Of course as with many other things Microsoft it can be tough to avoid assimilation. VS.Net is a sweet development environment.
 
This thread796-669619 was interesting to see too.

I think there are more C# jobs out there right now. But as places get ready to make the VB6 to VB.Net leap in coming months (even if C# might make more sense) there could be a sudden demand for VB.Net skills.
 
I'm just starting to learn VB.net, and frankly, it seems like overkill.

I know I've got a lot to learn, but it just seems like there's a lot of extra work for little if any gain in performance, code size, memory useage, etc.

But again, I'm just starting....
 
Overkill in what way? You can do heaps more in VB.net than you can in VB6. Although I do admit that VB.Net does have a few annoying problems... like Just-In-Time (read all the time) compiling.
 
Hey Thunderbird,

I'm just learning, so I'll take your word for it.

But based on very little tom-foolery and exploration on my part, I'm just not seeing any big advantage to VB.net.

To me all of the "object oriented" fanfare just means more code that you can see but cannot touch, so what the heck is the point?
 
Thunderbird? I am assuming you mean me. "Object oriented" means greater code reuse and easier maintainability. You can create objects which map directly to the business logic. For example, if you were writing an app about cats, then the code can talk about cats.
 
Thunderbear,

I'm sorry about the goof in your name.

Like I said, I'm still learning, and even though VB6 isn't truly OO, you can still write your forms and your modules in a way that makes them interchangable with other programs.

I guess that's only pseudo-OO, but it can make for some pretty swift coding.

I figure there must be some very significant advantages to C++ type programs, and .NET, which I look forward to discovering.

That's why I talked my company into buying the Studio .NET package.

But as of yet, honestly, all I see is a bunch of extra code that I didn't have to mess around with before.
 
Keep at it... OO is worth it in the end if you learn to use it to your advantage. Some people are of the mindset that if it's OO then it must be good. I don't agree with that. If making something OO adds a benefit to the way the code is maintained or how it performs, then yes OO is good. But you get some programmers that OO things to death.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top