A co-worker where I work is proposing all future code devopment be done
in Visual C#. Here is his assessment of VB:

VB.NET is hack as far as the CLR(Common Language Runtime) goes.  It was
retrofited into the .Net framework for those people who simply don't,
and do not care to, understand object oriented programming.  Quite a
few of it's (features) were forced into the language through very ugly
means to make it easier for the VB guys to bring in their code.  Things
like "static" veriables and functions are called "shared" in VB.NET,
because the keyword static was already used in VB6.  VB.NET is loaded
with these kinds of little idiocies.

Any comment?

only one comment - he does not know what he is talking about!
has he given you any real examples of "ugly means"
OO in vb.net is as clean as it is in c#
where does he see the problem with OO in vb.net?

Show quoteHide quote

Show quote Hide quote Almost sounds like a troll post. But, it sounds to me like your co-worker has no clue about
VB.NET.  There is not enough differences ( in my opinion) between using C# or VB, other
than language preference to make one better than the other.
As for the "features" to make it easier for VB6 programmers to import their code to VB.NET,
that is just a joke on his part.  Anything beyond a simple "Hello World" application written in
VB6 , will not be easy to move to VB.NET.  Countless VB6 programmers that have tried it can
testify that there is nothing simple about moving VB6 code to VB.NET.  While a lot of the syntax
has remained the same, there has been so many improvements made to VB , that it is more like a
new language than an upgrade to VB6.  Having experience in VB6 just makes the learning of VB.NET
easier in my opinion.
I have programmed in both C# and VB.NET and I like VB.NET mainly because of my familiarity with
VB6.  But, I have not found anything that C# can do that I have not been able to do in VB.NET(so far).
Tell your co-worker if he really wants to get away from the "idiocies" of VB, then you should do all your
future projects in C++.   That might change his way of thinking real fast.
james

just my .02 and worth exactly what you paid for it!!

I assure you, my post was not a troll post. I seriously wanted
feedback. I personally like VB.NET but am capable of using C#, but I
would prefer to stick with VB.NET. This decision isn't cast in stone
yet, and I was hoping to get some ammunition to fight for my cause.

It does seem that his comment was mostly based on his own personal
preferences.

<za***@construction-imaging.com> schrieb:
VB has some unique OO features C# is lacking: It supports late binding as a
built-in feature and declarative interface implementation ('Implements' on
member level).

In addition to that, the whole language is not case-sensitive, which sticks
to the rules used to name identifiers in CLS-compliant assemblies more
closely than C# does.  VB supports 'With' blocks, simplified and powerful
array handling statements ('ReDim', 'ReDim Preserve', 'Erase'), static
variables, declarative event handling syntax using 'WithEvents' and
'Handles', a 'Select Case' statement which is much more powerful than C#'s
legacy 'switch' statement.  In .NET 2.0, VB supports the 'My' namespace
which provides functionality which is not present in the .NET Framework and
easy access to often-used .NET Framework functionality.

Here's an example of why I love VB. It came from a post I found elsewhere
today:

*** C# code:
object objMissing = System.Reflection.Missing.Value;
object FileOpen = (object) @"\Test.doc";
Word.Application wordApp = new Word.ApplicationClass();
Word.Document oDoc = new Word.DocumentClass();
oDoc = wordApp.Documents.Open(ref FileOpen,
    ref objMissing, ref objMissing,ref objMissing,ref objMissing,
    ref objMissing, ref objMissing,ref objMissing,ref objMissing,
    ref objMissing, ref objMissing, ref objMissing,  ref objMissing,
    ref objMissing, ref objMissing);

*** VB.NET code:
Dim FileOpen As String = "C:\Temp\Test.doc"
Dim oWord As New Word.Application
Dim oDoc As Word.Document = _
    oWord.Documents.Open(FileOpen)

Show quoteHide quote

<za***@construction-imaging.com> wrote in message
As a general rule, I would expect Basic to be cheaper to support long term
than C.

But, "If you only have a hammer, everything looks like a nail".

How about using the 'using' statement?

Without external addons, how about code-commenting for intellisense?

Without extra addons (that don't come with VS.Net), how about code-comment
documentation?

How about unsafe code?

Hmm....I don't even use C# at work, yet I seem to come across more and more
of what C# can do/use that VB.Net can not...although, I do like the whole
point of being to use both :)  I just wish my department would use C#...or
even allow us to use C# :(

I'm not a C/C++ elitist ... I started in QBasic and moved to C/C++ with GNU
on *nix (Redhat Linux .. now Fedora).  So I started my development in QBasic
as a kid, moved on to C/C++ when I learned how much "better" C/C++
was...learned VB as a teenager when I learned that VB was better at RAD
business development and then learned Microsoft.Net (the framework).

Basically, it would be good to learn the framework of .Net, then learn both
languages.  Once you learn one, the other isn't that hard.  It's not the
language that provides a good, clean, working application.  It's the
development team and the standards they follow.  Develop good standards for
the shop, a clean template for code-behind, screen layout, et cetera, and
policies to follow for development.  These are all good for any language,
not just .Net, but you will see that the language doesn't matter, as long as
the developers follow the shop standards.

HTH,
Mythran
Programmer Analyst II

In VB2005, just write ''' and a template will appear, ready
to be filled with comments.

/JB

http://msdn2.microsoft.com/en-us/library/htd05whh.aspx

At least you can with .NET 2.0 :^)

Greg

"Using" works in VB 2005.  I use it.  The syntax and usage is the same as
C#.

Mike Ober.

Show quoteHide quote

VB's 'Using' is actually more powerful:

\\\
Using r, s, t, u

    ' Operate on 'r', 's', 't', and 'u'.
End Using
///

You can do the same in C#:

using(r)
using(s)
using(t)
using(u)
{
    //Operate on 'r', 's', 't', and 'u'.
}

Show quoteHide quote

Semantically it's the same, but the code above is a set of nested 'using'
blocks whereas the code I posted consisted of a single 'Using' block only.
I believe it's easier to type 'Using r, s, t, u' instead of typing 'using'
several times.

\\\
using (r)
    using (s)
        using (t)
            using (u)
            {
                ...
            }
///

I should probably also mention VB.NET/VS 2005 does both of these now also...

Greg

http://msdn2.microsoft.com/en-us/library/ms172652.aspx

Show quote Hide quote Yeah yeah, I'm ancient...I'm still stuck on 2003 cause I can't afford to
move to VS.Net 2005 (and I won't use the Express editions for production
work)...

Anywho, :)  There are some features I mentioned that "do" exist in VB.Net
2005 now...but as it shows, C# had better support from the get-go...but
there are still a few features one is missing that the other can do:

C#:
Unsafe Code

VB.Net:
single-line multiple using objects...

BUT, I have read time and time again (mostly, though, the elitists), that
C/C++ programmers tend to be more into problem solvers, application design,
and getting it right the first time.  VB programmers tend to want to get the
job done as fast as possible without much care for future maintenance
costs/problems/havoc and upgrade capabilities.  To upgrade a C/C++
application from one version to the next, it's not much..if any...to do it
from VB6 to VB.Net...well, that's going from Cobol to Java, complete rewrite
What I believe is the *majority* of the VB programmers out there look
forward to *completing* the product.  The *majority* of the C/C++
programmers out there look forward to *developing* the product.  There is a
difference, IMO...in the end...a finished product is a finished product and
it's only as good as the design and implementation of the product and the
tools (developers included) used to create the product.

Look at what I've done...gone off topic and started ranting....at least it's
not too long...

HTH,
Mythran

To VB or not to VB?
Excel automation???
VS2005 - Debug and Locked Files
Debugging in VS2005 - why is some code shaded grey?
SqlConnection component in VB.2005
For each ..... next Question
Setup and Deployment and Microsoft Jet OLE DB Provider
Dir(strPath, +R +A +S +H) keeps returning hidden folders
Tip of Day
Sending Emails from Code