Visual Basic is Dead!

  • Thread starter Thread starter Marcus
  • Start date Start date
I did not get this impression from reading the article. This is just one
person's opinion. I believe Microsoft has given the axe to J sharp, but I
don't believe they will ever do this to VB.Net. I do not agree with the
author on saying C# is for helping Java programmers transition over to .Net;
that is what J# was for.
From what I understand, it doesn't really matter what language you code
in, it all compiles down to the same MSIL.
I think VB.Net will be around for some time.

[Tim]
 
   I did not get this impression from reading the article.  This isjust one
person's opinion.  I believe Microsoft has given the axe to J sharp, but I
don't believe they will ever do this to VB.Net.  I do not agree with the
author on saying C# is for helping Java programmers transition over to .Net;
that is what J# was for.
   From what I understand, it doesn't really matter what language youcode
in, it all compiles down to the same MSIL.
   I think VB.Net will be around for some time.

[Tim]
Click to expand...

I agree. While the LSE and Intellisense works differently for VB than
it does for C#, and there are some namespaces available in VB that
aren't available in C# (and vice version, I assume), it is my
impression that both are merely wrappers for the .NET Framework, which
really does all the work.
 
The article is from 2007 while it state by instance that there was no Linq
in VB, which is completely wrong.

Linq was developed in different tastes for C#2 by instance DLink and
whatever fancy name.

The Linq that was used for C#3 was however the same as in VB9

And in that way the article goes on, it looks to nothing.

By the way, many C# developers complain that there are so few (correct)
samples on Internet, they only find VB

Cor
 
If you have to code in VB, make sure you charge by the line...

VB Property:

Private newPropertyValue As String
Public Property NewProperty() As String
Get
Return newPropertyValue
End Get
Set(ByVal value As String)
newPropertyValue = value
End Set
End Property

C# Property:

private int myVar;
public int MyProperty {
get{ return myVar; }
set{ myVar = value; }
}

It adds up.
 
Marcus said:
I found this: http://du2.in/VBDead
It means that C# will completely replace Visual Basic. What dou you think
about this, is VB dead?
Click to expand...
I don't think that is correct. In fact, MS themselves admit to about a 50/50
percent spread between C# and VB. In a recent video I watched, MS claimed
that they were directing future VS studio development to making features in
both languages equal and were diverting from adding even more bells and
whistles.

It is a good idea, however, to become conversant in both languages. They are
not that different, anyway,

Cheers
 
pfft! You would not believe how many new articles pop up a year stating
that.

And more often than not they are written by self righteous C# developers who
think it is a "better" language.

Has Harry rightly said above, Microsoft are improving development of both C#
and VB.NET to the extent that both languages will receive new features at
the same time. It's all horses for courses really, I write in both C# and
VB.NET regularly, and personally I prefer VB.NET.

So nope... VB.NET is far from being dead.
 
nak said:
pfft! You would not believe how many new articles pop up a year stating
that.

And more often than not they are written by self righteous C# developers
who think it is a "better" language.
Click to expand...

Finally, they've taken the blame out of us, C++ers... LOL
Has Harry rightly said above, Microsoft are improving development of
both C# and VB.NET to the extent that both languages will receive new
features at the same time. It's all horses for courses really, I write
in both C# and VB.NET regularly, and personally I prefer VB.NET.

So nope... VB.NET is far from being dead.
Click to expand...

VB6 completely sucked, but the .NET versions kinda improved the language
--as required by the CLS. Nowadays I don't like VB because it is very
verbose (see Okla's post above), but that's the only thing I can think
about.

But I agree that it is far from dead.

A new member to the family: F#. AFAIK it will be a fully supported
language in VS10. Let's see how it goes.

Regards.
 
rossum said:
private int myVar;

public int MyProperty
{
get
{
return myVar;
}

set
{
myVar = value;
}
}

:)

rossum
Click to expand...

However, the VB version can't be shortened... can it?
 
Neb said:
If you have to code in VB, make sure you charge by the line...

VB Property:

Private newPropertyValue As String
Public Property NewProperty() As String
Get
Return newPropertyValue
End Get
Set(ByVal value As String)
newPropertyValue = value
End Set
End Property

C# Property:

private int myVar;
public int MyProperty {
get{ return myVar; }
set{ myVar = value; }
}

It adds up.
Click to expand...
VB 10:
Public Property MyProperty As Integer

C# 3:
public int MyProperty { get; set; }

But if you're charging by the line, make sure to add a lot of attributes.
The sky's the limit! For starters I suggest XmlElement, DebuggerBrowsable,
DataMember, Description and DisplayName, but feel free to add custom
attributes...
 
VB 10:
Public Property MyProperty As Integer

C# 3:
public int MyProperty { get; set; }
Click to expand...

VB:

Exit Do
Exit While
Exit For

C#:

break;
break;
break;

VB:

End Class
End Enum
End Function
End Get
End If
End Interface
End Module
End Namespace
End Property
End Select
End Set
End Structure
End Sub
End SyncLock
End Try
End While
End With

C#:

}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
 
VB6 completely sucked, but the .NET versions kinda improved the language
--as required by the CLS. Nowadays I don't like VB because it is very
verbose (see Okla's post above), but that's the only thing I can think
about.
Click to expand...
Even for the property which was the exception does this end in version VB10

VB Property:

Private Property myVar As Integer

C# Property:

private int myVar;
public int MyProperty {
get{ return myVar; }
set{ myVar = value; }
}

And much more of that.

You saw Okla has typed this in his message, New is in VB with upercase like
it should be for keywords

C# is much more verbose then VB currently

Private a = ""
private string a = "";

Private a as new DataTable
private DataTable a = new DataTable();

And much more

You seems to compare VB with the version from '98. VB has a much mature
status than C#

Cor
 
"Fernando A. Gómez F." said:
However, the VB version can't be shortened... can it?
Click to expand...

I wonder why there should be the possibilty to shorten it. The way the
property is defined in VB allows for easy extension by adding new statements
to each accessor's body.

If I want to see the signatures only, I use the class view or object browser
instead.
 
Probably doable too in VbNet, the line:


public int WhatIsThat { get; set; }


***completely*** defines a perfectly working read/write propery, with
anonymous variable 'sustaining it', in C#, since version 3.5 of the
framework (if not before). It is not 'just' the signature. I don't see it
often used, though, in comparison with the long version., which uses an
explicit declaration of the local variable (the one capturing the 'value'
for the set definition and returning what get expect to return), and an
explicit statement for each get and set access.




Vanderghast, Access MVP
 
I do not agree with the
author on saying C# is for helping Java programmers transition over to ..Net;
that is what J# was for.
Click to expand...

The whole of .Net is aimed at Java programmers. (And at
getting 3rd-party programmers out of the Windows system.)
From "the horse's mouth" (Mark Russinovich):

"A few years ago Microsoft embarked on an anti-Java campaign called .NET,
spinning .NET as a revolutionary technology (while failing to explain that
it's really Microsoft's own implementation of the JVM concept with new
languages layered on top of it)."

http://blogs.technet.com/markrussinovich/archive/2005/04/16/the-coming-net-w
orld-i-m-scared.aspx

But people are writing Windows software with a 200 MB
dependency because they think it's "what Microsoft wants"!
Microsoft wants whatever makes money. That may be something
different tomorrow than it is today. Microsoft is not a guru. It's a
for-profit corporation.
If people don't know any better than to write Windows "desktop"
software with a 200 MB dependency, then what difference does it
make what language they're using?

The competition between languages will always be there.
Some C-type people look down on basic-type languages
as being too verbose. Some Perl people look down on everyone
else for the same reason. :) So what? Can't people think for
themselves a bit rather than trying to work out "the truth"
by reading junk filler pieces on blogs? The linked article is
written by someone with high school writing abilities who fails
to express any clear thoughts. It's just a "tossed salad" of
hearsay and wiseacreing.

------------ Looking at a few samples -------------------

* most really cool pieces seem to be in C# and not VB.Net.*

"Cool"? What's "cool" other than what does the job?

* The ones [job applicants] that strike me as really "senior" mostly
trend towards C# and not VB.Net. Sure, it could be a coincidence,
but it might not be. *

Translation: "C# people seem to be more "cool", but then
again my judgment can't be trusted."

* For the time being, VB.Net is my .Net language of choice; ...
VB.Net is an easy way to tap into the .Net Framework ....
So, C# it is. Am I thrilled? Not really. I like what they are doing with
C# but not C# itself. But I feel like I have hit the limits of VB.Net.
*

He's sticking with VB.Net, and VB.Net is good, but now he
apparently has to switch to C#, but he doesn't like C#, but VB.Net
is not so good...

Is your head spinning yet? Mine is.

Most of the "article" is just one long string of popular cliches. (It's
usually a good bet that people are going to prattle cliches when they
start sentences with "Sure, ..." Use of the word "cool" is another
dependable indicator. "Cool", after all, is really just a "cool"
synonym for "fashionable".)
 
Nobody wrote:
VB:

Exit Do
Exit While
Exit For

C#:

break;
break;
break;
Click to expand...

Inside nesting structures I prefer to know *what* I'm breaking off, so
VB's approach works better to me
VB:

End Class
End Enum
End Function
End Get
End If
End Interface
End Module
End Namespace
End Property
End Select
End Set
End Structure
End Sub
End SyncLock
End Try
End While
End With

C#:
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
Click to expand...

Yes, but since the "}" clutter in the end, you actually have to resort
to something like

} //if(...
} //try
} //function xxx
} //class

so you probably type more and have more trouble figuring out which "}"
relates to a given "{" (unless you only read code in the IDE)

Regards,

Branco.
 
Sometimes the verbosity of VB is good - other times it's not. However, the
one feature I really like in VB is the declarative syntax for event
handlers. Given that winforms are created as partial classes, having the
Click to expand...

VB is what it is, but the declarative syntax is fine until you want to add the
same event handler to multiple events, and then it becomes cumbersome really
quickly.
event handlers declared in the user part of the class and not hidden in the
designer.vb file is really nice. You don't have to go hunting for your
event handlers. The other thing I like, and this is an IDE issue only so C#
could also get it is the IDE feature that creates the interface handlers. I
Click to expand...

C# has been doing that for a long time. In a cooler way since C#'s IDE
experince is definately better overall.
 
Even for the property which was the exception does this end in version VB10

VB Property:

Private Property myVar As Integer

C# Property:

private int myVar;
public int MyProperty {
get{ return myVar; }
set{ myVar = value; }
}
Click to expand...

that property in C# would most likely be written:

public int MyProperty { get; set;}

C# already has auto-implement properties. In fact, I believe the overall
implementation to be better since I can actually make a readonly/writeonly
property in C# because the get and set allow differing visibility - VB10
doesn't. So, you could make the above readonly by doing:

public int MyProperty { get; private set;}

VB10 does allow you to do this:

Public Property MyVar As Integer = 10

Which is kind of cool, but for the most part they auto implement properties in
VB10 suck.
And much more of that.

You saw Okla has typed this in his message, New is in VB with upercase like
it should be for keywords

C# is much more verbose then VB currently

Private a = ""
private string a = "";
Click to expand...

Actually, that doesn't work in VB. Option Infer only applies to local
variables. So, unless your advocating using Option Strict Off, this is not
correct.
Private a as new DataTable
private DataTable a = new DataTable();
Click to expand...

LOL, considering VB propensity for being verbose, I would not quibble over a
declaration or two.
And much more

You seems to compare VB with the version from '98. VB has a much mature
status than C#
Click to expand...

LOL, Cor - not true. Current VB - no multistatement lambda support, can't use
lambda that don't return a value, no auto implement properties, lack of yield
return, and a clunky ide experience that drives me nutts when I have to
switch.

Go ahead, convert the following to VB, and then tell me that VB is more
mature:

public static int Main ()
{
var list = new List<int>() = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10};
list.ForEach (x => Console.WriteLine (x));
}

Have a nice day.
 
mayayana wrote:
  The whole of .Net is aimed at Java programmers. (And at
getting 3rd-party programmers out of the Windows system.)
Click to expand...
<snip>

Both of then fantastic goals. If Sun and friends hadn't sued MS years
ago, we'd all have to program in an MS variation of Java today.
Honestly, I can read Java, but I hate programming in it. =))

And having 3rd parties cast out off the Windows API is great,
considering the amount of trouble bad usage of said API and COM has
brought to us all in the years before .Net.
   But people are writing Windows software with a 200 MB
dependency because they think it's "what Microsoft wants"!
Microsoft wants whatever makes money. That may be something
different tomorrow than it is today. Microsoft is not a guru. It's a
for-profit corporation.
   If people don't know any better than to write Windows "desktop"
software with a 200 MB dependency, then what difference does it
make what language they're using?
Click to expand...
<snip>

The "dependency" part is really relative, don't you aggree? Ok, .Net,
if not installed in a system, will take some minutes to download
(according to Brazilian metrics =)) -- last time I checked the full
3.0 redist is around 50MB. Once it's installed, I have *no* idea how
much disk space/memory it will amount for. **But** once it is
installed (and it will be), it becomes part of the system (that is,
zero dependency =))). So, what are we talking about here? Download
time? Space in a setup CD? These are, usually, non-issues.

If for dependency you mean the actuall labraries each .Net app depends
upon, well, by this metric most native Windows app has a *huge*
dependency then (on all the native windows dll's that must be loaded
for the application to run). My point is: once the required code is
part of the system, dependency becomes zero.

Best regards,

Branco.
 
Back
Top