There is nothing that VB can do, nothing!
(Sorry; it just cried out to be said. :-) ThereIsNothingPerlCannotDo
Some people believe that VisualBasic
teaches new programmers bad habits.
There's no guidance towards ModularProgramming
. You don't even need to declare variables. This is great for small programs, but these programs grow into unmaintainable monsters very quickly.
While I don't like the way VB in particular handles undeclared variables, you seem to imply that dynamic languages in general don't scale. I think this depends on one's development methodology. See DynamicLanguagesAndLargeApps.
- No need to declare variables, no guidance towards modular programming: sounds like PhpLanguage.
Even if you know how to create good software, it's difficult. You can write ObjectOriented
code in VB. But you need to write the infrastructure yourself.
Part of the issue seems to be that Microsoft tends not to believe in OOP, and I generally agree with that assessment. OOP is okay for systems software, but sucks at biz apps. (See IsMicrosoftAgainstOo)
Aside: I actually prefer VbScript
because I can run it from the CommandLine
Suppose we took any comments related to the below EwDijkstra quote and moved it to BasicTeachesBadHabits?, or DartmouthBasicTaughtBadHabits??
- "It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration." -- EwDijkstra
Let's be fair and reproduce his remarks in their context:
- FORTRAN - "the infantile disorder" - is now nearly 20 years old, is hopelessly inadequate for whatever computer application you have in mind today -- FWIW, FORTRAN is a bit more than 20 years old now; the first FORTRAN was written in 1954-57
- PL/I - "the fatal disease" - belongs more to the problem set than to the solution set.
- The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense.
- APL is a mistake, carried through to perfection. It is the language of the future for the programming techniques of the past; it creates a new generation of coding bums.
I hesitate to think of what he would have to say about SmalltalkLanguage
, or any other language the self-anointed think is a good language.
Dijkstra was of course speaking of BasicLanguage
in general, not VisualBasic
was created to be an interactive alternative to batch FortranLanguage
. It is not known whether it was the interactivity that Dijkstra thought ruined students or the particular semantics Dartmouth chose for their language.
DartmouthBasic, and most of the variants that followed until the late 1980s, had only one control structure (FOR) and required extensive use of Gotos, which is probably the source of EwDijkstra's complaint. This has little to do with modern BASIC.
I actually think that EwDijkstra
objected at least as much to the interactive nature of BASIC. He was very big on formal proofs. I think he objected to the "hack it till it works" approach that many self-taught BASIC programmers followed.
It's worse than that. BASIC had single-letter variables, no control constructs, every line was numbered, subroutines were called by line number ...
programmer I have ever worked with declares their variables. The statement Option Explicit (a checkbox in the options dialog does this for you) will require you to declare your variables in much the same way that the PerlLanguage
"use strict" pragma does. -- NoahClements
VB is different from most other dynamic languages in that if you don't set mandatory declarations, then unassigned references are assumed 'nil' instead of a run-time error. If you wanted to avoid stealth nils, Option Explicit is just about a must. -- top
Lest we forget how VisualBasic
. It makes spiking (but not finishing) a huge project much easier if each coder "owns" one module, and all the modules link together thru COM (ComponentObjectModel
) instead of just getting bound into one EXE. This exploits VB's absolutely miserable support for the dependency management and script-based compiling that real languages take for granted. -- PhlIp
VisualBasic (at least VB5)
does not support putting user-defined Types (UDTs) into Collections. (VB "Type" = CeeCeePlusPlus
"struct" = Pascal "record".) So, when things get complex to the point where you'd want to do this, you're forced to either upgrade to full-fledged objects (COM classes) or downgrade to hacking (typically delimiter-separated fields in strings). Most VB programmers I know, being uncomfortable with classes, will jump right down to the hacking level. -- JeffGrigg
Alternatives include using MS-Jet tables, or using an invisible Grid widget. The nice thing about the latter is that you can see your structure for debugging and testing. Can't vouch for machine efficiency with it though.
That doesn't make the tool bad. It's the programmer who isn't learning the features! That's like saying a CeePlusPlus
programmer refuses to learn classes! -- InformedThirdParty?
I suspect it's more accurate to say The VB Committee has yet to learn the needs of real programmers. -- PhlIp
programmers should really learn to accept and use COM classes, rather than do hacks with strings. But there are pervasive cultural issues in the VB community that work against that. (Like, COBOL 85/95 programmers who are still writing COBOL-68, and (yes there are some!!!)
C++ programmers who don't know what a class
is.) -- JeffGrigg
Here's a clear cut, institutionalized example of the VB effect:
If you buy this particular 4th party Code Review add-in module and plug it into VB, it will read your code and review it.
If you then declare a variable inside a block, the Code Reviewer will tell you "All variables should be declared at the top of the current procedure, to ensure they are initialized properly."
Translation: "VB can't do nested scopes on variables. You can use a variable outside the block that appears to scope it. Therefore you might accidentally use it before it's assigned properly. Therefore VB is not even a StructuredProgramming
anguage. So you must learn a bad habit to overcome this."
Ironic. I find that declaring variables at the top of long procedures makes it more likely that we won't initialize them properly. It's good to have initialization close to use. If declaration is separated from usage, then the range of code where the variable's value is valid can become ambiguous. (cf. DeclareVariablesAtFirstUse
) However, to avoid upsetting the natives, when programming in VB, I follow the bad practice of putting all variable declarations at the top of each function. -- JeffGrigg
And the good practice of ShortMethods. If you can find a healthy Refactor Pattern that does not leave these functions just one long function in disguise. -- PhlIp
Have you ever lost a perfectly good job because your colleagues were all using VB exactly
the way they were supposed to, and the project ran absurdly late and your boss fired everyone and closed the company down? Some people make up what they bash MicroSoft
about, or read material on the Linux newsgroups. And some can speak from personal experience. -- PhlIp
No, I haven't, and I have never met anybody who told me a story about it. Why don't you tell your story instead of just making innuendos?
I would have to say that's the developers' problem, not VisualBasic's. When VisualBasic is in the right hands, it can work wonders. Granted it's not TheBest, but it can GetTheJobDone?. Like any other language, it has its advantages and disadvantages.
You can't blame the language for not getting the job done. If anything, blame the person that picked VisualBasic! If VisualBasic couldn't fit the requirements, somebody didn't do the research to PickTheRightToolForTheJob.
Just my 2 cents.
Given any random GuruProgrammer?
, what job would VisualBasic
be the right tool for?
Glue language for a bunch of ComComponents. That's about it.
My personal experience contradicts EwDijkstra
's claim that BasicLanguage
ruins a programmer forever. Recently, an ex-VBer who's now doing JavaLanguage
came to me for help with an object design. I sketched the UML outline of a pattern-dense design (AbstractFactory
) on the whiteboard. He tilted his head one way, and said "Hmmm." Then he tilted his head the other way and said "hmmm." Then he scratched his head, said "I think I see what you're saying," and two hours later came back with very well done code implementing that design.
I don't always see people catching on to that many new things that quickly. I've had positive experiences with other ex-BASIC programmers as well. I wonder what the difference is between my ex-BASICers and Ed's.
I myself have started programming with BASIC V2 (yes, on an old Commodore VC20, with GoTo
and line-numbers!). Today, I draw UML diagrams. I don't say, that BASIC is a good programming language to begin with, but such sentences are just exaggeration.
You weren't here for the VisualBasic wars, so you can't pronounce it an exaggeration.
What I referred to, was the sentence of EwDijkstra
. -- JuergenLindemeyer
That's funny. I started programming with QuickBasic
and wrote several games in it having no knowledge of functions, subs, or arrays. It was a giant maze of GoTo
statements and reused variables. I think I finally learned my lesson when I was trying to debug my 4D-Tic-Tac-Toe game and gave up in frustration. -- PatrickParker
I started programming in Applesoft BASIC and managed to pick up first ProceduralProgramming
and then ObjectOrientedProgramming
. So I was not brain damaged by BASIC, either. I do think that the old-style BasicLanguage
and, to a lesser extent, VisualBasic
, will teach you bad habits, however.
I notice that when I hack VB code for my web page, I fall into all sorts of bad programming habits, for some reason or another. It also happens whenever I use PerlLanguage
. -- KenWronkiewicz
I too was not permanently spoiled by BasicLanguage
. I started with BASIC on a Sinclair ZX81, progressing to CBM BASIC, QuickBasic
, and even a little early VisualBasic
. By that time, of course, I was skilled in proper structured and ObjectOrientedDesign
. The first couple of versions of VB turned me off to it forever, not because it was unstructured, but because I always had to resort to hacking in order to get the job done.
Anyhow, with all respect, I think Dijkstra's comment reeks of the CorrelationImpliesCausation
fallacy. In particular, it would imply that it's also difficult for someone to be a JavaLanguage
programmer and at the same time be adroit in AssemblyLanguage
, an hypothesis that (I hope) is demonstrably untrue.
Let's assume that 90% of BASIC developers never recover. (I don't know that this is the case, but let's assume it for the sake of discussion.) This doesn't mean that BASIC "mentally mutilated" them. It could be that skillful developers quickly go on to more expressive languages, leaving only those unable to master higher concepts to remain BASIC programmers. Or it could be that unskilled programmers are inordinately drawn to BASIC, for similar reasons.
code I've seen reminds me of straight CeeLanguage
, with long list of variable definitions up front, reuse of single a declaration multiple times, and random organization of functions within file. Although there are probably exceptions, most of the VB coders I am aware of have yet to switch from a ProceduralProgramming
style to an ObjectOriented
style. In this regard, EwDijkstra
may be correct. -- WayneMack
But most of the VB coders I know (I know dozens) write completely in an object-oriented fashion using classes. Any language has the ability to be abused. One must invest in books, skills to learn something completely, to be aware of both its limitations and strengths.
I'm curious, Sam, and you might have an insight here. I don't have much experience with VB; most of the stuff I code for (numerical) can't run on small (e.g., winboxes) machines - and where it can it needs to be pretty close to the metal. So I may be out to lunch here. But I have followed some issues from a distance with interest, especially CORBA/COM etc. as ideas that always made a lot of sense to me. And it seems to me that VB derives pretty much all of its power and utility from the component model. So here is my question: WhyVisualBasic
? -- AnonymousDonor
If I understand your question correctly, you have already given the answer. It is very easy to extend VB with new functionality using COM. I will not defend VB here, but repeat what other have said before: The chosen tool does not make the programmer. Using an object oriented tool does not make object oriented code. An exception is a tool where everything are objects. But then again, choosing such a tool does not guarantee clean or quality code. Why I use VB? Because I create pretty good code with it. -- ThomasEyde
No, that wasn't the question. IMO, none of the usefulness/value of VB comes from the Basic
part. You could have all of the rad and COM stuff with some other language as a base. So the question was, why start with Basic? My contention was that it could
have been a much better language, with a different starting point...
The worst one can say about BASIC (VB) is that it is an absolutely inconsistent language. The best one can say about BASIC (VB) is that there are absolutely no obstacles for changing the language or adding new features because it can't be made worse. No standards. No principles. It's a creature that's born to survive. -- AnonymousDonor
As in WorseIsBetter ?
VB is based on old languages, and thus has built up cruft over the years. I bet JavaLanguage
will do the same. It will gain every fad as it ages, and be ugly in 20 or so years also. -- top
I wonder if WithBlocks
teach bad habits.
This page sounds like nothing but a disguised HolyWar
. Non-OOP and LongFunctions
that don't violate OnceAndOnlyOnce
are not objectively worse. If you don't like that practice personally, that is fine, but please don't get a big head about it. -- top
[Someone who doesn't understand that factoring out common functionality increases the maintainability of code (as well as aiding you in writing bug-free code) has no business working as a programmer. I won't debate about OOP because I believe the benefits are highly subjective, but the idea that long swaths of highly duplicative code are in some way "good" is ridiculous.]
Nobody here proposed repetition that I know of. LongFunctions
do not necessarily have repetition. -- top
If a programmer only knows one language, and one way of thinking about how to solve problems, VB bad habits are probably the least of his problems. Remember, you can write FORTRAN in any language, and, conversely, I'd say, a good programmer can write good code in any language, too. [Some languages make the task harder, of course, but it can still be done.
I see a lot of comments hinting that ProgrammingIsInTheMind
, and that BadCodeCanBeWrittenInAnyLanguage
Here is a one line easy to understand program in VbScript
that would take hours if not days to do in C#. Go have fun with it:
After you spend 3-4 hours failing to implement it, read http://zones.advisor.com/doc/11639
then spend another 2 hours then give up. Then come back and tell me the virtues of RapidApplicationDevelopment
. This example single-handedly destroyed my confidence in CeeSharp
This seems to be off topic but it is quite easy to do in CeeSharp
// Add references to Microsoft Access and Microsoft dao
static void Main()
Not one line but not exactly challenging -- and less than 10 minutes start to finish.
See also VbIsBadForNewbies