Visual Basic is Dead!

[Marcus]

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?

 

[Tim]

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]

 

[Joe Cool]

   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 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.

 

[Cor Ligthert[MVP]]

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

 

[Neb Okla]

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.

 

[Harry]

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?

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

 

[nak]

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.

 

[Fernando A. Gómez F.]

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.

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.

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.

 

[Fernando A. Gómez F.]

private int myVar;

public int MyProperty
{
get
{
return myVar;
}

set
{
myVar = value;
}
}



rossum

However, the VB version can't be shortened... can it?

 

[Abubakar]

ummm Ladies and Gentlemen, this is not a newsgroup for c# vs vb discussions

 

[Herfried K. Wagner [MVP]]

However, the VB version can't be shortened... can it?

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.

 

[vanderghast]

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

 

[mayayana]

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.

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".)

 

[Tom Shelton]

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

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

C# has been doing that for a long time. In a cooler way since C#'s IDE
experince is definately better overall.

 

[Branco]

mayayana wrote:

  The whole of .Net is aimed at Java programmers. (And at
getting 3rd-party programmers out of the Windows system.)

<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?

<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.

 

[Ben Voigt [C++ MVP]]

------------ 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."

I translate this differently. .NET is (still) new. Senior people used
something before .NET, mostly C++ or Java. People who knew C++ or Java
before starting .NET were more comfortable with C#, people who knew Classic
VB/VBA were more comfortable with VB.NET

Once .NET reaches 10 years old this will no longer be true of course, and
we'll know longer be able to identify the bogus job postings by the way they
require "10 years experience with C#".

 

[Jeff Johnson]

VB6 completely sucked

Which is what made it the most popular Microsoft language ever, right?




Oh, I almost forgot: bite me.

(Flame on!)

 

[Timothy Casey]

[SNIP]

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.

[SNIP]

No, it was mostly hackers and malware that caused the most persistent
problems that weren't already caused by defects in the API and COM
themselves - and nearly all of the malware causing these problems got in
due to slack security settings that allowed the JavaScript, VBscript, &
ActiveX autoloaders to execute without the user's knowledge or consent.

As for buggy software, no serious problems here. Back in 1999, I surveyed
nearly 500 software packages and less than twenty functioned substantially
as documented. Most didn't function at all, many were pretendware (GUI with
no other object code), and about 1 in 5 blue screened windows or crashed
Windows altogether if they were set to run on startup. The Windows 98SE
operating system that bore the full fury of these tests still runs to this
day, and is more stable than some WinXP and Vista systems.

I might add that third party software is much improved. Fully half of it
actually works these days and pretendware is much rarer than it was in the
90's. Nonetheless if buggy software caused the amount of grief you mention,
that clunky old Win98SE system of mine would be reduced to a smoking pile of
blue-screens by now. This is not the case.

Without third parties in the API, you have no security packages other than
the few malware removal tools Microsoft have to offer. If it were not for
third party packages that police the security settings in the registry (eg.
Drawbridge), it would be impossible to keep the script kiddies out of any
computer system, because the door that is so commercially favourable SaaS is
the same hole that modern "hackers" use to gain access in more than 99% of
modern security exploits.

 

[Ertugrul Söylemez]

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?

It won't, since both languages have the same features. However, C# is
usually much easier to deal with and much less to write, especially when
it comes to advanced features like delegates, lambdas, LINQ, etc.


Greets,
Ertugrul.

 

[mayayana]

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.
I daresay that whole idea of "get the clowns
out of the API" is a good example of a cliche
that's been spread around, and that people have
picked up without really thinking about it. As the
marketing experts know, it's very easy to get
people to accept a premise by simply repeating
it over and over.

When your anti-API statement is scrutinized it's really
a somewhat illogical thing for a programmer to say. It
amounts to saying, "I'm happy to be put into a sandbox
where I can't access the system if that helps to block
other people who don't know what they're doing."

Beyond that there's a profound implication in
the changes brought by .Net's sandbox. The end result
of shutting off the real API is the transformation
of Windows from a platform to a service. The
security/stability issue is a red herring. (Remember,
the original idea was that an OS is a "platform"
that supports software by interfacing with the
hardware. It's important to distinguish between
needed security improvements on the one hand,
and radical redefiniton of the product on the other.)

...And speaking of cliches, what's with all the
badmouthing of COM? I don't mean just what you
said. I've heard derision of COM for years. But I don't
find any problems with it. It's been great for scripting.
And Windows itself is still extensively COM-oriented,
while being almost entirely free of .Net.
The "dependency" part is really relative, don't you aggree?
Ultimately, sure. But a basic XP system is about 1GB.
..Net2 is about 88 MB unpacked, by my measure. As I
understand it, .Net3 is over 200 MB. It's adding some
25% to the OS. So where do you draw the line with
what's "relative"? Would you install a 2 MB Java program
if you knew it was going to require a 200-300MB VM?
I wouldn't.
We're talking here about whether .Net is a sensible
choice for desktop software -- not just whether some
people will be agreeable to having the .Net runtime
installed. There are issues of bloat, security, possible
instability, etc. It's not just a question of how long it
takes to download the package.

If the "relative" bloat of the runtime were not an issue
then .Net installers wouldn't be designed to sneak out
and download the runtime without even asking the person
installing the software.

Then there's also the general unsuitability in the design
of .Net for Windows software. If you read Mark Russinovich's
piece from the link you'll see that his whole point is the same
point that I'm making. (And I suspect that most of the people
reading this also agree, and are probably using .Net not
for Windows software but rather are using it where
they might have formerly used Java -- server-side or for
producing corporate intranet web services.)