A VB.NET Critique

[Eric]

There is a VB.NET critique on the following page:
http://www.vb7-critique.741.com/
for those who are interested. Feel free to take a look and share your
thoughts.

Cheers, Eric.

Ps: for those on comp.programmin g, this may be off topic, but I've
posted there because the critique was part of a discussion in that
group.

[Herfried K. Wagner [MVP]]

* er********@emai l.com (Eric) scripsit:

There is a VB.NET critique on the following page:
http://www.vb7-critique.741.com/
for those who are interested. Feel free to take a look and share your
thoughts.

<http://www.vb7-critique.741.co m/VB7_Semantics_C ritique.htm>:

I don't understand what's bad to allow to call a procedure recursively.
The "problem" applies to every function the "user" of the programming
language can write. Leaving "that out" is IMO a useless exception.

<http://www.vb7-critique.741.co m/VB7_OOP_Critiqu e.htm>:

As I am not a native English-speaker, I don't have any problem to
understand the meaning of 'MustInherit'. If I use a programming
language, I read its syntax definition first and then have a look at the
code.

<http://www.vb7-critique.741.co m/VB7_Type_System _Critique.htm>:

Array bases: Yes, I agree, that's a problem. But it's not a problem of
VB.NET. There was a lot of discussion in the early beta phase of
..NET/VB.NET. I never liked 0-based arrays. I would prefer arrays like
in VB6. The same for the declaration of arrays (specifying of the upper
bound and not the number of elements). This problem can be solved by
changing the default start index of arrays to 1.

Field Initializers: ACK. That's an ugly limitation.

<http://www.vb7-critique.741.co m/VB7_Syntax_Crit ique.htm>:

This code would be IMO really ugly because of the assignment to a
variable which doesn't seem to have a type:

\\\
Dim c = 1, d = 2, e As Integer = 3
///

I'll go to bed now...

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>

[David]

I should really trim the group list, but your PS made me unsure about
it.

On 2004-01-04, Eric <er********@ema il.com> wrote:

There is a VB.NET critique on the following page:
http://www.vb7-critique.741.com/
for those who are interested. Feel free to take a look and share your
thoughts.
OK, a few thoughts, starting with the Syntax section.

The long rant about multiple initializations makes some sense, but I
personally find all of your alternatives to be much worse and much less
readable. Putting the type after the varname in declarations makes a
lot of usable syntax impossible, but that's just complaining about Basic
being Basic.

The Is operator tests whether two references are identical, it makes
absolutely no sense to allow it to apply to value types. Really, that's
just not understanding what a value type is. And as for TypeOf, again
it makes absolutely no sense to apply to a value type; there is simply
no possible reasonable use of such a feature. Should the language still
allow programmers to do nonsensical things for the sake of completeness;
maybe, but that's exactly what you're ranting *against* when you
complain about the fact that Sub Main can be recursive. Make up your
mind.

And if you really think
Dim p as Point = {12,15}
is much simpler and easier to read than
Dim p as New Point(12, 15)
then I'm kinda glad you don't do language design.
You cannot declare an optional parameter which is of a structure type. Public Sub Foo(Optional Arg As SomeStructure = Nothing) 'this wont compile
Why the limitation, when the above makes perfect sense?

Because the above doesn't make perfect sense, in fact it makes
absolutely no sense at all.

I'll zoom through a few other things. First, .Length in arrays and
..Count in collections aren't measuring the same thing, and it would be
much more confusing if two properties with such different meanings had
the same name. The constant complaints that objects must be initialized
(such as arrays and strings) just eludes me somewhat; I honestly find
the behavior to be perfectly logical and simple. And the idea that
zero-based arrays are more error prone is little more than personal
opinion, and one that flys in the face of an awful lot of comp sci
literature.

I think you have some decent points to make, but it seems like half of
the essay stems from a total misunderstandin g of .NET types and an
insistence on working with Option Strict Off. I agree with some of your
points, structure semantics are a mess, array declarations are error
prone, but unfortunately I also think that the good points are buried in
a morass of long rants that either exhibit misunderstandin g of the
language or are simply nit-picking at silly thing (e.g, the
"MustInheri t" example, the disgruntled employee with bad variables names
(would names like 'AAAAAAA' be any more readable?)).

All in all, I think the essay would be much more useful if you could
separate the "this is a problematic construction and here's why" issues
from the "I would have done it this way" issues.

Hey, you asked for comments...

--
David
dfoster at
hotpop dot com

[Cor]

Hi Eric,

It looks very much written from a personal view.

Although there are elements in it that can be thought about are there also
elements that has been discussed here also and have been criticized here,
but have an understandable reason by instance arrays and collections.

You are able to give your comments to the VB.net development group. There
are many chats in with you can participate. Serious things (and even stupid
things) are there normally threaten seriously.

An example of that what it makes a personal view is this. You are talking
about UK date format, are you talking in future about the US measure system
(miles) and the UK measure system (meters)?

Just my thoughts

Cor

[Eric]

Thank you all for taking some time to read the critique and sharing
your thoughts. I have been working full time trying to keep up with
the responses in this group:

http://tinyurl.com/2jszd

and will make some time tomorrow to respond more fully to the
responses here on Google groups.

Thanks again,
Eric.

Ps: David I think it's safe if you want to trim the group list now. I
think the regulars of comp.programmin g who would take interest in the
critique have already seen the post.

er********@emai l.com (Eric) wrote in message news:<ca******* *************** ****@posting.go ogle.com>...

There is a VB.NET critique on the following page:
http://www.vb7-critique.741.com/
for those who are interested. Feel free to take a look and share your
thoughts.

Cheers, Eric.

Ps: for those on comp.programmin g, this may be off topic, but I've
posted there because the critique was part of a discussion in that
group.

[Programmer Dude]

David wrote:

I think you have some decent points to make, but it seems like half
of the essay stems from a total misunderstandin g of .NET types and
an insistence on working with Option Strict Off. I agree with some
of your points, [...], but unfortunately I also think that the good
points are buried in a morass of long rants that either exhibit
misunderstandin g of the language or are simply nit-picking at silly
thing...

I will second that opinion. It's almost exactly what I thought as
I was reading it.

--
|_ CJSonnack <Ch***@Sonnack. com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ _______________ ____| Call: 1-800-DEV-NULL |
|______________ _______________ _______________ _|_____________ __________|

[Eric]

hi************* **@gmx.at (Herfried K. Wagner [MVP]) wrote in message news:<OZ******* *******@TK2MSFT NGP10.phx.gbl>. ..

<http://www.vb7-critique.741.co m/VB7_Semantics_C ritique.htm>:

I don't understand what's bad to allow to call a procedure recursively.
The "problem" applies to every function the "user" of the programming
language can write. Leaving "that out" is IMO a useless exception.
You are right about allowing recursive procedure calls. I'm not
against recursion in general (its an essential algorithmic tool), I
just feel that allowing recursion on Main() is both unnecessary and
dangerous due to the problems it can create. The semantic value of
Main() makes it special and different to all other procedures.
Consider for instance, to make recursion on Main() work like recursion
on any other procedure, Main() would need to allow parameters (which
it doesnt) and the user would need to be able to directly invoke all
the initialisation steps that take place before the run-time calls
Main() during program start-up. Again, that is something the user
can't do.

Opinions will differ, but my view is that since this feature (allowing
Main() to be called by the user) has little or no application and in
fact creates problems in some cases, it should be taken it out. I
admit its not a major issue, but like that nail that you dont see
round the corner until you step on it, leaving it in is IMO not such a
good idea.

<http://www.vb7-critique.741.co m/VB7_OOP_Critiqu e.htm>:

As I am not a native English-speaker, I don't have any problem to
understand the meaning of 'MustInherit'. If I use a programming
language, I read its syntax definition first and then have a look at the
code.
That is commendable indeed and is really the only way to get the
complete picture (or part of the complete picture) of a language. I
too am not a native English-speaker and when I first encountered
'MustInherit' the reason for the choice of words was immediately
apparent and I asked no further questions. One thing to note however
is that we are both *experienced* developers and we both probably had
a taste of all of OOP in languages other than VB (e.g Java or C++).
Experienced developers, by definition, will have more knowledge about
things and will ask less questions. But from a language design point
of view, one also needs to consider experienced programmers who've
never done OOP before and beginner-level programmers (especially since
VB has a reputation of attracting complete biginners). What may be
obvious to the experienced developers may not be obvious to the
beginning developers. The questions I say may be asked about
MustInherit, are imagined to be those that would be asked by a person
completely new to OOP and or programming. If one previously knows
about the rules for abstract classes then MustInherit is crystal
clear, but if one doesn't and questions why this keyword was chosen, I
would imagine that the questions I pose in that section, would also
come to their mind.
<http://www.vb7-critique.741.co m/VB7_Type_System _Critique.htm>:

Array bases: Yes, I agree, that's a problem. But it's not a problem of
VB.NET.
I understand the implementers wanted to be as close to the .NET CTS as
possible, but wouldnt they have been able to still provide a one-based
view of arrays? Granted, that would cause a slight loss of efficiency
but at the gain of the intuitiveness of one-based arrays which further
helps in the development of correct algorithms. A slower but correct
algorithm is countless times more valuable than a fast but incorrect
algorithm.

VB6 allowed n-based arrays (for all positive and negative integral
values of n, where 0 and 1 were most common) so no matter what choice
was made someone was bound to have their toes stepped upon. But such
is the nature of all design choices and I am glad that MS atleast
standardized on a single base for arrays (the situation in VB6 of
different possible bases for any array was quite problematic).

The 2 most common arguments I've heard for zero-based arrays is
efficiency and the fact that "every other language" does it that way
because its the "nature of computer science". Fair enough, but if
Moore's law continues to hold, the first argument will increasingly
become a non-issue (if it isn't one already) for a good chunk of
programs that VB developers make and as for the second argument, I
believe the creator of Ruby has some good advice:

"Be nice to others. Consider interface first: man-to-man,
man-to-machine, and machine-to-machine. And again remember the human
factor is important."
(http://www.artima.com/intv/craft2.html)
There was a lot of discussion in the early beta phase of
.NET/VB.NET. I never liked 0-based arrays. I would prefer arrays like
in VB6. The same for the declaration of arrays (specifying of the upper
bound and not the number of elements). This problem can be solved by
changing the default start index of arrays to 1.
After spending a good number of years using patterns that depend on
the base being 1, the new zero-based world of VB.NET makes me stumble
continously. Alas, change is inevitable (though not all change is
necessary) and I along with other people will just have to get used to
it.
Field Initializers: ACK. That's an ugly limitation.

<http://www.vb7-critique.741.co m/VB7_Syntax_Crit ique.htm>:

This code would be IMO really ugly because of the assignment to a
variable which doesn't seem to have a type:

\\\
Dim c = 1, d = 2, e As Integer = 3
///
Yeah, it does look kinda weird and is a rather unfortunate side-effect
of having the type name appear after the variable name. It was just a
suggestion and I am glad that atleast one person views it as ugly -
that helps add balance to the views which is important if Paul Vick
and his team ever decide to look at the critique.
I'll go to bed now...

Thank you very much for your time Herfried, and for sharing your
views.

Cheers,
Eric :)

[Eric]

David <df*****@127.0. 0.1> wrote in message news:<sl******* *************@w oofix.local.dom >...

OK, a few thoughts,
Thank you for spending some time to look at the critique.
starting with the Syntax section.
It seems this section has recieved the most attention in many
responses. It is hardly surprising since syntax is where a lot of
things are subjective.

The long rant about multiple initializations makes some sense
Yes, that section will need to be rewritten to be more concise. Others
have had the same impression and after re-reading it myself, I get the
same view.
but I personally find all of your alternatives to be much worse and much less
readable.
Fair enough, some others have thought the same thing too. IIRC, I
think I came up with that proposal like this. I had initially given
the declarations like so:

Dim c, d, e As Integer

then later on realised that I wanted to initialise all three variables
at their point of declaration, so I assumed one could just do this:

Dim c = 1, d = 2, e As Integer = 3

but obviously the compiler didn't agree with me. It does look awkward,
because as you mention below, the type name coming after the variable
name makes a lot of usable syntax impossible.
Putting the type after the varname in declarations makes a
lot of usable syntax impossible, but that's just complaining about Basic
being Basic.
I know what you mean :). At the end of the day, I guess one could just
settle for typing a few more characters and use this:

Dim c As Integer = 1, d As Integer = 2, e As Integer = 3

and afterall, a certain degree of verbosity is, IMO, what makes VB
easier to understand so its no biggie.
The Is operator tests whether two references are identical, it makes
absolutely no sense to allow it to apply to value types. Really, that's
just not understanding what a value type is. And as for TypeOf, again
it makes absolutely no sense to apply to a value type; there is simply
no possible reasonable use of such a feature. Should the language still
allow programmers to do nonsensical things for the sake of completeness;
maybe, but that's exactly what you're ranting *against* when you
complain about the fact that Sub Main can be recursive. Make up your
mind.
I will quote myself from another group, to show my reasoning behind
that argument:

<quote start>

This is going to be an interesting problem area of the .NET CTS
resulting from the difficult (and in some ways, pointless) goal of
type unification. Everything in .NET (and hence VB7) *is* an object
because all types either directly or indirectly inherit from Object.
If you agree with me so far, then you will also agree that *all* types
in .NET are actually *reference* types its just that *some* of those
reference types (those that inherit from ValueType) have *value
semantics*. Now then, the Is operator checks if two variables refer to
the same object. By way of logical deduction, the Is operator should
work in all cases because it works on object types and every type in
..NET is an object. The problem? It doesn't. While it is easy to accept
that and just work with it, the issue is still a consistency problem
from a language design point of view and is of more relevance to those
interested in language design. Such exceptions have to be made all the
time when one attempts type unification. Other examples abound in .NET
but to see this in a different language look at this article on the
Blue language (especially section 3.3): http://tinyurl.com/yryyz

<quote end>
And if you really think
Dim p as Point = {12,15}
is much simpler and easier to read than
Dim p as New Point(12, 15)
then I'm kinda glad you don't do language design.
:) It being easier to read is again subjective and my exposure to
C/C++ seems to be showing here (and yes, I know VB isn't C/C++ and nor
should it be). However, as for it being *simpler* (a notion which is
still subjective but one that is easier to give arguments for or
against) I said the following:

"...the variation I am suggesting, is conceptually simpler, IMO. With
the current syntax you have to understand constructors and their
semantics, use of the 'New' keyword both in variable declarations and
definitions of constructors, and finally, use of named arguments."

Opinions will differ, so it would be nice if someone can find and
present arguments that show it not to be simpler, so we can have
atleast two points of view to consider.

You cannot declare an optional parameter which is of a structure type.

Public Sub Foo(Optional Arg As SomeStructure = Nothing)

'this wont compile
Why the limitation, when the above makes perfect sense?

Because the above doesn't make perfect sense, in fact it makes
absolutely no sense at all.

Could you perhaps expand a little on your point of view? Given what
the language reference says about the Nothing keyword:

"The Nothing keyword represents the default value of any data type.
Assigning Nothing to a variable sets it to the default value for its
declared type. If that type contains variable members, they are all
set to their default values."

that syntax restriction on optional structure arguments still seems to
be an arbitrary limitation to me. Part of the problem stems from the
fact that VB.NET requires you to explicitly provide a default value
for optional parameters - a requirement which is somewhat redundant
since VB states that variables will always be automatically
initialised to the default value of their type. Maybe there is a good
reason for the limitation and if someone can point it out to me, I
will stand corrected.
I'll zoom through a few other things. First, .Length in arrays and
.Count in collections aren't measuring the same thing, and it would be
much more confusing if two properties with such different meanings had
the same name.
They have different meanings? Thats not the impression I get when I
read the documentation of those respective properties:

*Array.Length
Gets a 32-bit integer that represents the total number of elements in
all the dimensions of the System.Array.

*ICollection.Co unt
When implemented by a class, gets the number of elements contained in
the System.Collecti ons.ICollection .

The big give-away being the substring "number of elements" appearing
in *both* definitions.
The constant complaints that objects must be initialized
(such as arrays and strings) just eludes me somewhat; I honestly find
the behavior to be perfectly logical and simple.
Fair enough. I honestly dont find this behaviour logical and simple:

Dim arr1() As Integer
Debug.Assert(ar r1.Length = 0) 'exception thrown here

Dim arr2() As Integer = {}
Debug.Assert(ar r.Length = 0) 'no exception thrown here

but again, opinions differ. My complaint is geared towards some of the
types being half way between the value-type and reference-type
categories, which is one of the unfortunate side-effects of the goal
of type unification. The basis for my complaint about the Length
property is given in the "Arrays as objects" section:

"I now have to worry about null references while am using arrays. For
instance, the Length property should logically contain zero when an
array has no elements. However, because a reference to an array
without elements is a null reference, I can't check the Length of an
uninitialised array without getting a NullReferenceEx ception. If
arrays were not objects or the compiler was kind enough to 'cheat' and
return 0 for the expressions like "MyArray.Length " when MyArray was
null, I could retrieve certain info (array length, number of
dimensions and upper bounds of each dimension) without ever worrying
about null references."

Properties such as the number of dimensions, the upper bound of each
dimension and the length of an array should be things that you can
find out whether the array has elements or not. This is especially so
if you are not using dynamic arrays but I guess it isnt simply because
VB doesnt allow you to declare fixed size arrays. Actually that last
sentence may not be entirely true, because I came across an attribute
called VBFixedArrayAtt ribute that may allow declaration of fixed size
arrays but I will need to look into it.
And the idea that
zero-based arrays are more error prone is little more than personal
opinion, and one that flys in the face of an awful lot of comp sci
literature.
See my initial response to Herfried about this one.
I think you have some decent points to make,
Thank you :)
but it seems like half of
the essay stems from a total misunderstandin g of .NET types
I am human and hence prone to being wrong, but I can confidently say
(without meaning to sound haughty) that I have a fairly good if not
firm understanding of the .NET type system. I am always open to
correction, but I have attempted to provide the basis for my reasoning
(see earlier on in this response, where I quote myself from another
group) and hopefully someone can see where I am coming from with
respect to some of my arguments about the type system.
and an insistence on working with Option Strict Off.
Actually, I write all my production code with Option Strict On. I
don't quite remember if Option Strict was On in every instance where I
wrote the snippets, but I will confirm that in the next revision of
the critique.
I agree with some of your
points, structure semantics are a mess, array declarations are error
prone, but unfortunately I also think that the good points are buried in
a morass of long rants
Yeah, I will need to revise some parts to remove the unnecessary "blah
blah" and make the points more concise.
are simply nit-picking at silly thing (e.g, the
"MustInheri t" example, the disgruntled employee with bad variables names
(would names like 'AAAAAAA' be any more readable?)).
See my initial response to Herfried, for my reasoning on the
'MustInherit' example. As for the variable names consisting purely of
underscores and the disgruntled employee, the basis for my argument is
similar to that for a recursive Main(): IMO, unnecessary flexibility
is just as bad as no flexibility.
All in all, I think the essay would be much more useful if you could
separate the "this is a problematic construction and here's why" issues
from the "I would have done it this way" issues.
I am currently investigating a different format for the next
revision, so as to make the essay more useful. Many thanks for that
suggestion.
Hey, you asked for comments...

And great comments I got :). Thanks for sharing yours.

Cheers,
Eric :)

[Programmer Dude]

Just a couple random thoughts....
Eric wrote:

At the end of the day, I guess one could just
settle for typing a few more characters and use this:

Dim c As Integer = 1, d As Integer = 2, e As Integer = 3
I'm a big proponent of:

Dim c As Integer = 1 ' .....
Dim d As Integer = 2 ' .....
Dim e As Integer = 3 ' .....

Because it helps you to add documentation as to the purpose
of your variables. I also think it's easier to read and gives
you a better picture of how many locals you have.

Everything in .NET (and hence VB7) *is* an object because all
types either directly or indirectly inherit from Object.
I just started reading about C# last month and then set it aside
for other matters, but isn't it true the native types in C# do
NOT inherit from Object? If that's so, perhaps therein lies the
motivation?

C# does seem to have some "gotchas" with regard to the semantics
of native vs: object types.

By way of logical deduction, the Is operator should work in all
cases because it works on object types and every type in
.NET is an object. The problem? It doesn't.
I don't agree it should. The sematics of the Is operator, AIUI,
is to compare, essentially, the "pointers". The semantics of
a non-object type are such it doesn't HAVE a "pointer".

I think it is well to make distinct the semantics of "equal VALUE"
and "equal references". Just MO.
Regarding:
*Array.Length
...
*ICollection.Co unt

Arrays are Lists are quite distinct types, although languages like
VB can blur that distinction somewhat.

Consider that .Length and .Count can be DIFFERENT in an array,
but not (in almost all normal cases) in a collection. What I mean
is that an array might have a .Length of 50, but only a .Count of
10 items (the rest set to Nothing). Because reallocating an array
is expensive, it's not an uncommon technique.
--
|_ CJSonnack <Ch***@Sonnack. com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ _______________ ____| Call: 1-800-DEV-NULL |
|______________ _______________ _______________ _|_____________ __________|

[Daniel O'Connell]

"Programmer Dude" <Ch***@Sonnack. com> wrote in message
news:3F******** *******@Sonnack .com...

Just a couple random thoughts....
Eric wrote:

At the end of the day, I guess one could just
settle for typing a few more characters and use this:

Dim c As Integer = 1, d As Integer = 2, e As Integer = 3
I'm a big proponent of:

Dim c As Integer = 1 ' .....
Dim d As Integer = 2 ' .....
Dim e As Integer = 3 ' .....

Because it helps you to add documentation as to the purpose
of your variables. I also think it's easier to read and gives
you a better picture of how many locals you have.

Everything in .NET (and hence VB7) *is* an object because all
types either directly or indirectly inherit from Object.

I just started reading about C# last month and then set it aside
for other matters, but isn't it true the native types in C# do
NOT inherit from Object? If that's so, perhaps therein lies the
motivation?

Not quite, C# natives(int, uint, char, etc) are aliases to the System
equivilents(Sys tem.Int32, System.UInt32, System.Char respectivly). Each of
these values are value types which are *NOT* reference types with value
semantics, they are value types. In the case of
Dim x as Integer
You get a value on the stack that exists at a specific offset, not a
reference to an object. No reference to x will likely ever exist(not sure
what happens in the case of ref parameters with value types, though it may
be a copy back), to get a reference to an object with the value of x(not x
itself, note) requires you to assign it to a variable of type object(in
VB.NET or C# anyway, C++ requires the use of the __box keyword). Boxing
creates an object on the heap and returns a reference to it, this allows
value types to be passed into parameters typed as Object and to be treated
as reference type when needed, but to be value types in most other cases

Dim x As Integer
Dim o as Object
Dim y as Object
o = x ' o is a reference type, refering to the object containing the boxed
value of x
y = x ' y is a reference type, refering to the object containing the boxed
value of x
o is y ' I would still expect this to return false, they should be different
references.

o = x ' o is a reference, refering to the object containing the boxed value
of x
y = o ' y is a reference, containing the same reference as x
o is y ' this should return true


C# does seem to have some "gotchas" with regard to the semantics
of native vs: object types. There should be none that don't exist elsewhere in the framework. VB may
make it a bit easier but the same issues are there.

By way of logical deduction, the Is operator should work in all
cases because it works on object types and every type in
.NET is an object. The problem? It doesn't.
I don't agree it should. The sematics of the Is operator, AIUI,
is to compare, essentially, the "pointers". The semantics of
a non-object type are such it doesn't HAVE a "pointer".

I think it is well to make distinct the semantics of "equal VALUE"
and "equal references". Just MO.

It has its values, in languages like C# you can't always be sure what you
are comparing with ==, object == object results in a reference compare,
string == string a value comparison, in most cases it doesn't matter, but
you have to be aware of that possibility. Certain static and instance
methods are used to perform explicit comparisons.

Regarding:

*Array.Length
...
*ICollection.Co unt

Arrays are Lists are quite distinct types, although languages like
VB can blur that distinction somewhat.

Consider that .Length and .Count can be DIFFERENT in an array,
but not (in almost all normal cases) in a collection. What I mean
is that an array might have a .Length of 50, but only a .Count of
10 items (the rest set to Nothing). Because reallocating an array
is expensive, it's not an uncommon technique.
--
|_ CJSonnack <Ch***@Sonnack. com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ _______________ ____| Call: 1-800-DEV-NULL |
|______________ _______________ _______________ _|_____________ __________|