|
Shog,
Yes, you are correct, there are things that are very complicated in VB alone. I am really a C++ programmer, and I know I tend to forget the number of times I would drop into a C++ DLL from VB. However, I cannot think of too many things (there are a few) that are not possible in VB. However, the few things I can think of are not of much use in corporate applications.
I also agree that the reason for VB.Net is because of corporate pressure to maintain support for the language. In addition, I think there is some pride in VB. I remember attending a very expensive Microsoft VB 10 year Birthday Party. Still have the tee shirt. 
However, Managed C++ and C# offer a unique blend. C# makes creating simple applications quick, safe, and easy. C++ allows you, with very similar syntax, to do anything. I always like to say, C++ offers the performance and abilities of assembly language with all the ease and safety of assembly language programming. 
I cannot speak on COBOL.Net. I know Cobol from back in the 70's. The thought today turns my stomach to the point where I cannot even get a full sentance out. 
|
|
|
|
|
> It does everything every other language can do.
How about template programming or template meta-programming? What about inline assembly? What about built-in "design by contract" methodology (Eiffel)? What about cross-platform compatibility? What about ... (and the list goes on) ...?
|
|
|
|
|
Good point. But, not what I meant.
What I mean is that from the constructs of computer science (finite automata) it contains the same language features built into most (if not all) languages. For example, looping (for/next, do/while, while/do), selection (if, switch/case), etc.
If you drill into the finer points of each language, each has its strengths and weaknesses. I am making a more general comparison. Some of the features you mention come with huge pitfalls. For example, why use C++ to write inline assembly? Why not write assembly? If the function calls for that kind of performance, I want a tool that supports that type of development. What about macro substitution? I cannot begin to tell you the number of times I have seen programmers shoot theirself in the foot with a macro in C or C++.
I fully agree that C++ templates, and Eiffel "design by contract", etc. are wonderful features. Personally, I love to build objects using mix-in classes. This works best using multiple inheritence. Interfaces are great, but I don't want to have to build every interface from scratch.
|
|
|
|
|
Well... I have to admit that it does its job.
I just REALLY wish it had strong typing, and a better (c-like) variable scoping, but since I started writing PHP code, which doesn't have these features too, I really think it's better as a base language (I'm not talking about libraries here, in ASP they really don't exist).
Of course I'd like to have brackets instead of ugly if ... then ... end if blocks, but that's just syntax, and after a bit you get used to it.
VBScript it's not so bad after all, especially compared to PHP 
Please, don't flame me if this was a full-VB only poll 
Luca Leonardo Scorcia
http://zip.to/kojak (only in Italian)
|
|
|
|
|
Luca Leonardo Scorcia wrote:
VBScript it's not so bad after all, especially compared to PHP
Apples and Oranges, Luca
Personally, i'm much fonder of PHP than of "classic" ASP (VBScript). Even though VBScript is somewhat more flexible (or at least was the last time i checked), PHP focused on one thing - creating web apps - and did it well. After all, no-one's gonna be writing the next OS or heavy-duty CAD program in either VBS or PHP.
Now, JavaScript - there's a language!
But in the end, it's all just database access right? And that stuff is just plain boring.
|
|
|
|
|
I voted 'Horrible', but I need to clarify.
My programming background is BASIC up to 1996, then Ada, C and C++ at University (among others) until 2001, and now mainly C, C++, VB6 and VB.NET (oh, and T-SQL). I only learned VB6 last year.
I'll admit to coming from a server-based background. My boss wrote a server in VB6 about four years ago, and we're hitting the wall. Well, I'm hitting my head against a wall.
From this perspective, I have the following criticisms of the VB 6 language and runtime: it's very hard to write any kind of concurrency, you can't write an application with no GUI (and hence, writing a service, while possible, is almost insane), has terrible support for TCP communications, and file I/O is also poor.
With regard to files, I've discovered that the Dir() function just doesn't work properly if you're deleting the files as you go.
The VB6 environment isn't conducive to large-scale codebases. There's no way to find references to a particular variable or method. You must handle each and every compile error one at a time - you can't get a list of all errors. You can't easily use an alternate editor. You can't jump to a particular line if you know which line you need.
Most of these annoyances have been fixed in VB.NET, of course. The thing that still irritates me is the line continuation operator, and the fact that you can't do end-line comments if you use it. The new VB.NET array initialisation syntax is useful (and means that we've been able to move from a manually coded to a state table form of implementing state machines).
|
|
|
|
|
I had to use VB for over a year, because I was being forced to write Word makros. This is my experience with VB:
- Went home with a headache every day, because to my poor eyes the code seems to flicker even on a good screen. All those upper case letters, no brackets, no "==", no shortcuts like "++",...
- The syntax to import functions from DLLs is horribly long
- Event procedures are identified by their names!
- People say, in VB you can write applications very fast. I don't know what they mean. Typing long words and reading code with nearly no brackets is definitely not fast.
That's why I don't like VB. I have already used it, I'm not a snob, and I don't need to grow up for this statements
|
|
|
|
|
Corinna John wrote:
- People say, in VB you can write applications very fast. I don't know what they mean. Typing long words and reading code with nearly no brackets is definitely not fast.
Point and click programmers say that. The apps look good, but they don't do anything
--
Seraphim Shock. Gold for your ears.
|
|
|
|
|
out of my own pocket, for a copy of VB 1.0 in July 1990 (or was it 1991?). Either way, it was within a month of the language being released.
I remember liking the language. I'd been working in C and trying to learn Windows programming and VB helped me get over the initial learning curve.
I think it was sometime in 1991 that I made the plunge into c++ (Zortech's excellent compiler). Then along came Access 1.0 - my introduction to Relational Databases.
Sicne then I concentrated on c and c++, though I've written real applications in VB (and written VBX's in C++) for real applications (where real is defined as used by paying customers to run business functions).
I think the problem with VB is the problem of RAD. It's really easy to define a database, create a VB form, drop a databound control onto it and get some records displayed. This makes anyone capable of following a cookbook capable of creating a basic BASIC application. Wow! That was easy! Hey everyone, look at me, I'm a programmer.
In the process they've failed to notice that design is required.
Now let's see it from the managers perspective. This guy using VB can create a pretty front end really fast. And the pretty front end is all the manager or the client sees. They don't know about database concurrency or paging or memory management. The problem is that the guy who got into programming because of the ease of RAD is unlikely to understand the issues of resource contention, let alone the issues of design. It works for a 1000 record database so why should it not work for a million records?
I've had to work with people who didn't believe it was necessary to understand the underlying machine and who were baffled when they hit a wall. I've worked with people who didn't feel a design was necessary up front, and were baffled when the customer balked.
In the first case, since they didn't understand the machine, they didn't understand the walls and how to step around them. And in the second case, it was easy for them so that was the obvious way. Unfortunately the real world doesn't work that way.
Hmmm I've wandered a bit from the point I think my point is that VB doesn't encourage rigour of thought.
Rob Manderson
http://www.mindprobes.net
Paul Watson wrote:What sense would you most dislike loosing?
Ian Darling replied.
Telepathy
Then I'd no longer be able to find out everyones dirty little secrets The Lounge, December 4 2003
|
|
|
|
|
I've used VB for DOS (well not actually used, I loaded, the removed it), I felt it better to stick with QuickC for Windows.
I am that is
|
|
|
|
|
I quite liked Quick C (though I seem to remember it was called Visual C - this would be about 1991?). It was a big step up from MS C 2 (aka Lattice C) and Symdeb.
Ah, the good old days that seem good only in retrospect
I never used VB for DOS. Never even saw a copy for that matter though I did see one or two examples of the programs it produced. I did enjoy QuickBasic and I was assigned (in 1985 I think) to teach some graduates at HP Australia how to write assembly language interfaces to MS QB. This was my first introduction to Computer Science graduates. I was somewhat shocked that these people had degrees and yet no idea of hardware abstracted to software (ie, accumulators, index registers, carry flags, stacks etc). Even now, nearly 20 years later, I'm still undecided on that particular question.
I probably sound like that old fart who complains that young people these days don't have to trudge 20 miles through the snow to school I didn't have to do that either
Rob Manderson
http://www.mindprobes.net
Paul Watson wrote:What sense would you most dislike loosing?
Ian Darling replied.
Telepathy
Then I'd no longer be able to find out everyones dirty little secrets The Lounge, December 4 2003
|
|
|
|
|
It's the people that enforce the use of VB.
OK, an unfair generalization to be sure, but I have encountered a lot more ignorance of good coding practices among VB programmers than among C++ programmers. Probably because C++ weans out the bad practices a lot faster.
And really, any language that forced upon us by ignorant managers on the grounds that writing apps in it is cheaper, faster, and less buggy, is by its very nature highly suspect.
Marc
Latest AAL Article
My blog
Join my forum!
|
|
|
|
|
Can a language, that requires one to define your own kernel or system access prototypes yourself, really be called a language.
 I know VB is used a lot, but where are "standard" includes for it.
I know it's fast to do something.
 Only pity about VC++ is the lack of COM support as VB has.
Well that's my 10 cents worth.
AllenR
|
|
|
|
|
AllenR wrote:
Only pity about VC++ is the lack of COM support as VB has.
I don't know if that is really true anymore. Since Microsoft introduced the #import command, it is very easy to call COM object from C++.
Michael
But you know when the truth is told,
That you can get what you want or you can just get old,
Your're going to kick off before you even get halfway through.
When will you realise... Vienna waits for you? - "The Stranger," Billy Joel
|
|
|
|
|
If I remember correctly, the import command automatically creates a com class derived from the interface defination, then secretly puts it hidden .h files in your target build directory... that makes less work for the programmer... unless something goes wrong, or you are doing something slightly non standard - for instance if you want to re-use common code you won't be able to subclass, or superclass the generated class.
In general I hate things that generate code automatically, they normally only work for the simplest cases.
|
|
|
|
|
I agree, I have more problems with programmers who only know VB and never were exposed to the C language or C++. I guess I am a language biget because I no longer look at resumes where their primary language is VB. I find these people too hard to retrain and I don't have time.
There are a couple of things that bug me about VB aside from the programmer base.
1. It still supports "Variant" datatype which doesn't exist.
2. It still thinks true = -1
3. It still allows programmer to get away with not initializing their variables. Which returns us to item 1. and so it will guess what a datatype is and goof up the results.
4. It allows too much type casting with CType insteading enforcing the rules of conversion.
5. I hate the open construct of the syntax, I find it hard to figure out where things end and begin.
6. VB Subs do not enforce the return of either nothing or something and I find many problems with junior programmers calling a sub and forgetting that it has to come back to the caller so it can execute the next instruction.
7. VB "on Error resume next" drives me insane. I was glad to see the try catch added to the language; but I find that the VB programmers will put the try at the top of 14 instuctions and the catch at the end. You ask them where did the error actually occur and they say "what error" or "I don't want the user to see any errors so what do I do?" grrrrr.
Of the four things I rant about Number 2 is the one that makes my blood pressure rise to 187. When I have a VB programmer set up a DB Table they always set it up as an integer and allow -1 for true instead of a bit 0/1. This annoys me to no end and if it goes for too long I can't get rid of it that easily.
The next in line is the "on error resume next" nonsense it requires too much energy on my part to even discuss it.
I also find that VB programmers have no concept of an algorithm and are experts at wizards. They have no "under the hood" knowledge and when you try to explain it to them their eyes glaze over.
However, I do know many programmers who have managed to go between both languages and force VB to behave, I admire and respect those programmers and wish there were more.
Pamela Reinskou
Some Days the Dragon Wins!!
VersusLaw Inc.
|
|
|
|
|
Well said!
Pamela Reinskou wrote:
It still thinks true = -1
This is sort of a fun one, if only for purely academic reasons. I suspect that true=-1 because -1 sets all the bits, including the sign bit. Any bit test in assembly will therefore be true. A lot of CPU's automatically set the sign bit when loading a byte into a register, so it's really easy to test for "trueness".
This "problem" isn't just a VB artifact though. In fact, an argument can be made that C/C++ completely violates the concept of "trueness". In C, a "0" is considered false, but any non-zero value is considered true. Not quite pure logic there. I much prefer the C# form, which requires a bool, forcing the programmer to make a comparison of equality. Annoying sometimes, but more readable, and more correct, IMHO.
I think the thing that annoys me most about VB programmers is their propensity for "cut and paste" similar or identical code, rather than writing a function. I can tell C# programmers that come from a VB background for the same reason.
Marc
Latest AAL Article
My blog
Join my forum!
|
|
|
|
|
I think the thing that annoys me most about VB programmers is their propensity for "cut and paste" similar or identical code, rather than writing a function.
I truly understand this... because I am a victim.
I was assigned to maintain a VB coder's "applicaitons" few years ago; the coder just wrote a "working" module and copy-paste it to all other similar modules. As you expect, all module had same error and I must spent months to fix all modules.
VB coder never understand "design", algorithm, not even programming.
Coding != Programming
|
|
|
|
|
I agree that it is not the language, it is the accessibility of the language that has attracted a lot of non-disciplined programmers who give a good language a bad rap.
The issues you sited are issues that do not have to be used (except for true = -1, but that is easy to work around with a const). It is not hard for someone with the discipline to write clean, concise, well-written code that would pass most requirements for professional code. Unfortunately, if you puruse the VB code sites, you get a lot of guys who never heard of style, or error handling (other than "do not let theuser see any"). And so, too many aspiring programmers learn from these examples, and the problem is propogated.
In my line of work, I am often to be foudn supporting engineers who main job is something totally unrelated to VB, who are tasked to code in VB. It is painful. They treat VB like a shell or batch language, instead of the language it really is. Something that worked with a few objects back in '99 all of a sudden does not work when a few thousan objects are thrown at it. And they just do not get it. Or, they throw a hack to get by for the day, until the next issue.
But that does not mean that VB6 is a bad language, and that it cannot write good programs, if one understands how to make use of it. I have been writing C/C++ since '91, and VB only since '98, and I have seen more bad C/C++ than VB code. Complicated does not mean more advanced or better!
In the meantime, I have developed tools and classes to make VB6 coding a breeze. I will deliver a working program for (non-enterprise) apps faster than a C++ coder will, and time is money. In fact, it often works better than or just as well as the C++ code, in less than half the time. And for UIs for multi-tiered apps, it is hard to be more productive. It is hard argue those facts, with well-written code.
I can say that I owe my abilities to write good VB code to my background in C++. It is very frustrating to try to explain error handling concepts to newbies. they just do not think things through like a C++ coder would. And we are back to the crux of the issue. The lack of trainign in formal coding practices for VB users.
Anyway, I choose the 'snob' answer, because being a C/C++ AND a VB coder, I feel it is not the language, it is the reputation of the coders who have given it the bad rap. If people would give it a chance, a good coder can write good code in any language. But I see many responses here from people who want to try to give technical reasons why they would be unable to write good code with VB. And they just do not fly with me. YOU are the one who has control over whether you write good code, not the language. Choose your tools as appropriate for the job, but do not rule out tools due to your lack of experience with the tools. There are very few circumstances where I could not make VB fit (scalable server apps being one of them - and guess how many servers apps I write that have to scale to more than a few hundred, which I can handle very easily with VB, thank you very much!). Even if I had to write a small C DLL to get some functionality, it was still less time in the long run to do the majority in VB, and only dip into C when I needed. And I can't count the number of times I was able to show management the numbers on how cost effective off-the-shelf, proven, supported components were, compared to in-house code, especially when I showed them the badly-formatted, non-commented code that so many in-house C/C++ developers wrote. Do they not teach these things in school anymore? One guy never used new lines in his code, because 'it made it easier to read a lot of code at once'. Good for him, then he left, and we were stuck with it. And people think C coders are held to higher standards.
Again, productivity is time is money, and I get paid very well (higher than most from the replies in the salary surveys) to be productive, not to be tied to one language, not for elegance (although a good solution is elegant unto itself), or how complicated, or how many lines of code I write. So, as far as I am concerned, the more people who thumb their noses at VB, VB.NET, etc., the more room for me to shine by delivering good code, on time, and robustly, and make more money!
Noël Henderson
|
|
|
|
|
I understand your point about productivity and most likely you are very productive, we all must remember that not all VB programmers produce poor code.
However, Small businesses have to put up with programmers who dazzle with BS instead of shine with skill. While a BS artist can put something together in record time in the end the cost of maintenance and the possibility of a total rewrite far outway the initial savings. In my company we have actually lost revenue because I cannot implement a feature without a total rewrite. It takes me three times longer to troubleshoot the problem because of the extensive use of CType and Subs. In some cases to fix a problem with our changing business rules I have had to duplicate the existing function and rewrite it correctly; but I have to branch the code so that only the new business rules look at that function. It is absolutely crazy making and it is lost revenue as far as I am concerned not to mention the hours I don't get paid for because I am salaried.
VB was designed for the non-programmer to write simple productivity applications; but somehow it took on a life of it's own. Now we have social workers writing enterprise applications when they can barely figure out the algorithm for getting dressed in the morning.
Don't take me wrong there are very good programmers out there who can write in any language and adhere to best practices, know what an algorithm is and inplement it; but they are the minority and they have no interest in working in an 18 person company.
BTW - the orginal program I am now supporting was outsourced by my company. I have since rewritten the application in C# which is another story for another time.
Pamela Reinskou
Some Days the Dragon Wins!!
VersusLaw Inc.
|
|
|
|
|
Thanks for the reply. I still do not see anything that is a problem with VB. As the title of the thread says 'it's not the language...'
With pointers in C++, I can do much more damage. In fact, it is the poorly coded use of pointers in a lot of applications that had lead to some of the most famous and damaging code of our time - look at all the problems with IE and IIS and other programs that allowed someone to send input that allowed code to run when a pointer's contents were overrun. My company (the most respected in the world), does not allow IIS to be used internally for this reason.
Does this make C++/C a bad language? Because some coders were too lazy to do checking on input to make sure buffers were not overrun? Wasn't this one of the reasons Java does not implement pointers per se? no, when it is the language THEY use, everyone refocuses on a nice big target, like MS as being the culprit, not the fact that the language was sloppy enough to allow non-disciplined programmers to be lazy, and exhibit poor coding practices. It could not be the language that is not safe ... could it?
Why are there poorly rated submissions on this site, for code written in languages other than VB? Does that make the languages those poorly rated submissions were written in bad?
For that matter, I have seen some very 'hacked-together' code in C# in the past few years, that has crashed my machines a number of times.
I am not denying the fact that VB has attracted many more of the less disciplined variety of wannabe programers, and these programmers have given VB a bad rap. But it does not diminish the value of the language, nor the capabilities of the language. From what I have been reading, it only fuels the bias (which I read as snobbishness) of other programmers with formal training.
Poor hiring practices (can we say 'references'?) does not make a poor programming language. I can site numerous cases of the same thing happening as happened to your company with C/C++, and I anticipate that we will see more of it with .NET now.
Poor coding skills does not make a poor programming language. I have heard more urban legends of poor code written in VB, than have actually come across it in my professional career. Although, if the code on such sites as PSC is an indication, there is a lot of bad VB code out there. I guess companies that can afford my services are more discriminating.
Unsafe shortcuts does not make a poor programing language. How often have you read about a feature supported by a given compiler that is not recommended for general use? How safe are pointers when not used properly?
Someone mentioned 'On Error GoTo Next' as being evil. Only if the error number is not checked. A try...catch block can be just as dangerous, and used in the same way. Just because you catch an error does not mean that you handle it correctly, or make the best decision on where to go from there. How is this different from what VB allows you to do? What is the difference? It is not the language, it is the coder. I refer you to the title of this thread.
I think the conversations in these threads here solidify my feelings that it is snobbery that has fueled this bias. Anyone can find issue wih anything they are biased against. But all I see here are people saying that the possibility exists in VB to write bad code, and therefore it is a bad language. I have not seen anyone saying that it FORCES you to write bad code, that no matter what techniques or discipline you employ your code will end up bad. To me, that is the only definition of a poorly implemented language. People who think in one way, feel the rest of the world should think the way they do, and if not, then they are bad. Like MAC vs. WINTEL. Give me a break, get a life, and please, step out of the way so that I can get that money waiting to be had while others are pontificating about why their language preference defines your skills.
All I need is for the general admission that in the wrong hands ANY language is dangerous, and can deliver poor code. From there, we take the correllary that in the RIGHT hands, ANY language can produce robust, well thought-out code. At that point, we have successfully isolated the issue from being about the language, and about the nut loose on the end of the keyboard. A totally different issue. but one that identifies the only true ubjective answer to the poll is that VB has a bad rep due to the general awareness of the lack of discipline in many VB programers.
If more people would get beyond that way of thinking, and start worrying about delivering the best value, and which language can deliver that value (note that time is a factor in value), the market would be much tougher than I see it being. You can see that I am not to worried about this happening. This is not directed at anyone, as I know none of you here. But please, separate the language from the hacks.
Noël Henderson
|
|
|
|
|
So true,
and you'll find most VB programs lack concepts of OOP/OOD and User Interface Design.
Because it is so easy to learn, people with little or no programming experience find it easy way to move into the computer industry and wean themselves on VB projects only to produce what I call dogshit code.
I am that is
|
|
|
|
|
I have written many apps in VB. One of which is still running and handles over a £1,000,000 of data. Even with VB6 I was hooking into the windows API and making GUI do things that would make some C programmers blush!
It's true that people can pick VB up without a good understanding of programming, but thats not the languages fault. There are an awful lot of bad C, C++, C#, Java, COBOL programmers out there too!
|
|
|
|
|
Agreed I have seen bad COBOL in my day so I understand what you are saying. However notice that the only ones taking exception to this thread are decent or excellent programmers.
The problem is the language because if you do not control it, it will control you. If the programmer forgets to initialize a variable no sweat VB will just make it a variant and allow you to cast it any way you want. If the programmer creates a subroutine that returns no value at all no problem nothing happens. If an object has not been instatiated no problem if you test that it is "Nothing" instead of testing for the datatype; providing that you test at all. Oh I forgot VB doesn't know what a datatype is sorry.
The language is at fault because it was designed to be freindly and do the thinking for the programmer. Excuse me I will think for myself and you the programmer language will do as I say even if it is wrong. At least with ansi C based languages when I give it an instuction that makes no sense it has the ability to come back and say--"Are you sure(warning)" or "forget it I am not doing that it makes no sense (error)". VB on the other hand will just calmly make some assumption and go for it. This has nothing to do with the programmer, if he gets used to the language making the decisions he will never learn the correct way to do things.
Sorry, I tend to get a little excited, I do not mean harm to anyone.
Pamela Reinskou
Some Days the Dragon Wins!!
VersusLaw Inc.
|
|
|
|
|
VB = Pandora's Box...
I had to translate a lot app from VB to VC++ (No words)
I saw the problem is like you said:
The language control you
The most problems were sentences that doesn't that must to do.
Best Regards.
Carlos Antollini
Do you know piFive[^] ?
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
