|
I've used VB professionally for many years and the reason for that is that so many employers picked it for their developments. Why? Because the productivity levels are so superior to C++.
Who wants to spend days coding their own components when they're already available. 
C++ programmers spend so much time bleating about coding for re-use and not enough time actually re-using existing code. VB programmers have, from day one, re-used the components already written for them. No-one builds a house these days by making their own bricks.
Admittedly VB6 is lacking in many areas. It's not anywhere near an OO language. It would be foolish to attempt many projects using it. C++ is obviously the most powerful, complex and multi-purpose language available. However these strengths are also it's weaknesses.
VB's weaknesses have been addressed by Microsoft in VB.NET. They have bravely cut many ties with VB6 leaving it in-compatible. This has resulted in a usable object-oriented language (admittedly still not fully OO).
For the odd occasion where VB.NET is not appropriate we now have C#. At last a version of C which addresses the complexity issues and provides productivity levels on a par with VB. Perhaps this is why I have noticed that the majority of .NET jobs advertised are asking for C#.
I evolved into VB.NET, but I am going to move to C# because it now offers the best combination of simplicity and productivity. This move will be helped by the fact that the languages are so similar and that 90% of the time you are merely using the .NET Framework which is the same in either language. Who knows, perhaps this was Microsoft's master plan all along. Maybe VB.NET was written merely to ease the passage of VB programmers over to C#. 
We find comfort among those who agree with us - growth among those who don't
(Frank A. Clark)
|
|
|
|
|
I've used VB professionally for many years and the reason for that is that so many employers picked it for their developments. Why? Because the productivity levels are so superior to C++.
Yes and no. In San Diego a few years ago, most employers wanted VB consultants because they were cheaper, and because they were more numerous, thus easily replaceable.
Productivity appears superior to begin with, but I've found that large scale development in VB eventually becomes unmaintainable, primarily because most VB programmers don't think in terms of generalization and abstraction. In my experience, VB programmers cut&paste code everywhere (hence your reuse) but fail to generalize. Eventually, making a simple change means finding 100 places that it needs to be changed and missing a 100 more.
That said, I'd say the biggest problem with C++ programmers is their complete lack of understanding of object oriented design and the appropriate use of objects, which leads to a different problem than the VB camp--namely inflexibility. It becomes impossible to make changes to the program without breaking the entire thing.
In either case, I feel the productivity thing is based on perception as opposed to real numbers (or simply having been burned on a C++ project first!).
What we need is a language/environment that promotes generalization AND flexibility. In some ways (especially with the event capability), .NET (whether C# or VB or anything else) helps this situation, but not totally, in my opinion.
Marc
Help! I'm an AI running around in someone's f*cked up universe simulator.
Sensitivity and ethnic diversity means celebrating difference, not hiding from it. - Christian Graus
Every line of code is a liability - Taka Muraoka
Microsoft deliberately adds arbitrary layers of complexity to make it difficult to deliver Windows features on non-Windows platforms--Microsoft's "Halloween files"
|
|
|
|
|
>>VB programmers cut&paste code everywhere (hence your reuse) but fail to generalize
As that statement is a generalization I take it you're a C++ programmer 
I think it would be fairer to say that BAD programmers write unmaintainable code. It would also be fair to say that more VB programmers fall into that category - because only good programmers can cope with C++'s complexity.
Lots of people get drawn to VB because it is easy to get a simple program written in a very short period of time. Consequently everyone thinks they're a programmer and we end up with badly written unmaintainable code.
OK so assuming we have a set of bad programmers, which of their code would you rather debug - VB or C++? I suppose the answer would be whichever you're most comfortable with, but I for one would find the C++ harder because it's harder in the first place. I don't know of any figures (perhaps someone reading this may know) but I would imagine that the C++ equivalent of a VB program would require many more lines of source code. Increased source size inevitably leads to increased complexity - there's a whole industry called software metrics which swears by this.
Assuming we have a set of good programmers I would say it was a mute point and that the productivity I mentioned before would swing into VB's favour.
Asserting yourself while respecting others is a very good way to win respect yourself.
- Janice LaRouche
|
|
|
|
|
Assuming we have a set of good programmers I would say it was a mute point and that the productivity I mentioned before would swing into VB's favour.
Wow, this thread is sure getting a lot of message voting!
I've done some VB programming for a couple clients, and I rapidly became "comfortable" with the language but there were some things that I simply couldn't figure out how to do in VB (partly because the client didn't want to pay for too much of my learning curve).
In particular, part of what I consider to be productivity enhancing is:
1. ability to hook into memory allocation and deallocations to test for memory leaks. I prefer this method to other methods, but that may just be me.
2. the ability to implement sophisticated instrumentation using macros--assertions, warnings, traces, etc...
3. multithreading, semaphores, mutexes, etc...
4. the ability to implement objects for things like internal messaging, state machine, event handlers, and data pooling, and thread pooling, all of which I consider to be foundational requirements in any application, now matter how small. Instrumentation of these objects is a major productivity enhancer when it comes time to debug complex code interactions.
5. runtime generated GUI's instead of design time .RC style GUI's.
Now, it seems that VB.NET can do all of the above (except for the cool /// comment capability that C# has but I didn't put that in the above list), but how much of this was possible with VB5/6?
There. I have revealed my ignorance. I am actually quite interested in the answers, as I have never taken the opportunity to have this discussion with someone well versed in VB. No criticism intended, but my limited experience with project leads on VB projects (both for HMO provider companies) was that the project lead wasn't really running on all cylinders. And therefore I didn't feel there was much point in any meaningful discussion.
Marc
Help! I'm an AI running around in someone's f*cked up universe simulator.
Sensitivity and ethnic diversity means celebrating difference, not hiding from it. - Christian Graus
Every line of code is a liability - Taka Muraoka
Microsoft deliberately adds arbitrary layers of complexity to make it difficult to deliver Windows features on non-Windows platforms--Microsoft's "Halloween files"
|
|
|
|
|
Marc Clifton wrote:
how much of this was possible with VB5/6?
Not much.
1. memory leaks. - VB5/6 hides the allocation/de-allocation of memory as any good high-level language should. Memory leaks would therefore come from such things as circular object references or other bad programming. You should be able to track these thing down quite easily, unless the problem lies within the VB runtime (nobody said it was perfect).
2. debugging in VB has always been woefully inadequate. I have myself built up a useful toolkit to provide a lot trace functionality and error handling, but VB is nowhere near C++ on this issue.
3. multithreading - forget about it, although you could do this using out of process COM components it was hard.
4. internal messaging - see EVENTS, state machine - never understood the big deal here (certainly not built in to VB5/6), event handling - works if used properly, data pooling and thread pooling - well if you're doing things at this sort of level you'd probably be using MTS for that.
5. Actually it is possible to have runtime generated GUI's. Check out the LOAD command.
As you say VB.NET can now do all of this (thank <insert deity="" of="" your="" choice="" here="">).
By the way, when did this thread turn into me defending VB5/6 against C++. I think they're both useful and that VB is the better tool for 80% of the jobs. C++ catches the other more difficult stuff. Of course .NET pisses on both of them.
|
|
|
|
|
Marc Clifton wrote:
reuse
OK, firstly, VB has decent reuse through components (COM objects) so your argument is muted to some extent.
The problem was that VB6 wasn't an OO language, so you couldn't derive from ancestor classes, etc... In that way reuse was limited.
I think a big issue was programmers forcing a solution on a problem that just didn't fit. One example was OO-style VB5/6 designs, but it wasn't limited to VB.
Cheers,
Simon
"I ask candidates to create an object model of a chicken.", Bruce Eckel on interviewing programmers.
animation mechanics in SVG (latest pic 1) (latest pic 2)
|
|
|
|
|
antidemon wrote:
Who wants to spend days coding their own components when they're already available
Not VB people, because they don't know how. C++ developer's don't reinvent the wheel, I don't know where your getting your info, obviously you are not a C++ programmer. Almost every program I've reviewed contains code reuse or library use.
antidemon wrote:
C++ programmers spend so much time bleating about coding for re-use and not enough time actually re-using existing code
WRONG! Just browse the articles here at CP , there is a high level of class reuse.
antidemon wrote:
VB's weaknesses have been addressed by Microsoft in VB.NET
Except for that horrid syntax.
R.Bischoff | C++
.NET, Kommst du mit?
|
|
|
|
|
Soliant wrote:
Not VB people, because they don't know how
Well I'm a VB programmer and I know how and do. Of course generalised insults are easier to come up with than intelligent discussion so I'll have to let you off.
Soliant wrote:
obviously you are not a C++ programmer
I am not a C++ programmer (by choice). Although I have programmed in C++ professionaly, so guess again.
Soliant wrote:
Except for that horrid syntax.
You're so right curly brackets and semicolons are so much more readable than words. I expect you like those nice pop-up picture books as well - no nasty words involved.
{HaHaHa++}
|
|
|
|
|
no doubt C++ has a deeper learning curve,since it is multiparadigm and verstile language,
you can do low level programming and access raw memory with pointers,application programming with OO techniques, and meta programming with templates.No need to argue,C++ is always superior to VB, C++ is a computer language and VB is a just tools for application development.
I wonder why people said VB is more productive, probably they are messing up with the learning time and production time, yes, VB definitely has a shorter learning time since they aint got much to learn, but once u master C++, the production time won't take longer than VB.
I think the following reasons might raise the illusion of VB is superior
1.MFC sucks,it simply a wrapper of win32API and have no sense to OO(like OnInitDialog,OnDestroy..e.tc), MFC developers has to climb up the deep learning curve on learning C++, but hardly benefit from OO.
2.Microsoft intentionally build better support on VB,whatever in IDE,library and source sample,MS is a commerical unit, they want more developer to join the Win32 community, thats why VB got better support since it is easier to pick up.A better supported tools doesn't mean it is superior.
VB did a pretty good job in quick and dirty application development,but lacking of OO will impose some critical constraints to produce maintainable code in large scale development.
There is nothing wrong for ppl to program VB, ppl got their own role in the software industry, but PLEASE don't ever dream about to compare VB and C++ and don't proud of being a VB developer, just like no one will proud of the max speed your car can go, but should proud of your driving skills.
VB.net should be trashed, it is nothing but a clone from other OO language with cryptic syntax.
|
|
|
|
|
demofo wrote:
access raw memory with pointers
Why on earth would you want to do something so dodgy? That breaks every structured / OO programming rule in the book.
demofo wrote:
No need to argue,C++ is always superior to VB
Depends upon your definition of superior. (more later)
demofo wrote:
.MFC sucks,it simply a wrapper of win32API and have no sense to OO(like OnInitDialog,OnDestroy..e.tc),
This gets to the heart of the matter. The pure C++ language used on it's own is fantastic, VB can not stand against it. The problem comes when you want to use it on the Win32 system.
C++/MFC makes it unnecessarily hard to use COM objects. The whole point of OO programming is to abstract things. This is meant to HIDE complexity. In VB if I want to use a COM object I just create it and use it, VB hides all of the API calls and handles reference counting and all of the other crap. In C++ I am responsible for so much crap that the job becomes unnecessarily more complex.
demofo wrote:
2.Microsoft intentionally build better support on VB,whatever in IDE,library and source sample
You're right to say that the VB IDE has always been much better than C++'s (now irrelevant as all use the same IDE). As I've said before, if you are comparing the C++ language with the VB (pre .NET) language then C++ wins by a mile. If you include the IDE and other tools then VB starts to catch up, and if you look at my argument (which was about productivity) - as you said yourself:
demofo wrote:
VB did a pretty good job in quick and dirty application development
Unfortunately, as I've said before, this has led to any idiot believing they could program (hence your dirty comment).
Anyway crap un-reusable code comes from crap (or no) analysis. You can write crap code in ay language.
demofo wrote:
VB.net should be trashed, it is nothing but a clone from other OO language with cryptic syntax
Get your facts right. VB was created in 1964, C was created 7 years later in 1971 as an evolution (i.e. clone) of B and BCPL.
The move from VB to VB.NET, although described as revolutionary, is not as big as some people make out, they simply ironed out some of the stupid idiosyncracies. VB was nearly an OO language before, now VB.NET is.
Also, there is no way VB.NET's syntax can be described as cryptic when compared to C++. In all languages the use of symbols should be restricted to operators/expressions, not used in place of keywords. BEGIN and END are much more informative than {} (and easier to keep track of)
If you had said VB should be trashed I would tend to agree with you (as both C# and VB.NET are far superior development environments).
Before .NET came about we had no development tool which satisfied all requirements. C++ was powerful but failed to hide the complexity of COM, VB lacked inheritance and lots of other stuff, but had a great IDE and hid a lot of complexity)
Now we turn to .NET. The framework has eliminated the problems associated with MFC. We now have one IDE for all languages. This means we can compare the .NET languages on their own merits ie syntax and power. As C# still contains some functionality that VB.NET doesn't, I would say that C# is currently the best programming environment. That doesn't mean that we should ignore VB.NET Many people are more comfortable with VB than C and the differences are so minute that there is no reason to ditch VB.NET. At least all of us crap VB programmers will have an OO language to write crap code in. 
demofo wrote:
and don't proud of being a VB developer
Actually the biggest problem I can see with C++ is that overuse of it tends to bring on a superiority complex. I don't think I'm any better than someone just because they use a different programming language to me. Thinking like that has caused more problems in life than anything else. Can you provide a rational explanation of why people spit blood over issues like this? These people are no better than the religious bigots who cause most of the problems in this world. If someone wishes to use VB then let them, it's none of your business.
|
|
|
|
|
antidemon wrote:
I've used VB professionally for many years and the reason for that is that so many employers picked it for their developments. Why? Because the productivity levels are so superior to C++.
The right tool for the job.
You can be productive hanging pictures by useing a small hammer and small nails. You can be productive building a house by using a big hammer and big nails. But if you try to build a house with a small hammer and small nails, you will not be too productive.
If you need to hang pictures, use VB. If you need to build a house, use C++ (or possibly C# if the house needs some kind of ASP.NET connectivity).
"Any clod can have the facts, but having opinions is an art."
Charles McCabe, San Francisco Chronicle
|
|
|
|
|
So true, I was going to say something similar but thought I might be overdoing the housebuilding analogy 
|
|
|
|
|
"But if you try to build a house with a small hammer and small nails, you will not be too productive."
But the sentiment here is, you should use a big hammer no matter what you do. If you dare to disagree, then you must be a stupid low-life VBer, and you will be condamned into some bigshot's signature forever.
|
|
|
|
|
Picture Hanger wrote:
But the sentiment here is, you should use a big hammer no matter what you do. If you dare to disagree, then you must be a stupid low-life VBer, and you will be condamned into some bigshot's signature forever.
No the sentiment here is: Use VB for whatever it is good for, but don't claim that VB is anywhere near C++ - especially if you have problems with semicolons and curly braces.
|
|
|
|
|
Nemanja Trifunovic wrote:
No the sentiment here is: Use VB for whatever it is good for, but don't claim that VB is anywhere near C++ - especially if you have problems with semicolons and curly braces.
Yeah, right. It is quite reasonable to require all the small hammer users to take a moment of silence, before starting their work, to pay respect to all the big hammer users, failing to do so will result in a holy attack from the big hammer users. 
|
|
|
|
|
Picture Hanger wrote:
you will be condamned into some bigshot's signature forever
You will only be condemded until some other picture hanger comes along and dares to disagree.
Build a man a fire, and he will be warm for a day
Light a man on fire, and he will be warm for the rest of his life!
|
|
|
|
|
antidemon wrote:
I've used VB professionally
That sounds like an oxymoron !
Regardz
Colin J Davies
Sonork ID 100.9197:Colin
I'm guessing the concept of a 2 hour movie showing two guys eating a meal and talking struck them as 'foreign'
Rob Manderson wrote:
|
|
|
|
|
I couldn't agree more. A language that before templates I would have to create a string class to be able to work with strings. I spent many years on mainframes writing code in COBOL, I hated every minute of it, Assembler let me do so much more, more efficiently, and was even easier to debug. But most other developers could not support it, but everyone was able to use COBOL. Quick and Easy and full of wholes. If I had to choose between VB and COBOL, I would choose VB without a doubt.
If I was to look at PC development languages prior to Java, limiting them to VB, Delphi and C++, believe you me I would choose Delphi, and I am sure that is why Microsoft hired Delphi's architect to develop C#. Delphi is C++ developed like VB, with all the advantages of both languages, and the eloquence of Pascal.
|
|
|
|
|
Ok I understand some bias towards VB6 and prior, it lacked in a lot of oomph. But now with the CLR and a lot of oomph and access to the same things I'm surprised by the poll. I suppose in part it's likely VB.Net developers are elsewhere, as there's not even a tab for developers going that route here.
Even so, I'm a bit surprised.. maybe that'll turn me more to C# or another C-variant. Although familiar with C I've done a lot of Powerbuilder / Powerscript and have been headed towards a VB.Net certification, thinking that might be the most logical approach - still some RAD but finally some real OO and reuse (at least by appearances thusfar). Maybe that thought will prove wrong.. any educated feedback rather than 'I don't like VB' knee-jerk reactions? 
Craig
edit - I'll do some searching around here too, the more I look the more I get the impression there's some concrete stuff, but also a lot of fluff.. looking for the concrete - and note that I'm NOT coming from VB, I'm quite used to real enterprise applications with OO and reuse and very powerful data controls, thanks
|
|
|
|
|
Your approach is fine, I think.
Don't take the VB-bashing here too seriously. This site used to be for MFC and such, so mostly C++ guys visit here. C++ developers in general are very reasonable people, except when it comes to VB some of them become very biased and childish. This is probably a result of their insecurity and jealousy.
Before I got flamed, please note that I haven't made a single comment about which language or tool is better. Perhaps just being impartial between VB and C++ will be enough to earn me a death penalty with a panel of all C++ jurors.
|
|
|
|
|
Anonymous wrote:
Before I got flamed, please note that I haven't made a single comment about which language or tool is better.
You also have not allowed us to know just who you are either. 
Comon... come out of the shadows and let the rest of us VBers know who you are....
Paul Watson wrote:
"At the end of the day it is what you produce that counts, not how many doctorates you have on the wall."
George Carlin wrote:
"Don't sweat the petty things, and don't pet the sweaty things."
|
|
|
|
|
"Comon... come out of the shadows and let the rest of us VBers know who you are..."
I am working for the CIA, that's why I am in the shadow. We use buggy VB programs to find Bin Laden and buggy C++ programs to crash Sadam's computer. You see, the job market for incompetent programmers will never dry up.
|
|
|
|
|
 I have no idea why so many people don't like C# i mean come on you have to expect some kind of change in 10 years. I mean it's so much easier to write C#/DirectX 9.0 than it is to write C++/DirectX 9.0 trust me i know. I tried a few months ago and then support came for C# and it clicked instantly. I have even read a few books where the authors were former C++ developers and then came C# and they never went back.
|
|
|
|
|
Huh?
From the activity I've seen on this site, both in terms of new C# articles and comments on the Lounge, etc., I'd say that most C++ programmers have embraced C#. They understand that it's not as powerful and flexible as C++, but most know that C# makes .NET programming (expecially ASP.NET) a joy.
Regards,
Alvaro
The world is a dangerous place, not because of those who do evil, but because of those who look on and do nothing. -- Albert Einstein
|
|
|
|
|
sumo_guy wrote:
have no idea why so many people don't like C#
I use C# for .NET development, and can't say that I don't like it (I'll like it even more when generics are included). For everything else, I see no reason to leave C++ which is more powerful and flexible language.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
