Lambda the Ultimate

Six years later, I am still a VB addict and the new VB.NET comes as a breath of fresh air. But suddenly things aren't so simple anymore. VB in its .NET incarnation, has matured into a powerful language with a whole host of features. True OOP is a breeze, it has shift operators, function overloading and soon there will be operator overloading, unsigned types and even generics.

Searching for a VB critique on google doesn't give you much to work on. You run into Verity Stob's "13 ways to loathe VB" and the occassional snide remarks from some programmers that VB is just a toy. Working with VB.NET in the last year prompted me to write a critique on it to set things straight. Hopefully the critique will be of value from a language design perspective and give an idea of the issues that can arise when languages evolve too suddenly.

[Start Edited Section]
Here is the link: http://www.vb7-critique.741.com/

The critique files have now been relocated to another site at the above link. My thanks goes to Ehud for temporarily hosting the files on LtU.
[End Edit Section]

Although I've done a bunch of VB6, I haven't really done anything with VB7, preferring to convert over to C#. Other than familiarity with VB, I don't see much advantages of VB or C# (but I do see advantages to going to C#).

I use VB.Net because it's what "we" (both of "us") use at work. The only substantial reasons I can think of for choosing C# over VB.Net are aesthetic, in that it might be annoying to have to use special keywords like AddHandler and AddressOf to do things with delegates that C# does without them. Otherwise there's no great pain involved in having to use VB.Net instead of C# - I don't really miss operator overloading, for instance.

I still don't really understand why VB.Net exists, given that it is so much like C#. I suppose it's meant to be easier to learn for VB6 coders; but actually, I've found what I know of Java considerably more helpful in getting to grips with the language than what I know of VB6. On the whole, the less like VB6 a language is, the better in my view.

My findings are in the form of that critique (link given in first post).

I am curious, what language did you use before VB6? C/C++ perhaps?? If so, then going to C# is a natural move to make. There are far too many people falling for the (IMO, somewhat ridiculous) idea that VB7 is so different from VB6 that they might as well move to a new language, namely C#. In fact, its all too tempting to do so, given the great similarities between C# and VB7.

To move to VB7 from VB6 you only have to do away with a limited amount of knowlegde/habits. To move from VB6 to C#? You not only have to throw practically everything you know about VB, but *also* learn a new language, with new syntax(that famous semicolon, case sentivity...), new semantics, a new type system, a new mentality (VB7 is multiparadigm, C# follows my pet peeve: the 'everything is an object' philosophy), and a totally new standard library. Then you have to learn new ways of getting things done, C# style....Its not a trivial task as some seem to assume and I would recommend this only to people with little experience and investment in VB (since then you have little to lose).

In a sense, I believe there is a psychological factor behind that migration idea. VB programmers have often been belittled in an industry mainly dominated by C/C++ programmers - the very programmers who would be more likely to use C#. Now that C# is out, some VB programmers may feel that by taking it up, they may gain more credibility in the eyes of those who scorned them. It is not unlike someone joining a street gang in order to escape oppression from that gang.

I spend a good sum of my time reading open source code, most of which is in C/C++ (all the goodies: apache, linux, sendmail, gcc, KDE, GNOME, Mozilla, Mesa etc). As a result, I can read and understand C/C++ without difficulty (more C really, C++ is another story). I spent a good deal of time learning C and C++, and even contemplated abandoning VB and move to them. The culture shock from the semantic and syntactical differences was too much to handle and to this day I can read C and C++ but dont try to write software with them. I'd be interested to hear the experiences of other VB programmers who try this with C#.

In your case, what advantages do you see in going to C#?

Cheers,Eric.

I totally agree with you that the only major reason for choosing C# over VB.NET is that of aesthetic preference. However, I highly doubt it that a programmer who's primary language is VB, will find using words like AddHandler and RemoveHandler to be annoying. It is part of the core nature of VB and many VB programmers do *like* the more verbose syntax - it leaves no room for second guessing. The statement below is idiomatic C# (you have to be told what it means - its hard to guess what's going on)

this.foo += new EventHandler(this.fooHandler);

and the same one in VB7:

AddHandler Me.foo, Me.FooHandler

leaves plenty of room for a good guess (and is, funnily enough, *less* verbose than the C# version). Furthermore, given one's knowledge of the += operator in C#, someone can easily interpret the C# version as:

this.foo = this.foo + new EventHandler(this.fooHandler);

which can lead to a conceptual dazzler: What does it mean to add an event handler object and an event? what is the result?...etc. There's just more room for complexity IMO, whereas the AddHandler version of VB says it all in single line.

You said:

"I still don't really understand why VB.Net exists, given that it is so much like C#"

How about turning that around to:

"I still don't really understand why C# exists, given that it is so much like VB.NET"

in fact a better version is:

"I still don't really understand why C# exists, given that it is so much like Java"

Languages dont have to be mutually exclusive, regardless of the amount of similarities between them. C# exists for the C/C++/Java programmers who want to move to .NET, while VB.NET exists for the VB6 programmers who want to move to .NET.

Finally, you said:

"I've found what I know of Java considerably more helpful in getting to grips with the language than what I know of VB6."

which is all too natural really :) C# and Java are very similar. Also since VB6 doesnt have complete OOP support, it would offer very little help when you move into the "everything is an object" world of C# ;).

Cheers,Eric.

If find it annoying that to initialize a new object of type foo in Java/C#/VB.NET I have to write something like:

foo bar = new foo();

instead of just

foo new bar;

or some such. Yes, I know you can initialize bar with a type derived from foo, but very often you just use the same type. Anyway, you could allow both styles.

BTW VB6 allowed:

Dim bar as new foo

I hate the Dim keyword (I mean what does dimension have to do with variable declaration) and this syntax means more than what you’d expect (dynamic instantiation - actually a cool feature (also missing from VB7), but the concise syntax is very appealing.

I also don't get the point of VB.NET. Seems to me that the similarity to VB6 is more misleading than helpful. But then, I also don't get the point of JScript.NET. And if you loose these two, well then you're left only with C#, and .NET is supposed to be a VM with multiple PLs.

Paul Vick a member of the VB.Net team addressed this issue on his blog.

foo bar();

is it an instance definition or a function declaration?

Stroustrop considered changing it to be something similar to Java's but decided in the end that backward compatibility was paramount.

Aaaah, the good old Dim keyword :). Although clearly not the best keyword for the job, its still reasonably applicable. A declaration essentially says to the compiler "reserve some memory big enough to hold values of type T" (among other things). The word "dimension" when used as a verb in a sentence such as "dimension X", essentially says "indicate the dimensions/size/length/width of X". So a declaration like:

Dim X As Integer

ends up reading like "the Dim(ensions) of X, are the same As those of Integer" or something to that tune. I like to follow, what I call the "no-questions-asked" principle of language design: design a feature such that its so obvious whats happening that no questions will be asked. Applying that principle to variable declarations, yields a syntax like this:

Reserve <type name> Storage For <variable name>

with concrete examples like:

Reserve Integer Storage For X

That declaration pretty much says all you need to know to figure out what's happening - no questions asked :)

Dan wrote: "I also don't get the point of VB.NET. Seems to me that the similarity to VB6 is more misleading than helpful."

Hmm, I would say otherwise, because the similarities make the migration path from VB6 to VB7, a lot smoother. It would be disheartin g if there were no similarities at all. In moving to VB7 myself (not exclusively - I still write VB6) the only thing I can think of that is misleading is that the types "Integer" and "Long" have different sizes in the two versions, but still use the same keyword. Otherwise, I have found that the remaining VB6 features either work in VB7 as expected or not at all (i.e without the compiler or conversion wizard complaining), and vice versa.

Dan wrote: "But then, I also don't get the point of JScript.NET. And if you loose these two, well then you're left only with C#, and .NET is supposed to be a VM with multiple PLs."

JScript.NET is just JScript running under .NET. The point of its existence? Same purpose it served before .NET showed up, only this time with room for new possibilities (e.g access to that huge base class library). Generally for any language X, language X.NET is just X running under the CLR.

Finally, if you lose VB.NET and JScript.NET, you are left with more than just C# ;) The number of .NET languages is near 30 now (see http://www12.brinkster.com/brianr/languages.aspx) It just seems that VB and C# make the most noise :)

Cheers,Eric.

Actually, I'm not sure about this one. Yes, you need to reserve at least the amount of storage for an Integer. But there is more about being an Integer than just having storage. Also, I believe the new keyword has become so popular in mainstream PLs, it is universally understood.

> Hmm, I would say otherwise, because the similarities make the migration path from VB6 to VB7, a lot smoother.

While I've used both, I'm certainly not your typical VB programmer, nor are these my main environments. Thus I can easily be off base here. Still seems to me that the similarity is very much at the syntax level, while the semantics are different. This seems like a recipe for confusion.

> JScript.NET is just JScript running under .NET.

No it is not. JScript.NET does have a classic mode that is mostly like standard JavaScript, but in fast mode, which is the mode you should usually use when doing .NET programming, it very much isn't. For more information about the new modes and the various new datatypes see this blog.

> The number of .NET languages is near 30 now

Just the fact the somebody ported a PL more-or-less (often a bit less) to .NET does not, IMO, justify that PL's existence on that platform. It needs to provide some sort of added value, in my mind. Currently I can think of only two that seem to provide such added value: Managed Extensions for C++ and NetCOBOL. Maybe also Fortran for .NET. I'll be glad to learn about more.

> Actually, I'm not sure about this one. Yes, you need to reserve at least the amount of storage for an Integer. But there is more about being an Integer than just having storage.

You are quite right Dan. I failed to mention other details about that syntax, because I was explaining how it relates to the Dim keyword and storage size. In the language where this comes from, the programmer is taught that if they need to store data, they have to allocate storage appropriate for that data. Notice the word "appropriate". What determines the appropriateness of storage space for particular data? The type name does. It not only describes size for the storage, but the nature of values that go into that location as well as the operations that may be performed on those values (at least that's the minimum in this language anyway, other things include how optimisations are done on that storage such as caching and recycling, and how that memory behaves in multithreaded, possibly distributed, environments).

>Also, I believe the new keyword has become so popular in mainstream PLs, it is universally understood.

Indeed, though IMO, it should be only be associated with type's that have reference semantics (namely, objects). In VB.NET, structures have value semantics and are allocated on the stack, but you can still do this:

Dim s As SomeStruct = New SomeStruct(blah, blah)

That threw me off at first, because in all previous instances where I'd seen the word New in a language, it meant "release the current reference, allocate NEW memory for this kind of object, and initialise it with this constructor". (The "release current reference" here just means disassociate this variable with that previous object - it doesnt necessarily imply reference-counting GC). Only thing is, in VB.NET when you do that on structures, the first two steps (release, allocate) are not done and only the third one (initialise) is performed, while with objects, all three steps are done. I managed to get over it and found it quite useful (since I could switch from a structure to a class type without having to change code), despite the room for confusion.

>> JScript.NET is just JScript running under .NET.

> No it is not. JScript.NET does have a classic mode that is mostly like standard JavaScript, but in fast mode, which is the mode you should usually use when doing .NET programming, it very much isn't. For more information about the new modes and the various new datatypes see this blog.

Hehehe, this is going to be a common theme with a lot of languages I see! Thanks for pointing it out Dan. I think I'll go prowl the news groups to see if the Fortan, Cobol, Eiffel and all folks of .NET languages that existed in "classic" versions, are making as much noise about the changes as the VB guys have. History seems to be repeating itself. I remember the times when it was a very common question to ask on Usenet whether you need to learn C before learning C++. This question may resurface now given that VB.NET is as to VB as C++ is to C.

>> The number of .NET languages is near 30 now

>Just the fact the somebody ported a PL more-or-less (often a bit less) to .NET does not, IMO, justify that PL's existence on that platform. It needs to provide some sort of added value, in my mind. Currently I can think of only two that seem to provide such added value: Managed Extensions for C++ and NetCOBOL. Maybe also Fortran for .NET. I'll be glad to learn about more.

Yeah, I think so too. Many implementers may just be feeling the band-wagon effect and dont want to be left out of the .NET buzz: "Hey look! we have a .NET compiler for our language too!". In many cases, I think people are more experimenting with targeting the CLR, rather than aiming for production quality implementations (and if they are, then what gives?).

I'll have to check out Managed Extensions for C++. I imagine the folks who had to make C++ run on a managed platform, experienced a lot of sore thoughts!

Isn't that the truth! See this blog for all the greasily details.

The reason I singled out C++, COBOL and Fortran for .NET is that they seem to have been created with explicit intention of easing the migration of legacy code to that platform. While I haven't used any of these (I have used the C++ compiler but not the managed extensions), the C++ implementation lets you compile existing code as is AFAIK.

I must also be stated in Microsoft's favor that with VC7 they not only provided the managed extensions but also significantly improved standard compliance. It would have been very easy for them, and also in accordance to past behavior, to provide just the former and not the later.

As a result, you get the advantage of being able to use both .NET features and C++ features in the same app. For example, you can store references to .NET objects in STL containers.

To move to VB7 from VB6 you only have to do away with a limited amount of knowlegde/habits.

This is not so: to move code from VB6 to VB.NET (what you call "VB7") requires a complete rewrite and retest of the code because

• the syntax of VB.NET differs from that of VB6,
• the object models of VB.NET differ from those of VB6,
• the libraries of VB.NET differ from those of VB6,
• the automated migration tool cannot overcome the above differences and can make only limited changes. Manual editing and testing is always required for any non-trivial program.

Add to this the changes necessary for the VB6 developer to understand OOP in the VB.NET context and you have a failure-in-progress.

Although that is the general perception, I partially disagree. A complete rewrite and retest of the code is *advisable* (so that you can take full advantage of .NET) but it is not *required* - atleast not for all the code.

Furthermore, you have to take into account the *kind* of applications that you can write with VB6, because not all of them are affected by the changes made to VB. If you wrote GUI apps (which is what many would do with VB in fact) then you have a problem because the model has changed completely. If you did data access, you still have a problem but you can fall back on COM interop and still use DAO. If you wrote purely procedural code (like a 6,000 line string library I have) then a complete rewrite is not necessary.

>the syntax of VB.NET differs from that of VB6

Indeed it does, but again you have to consider *how* it differs. A language suffers when *omissions* are made to its syntax. When *additions* are made, the old code continues to work fine. Now some omissions were made to the syntax but in 99% of the cases the syntax elements were rare (e.g the DefInt clan, Imp and Eqv operators, GoSub etc) and hence not much of a hassle, or could be migrated automatically by the upgrade wizard (best example being the VB6 syntax for properties). So, either the element was rare and wont be missed, or it was common and can be upgraded automatically. Are there any syntactical differences you have in mind that you believe cause problems in moving to VB.NET?

>the object models of VB.NET differ from those of VB6

This perhaps is where the biggest challenge lies in the migration to VB.NET. There are two perspectives to consider: the library aspect and the user code aspect.

The library aspect is to do with the object models in the common libraries like ADO, DAO, and the file system object library. Though I haven't tried it yet, it appears that VS.NET can automatically create COM interop assemblies to wrap around the old models and allow you to continue to use them, so there is something to fall back on and you can still rely on your old knowledge. In the case where you want to use the new libraries, there is a learning curve but for experienced users its only slight (e.g doing file IO in VB.NET is a piece of cake if you were familiar with the file system object library of VB6...ADO.NET however is a bit more radical, especially if you are coming from DAO).

The user code aspect is to do with the object models that YOU create (as opposed to those done by MS). VB6 didnt give you much in the way of OOP so there are few things (if any) you could do that wouldnt port to VB7 (BTW, I call it VB7 'cause its easier to type than VB.NET <g>). The biggest difference is in implementing interfaces, but otherwise the OOP of VB6 is a perfect(?) subset of the full blown OOP of VB7.

>the libraries of VB.NET differ from those of VB6

*Some* differ but not *all*. The core libraries remain largely the same (Mid, Left, Right, UBound, LBound, Timer, MsgBox, InputBox etc all work). So once again, a complete rewrite isn't needed (and in some cases is actually *inadvisable*)

>the automated migration tool cannot overcome the above differences >and can make only limited changes. Manual editing and testing is >always required for any non-trivial program.

Agreed.

>Add to this the changes necessary for the VB6 developer to understand >OOP in the VB.NET context and you have a failure-in-progress.

Hmmm, perhaps you should have more faith in VB6 developers :). Any experienced VB6 developer who has done something non-trivial in VB6 will be well aware (I hope!) of the short-comings of OOP in VB6. They would know about encapsulation and data hiding, they would have faked inheritance using aggregation and delegation, faked overriding using delegation and done some polymorphism using the VB6 flavour of "Implements". In short, an experienced developer (many of which would have had exposure to some other languages) would know about OOP, but would have suffered from the lack of full support for it in VB6. The move to VB7 would be more a breath of fresh air (since now full OOP support is available) than a "failure-in-progress".

In the case of less experienced developers who didn't attempt to use OOP, or those experienced developers who programmed in a primarily procedural style (remember VB is multi-paradigm) the "changes necessary" don't make a difference because they didn't use OOP in the first place and have little or nothing to unlearn and relearn.

In summary, yes, there are many changes but those changes are not earth shattering - not to every VB6 developer and not to every type of non-trivial application that could be done in VB6.

All change is met with initial resistance - its human nature. However, I urge other VB6 developers to spend less time complaining (even though that is justifiable in some cases) and more time embracing VB.NET becomes with it come a lot of productivity enhancing features that were long overdue VB6.

Very few VB6 programmers have knowingly used any OOP features whatsoever. They are aware of components, but not of OOP. They moved to VB for ease-of-use; most will not move to VB.NET.

In summary, yes, there are many changes but those changes are not earth shattering - not to every VB6 developer and not to every type of non-trivial application that could be done in VB6.

Sadly you've apparently missed years of discussion on this topic and it shows. Publishing on the WWW in a zip file format rather than an HTML page is revealing. Any visit to such forums as news://www.devx.com/ (whose NNTP feed was recently shut down) during the last few years would have provided much needed feedback. Perhaps a personal investment in .NET is the primary reason for your attempts to support the platform despite it's failure.

However, I urge other VB6 developers to spend less time complaining (even though that is justifiable in some cases) and more time embracing VB.NET becomes with it come a lot of productivity enhancing features that were long overdue VB6.

Not gonna happen. Microsoft has already lost the majority of it's VB6 developers: they will not be using Microsoft'S .NET development software in the future.

As to the technical details, most of your post supports what I stated earlier.

I wish to warn managers to not be optimistic about migration to .NET: there is no doubt that migrating code from VB6 to VB.NET (what you call "VB7") requires a complete rewrite and retest of the code. Anyone who makes decisions without knowing that is making a foolish mistake.

Are you saying that as a prediction based on personal opinion or as statement based on facts and figures? I don't mean to sound confrontational - I'm just interested in knowing how you came to draw that conclusion.

>Sadly you've apparently missed years of discussion on this topic and it shows.

Well, would you care to point me to those discussions so I can see what others think?

>Publishing on the WWW in a zip file format rather than an HTML page is revealing.

You are just throwing in that one for good measure. I guess those who publish in PDF, Postscript and other formats not viewable directly in a browser are also uninformed? There have been over 700 reads of this discussion and no one else has complained. The zip file is a temporary arrangement made with Ehud. The critique will be posted on my own site (when its constructed) in due time.

>Perhaps a personal investment in .NET is the primary reason for your attempts to support the platform despite it's failure.

Despite its failure? .NET has failed has it? Its clear Xeo, that you are not a fan of .NET, but please backup your claims with valid points or otherwise indicate that you are giving an opinion.

>Not gonna happen. Microsoft has already lost the majority of it's VB6 developers: they will not be using Microsoft'S .NET development software in the future.

If you are speaking for yourself only then fine, otherwise, please show me the facts and figures to support your claim.

Well Xeo, thanks for sharing your views. Before this escalates into an unfriendly exchange, I will just say lets agree to disagree on some points and leave it at that.

Well, would you care to point me to those discussions so I can see what others think?

I provided one reference above( news://www.devx.com/ ), but like so many other sites, once interest plummetted and Microsoft ceased to market .NET so actively, then, well, interest plummetted!-) Recently too that site changed from a newsgroup format (NNTP) to HTTP, further reducing interest levels.

It would be difficult for you to go back and reread years worth of posts. But if you wish, you have Google, Google Groups and The WayBack Machine and others at your disposal.

As for me, I've been buried in the examination of .NET for more than four years. Why should my research be so easily available to you? The party's over and you arrived late; sorry.

There have been over 700 reads of this discussion and no one else has complained.

Actually, in the first reply on this topic Chris Rathman asked:

Any chance you can post your findings on a web page?

I merely underscored your naivete. It takes all of 15 minutes to put up a web page with text content - less time than to complain here. And I would say the same were you to use PDF or postscript.

Finally, please do not attack the messenger; you have either ignored or incredibly, supported the technical points I have made while nonetheless claiming that I am wrong. I stand by my arguments.

Out-of-channel question: Immediately after my previous post, lambda-the-ultimate.org attempted to connect to my system via NETBIOS. This reoccurred the first time I visited lambda-the-ultimate.org this morning. I am aware that an improperly-configured server will attempt a NETBIOS connect under certain circumstances, but it doesn't do so selectively. Is there an explanation for these intrusions?

Nothing that I am aware of. But since lambda-the-ultimate.org is a Userland hosted site, I don't know everything that's going on.

If anyone has information about this, let me know.

I do agree that Microsoft's message with regard to VB.NET was muddled at best. If the point was to ease and encourage the transition of VB developers to .NET, then they have missed. To do that they should have allowed VB programs to run unchanged on the .NET platform, even if slower and after a re-compile. The .NET features should have been provided as optional enhancements.

Instead Microsoft, apparently under the influence of Java-envy, decided to push its customers - the VB developers - where they didn't really want to go. I mean, even Microsoft admits that some of the interactive qualities of VB6 programming is still missing from .NET.

If find all this surprising since backward compatibility is the wintel hallmark.

I usually prowl Google groups from time to time, but have been pretty busy. I'll pop over and check it out sometime. Thanks for the links.

Xeo: >As for me, I've been buried in the examination of .NET for more than four years. Why should my research be so easily available to you?

Ummm, because it would be kind of you? <g>. No biggie Xeo. Its your research, so you are entitled to withhold it as you see fit <shrug>.

Xeo: >I merely underscored your naivete. It takes all of 15 minutes to put up a web page with text content - less time than to complain here. And I would say the same were you to use PDF or postscript.

Fair enough, but the way you initially expressed that concern carried belittling undertones. None-the-less, here is the site http://www.vb7-critique.741.com/

Xeo: >Finally, please do not attack the messenger; you have either ignored or incredibly, supported the technical points I have made while nonetheless claiming that I am wrong.

Not intending to attack the messenger, its just that you've left some of my questions unanswered, only provided 8 lines of "technical points", provided no proof for some of your claims, and withheld the findings of the four years of research that you say you've done. You may be right, but I'm not to just to naively digest your claims as facts when you have given little or no basis for them.

Xeo: >I stand by my arguments.

And I, by mine, until you can backup your claims with explanations, facts, and or figures. Surely your four years of research has yielded more than the four points you made in your initial post, no? So why the evasion of a point-by-point counter-argument to my claims which you state are wrong?

Have you attempted a migration .NET? Is VB your primary development language? If the answer to these questions is yes, and you are not a casual .NET/VB onlooker, then all the more reason for you to be able to justify your claims. That's all I ask for.

Great reasoning Dan. I hope Xeo can apply similar reasoning to see why I was refuting his claims.

Dan: >The .NET features should have been provided as optional enhancements.

This would have worked out quite well too because many of the new features are extensions rather than modifications.

Dan: >Instead Microsoft, apparently under the influence of Java-envy, decided to push its customers - the VB developers - where they didn't really want to go. I mean, even Microsoft admits that some of the interactive qualities of VB6 programming is still missing from .NET.

And the interactive qualities were what made VB6 so nice for rapid prototyping! I'm glad that Edit-n-Continue as well as code execution from the command window will be back in VB.NET Whidbey, due out later this year. I especially cant wait for generics and unsigned types because they will save me from the pain in the neck I have been experiencing in the last week while writing a compiler.