"You have to respect a man who isn't about to let mere ignorance keep him from having an opinion."

Amen to that.

Then he put a question to the audience: "What specific things about VB6 make it an anti-pattern?"

You would think that he would have avoided that question if he knew how unfamiliar he was.

So go into your underhanded pitch.. why is Option Explicit in VB6 an anti-pattern?

I think you have to know Richard Hale Shaw to know just how "on character" that statement was. He is just a classic very opinionated person. Sometimes he even does have data to back up his opinions and in this case he was probably just gathering that data without as much work as it would have taken to actually use VB (he is a long time C++ bigot and proud of it).

Also, ReSharper (http://www.jetbrains.com/resharper/) is a godsend. It's a VS.NET 2003 plug-in for C# that adds background compiling along with a host of other features that should be in any IDE worth a damn (refactoring, code generation, etc.). If there was something like ReSharper for VB.NET, I would consider using VB.NET more often.

I never use /* */ comment syntax in C# and I can't imagine a good reason anyone would other than personal preference. It definitely shouldn't be listed in "top ten" list of reasons not to use VB.NET when there are other much better reasons... tool support being the main one for me, there are a lot of other great tools like ReSharper that are C# only.

I currently maintain a code base written in both VB.NET and C# (really, don't ask) and there is much more friction than I expected.

There is supposed to be a VB.NET version of ReSharper-- I saw a post from one of the JetBrains developers that indicated they were working on it.

Option Explicit (off) is pretty evil-- all variables "just work" without declaration. Leads to a lot of typo-style bugs..

Before VB.NET 2003, I hadn't used VB since version 3, ten years ago. I was really surprised to see "option explicit" still in there!

Um a number of observations:

Firstly I think one problem we have is that VB.NET and VC#.NET programmers can do the same task the same way but typically they do think differently. This isn't bad it just "is". I don't have a problem with functions not returning values. For some reason, when I code little details like my function achieving a point are on the top of my list. Maybe it's the intellisense, the case-insensitivity, the With block, autoindentation or the CrLf logical line termination that frees up my mind to spin on those little matters.

In VB8 I'm actually annoyed by the background compiler telling me my variables aren't used, I wouldn't mind it on a build, but as soon as I declare a variable I have to hear about how I haven't used it.

I agree, background compilation should be turn-offable. Secondly you should never have 31 projects with 1,000 classes each open at the same time, working on them, using project references. Friends don't let friends develop Enterprise Applications by themselves. Seriously, get a team.

Multiline strings would be nice, I don't remember seeing any C# syntax for that either though (or were you describing strings with next lines in them?) multiline comments, I'm sorry but I've never considered typing ' a big enough hassel to complain, perhaps if I had to type // I'd be irritated. Middle-of-line comments, why would you use this?

As for unitialized variables, ValueTypes are preinitialized, I think you know this. Reference types are initialized to Nothing and I seem to remember that well enough. However, in VB (I assumed in C#) when you have a bug due to a null reference VS tends to open the code file and highlight the line and throw up a big box, so no, I don't have problems tracking those down.

Your problem wasn't that you moved to VB.NET, the problem was that you were a bunch of C# coders moving to VB.NET and even that's not the greatest of excuses. I thought you guys were suppose to have all that natural discipline and hardcore 1337 5k!115.

In all fairness you have some legitimate concern about my language and I respect them as valid.

While I don't often find myself spanning lines of code across 15 logical lines I suppose that's an issue. However in terms of multi-line comments none of the code from Microsoft that I see uses them, I think the message is clear that to get good Enterprise level code you should only use \\.

I don't know if it was fixed or not but last I checked C# has no intellisense ability with respect to Enumerations, neither with setting/checking variable values or passing parameters to methods. This bothers me.

C# more literally reflects the Event model but I really like declaring events the VB way without the middle step.

So in C# do you guys have to declare a wrapper method to expose an interface member under an alternate name?

I always thought the purpose of ref arguments was to get out return values, leave it to C# to invent a near useless redundant argument passing mechanism (I know the counter-argument so don't bother).

Damn I wish we had XML comments, you guys definately won out there.

Using is overkill. It's nice when you don't care about the exceptions that pop up and when you only have 1 object to track. Nested Using blocks are worse than nested With blocks. If you're already using it's not like you have to do that much work for Try/Catch/Finally (Type Try, hit Enter, most of the work is done now). The more variables you have to dispose of the less useful Using is. If you really want to streamline the process, Declare this somewhere global:

Friend Sub IDispose(ParamArray iDisposables as System.IDisposable())
If iDisposables Is Nothing Then Return

For Each iDisposable As System.IDisposable In iDisposables
If Not iDisposable Is Nothing Then iDisposable.Dispose()
Next
End Sub

yeah I know, I overloaded the identifier a lot and I don't apologize for it, not like I have to look at it all the time. With a method like that you could Dispose of 100 objects in 1 line placed in your finally block.

...
Try
...
Finally
IDispose(fsIn, fsOut, myForm, someObject, moreObject, otherStuff, tooManyObjectsWithUnmanagedResourcesInThisMethod)
End Try

We just think differently. That's why the two languages coexist - We're not all the same.

"you guys"? I use VB! I think you might have me confused with the person whose post I quoted from Paul Vick's post:

http://www.panopticoncentral.net/archive/2004/05/28/1085.aspx

While a few of the points are valid, as always the language you choose to develop with against the .NET framework has less to do with productivity than the overall talent of the developer. Inherently, one language will be easier to use for this functionality or that functionality, but come on its the same CLR. Its like arguing over whether chocolate or vanilla is better its just opinion. I get so tired of this discussion. Just think if each .NET developer who had argued about this had used that much time to learn the other language, or least parts there would be much less arguing. In closing it does the .NET community a great disservice, and is counter productive.

But chocolate IS vastly superior to vanilla in every way.

Just ran across this on the Web.

Jeff, you were there, I would have thought you'd have gotten your facts straight. My reply was, "what does that do? I'm not very familiar with that feature of VB6." After you described it, I remembered it. If I recall, I even talked about why it's a problem that a language even needs a feature like that.

Interestingly you used my indictment of VB6 to indict VB.NET; and yet my discussion had little to do with VB.NET per se.

So maybe you need to get your facts straight, Jeff.
Regards,
RHS

Where do VB.NET programmers come from? I know where C# programmers come from. They go to college and study computer science where they learn C, C++ and Java. From what I've seen, you get VB.NET programmers from VB Programmers who became VB Programmers because they were teaching themselves how to write software in the first place. Calling VB 6 code programming is like calling an MS Access user a Database Administrator.

People without CS degrees who get into VB.NET don't have the same sophistication in their technique or depth of computer understanding, and the needs of these less sophisticated developers are reflected in crappier tools and the weaker constraints of the language. VB.NET programmers are expected to make some software but not realy commercial enterprise applications. I mean come on, if you want a programmer to write multi-threaded n-tier client/server applications where they have to manage thread contention over shared resources, optimize database access resources, program asynchronous IO calls, and understand how the CPU processes context switching to make good solid stable robust scalable code, would you want the typical VB.NET (formerly VB self taught) programmer or the typical C# (formerly C++, Java, C, Lisp) programmer? Who would you rather do your multi-million dollar big software development project?

By the way, I found this thread by googling for "VB.NET SUCKS" (I guess that means I'm not un-biased).

AND YES, CHOCOLATE *IS* BETTER THAN VANILLA!

Ok I look forward to your backlash of comments. Flame on VB guys I got it comming to me...

To do a multiline comment:

select the block of code then,
ctrl + k then ctrl + c

to remove multiline comment:

select the block of code then,
ctrl + k then ctrl + u

No flame David B. You're just wrong because you're overgeneralizing.

Some of us are well trained and experienced in C/C++ , but our companies dictate that we program in VB.NET. With what they're paying me, I'll program in VB.NET with a big smile on my face, and use C/C++ on my linux machine at home.

BTW, I've done "multi-threaded n-tier client/server applications where they have to manage thread contention over shared resources, optimize database access resources, program asynchronous IO calls" just fine in VB.NET thank you.

spacca: Also, don't forget the GUI way too. Select the code block, click the "Comment text out the selected lines" button. And to reverse it, click the "Uncomment the selected lines" button.

Note: This feature, along with the keyboard shortcuts, have been in the VB IDE since (I think) VB5.

David B.: One of the points you are missing is that if you are going to hang a picture on your wall, which would you use to get the job done quickly: A 16 oz. hammer or a 5 pound sledgehammer? (Something to think about: Holes in the wall larger than your fist)

Most people know now (after more than a decade of VB's existence) that VB (VB3-6, VB.NET) has always been considered a RAD language. If you don't know what RAD is Google "VB RAD". And, yes there is a right way and a wrong way to implement RAD. The same as there is a right way and wrong way to hang a picture on your wall.

Basically, choose the right tool for the job. C/C++/Java are all good languages (Java leaves some things to be desired...) as are VB/VB.NET and C#. One thing to always remember, which is going to get the job done quicker? I'll bet you that I can code a database app with full transactions and validation along with a useful and functional GUI quicker in VB.NET than you can in C/C++/Java. I've been there on the C++ front with a DB app and it took me longer to declare and implement all the necessary ADO calls than in the similar app created in VB.

On the same note, I wouldn't use VB for low level functionality that C can accomplish quickly and efficiently.

Just for fun, code a full accounting system in assembly... ;)

Heh... Try this in visual studio:

1.) Create a new asp.net web application (vb.net). Import System.Data.SqlClient.
2.) Create a class library in the same solution.
3.) Add to that class library a function with 31 input parameters
4.) put a button on the webform1.aspx page (or whatever page you have set as your start page for debugging). Create an event handler for the button.
5.) In the event handler declare a SqlParameter and assign it a value. Also put in a call to your function with 31 input parameters. Put a breakpoint anywhere in the function.
6.) Start the solution in debug mode. Now, click on the button and try to reference the value of the SqlParameter in the immediate window; you'll get something like this:

? paramApplication_id.Value
error: cannot obtain value
paramApplication_id.Value = 1
System Error &H80131313&

To my knowledge this issue popped up randomly in the past week, perhaps Microsoft put out a patch that screwed up memory handling. Anyway, if you run into this problem, be aware that it's the number of input parameters you're passing to the function that's causing it. I spent about 5 hours trying to track this down, hopefully you won't be so lucky...

Well... I think that settles that. I think it's quite obvious by now, and that everyone is very much aware that VB.Net is a much better product. Bravo Microsoft. BRAVO!

To dave b, i agree with Mako. I too am in the same situation where I have been told to use VB.Net rather than C#.NET . Your comments are childish. My college (pre university) course taught VB6 as the primary language and I taught myself C.

When you say in vb.net your project will take 2 to 3 times longer i agree, i have been working on a project which i would probobly have finished by now and be selling, but because of the 'advantages' of vb.net i am so far behind its unreal, like nearly 8 months behind, and i would just scrap what i have done and recode the whole thing in vb6 again, but i have something like 35 forms, and 10,000's of lines of code which simply wont work if you copy it back into vb6, i dont really have much choice then to stick with it.

another thing i hate about vb.net is it is so fussy and buggy, for example if i copy the code (which works) from my desktop pc to my laptop , so i can work on it when im not at home, the program just doesnt work, and im talking about things like, closing one form and opening another straight afterwards. vb6....simple and easy. vb.net, it doesnt work if i run it on my laptop, but it works fine on my desktop PC, ?!?!?!!?!?!?!!?!?! wtf? they are both 32bit systems, the only difference is my laptop is just a bit faster. why would the code not work. and if i compile the program on my desktop pc and run it on the laptop it works, if i compile it on my laptop, it doesnt work, the program just crashes.

christ and i have had 100's of other problems, including control arrays, that was so easy and usefull in vb6, but nooooooo. M$ scraped it and made their own code based way to do it, which i have never gotten to work.

i thought it would be a good idea to finally catch upto the 'latest and greatest' technology and stick with vb.net. i was SO wrong. just stick to the old stuff, it works fine.

i hate vb.net and i hope they fix stupid problems like this soon, you would have thought with all their money and resources microsoft would produce a decent bit of software.

My company has its entire system written in vb6. Iam relatively new in the company, and men... I F**in hate vb6!!!!!! Its just sooooo painful.

Global variables everywere, stupid functions that dont return values, freakin dimAs, absolutely no abstraction... Maybe is just because the system is so big(CRM, finnancing, and production). I dunno... But its hard to read and it sucks, and the worst thing of all is that iam obligued to do bad programming practices....
Ahh, I almost forgot, the aplications run soooo slow, but then it may be because the DB is in MS access....

Yeah called me closed-minded, but there's no comparison to c++ and java(even c#). OO rules.

To VB.crap:

I used VB6 at my job because it's what we were told to use. My programs are not littered with globals, they use abstraction, interfaces and are object oriented when OO models the solution to the problem. It sounds to me like your programmers suck.

To DavidB:

You don't know squat. I've met plenty of CS degree holding programmers who could not write a binary sort. I've also met some programmers who've no degree and could code concentric circles around most CS degree holders -- yourself included I'm sure.

Oh, and it's spelled "coming."

C++ is NOT the end all of "OO" programming. Neither is Java. I'm not convinced that "OO" is even the end all paradigm of modeling software. A good programmer knows when to use procedural, functional, and object oriented constructs; when they should be used together; and how to use them together properly.

Patrick; you, my friend, are my hero. :)

Patrick

You nailed it - Its not the language - its the resources that choose certain langauages historically that have sided with bad software design approaches. Good software design - patterns, OO design and such - seems to be luxory anymore. It has been my experience that many from the VB6 have given VB developers a bad name in the choice of software design. I run multiple C# projects and often find bad design choices that we have had too clean up also.

Its my belief that starting a project without a software architect is like building a house without a plan. You can (and probably should) design software without even looking at a line of code.

Thanks, Tim.

Although I do agree that a plan is necessary before you start coding, I'm not of the mind that one should go about drawing all sorts of UML diagrams, flowcharts and hierarchy charts before he gets there. I prefer to define the outputs and define the inputs. If it's a large enough project, then I might even lay out some sort of organizational chart. Then I'll design the database layout, if one is involved. Then I'll start coding. Once the software is done it will look *nothing* like any of those UML diagrams. In my opinion they only stifle ones ability to adjust to new specifications and unforeseen circumstances. Plus they're a real bitch to keep synchronized to your application. Eventually the code dictates the UML, instead of the UML dictating the code.

"Eventually the code dictates the UML"
WOW, I am glad I don't work with VB programmers.
Please stick to VB... leave c# to the educated professionals.

You can leave the completed projects with us too.

Thanks.

Interesting discussion. I code vb.net, and that was a personal choice. I've been in the game a long time, long enough for ALL the knowledge I have (that is still relevant) to be self taught. I haven't recently had much call for the Lisp and Fortran we used back when I got my Diploma in computer science. I've used all sorts since, Pl/1, COBOL, Basic, Assembly, DL/1 and probably dozens of others I can barely remember.

At the end of the day what matters is not the syntax of any particular language, not even how "explicit" its compiler forces a coder to be. A good coder can use ANY tool, and will recognise, understand and work with it's limitations ... and just plain get on with the job.

The environment I much prefer to work in actually has no concept of data type, let alone an "option explicit", with a database and coding language that allows variables to be declaried implicitly, and doesn't care if you use a variable as a string in one statement, a numeric in the next and a boolean in another. Complete anarchy! Yet it can produce systems - that work - at a speed that would make your eyes water.

Oh, and Sam, one mans educated professional is another mans wet behind the ears graduate. ;)

Phil nailed it rather well 2 months ago.

If there's one thing that shows ignorance faster than anything else, it's dualistic thinking...Apple vs. PC, Con vs. Lib, non-straight vs. straight, Dem vs. Repub, Hillary vs Obama, VB.NET vs C#.NET... ALL of these dualisms are rooted in ignorance.

(Although hands down the dumbest post here was the guy that equated C#ers as consummate professionals, and VBers as unmitigated self-taught neanderthals! If I were that poster's boss and saw that post, I'd likely remove that person from my staff pronto, on the basis that he was just too dumb to be allowed anywhere near a keyboard.)

Coding is coding. The various flavors of languages out there are exactly that...FLAVORS. Some go better with one meal over another. Some appeal to some tasters' palates more than another...but beyond that, considering one wholly superior to another is pure folly. As Phil so aplty puts it, a true 'gourmand' appreciates ALL the nuances available at the coding smorgasbord, and uses them to best suit HIS particular purpose at the moment.

Any perspective less broad than that only labels the owner of that perspective as a person of diminished capacity, hypocritically pointing at the shortcomings of others.

BTW, it was those self-taught VBers that DROVE the creation of the curriculum that now allows the C#ers to TAKE those courses...because when those intrepid 'cutting edge' VB do-it-yourselfers were coming through school, THEY knew more than their teachers...THEY were the ones forging the way so that today's candy-ass coders could COAST through secondary school and beyond and GET educated in the 'flavor-of-the-moment languages. How many of TODAY's young C#ers would have had the pure intellectual capacity to teach THEMSELVES anything that wasn't served up on a silver platter to them?

One should never disparage those who've gone before you, blazing the trail. Instead, one should revere them....and pay it forward.

All coding is not coding.
If all you have is Java experience I cannot hire you to fill our embedded automotive programming position.
If all you've done is assembly & C coding I can't hire you for our .Net developer position.

And all tools are not just flavors of each other.
We have work to do, if you want to draw a construction analogy, the debate ought to be which is the best truck to use and you're claiming an electric-powered 3rd-world import golf-cart is just as good as... an actual truck.

There is no "trail-blazer" VB programmer.
Dijkstra, Bressingham, & Carmack were about the last trail blazers.

The recent movement to padded-walls languages in CS college curriculum's just makes that degree worth less.

PS It is by definition not possible to do OO programming in VB6 because VB6 did not support inheritance.

It's remarkable how these debates reveal character.

You can see:
1) Balanced versus Bigotted
2) Fact Free vs Fact Based
3) I'm more educated, a better human being... than you are
3) Inflexible vs...

I think it would be really powerful if I could try out some matrix based code (APL/J style), some stack based coding (Forth/HP 41 C style), so set thinking (T-SQL style but better), Functional... in the same code base. No starting a new solution, just use the right tool. F# might be getting there but it's not all the way.

Computer Languages are for humans, it's great to see some flexible balanced humans in here. (Remember some of the commenters are just trolling, there might actually be more rounded people behind the post.)

Wouldn't it be great to have a way of uniquely identifying each poster (like a GUID) then permanently marking those who waste your time so that can filter them out, here, in blog comments, in newsgroups and in forums. (The danger is that some of them might become people who you do want to pay attention to.)

Some people identify a problem, and then seek the best course of action, and eventually, solution. During this process they are likely to enjoy both discovering how things work and making them work.

Other people, instead of looking for the solution to the real-world problem, are seeking to apply the methods that will give them the satisfaction, while results come only next - not disregarded though.

Which satisfaction? The one that -supposedly- verifies their fairy tale: "How much of a programmer am I???!".

Fighting over which language is the best, is abstraction!! It cannot be used "as is" in a real conversation. Lets try saying "C# is best when..." or "VB is best when...." (like some people have already tried). THEN everything we say will count as an argument.

If I can achieve good memory/CPU/thread/you-name-it management with VB AND do the job nicely AND on time then choice is just a matter of what I am getting my kicks off.

But if I HAVE to, just HAVE to, use C# because "educated professionals" like me don't understand "End If", unless it is spelt "}", then my friends, I do have a personal problem. I NEED to believe that I am a scientist more than I need to do my job/hobby (or whatever reason one is programming for).

That said, I have the utmost respect for both languages, acknowledging their pros and cons. Due to the fact that I am self-taught, VB6 originating programmer, but not an "educated professional" (even though I get money AND merit for my work, people are probably crazy around here), I 've opted for VB.NET, while not writing-out the possibility of shifting in the future.

Lol!!

I love some of the analogies here, especially the one about the construction trucks.

If the truck (i.e. the language) is the tool to get the job done, and the programmer is the driver, whether your boss gives you an actual truck or a "electric-powered 3rd-world import golf-cart" to get the job done, your still expected to do it.

This is where the whole "better language battle" is irrelevant. A driver who is highly trained and familiar with a "electric-powered 3rd-world import golf-cart" (and it is really.... really hard to make a comparison between any modern programming language and a golf-cart) will still do a better job than a person who has very little experience driving a truck.

On a personal note, if your boss tells you to program in a given language because that's what your company uses, your better learn the syntax of that language pretty well, or start updating your resume. Otherwise, a programmers ability to create a solid program is directly proportional to his experience in a language and his mastery of concepts in a given paradigm(functional vs. procedural vs. OO)