Vb Teaches Bad Habits

There is nothing that VB can do, nothing!

(Sorry; it just cried out to be said. :-) ThereIsNothingPerlCannotDo.) ThereIsNothingAssemblerCannotDo


Some people believe that VisualBasic teaches new programmers bad habits.

Details:

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.

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.

-- EricUlevik


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, PythonLanguage, PerlLanguage, or any other language the self-anointed think is a good language.

Dijkstra was of course speaking of BasicLanguage in general, not VisualBasic from MicroSoft. DartmouthBasic 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.

-- StephanHouben

It's worse than that. BASIC had single-letter variables, no control constructs, every line was numbered, subroutines were called by line number ...


Every VisualBasic 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 promotes ActivexTechnology. 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

Right, VisualBasic 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."

-- PhlIp

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

See RefactoringInVisualBasic.


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.

-- DrewMarsh

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 + CompositePattern) 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.

-- JuergenLindemeyer

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.

-- TimKing


Most VisualBasic code I've seen reminds me of straight CeeLanguage code: LongFunctions, 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.

Sure does!

See WithBlockCodeSmell.


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:

createobject("access.application").DBEngine.Createdatabase "c:\db1.mdb",";LANGID=0x0409;CP=1252;COUNTRY=0"

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 in DotNet. 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

 namespace CreateDb?
 {
   class Program
    {
       static void Main()
       {
         (new Microsoft.Office.Interop.Access.Application())
              .DBEngine.CreateDatabase?(@"c:\Temp\db1.mdb", @";LANGID=0x0409;CP=1252;COUNTRY=0");
       }
   }
 }

Not one line but not exactly challenging -- and less than 10 minutes start to finish.


See also VbIsBadForNewbies, ToolsThatTeachPoorHabits


CategoryCoding


EditText of this page (last edited November 13, 2014) or FindPage with title or text search