Visual Basic is Dead!

  • Thread starter Thread starter Marcus
  • Start date Start date
------------ 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#".
 
Tom said:
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));
}

sub main()
for i as integer=1 to 10
console.writeline(i)
next
end sub

No need for all that complicated LINQ stuff.

VB is more mature <g>.

HTH

Andrew
 
Branco said:
Nobody wrote:


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

And that was my point. VB code is easier to read.
 
"Tom Shelton" >> Private a = ""
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.

All day I was hoping that nobody would see that mistake, you are right, and
when I had sent it, I realized that myself too.
But then Tom passes by
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));
}
You mean something like this?

Sub Main()
Dim newList As New List(Of Integer) From {1, 2, 3, 4, 5, 6, 7, 8, 9,
10}
newList.ForEach(AddressOf Console.WriteLine)
End Sub
Have a nice day.

You too,

:-)

Cor
 
Hello Tom,
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));
}

Please go ahead and convert the following code to C#:

Public Class TestCs
Dim Ar(-1) As String

Public Sub Add(ByVal value As String)
Dim u As Integer = UBound(Ar) + 1
ReDim Preserve Ar(u)
Ar(u) = value
End Sub

Public Property Item(ByVal Index As Integer) As String
Get
Return Ar(Index)
End Get
Set(ByVal value As String)
Ar(Index) = value
End Set
End Property

End Class
Have a nice day.


You, too.

Martin
 
Go ahead, convert the following to VB, and then tell me that VB is
You mean something like this?

Sub Main()
Dim newList As New List(Of Integer) From {1, 2, 3, 4, 5, 6, 7, 8,
9, 10}
newList.ForEach(AddressOf Console.WriteLine)
End Sub

You too,

Ok, but try converting *this* (your conversion isn't exact, you're missing
the anonymous function and the flexibility that comes with it):

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

There are endless jokes made about this kind of argumentation you are using.

Often they are political so I don't do that on this board.

:-)

Cor
 
C# won't use an array of string, but a list of string, in the first place:



List<String> Ar = new List<String>( );
...
Ar.Add(newString);


No need to explicitly Redim Preverve in the first place!



Sure, sure, VbNet was having SOME advantages over C# when using some COM
objects, but the framework 4.0 is, for a big part, to bring C# as easy to
use as VbNet was tin hose waters. Maybe Microsoft marketing is all about
saying C# and VbNet will be at the same level, but none the less, I am still
on the impression the the framework is developped with C# in mind, and VbNet
only come as an after thought. But again, in Bill Gates way of thinking,
VbNet is great: consider that without it, the framework would have not
brought 'missing' and named parameter to C#, so, as bringing some
competition, VbNet is great and if it was really dying, it would have to be
resurected in emergency.




Vanderghast, Access MVP
 
Cor said:
Ben,

There are endless jokes made about this kind of argumentation you are
using.
Often they are political so I don't do that on this board.

Well, to be sure, you converted a function with an anonymous delegate into
one without. For that matter, you could achieve the same behavior with a
simple for loop and no functional style.

So it appears that you're the one answering the letter of the question but
not the spirit. And maybe that does have some political connotations, but
we're talking about making a convincing argument here, not law enforcement,
so the spirit of the question IS important.
 
vanderghast said:
C# won't use an array of string, but a list of string, in the first
place:

I think you missed the point, ReDim Preserve does have a direct equivalent
(Array.Resize). It's the indexed property that's more challenging in C#
(you need to return a helper object).
 
Ben,

Once somebody had some told me that 0.000000000 millimeter is more precise
then 0 millimeter I denied that.

I had than not the right answer, now I have it when somebody tells this to
me.

:-)

Cor
 
Ben,

Here was asked for some code, like Tom did, you comes only with
argumentation, there is asked how to do it and proof then that your code is
more mature than VB.

If it is mature that is not your decision, that will be done to you. Like
yourself said that the answer to Tom which Andrew gave was more mature than
mine.

Cor
 
[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.
 
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?

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.
 
I was unaware of Array.Resize, to my defense, I don't use Array much, but it
still good thing to know anyway, thanks,


Vanderghast, Access MVP
 
Cor Ligthert said:
Ben,

Once somebody had some told me that 0.000000000 millimeter is more
precise then 0 millimeter I denied that.
(...)

By convention, the statement holds, the zeros stands for a MEASURE which is
measured to be, unfortunately, with digits being 0. It is a shorthand to
mention what was the precision of the measure. The not-ambiguous way would
be to follow the measure with the +/- sign: 0.000 +/- 0.001 It is
BY CONVENTION, not by logic, deduction, even if the convention is coherent,
though: 0.002324034 +/- 0.01 is NOT much 'coherent', as
counter-example, as someone would ask if supplying all those irrelevant
digits, giving the precision, was done by someone knowing what was done.

So, yep, *if* the implicit convention is used, or if the one supplying the
measure is *reliable*, then 0.0000 mm is more precise, carry more
information, than just 0 mm.

There is an if, though. :-)


Vanderghast, Access MVP
 
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.)
 
You got it,
or if the one supplying the measure is *reliable*, then 0.0000 mm is more
precise, carry more information, than just 0 mm.
As I see 0.000000000000000000 mm I don't have the idea that the measurement
was reliable the chance that this happens is probably 1.00000000000000000000
: 1

:-)

Cor
 
Back
Top