I was curious how you guys (who, from what I can tell are generally biased against VB as a whole) think of Visual Basic.Net. Especially how it is compared to other languages such as C#. I'm reading a book on the differences between Visual Basic 6 and .NET and how to migrate between them, just for fun and it's been rather informing about .NET in general. It said that now VB can be considered an enterprsise programming language, or something like that now. And since all the .NET languages inherit the same functions from the .NET framework, and the MSIL instruction sets are the same, I don't see how it can be that different. From what I've read so far, the only difference between VB.NET and say C# is that VB.NET doesn't have native support for pointers, but they can still be handled with 'garbage collection.' One thing I can think of that is a downfall in Visual Basic.NET is that variables are indeterministic, however in VB they're deterministic. So, anyways, I'm curious if anybody who was/is against VB6 has a different opinion on VB.NET.

Sucks.

Eliminated the major reason used VB6, not having to deal with classes and types and stuff like that. They also lost a major developer base (newbies). Finally, it's OOP syntax is overly verbose and assumes I'm stupid. No thanks.

C# is good though.

Well, personally I disdain VB.NET. Reason being, it's so absolutely verbose.

C# has a lot of keywords, but there are some cases where VB has a two-to-one match. The best example I can come up with it this:

[code]
Public Class BaseClass
Public Overridable Overloads Sub DoSomething()
End Sub

Public Overridable Overloads Sub DoSomething(ByVal str As String)
End Sub
End Class

Public Class SubClass
Inherits BaseClass

Public Overrides Overloads Sub DoSomething()
End Sub

Public Overrides Overloads Sub DoSomething(ByVal str As String)
End Sub
End Class
[/code]

IMHO, it's RETARDED to have an "Overloads" keyword. IMO, they added it just so VB developers could see "function overloading."

Plus, looking at the two classes you can hardly tell them apart. The distinction between "Overridable" and "Overrides" is very minute and very easy to overlook. "virtual" and "override" is pretty easy....

VB.NET does not support unsigned numbers (one of the reasons my bot library uses signed integers). It doesn't support pointers at all (not even with Garbage Collection).

Finally, I've found the VB .NET work environment to fell, well, cluttered. I fixed the problem the BaDD had (see post "If anyone still has pity for BaDD" or something like that), but it was really not a comfortable work environment.

I'd suggest you take the plunge into C#. By referring all the time to the documentation, if you don't use the language filter, you'll be able to see how the VB and C# syntax compare very quickly. I'd say I learned VB.NET and C# more or less simultaneously.

[quote]VB.NET does not support unsigned numbers (one of the reasons my bot library uses signed integers). It doesn't support pointers at all (not even with Garbage Collection).[/quote]

Yes it can, I read it in my book. I trust Microsofts word on that more than yours. ;)

[quote]I'd suggest you take the plunge into C#. [/quote]

This didn't have anything to do with learning either, I've used C# more extensively than I have VB.NET.

[quote author=Myndfyre link=board=37;threadid=7871;start=0#msg72457 date=1090780590]
IMHO, it's RETARDED to have an "Overloads" keyword. IMO, they added it just so VB developers could see "function overloading."
[/quote]

You don't need the overloads keyword in VB 2005.

Edit: I love VB 2005 Express. It's a nice coding environment and the language is a lot better. Am porting my bot to VB 2005 at the moment.

[quote author=hismajesty[yL] link=board=37;threadid=7871;start=0#msg72498 date=1090789067]
[quote]VB.NET does not support unsigned numbers (one of the reasons my bot library uses signed integers). It doesn't support pointers at all (not even with Garbage Collection).[/quote]

Yes it can, I read it in my book. I trust Microsofts word on that more than yours. ;)
[/quote]

Try compiling the following code:

[code]
Dim myUnsignedInteger as System.UInt32 = &Hffffffff
[/code]

In fact, I'll do it for you.

Full source code for a console app in VB 2003:
[code]
Module Module1

Sub Main()

Dim myUnsignedInteger As System.UInt32 = &HFFFFFFFF

End Sub

End Module
[/code]

Compiler output:
[code]
------ Build started: Project: IToldYouSoTrust, Configuration: Debug .NET ------

Preparing resources...
Updating references...
Performing main compilation...
C:\Documents and Settings\Robert A. Paveza\My Documents\Visual Studio Projects\IToldYouSoTrust\IToldYouSoTrust\Module1.vb(5) : error BC30311: Value of type 'Integer' cannot be converted to 'System.UInt32'.
Building satellite assemblies...
Satellite assemblies could not be built because the main project output is missing.


---------------------- Done ----------------------

Build: 0 succeeded, 1 failed, 0 skipped
[/code]
Trust the book all you want, but I trust the compiler.

As for pointers, what your book was most likely saying is that .NET cannot support pointers at all, except when objects are fixed in a single location, so that the Garbage Collector cannot move them. Pointers are supported in C#. If you find a way to retrieve a pointer in VB syntax, by all means, please post it here. This is how it's done in C# (taken right from the unsafe code overview in the .NET Platform SDK):

[code]
// The unsafe keyword allows pointers to be used within
// the following method:
static unsafe void Copy(byte[] src, int srcIndex,
byte[] dst, int dstIndex, int count)
{
if (src == null || srcIndex < 0 ||
dst == null || dstIndex < 0 || count < 0)
{
throw new ArgumentException();
}
int srcLen = src.Length;
int dstLen = dst.Length;
if (srcLen - srcIndex < count ||
dstLen - dstIndex < count)
{
throw new ArgumentException();
}


// The following fixed statement pins the location of
// the src and dst objects in memory so that they will
// not be moved by garbage collection.
fixed (byte* pSrc = src, pDst = dst)
{
byte* ps = pSrc;
byte* pd = pDst;

// Loop over the count in blocks of 4 bytes, copying an
// integer (4 bytes) at a time:
for (int n =0 ; n < count/4 ; n++)
{
*((int*)pd) = *((int*)ps);
pd += 4;
ps += 4;
}

// Complete the copy by moving any bytes that weren't
// moved in blocks of 4:
for (int n =0; n < count%4; n++)
{
*pd = *ps;
pd++;
ps++;
}
}
}
[/code]

Note the absence of a "fixed" or "unsafe" keyword in VB .NET.

Hmm there is support for unsigned types, atleast in 2005; you're using 2003, eww.

[code]
Module Module1

Sub Main()

Dim myUnsignedInteger As UInteger = &HFFFFFFFF&

Debug.Print(myUnsignedInteger)

End Sub

End Module

Outputs:
4294967295
[/code]

Edit: In you're above code example, trying making it &HFFFFFFFF& instead of &HFFFFFFFF

[quote author=dxoigmn link=board=37;threadid=7871;start=0#msg72550 date=1090802866]
Hmm there is support for unsigned types, atleast in 2005; you're using 2003, eww.
[/quote]

Hmm considering that 2002 and 2003 are pretty much the standard and that 2005 is in beta.....

As far as I understand it, VB.NET is now OO. Why would you ever use it over C#? The only real advantage, as storm said, is that VB was simple; now the learning curve is just as steep as C# or any other strongly OO language like Java.

[quote author=c0ol link=board=37;threadid=7871;start=0#msg72671 date=1090858057]
As far as I understand it, VB.NET is now OO. Why would you ever use it over C#?
[/quote]

Those two sentences don't really go together. Both C# and VB.NET are OO languages. In my opinion the only thing C# has over VB.NET is it's ability to handle pointers and the syntax looks cooler. :P

I don't really find any of the .NET languages that different, apart from syntax. If you're using VS.NET then all of them make use of the same IDE. All the languages use the same forms packages, and all use the same framework. They all use the same set of MISL instructions, it's just a matter of preference in my opinion.

[quote author=hismajesty[yL] link=board=37;threadid=7871;start=0#msg72680 date=1090860897]
I don't really find any of the .NET languages that different, apart from syntax. [/quote]

Which is what I was trying to say in this thread.