Not Another C# Versus VB Article (It has a lot to say about Anders and Delphi)

  • Thread starter Thread starter Arjang
  • Start date Start date
Robin Tucker said:
Will intellisense automatically stick a semi-colon at the end of a
statement? ;)
Click to expand...

AFAIK no, but it will help you to type keywords, similar to how it's
currently available for parts of VB.NET's 'Declare' statement.
 
Robin,

For me is not the adding of a semicolon, however inteligent keeping the
opening and clossing of paragraphs.

I like every day more that when I set an "if then" that there is than
automaticly created an end if. I see that with VBNet I even am nesting more
than I did in past.

I wished that in C# was that when I typed an "{" there was automatic an "}"
in place.

Cor
 
Yes, i have learned over time that nesting is generally bad for readability
and maintainability in any case. I try to unitise tests, even if it means
the same test might be repeated twice in a block - as a stupid noddy example
(note, I tend to do this when there are 2 or 3 or more nesting levels,
rather than this examples):


If aThing and not bThing Then
' Do thing 1
End If



If aThing Then
' Do thing 2
End If



rather than:


If aThing Then

If not bThing Then
' Do thing 1
End If

' Do thing 2

End If
 
Robin,

In your sample is in my opinion not much need for nesting.

However, there are a lot of situations, where a good nested written program
is much more readable than those from people who have force themselves not
to use that.

However just my thought,

Cor
 
Robin,

In your sample is in my opinion not much need for nesting.

However, there are a lot of situations, where a good nested written program
is much more readable than those from people who have force themselves not
to use that.

However just my thought,

Cor
Click to expand...
I would agree with Cor, but it is a matter of personal preference, I
prefer nesting rather than having complicated if clauses, I find I'm
less likely to make mistakes that way. I find it easier to read my
intentions later and easier to comment the code.

Doug Taylor
 
Yes, it's better for reading intentions to use nesting. But changing the
intention may be more difficult. I think IF nesting complexity is a common
quality metric (although it all depends on the situation).
 
Hi Doug,

Doug Taylor said:
There are a few inaccuracy in the article as regards the history of
Borland Pascal, which it claims was the first commercially available
Pascal.

For the record USCD was available prior to Borland Pascal 3 and of
course Anders and Niels Kompass Pascal 1 and 2 predate Phillipe Kahn
persuading them to remarket the company as Borland (appearing to be
American rather than European) and selling the product cheaply, if I
remember correctly the UK price was £35 as compared to £250 for
version 2, with a restrictive license.

Doug Taylor
Click to expand...

I bought a copy of Apple Pascal ca 1984. This was a version of the UCSD
pcode system. I paid $500 US for it ;) back then. What a world :).

Charles
 
Here's a rough translation (I did my best, chalk up minor mistakes to
artistic license... major ones to ignorance. Please forgive if I didn't
get it quite right) :)
IMO, this article [http://www.codeproject.com/useritems/CSharpVersusVB.asp]
is shaped by unfounded prejudices and based upon implications that are
"off-track". I went through the trouble to thoroughly study and comment on
the points made in "Propagation Of Culture in NET":
| 1. VB by default allows support for late binding. Although it can be
| turned off with "Option strict", the culture is such that it's usually
| left on. This leads to numerous difficult to catch errors. C# binding
| is always early.

This has no foundation. In the professional field most developers work with
'option Strict on'. If 'option Strict' is switched off, then usually from
technical considerations, it is to access a COM object model approximatley
like the one in [MS] Office. Here, a useful secondary(?) functional
characteristic is called a disadvantage.

| 2. VB still supports the old "On error goto" construct. This leads to
| sloppy or non-existent error handling. C# supports only the superior
| try.catch error handling.

Why does the existence of one additional error handling construct lead to
sloppier or non-existent error handling? VB.NET supports the superior
C#-style 'try...catch[...finally]' with ' Try...Catch...Finally'. In error
handling, VB.NET is superior to C#, since it makes a different construct
available, which covers a better diversity of applications.

| 3. VB supports optional parameters. Although VB developers often
| list this as an advantage, it is a disadvantage because the use of
| optional parameters weakens the contract between the caller and
| the method, allowing the developer to slacken his analysis and get
| away with it until bugs creep in. [note: C# param array construct is
| not the same as optional params]

Again this is not correct. VB supports optional parameters as a
secondary(?) functional characteristic. Sometimes within implementations
optional parameters prove useful. Don't forget there is also the "Overloads
Hell". You can compare the overloads of 'MessageBox.Show' with 'MsgBox',
with the former one must scroll through numerous overloading pages, until
you find the correct one, whereas you will find only one signature form with
'MsgBox' with several optional parameters. It is not disputed that
overloaded, in some cases is advisable. Instead of using too many
overloaded methods, however, optional parameters with their own, more
appropriate and more specific names are also provided. In no case there is
only one ideal solution.

| 4. VB supports the legacy VB functions, with reference to Microsoft.
| VisualBasic.dll. Many of these functions are slow and they should all
| be avoided in favor of the .NET framework. However many VB programmers
| still use them. In new VB projects, this dangerous namespace is included
| by default.

There are no recommendations on the part of Microsoft not to use
functionality from "Microsoft.VisualBasic.dll". "Microsoft.VisualBasic.dll"
can be seen as "language extension" of VB.NET and is just as
sensible/clear(?) as 'using' in C#. The namespace 'Microsoft.VisualBasic'
is in no way "dangerous", even if some of the functions are somewhat slower
than those of the .NET Framework, some of the functions in this namespace
are not provided at all in the .NET Framework (mathematics of finance,
'Left', 'right', 'fixed', 'Split' with character sequences as disconnecting
switches, etc...) and/or these functions are faster than those of the .NET
Framework.

| 5. VB allows implementation of interfaces with methods of different
| names, making it confusing and difficult to find the implementation. C#
| does not.

Due to the explicit implementation syntax of VB.NET ('Implements') it is
obvious which method of the class implements which interface method. In C #
this is not obvious, since the definition (?) of a method does not say
whether it was implemented as a method of an interface or established as
new.

| 6. VB supports background compilation. While this speeds the
development
| cycle for small projects, it slows down the IDE in large projects,
contributing
| at least in part to the culture tending to gravitate toward small
projects.

That applied unfortunately to VB.NET 2002, in version 2003 the situation was
substantially corrected. In VB it will probably still give some
improvements in regard to the speed of the background compiling to [VB.NET]
2005. If necessary, re-referencing projects (clean reference) can also give
an improvement.

| 7. C# namespaces are managed in way that makes programmers aware
| of namespaces and their importance. VB namespaces are managed in a
| way that hides them from the programmers by default. Careful attention
| to namespace management is a fundamental tenet of strong application
| design and its importance cannot be overestimated.

Using namespaces in VB.NET exactly the same as in C# prevents absolutely
nothing.

An unprofessional (?) developer will write bad code in both C# and VB.NET, a
good developer can write good code in in both programming languages.
Optional operators of a programming language are an advantage if they
support the professional user in his/her work. They are not bad, because a
fool does not know to use them correctly.

Translated from post by M S Herfried K. Wagner, M V P

Earl said:
How about translating the entire post!?
Click to expand...
 
Pretty darn good translation, from the looks of it! Thanks Michael.

Michael C# said:
Here's a rough translation (I did my best, chalk up minor mistakes to
artistic license... major ones to ignorance. Please forgive if I didn't
get it quite right) :)
IMO, this article
[http://www.codeproject.com/useritems/CSharpVersusVB.asp] is shaped by
unfounded prejudices and based upon implications that are "off-track". I
went through the trouble to thoroughly study and comment on the points
made in "Propagation Of Culture in NET":
| 1. VB by default allows support for late binding. Although it can be
| turned off with "Option strict", the culture is such that it's usually
| left on. This leads to numerous difficult to catch errors. C# binding
| is always early.

This has no foundation. In the professional field most developers work
with 'option Strict on'. If 'option Strict' is switched off, then usually
from technical considerations, it is to access a COM object model
approximatley like the one in [MS] Office. Here, a useful secondary(?)
functional characteristic is called a disadvantage.

| 2. VB still supports the old "On error goto" construct. This leads to
| sloppy or non-existent error handling. C# supports only the superior
| try.catch error handling.

Why does the existence of one additional error handling construct lead to
sloppier or non-existent error handling? VB.NET supports the superior
C#-style 'try...catch[...finally]' with ' Try...Catch...Finally'. In error
handling, VB.NET is superior to C#, since it makes a different construct
available, which covers a better diversity of applications.

| 3. VB supports optional parameters. Although VB developers often
| list this as an advantage, it is a disadvantage because the use of
| optional parameters weakens the contract between the caller and
| the method, allowing the developer to slacken his analysis and get
| away with it until bugs creep in. [note: C# param array construct is
| not the same as optional params]

Again this is not correct. VB supports optional parameters as a
secondary(?) functional characteristic. Sometimes within implementations
optional parameters prove useful. Don't forget there is also the
"Overloads Hell". You can compare the overloads of 'MessageBox.Show' with
'MsgBox', with the former one must scroll through numerous overloading
pages, until you find the correct one, whereas you will find only one
signature form with 'MsgBox' with several optional parameters. It is not
disputed that overloaded, in some cases is advisable. Instead of using
too many overloaded methods, however, optional parameters with their own,
more appropriate and more specific names are also provided. In no case
there is only one ideal solution.

| 4. VB supports the legacy VB functions, with reference to Microsoft.
| VisualBasic.dll. Many of these functions are slow and they should all
| be avoided in favor of the .NET framework. However many VB programmers
| still use them. In new VB projects, this dangerous namespace is
included
| by default.

There are no recommendations on the part of Microsoft not to use
functionality from "Microsoft.VisualBasic.dll".
"Microsoft.VisualBasic.dll" can be seen as "language extension" of VB.NET
and is just as sensible/clear(?) as 'using' in C#. The namespace
'Microsoft.VisualBasic' is in no way "dangerous", even if some of the
functions are somewhat slower than those of the .NET Framework, some of
the functions in this namespace are not provided at all in the .NET
Framework (mathematics of finance, 'Left', 'right', 'fixed', 'Split' with
character sequences as disconnecting switches, etc...) and/or these
functions are faster than those of the .NET Framework.

| 5. VB allows implementation of interfaces with methods of different
| names, making it confusing and difficult to find the implementation. C#
| does not.

Due to the explicit implementation syntax of VB.NET ('Implements') it is
obvious which method of the class implements which interface method. In C
# this is not obvious, since the definition (?) of a method does not say
whether it was implemented as a method of an interface or established as
new.

| 6. VB supports background compilation. While this speeds the
development
| cycle for small projects, it slows down the IDE in large projects,
contributing
| at least in part to the culture tending to gravitate toward small
projects.

That applied unfortunately to VB.NET 2002, in version 2003 the situation
was substantially corrected. In VB it will probably still give some
improvements in regard to the speed of the background compiling to
[VB.NET] 2005. If necessary, re-referencing projects (clean reference) can
also give an improvement.

| 7. C# namespaces are managed in way that makes programmers aware
| of namespaces and their importance. VB namespaces are managed in a
| way that hides them from the programmers by default. Careful attention
| to namespace management is a fundamental tenet of strong application
| design and its importance cannot be overestimated.

Using namespaces in VB.NET exactly the same as in C# prevents absolutely
nothing.

An unprofessional (?) developer will write bad code in both C# and VB.NET,
a good developer can write good code in in both programming languages.
Optional operators of a programming language are an advantage if they
support the professional user in his/her work. They are not bad, because
a fool does not know to use them correctly.

Translated from post by M S Herfried K. Wagner, M V P
Click to expand...
 
Addendum:
I feel sorry, but I currently don't have enough time to do that...
Click to expand...

Based on the requests, I'll translate and extend my critique and post it in
a few hours.
 
Hi Doug,



I bought a copy of Apple Pascal ca 1984. This was a version of the UCSD
pcode system. I paid $500 US for it ;) back then. What a world :).
Click to expand...

Which translates to around $2000 in todays money.

Doug.
 
You'll find the translation below:
http://www.codeproject.com/useritems/CSharpVersusVB.asp
Click to expand...

This article is IMO stamped by a number of unfounded prejudices and thus
includes some incorrect conclusions. I have taken some of the points made
in the section "Propagation of Culture in .NET" and commented them:

| 1. VB by default allows support for late binding. Although it can be
| turned off with "Option strict", the culture is such that it's usually
| left on. This leads to numerous difficult to catch errors. C# binding
| is always early.

This point doesn't apply to professional development. In a professional
environment, almost all developers work with 'Option Strict On', which will
make VB.NET more type-safe than C#. If 'Option Strict' is turned off, this
decision is based on technical considerations, for example, to ease access
to COM object models like those of Microsoft Office. The author of the
article constructs a disadvantage out from an additional, useful feature.

| 2. VB still supports the old "On error goto" construct. This leads to
| sloppy or non-existent error handling. C# supports only the superior
| try.catch error handling.

I don't see any reasons whe the existance of an /additional/ language
construct for error handling leads to sloppier code or non-existant error
handling. VB.NET supports 'Try...Catch' including 'When', which is superior
to C#'s 'try...catch' error handling structure. VB.NET provides advantages
over C# in matters of error/exception handling capabilities because it
provides constructs which match better with the different afforfances of
error/exception handling.

| 3. VB supports optional parameters. Although VB developers often
| list this as an advantage, it is a disadvantage because the use of
| optional parameters weakens the contract between the caller and
| the method, allowing the developer to slacken his analysis and get
| away with it until bugs creep in. [note: C# param array construct is
| not the same as optional params]

That's wrong too. VB.NET supports optional parameters as an additional
feature. Optional parameters provide advantages when used inside
implementations, and are thus useful in some situations. Don't forget that
methods using optional parameters do not suffer from the "overloads hell".
When comparing 'MsgBox' to 'MessageBox.Show' usability for the latter in
VS.NET is bad because you'll have to pick the right overload from a long
list. On the other hand, 'MsgBox' is a function with many optional
paramters, but usability doesn't suffer. While overloading makes sense in
some cases, I would not see it as a general replacement of optional
parameters, because makes writing code harder and will lead to
less-descriptive code. One other solution to this problem is to give the
methods more specific names instead of overloading a single, generic name.
Altogether there is not a single "best" solution, but there are many good
solution for different cases -- and optional parameters are one of them.

Overloading vs. Object Technology
<URL:http://www.inf.ethz.ch/personal/meyer/publications/joop/overloading.pdf>

| 4. VB supports the legacy VB functions, with reference to Microsoft.
| VisualBasic.dll. Many of these functions are slow and they should all
| be avoided in favor of the .NET framework. However many VB programmers
| still use them. In new VB projects, this dangerous namespace is included
| by default.

Wrong. Microsoft has never published a recommendation not to use
functionality implemented in
"Microsoft.VisualBasic.dll". "Microsoft.VisualBasic.dll" can be seen as a
"language extension" of the core VB.NET programming language. It's as
useful as 'using' in C# because it provides a shortcut to existing
functionality of the .NET Framework. Additionally 'Microsoft.VisualBasic'
contains functionality which is not present in the .NET Framework, like
support for financial mathematics, 'Left', 'Right', 'Fix', 'Split' with
support for strings as separators, ..., and it's absolutely not "dangerous"
to use this functionality. Some of the functions provided in
'Microsoft.VisualBasic' are even faster than their .NET Framework
counterparts.

| 5. VB allows implementation of interfaces with methods of different
| names, making it confusing and difficult to find the implementation. C#
| does not.

Wrong again. VB.NEt supports are more explicit syntax for interface
implementation ('Implements <interface>.<method>') than C#. This syntax
makes it more obviosu which method of the class implements which method of
an interface. In C# that's not obvious because there is no way to decide
whether or not a method implements a method of an interface or simply
extends the class without taking a look at the base class.

| 6. VB supports background compilation. While this speeds the
development
| cycle for small projects, it slows down the IDE in large projects,
contributing
| at least in part to the culture tending to gravitate toward small
| projects.

This was true for VB.NET 2002, but in version 2003 there were significant
speed improvements. In VB 2005 there will likely be some additional
improvements for background compilation. Splitting up the solution into
multiple projects can lead to an improved experience too.

| 7. C# namespaces are managed in way that makes programmers aware
| of namespaces and their importance. VB namespaces are managed in a
| way that hides them from the programmers by default. Careful attention
| to namespace management is a fundamental tenet of strong application
| design and its importance cannot be overestimated.

There is absolutely nothing that prevents one from using namespaces in
VB.NET the way they are used in C#.

Conclusion: An unprofessional developer will write bad code in both C# and
VB.NET, a good deveöoper will be able to write good code in both programming
languages. Optional additional language features are an advantage if the
assist a professional developer with his/her work. They are not bad only
because an unprofessional developer doesn't know how and when to use them.
 
Sorry I butchered it so badly :) The newer "technical" terms mess me up
quite a bit. It took me three passes to figure out "namespaces" (I kept
seeing "name area" LOL). Thanks for the good translation!

Herfried K. Wagner said:
You'll find the translation below:
http://www.codeproject.com/useritems/CSharpVersusVB.asp
Click to expand...

This article is IMO stamped by a number of unfounded prejudices and thus
includes some incorrect conclusions. I have taken some of the points made
in the section "Propagation of Culture in .NET" and commented them:

| 1. VB by default allows support for late binding. Although it can be
| turned off with "Option strict", the culture is such that it's usually
| left on. This leads to numerous difficult to catch errors. C# binding
| is always early.

This point doesn't apply to professional development. In a professional
environment, almost all developers work with 'Option Strict On', which
will make VB.NET more type-safe than C#. If 'Option Strict' is turned
off, this decision is based on technical considerations, for example, to
ease access to COM object models like those of Microsoft Office. The
author of the article constructs a disadvantage out from an additional,
useful feature.

| 2. VB still supports the old "On error goto" construct. This leads to
| sloppy or non-existent error handling. C# supports only the superior
| try.catch error handling.

I don't see any reasons whe the existance of an /additional/ language
construct for error handling leads to sloppier code or non-existant error
handling. VB.NET supports 'Try...Catch' including 'When', which is
superior to C#'s 'try...catch' error handling structure. VB.NET provides
advantages over C# in matters of error/exception handling capabilities
because it provides constructs which match better with the different
afforfances of error/exception handling.

| 3. VB supports optional parameters. Although VB developers often
| list this as an advantage, it is a disadvantage because the use of
| optional parameters weakens the contract between the caller and
| the method, allowing the developer to slacken his analysis and get
| away with it until bugs creep in. [note: C# param array construct is
| not the same as optional params]

That's wrong too. VB.NET supports optional parameters as an additional
feature. Optional parameters provide advantages when used inside
implementations, and are thus useful in some situations. Don't forget
that methods using optional parameters do not suffer from the "overloads
hell". When comparing 'MsgBox' to 'MessageBox.Show' usability for the
latter in VS.NET is bad because you'll have to pick the right overload
from a long list. On the other hand, 'MsgBox' is a function with many
optional paramters, but usability doesn't suffer. While overloading makes
sense in some cases, I would not see it as a general replacement of
optional parameters, because makes writing code harder and will lead to
less-descriptive code. One other solution to this problem is to give the
methods more specific names instead of overloading a single, generic name.
Altogether there is not a single "best" solution, but there are many good
solution for different cases -- and optional parameters are one of them.

Overloading vs. Object Technology
<URL:http://www.inf.ethz.ch/personal/meyer/publications/joop/overloading.pdf>

| 4. VB supports the legacy VB functions, with reference to Microsoft.
| VisualBasic.dll. Many of these functions are slow and they should all
| be avoided in favor of the .NET framework. However many VB programmers
| still use them. In new VB projects, this dangerous namespace is
included
| by default.

Wrong. Microsoft has never published a recommendation not to use
functionality implemented in
"Microsoft.VisualBasic.dll". "Microsoft.VisualBasic.dll" can be seen as a
"language extension" of the core VB.NET programming language. It's as
useful as 'using' in C# because it provides a shortcut to existing
functionality of the .NET Framework. Additionally 'Microsoft.VisualBasic'
contains functionality which is not present in the .NET Framework, like
support for financial mathematics, 'Left', 'Right', 'Fix', 'Split' with
support for strings as separators, ..., and it's absolutely not
"dangerous" to use this functionality. Some of the functions provided in
'Microsoft.VisualBasic' are even faster than their .NET Framework
counterparts.

| 5. VB allows implementation of interfaces with methods of different
| names, making it confusing and difficult to find the implementation. C#
| does not.

Wrong again. VB.NEt supports are more explicit syntax for interface
implementation ('Implements <interface>.<method>') than C#. This syntax
makes it more obviosu which method of the class implements which method of
an interface. In C# that's not obvious because there is no way to decide
whether or not a method implements a method of an interface or simply
extends the class without taking a look at the base class.

| 6. VB supports background compilation. While this speeds the
development
| cycle for small projects, it slows down the IDE in large projects,
contributing
| at least in part to the culture tending to gravitate toward small
| projects.

This was true for VB.NET 2002, but in version 2003 there were significant
speed improvements. In VB 2005 there will likely be some additional
improvements for background compilation. Splitting up the solution into
multiple projects can lead to an improved experience too.

| 7. C# namespaces are managed in way that makes programmers aware
| of namespaces and their importance. VB namespaces are managed in a
| way that hides them from the programmers by default. Careful attention
| to namespace management is a fundamental tenet of strong application
| design and its importance cannot be overestimated.

There is absolutely nothing that prevents one from using namespaces in
VB.NET the way they are used in C#.

Conclusion: An unprofessional developer will write bad code in both C#
and VB.NET, a good deveöoper will be able to write good code in both
programming languages. Optional additional language features are an
advantage if the assist a professional developer with his/her work. They
are not bad only because an unprofessional developer doesn't know how and
when to use them.
Click to expand...
 
Thanks for the translation Herfried. A damn fair analysis, I might add!

Herfried K. Wagner said:
You'll find the translation below:
http://www.codeproject.com/useritems/CSharpVersusVB.asp
Click to expand...

This article is IMO stamped by a number of unfounded prejudices and thus
includes some incorrect conclusions. I have taken some of the points made
in the section "Propagation of Culture in .NET" and commented them:

| 1. VB by default allows support for late binding. Although it can be
| turned off with "Option strict", the culture is such that it's usually
| left on. This leads to numerous difficult to catch errors. C# binding
| is always early.

This point doesn't apply to professional development. In a professional
environment, almost all developers work with 'Option Strict On', which
will make VB.NET more type-safe than C#. If 'Option Strict' is turned
off, this decision is based on technical considerations, for example, to
ease access to COM object models like those of Microsoft Office. The
author of the article constructs a disadvantage out from an additional,
useful feature.

| 2. VB still supports the old "On error goto" construct. This leads to
| sloppy or non-existent error handling. C# supports only the superior
| try.catch error handling.

I don't see any reasons whe the existance of an /additional/ language
construct for error handling leads to sloppier code or non-existant error
handling. VB.NET supports 'Try...Catch' including 'When', which is
superior to C#'s 'try...catch' error handling structure. VB.NET provides
advantages over C# in matters of error/exception handling capabilities
because it provides constructs which match better with the different
afforfances of error/exception handling.

| 3. VB supports optional parameters. Although VB developers often
| list this as an advantage, it is a disadvantage because the use of
| optional parameters weakens the contract between the caller and
| the method, allowing the developer to slacken his analysis and get
| away with it until bugs creep in. [note: C# param array construct is
| not the same as optional params]

That's wrong too. VB.NET supports optional parameters as an additional
feature. Optional parameters provide advantages when used inside
implementations, and are thus useful in some situations. Don't forget
that methods using optional parameters do not suffer from the "overloads
hell". When comparing 'MsgBox' to 'MessageBox.Show' usability for the
latter in VS.NET is bad because you'll have to pick the right overload
from a long list. On the other hand, 'MsgBox' is a function with many
optional paramters, but usability doesn't suffer. While overloading makes
sense in some cases, I would not see it as a general replacement of
optional parameters, because makes writing code harder and will lead to
less-descriptive code. One other solution to this problem is to give the
methods more specific names instead of overloading a single, generic name.
Altogether there is not a single "best" solution, but there are many good
solution for different cases -- and optional parameters are one of them.

Overloading vs. Object Technology
<URL:http://www.inf.ethz.ch/personal/meyer/publications/joop/overloading.pdf>

| 4. VB supports the legacy VB functions, with reference to Microsoft.
| VisualBasic.dll. Many of these functions are slow and they should all
| be avoided in favor of the .NET framework. However many VB programmers
| still use them. In new VB projects, this dangerous namespace is
included
| by default.

Wrong. Microsoft has never published a recommendation not to use
functionality implemented in
"Microsoft.VisualBasic.dll". "Microsoft.VisualBasic.dll" can be seen as a
"language extension" of the core VB.NET programming language. It's as
useful as 'using' in C# because it provides a shortcut to existing
functionality of the .NET Framework. Additionally 'Microsoft.VisualBasic'
contains functionality which is not present in the .NET Framework, like
support for financial mathematics, 'Left', 'Right', 'Fix', 'Split' with
support for strings as separators, ..., and it's absolutely not
"dangerous" to use this functionality. Some of the functions provided in
'Microsoft.VisualBasic' are even faster than their .NET Framework
counterparts.

| 5. VB allows implementation of interfaces with methods of different
| names, making it confusing and difficult to find the implementation. C#
| does not.

Wrong again. VB.NEt supports are more explicit syntax for interface
implementation ('Implements <interface>.<method>') than C#. This syntax
makes it more obviosu which method of the class implements which method of
an interface. In C# that's not obvious because there is no way to decide
whether or not a method implements a method of an interface or simply
extends the class without taking a look at the base class.

| 6. VB supports background compilation. While this speeds the
development
| cycle for small projects, it slows down the IDE in large projects,
contributing
| at least in part to the culture tending to gravitate toward small
| projects.

This was true for VB.NET 2002, but in version 2003 there were significant
speed improvements. In VB 2005 there will likely be some additional
improvements for background compilation. Splitting up the solution into
multiple projects can lead to an improved experience too.

| 7. C# namespaces are managed in way that makes programmers aware
| of namespaces and their importance. VB namespaces are managed in a
| way that hides them from the programmers by default. Careful attention
| to namespace management is a fundamental tenet of strong application
| design and its importance cannot be overestimated.

There is absolutely nothing that prevents one from using namespaces in
VB.NET the way they are used in C#.

Conclusion: An unprofessional developer will write bad code in both C#
and VB.NET, a good deveöoper will be able to write good code in both
programming languages. Optional additional language features are an
advantage if the assist a professional developer with his/her work. They
are not bad only because an unprofessional developer doesn't know how and
when to use them.
Click to expand...
 
Back
Top