Article: Achieve pure .NET development with VB.NET

http://builder.com.com/article.jhtml...21106lan01.htm

Content:
"I have worked with companies that have made a long-term commitment to using
VB.NET as their core development tool, and one of their biggest concerns is
that they're not writing Pure Framework code unless they use C#. "

Article discusses why VB is viable etc.

rgds
John Butler

"John Butler" <nospamjrbutler@btinternet.com> wrote in message
news:3dc9bd64@tnews.web.devx.com...
> http://builder.com.com/article.jhtml...21106lan01.htm

Um...article is more a quick discussion of some VB internals...but may be of
interest.

On Thu, 7 Nov 2002 01:20:14 -0000, "John Butler"

>Article discusses why VB is viable etc.

I liked the part where he said: "In fact, some VB functions
(particularly conversion) offer better performance than calling native
CLR objects. For instance, CInt() is better than calling the Convert
object."

So, better performance got lost in all the oopification madness, yes?
(Plus clarity, ease-of-use, accessibility, etc etc...)

And then there's:

"Also, this library provides access to common environment constants
that VB developers have learned to use like vbCrLf. You create the
same constants by using either the System.Environment.Newline method
or System.Convert.ToChar(13) & System.Convert.ToChar(10)."

Eh? System.Convert.ToChar(13) ? Is that a foreign language, mother?
What utter nonsense to need stuff like that when we've been happy with
vbCrLf for years. Of course, I realise that the .Netizens will
interpret this as me just being a troll or negative or a f***wit, but
I'm sorry for having to keep on pointing out that the emperor ain't
wearin' anything! Not yesterday; not today; and probably not tomorrow.

By the way, nice of 'em to tell us that the VisualBasic.Compatibility
namespace may not be supported in future versions. It would also have
been nice if the VB6 carton had had wording printed on the outside (so
that we could read it before purchase) that the traditional VB inside
could be superseded in the not too distant future by an almost
completely incompatible new kind of product. They probably had the
ditches dug for the VB.Net foundations as VB6 was coming on stream.

"Use equivalent functions or objects from other .NET namespaces
instead."

In other words, don't use the intrinisc VB6 functions which offer
better performance; instead, use the CLR ones like
System.Convert.ToChar(13), which are just so darn readable!

Crikey, the author of that article really enjoys punishment, doesn't
he! He recommends that his customers avoid using the upgrade wizard at
all! So not only NO backward compatibility to speak of, but when
Microsoft actually do provide the semblance of a conversion wizard,
people are saying DON'T USE IT, GUYS! I'd say, if the conversion
wizard was better, maybe all the fuss over VB6/VB.Net would be water
under the bridge by now. But maybe the hairshirts wouldn't even wear
it then.

MM

"Mike Mitchell" <kylix_is@yahoo.co.uk> wrote in message
news:sisksus4hv1ehrbv1bv6kdqqeiavjlogk9@4ax.com...
> On Thu, 7 Nov 2002 01:20:14 -0000, "John Butler"
>
> >Article discusses why VB is viable etc.
>
> I liked the part where he said: "In fact, some VB functions
> (particularly conversion) offer better performance than calling native
> CLR objects. For instance, CInt() is better than calling the Convert
> object."
>
> So, better performance got lost in all the oopification madness, yes?
> (Plus clarity, ease-of-use, accessibility, etc etc...)

This has nothing to do with OOP, it has to do with implementation.

> And then there's:
>
> "Also, this library provides access to common environment constants
> that VB developers have learned to use like vbCrLf. You create the
> same constants by using either the System.Environment.Newline method
> or System.Convert.ToChar(13) & System.Convert.ToChar(10)."

So use vbCrLf - what's your beef.

> Eh? System.Convert.ToChar(13) ? Is that a foreign language, mother?
> What utter nonsense to need stuff like that when we've been happy with
> vbCrLf for years. Of course, I realise that the .Netizens will
> interpret this as me just being a troll or negative or a f***wit, but
> I'm sorry for having to keep on pointing out that the emperor ain't
> wearin' anything! Not yesterday; not today; and probably not tomorrow.

Your point is meaningless, since if your a VB.NET developer you don't have
to use those other methods.

> By the way, nice of 'em to tell us that the VisualBasic.Compatibility
> namespace may not be supported in future versions. It would also have
> been nice if the VB6 carton had had wording printed on the outside (so
> that we could read it before purchase) that the traditional VB inside
> could be superseded in the not too distant future by an almost
> completely incompatible new kind of product. They probably had the
> ditches dug for the VB.Net foundations as VB6 was coming on stream.

They did - a long time ago, where have you been?

> "Use equivalent functions or objects from other .NET namespaces
> instead."

Yes for things in Microsoft.VisualBasic.Compatability. That's completely
different from Microsoft.VisualBasic. There separate dll's even.

> In other words, don't use the intrinisc VB6 functions which offer
> better performance; instead, use the CLR ones like
> System.Convert.ToChar(13), which are just so darn readable!

Hey, f***wit (to use your own wording) - CInt lives in
Microsoft.VisualBasic, not Microsoft.VisualBasic.Compatability. CInt and
most other "instrinsic" VB6 functions aren't going anywhere - that was the
point of this quote at the end:

*********
Microsoft.VisualBasic is part of the implementation of the VB language
itself. The functions are true .NET and were not added solely for
compatibility with earlier versions of Visual Basic. Leaving the project
Imports statement in a VS.NET project has no impact on the performance of a
VB.NET application. Basically, it tells the compiler where to find
compatibility code if the program attempts to use it.

The .NET Framework will always have the Microsoft.VisualBasic namespace, and
it will always be in the redistribution. In the words of one of the members
of the VB.NET product team, "You're not gaining anything by removing
Microsoft.VisualBasic.dll. The functions the DLL exposes are not VB6
baggage; they are fully implemented in VB.NET, familiar to VB programmers,
and forward compatible. Lastly, if you reuse code from any VB samples, they
will use these functions. Removing the DLL does not make the application
more pure; it means you are removing helpful classes."
*****

And I dont find Convert.ToInt32(...) any less readable then CInt. Mike, you
almost never include the fully qualified name... Thats why we have the
Imports statement.

[snip - anti-conversion wizard rant]

Tom Shelton

"Tom Shelton" <toms@dakcs.com> wrote:
>
>"Mike Mitchell" <kylix_is@yahoo.co.uk> wrote in message
>news:sisksus4hv1ehrbv1bv6kdqqeiavjlogk9@4ax.com...
<<SNIP>>

Tom, you are wasting your time. Mike has this same argument about four times
a week with anyone who cares to discuss it. In all the time I have been
reading his posts, he has not changed his opinion of VB.NET or of Microsoft.
The only person who is more stubborn is Bill, and I am beginning to think
they may actually be the same person. The only difference between them is
that Bill is flagrantly anti-everything, and Mike stays on subject. And
Bill is a troll, whereas I do not believe that Mike is.

Also, Mike has not started to learn VB.NET, so all the arguments he makes
are from what he reads in magazines, on the web, and from other posts. This
makes it difficult to have an intelligent argument with him, since he really
does not know what he is arguing about.

Mike isn't really interested in learning anything new about .NET. He is
just interested in justifying his position on VB6, and he believes that VB7
should accept and run VB6 code. He does not understand - well, pretty much
anything - about the new architectures that .NET supports, nor does he seem
to be interested in learning new concepts in programming. He does not want
to understand. He only wants to continue to do the things he always did
in VB6 carried forward to VB7.

In other words, Mike is a dinosaur. Little brain, big roar, facing extinction.

Good luck with the glaciers, Mike. It's gonna be a cold winter.

"Jason" <jason@hotmail.com> wrote in message
news:3dcacab5$1@tnews.web.devx.com...
> In other words, Mike is a dinosaur. Little brain, big roar, facing
extinction.
>
> Good luck with the glaciers, Mike. It's gonna be a cold winter.

He he, Roflmao

:-)

rgds
John Butler

> And I dont find Convert.ToInt32(...) any less readable then CInt. Mike,
you
> almost never include the fully qualified name... Thats why we have the
> Imports statement.

By the way, one usefull feature of using the convert class:

Module Module1
Sub Main()
Dim i As Integer = 25
Dim binary As String

binary = Convert.ToString(i, 2)
Console.WriteLine(binary)
End Sub
End Module

' Output
25 = 11001

So much for that classic homework problem

Tom Shelton

"Tom Shelton" <tom@mtogden.com> wrote in message
news:3dcb1cd4@tnews.web.devx.com...
>
> > And I dont find Convert.ToInt32(...) any less readable then CInt. Mike,
> you
> > almost never include the fully qualified name... Thats why we have the
> > Imports statement.
>
> By the way, one usefull feature of using the convert class:
>
> Module Module1
> Sub Main()
> Dim i As Integer = 25
> Dim binary As String
>
> binary = Convert.ToString(i, 2)
> Console.WriteLine(binary)
> End Sub
> End Module
>
> ' Output
> 25 = 11001
>
> So much for that classic homework problem
>
> Tom Shelton

Dang it! I forgot to change the last line to:

Console.WriteLine("{0} = {1}", i, binary)

Tom Shelton

"Jason" <jason@hotmail.com> wrote:
>
>"Tom Shelton" <toms@dakcs.com> wrote:
>>
>>"Mike Mitchell" <kylix_is@yahoo.co.uk> wrote in message
>>news:sisksus4hv1ehrbv1bv6kdqqeiavjlogk9@4ax.com...
><<SNIP>>
>
>Tom, you are wasting your time. Mike has this same argument about four
times
>a week with anyone who cares to discuss it. In all the time I have been
>reading his posts, he has not changed his opinion of VB.NET or of Microsoft.
> The only person who is more stubborn is Bill, and I am beginning to think
>they may actually be the same person. The only difference between them
is
>that Bill is flagrantly anti-everything, and Mike stays on subject. And
>Bill is a troll, whereas I do not believe that Mike is.
>
>Also, Mike has not started to learn VB.NET, so all the arguments he makes
>are from what he reads in magazines, on the web, and from other posts.
This
>makes it difficult to have an intelligent argument with him, since he really
>does not know what he is arguing about.
>
>Mike isn't really interested in learning anything new about .NET. He is
>just interested in justifying his position on VB6, and he believes that
VB7
>should accept and run VB6 code. He does not understand - well, pretty much
>anything - about the new architectures that .NET supports, nor does he seem
>to be interested in learning new concepts in programming. He does not want
>to understand. He only wants to continue to do the things he always did
>in VB6 carried forward to VB7.
>
>In other words, Mike is a dinosaur. Little brain, big roar, facing extinction.
>
>Good luck with the glaciers, Mike. It's gonna be a cold winter.

Jason,

I just looked up lemming and the dictionary and found your picture. Do you
have any thoughts of your own? You should get out more and realize .NET
is not life.

"Blob" <blob@blobbloblboblo.com> wrote:
>I just looked up lemming and the dictionary and found your picture. Do
you
>have any thoughts of your own? You should get out more and realize .NET
>is not life.

I just looked up "troll" in the dictionary and found a picture of an inflamed
rectum ... no, wait, that's a picture of you. But you can see how I could
get confused.

"Jason" <jason@hotmail.com> wrote:
>
>"Blob" <blob@blobbloblboblo.com> wrote:
>>I just looked up lemming and the dictionary and found your picture. Do
>you
>>have any thoughts of your own? You should get out more and realize .NET
>>is not life.
>
>I just looked up "troll" in the dictionary and found a picture of an inflamed
>rectum ... no, wait, that's a picture of you. But you can see how I could
>get confused.
>


Holy crap, that's funny. So, did you think that up on your own? Still no
comment from the peanut gallery on the speed issues we were talking about
over in the C# group? Surely you remember "speed is a weak reason to choose
a piece of code"? Not exactly those words but that's what it ammounted to.

"Blob" <blob@blobbloblboblo.com> wrote:
>>Holy crap, that's funny. So, did you think that up on your own?

Naw. Spent all night looking up variations of "insults" and "lemming" on
Google.


>Still no
>comment from the peanut gallery on the speed issues we were talking about
>over in the C# group? Surely you remember "speed is a weak reason to choose
>a piece of code"? Not exactly those words but that's what it ammounted
to.

I think maybe you are referring to another "Jason." I responded once to
your IL thread on the "C# Technical" board, only just to comment that you
were arguing a case for speed on some code that would get run once each time
you start the program, or something like that. I did say that a couple of
extra IL instructions, run once, would not make a noticable difference in
the running time of the program. I don't recall if you replied or not.

As for my opinion of .NET speed, I have not found it to be lacking at all.
I have not done a scientific head-to-head comparison with VB, but I'm not
doing anything that requires a great amount of CPU. Mostly drawing GUIs
and some network operations. So as far as I can tell, the VB code and the
.NET code run neck and neck. Mind you, I am running 2GHz P4 machines, so
there may be a larger difference at, say, 300MHz.

Anyway, my design philosophy is generally to pick decent algorithms, make
the code as clear as possible, and only worry about profiling if I notice
an actual problem. I am most concerned with robust, maintainable, well documented
code. I find that usually, if you design the algorithms correctly in the
first place, a few extra IL statements won't hurt you enough to bother with
them.

In fact, I am using COM Interop quite a bit. If I were really concerned
with speed above all else, I would just stick with VB6. COM Interop is a
pretty heavy-handed protocol - it slows things down measurably. But that
doesn't mean it slows them down enough to make a real difference, and like
I said before, I am more concerned with robust, maintainable, well documented
code. For me, fast enough is just right. So I don't spend a whole lot of
time twiddling IL bits.

> I think maybe you are referring to another "Jason."

Wasn't me

Cheers,
Jason S

>Naw. Spent all night looking up variations of "insults" and "lemming" on
>Google.
You need to get a life.

>I think maybe you are referring to another "Jason." I responded once to
>your IL thread on the "C# Technical" board, only just to comment that you
>were arguing a case for speed on some code that would get run once each
time
>you start the program, or something like that.
I believe it went something like:

>If it takes 100 microseconds to run the fast one, and 133 microseconds to
>run the slow one (you didn't mention actual running times, so this is a
>guess),
>haven't you spent an inordinate amount of time fretting over a code >optimization
>that no one will ever notice?

Having said that you are "only" doing gui stuff, I would have expected this.
I don't do gui. All of my code is middle tier business logic that is hit
continuously and needs to be as fast as it can. And believe me people do
notice.


>Not saying that it is a bad thing to use your solution over Jay's, but the
>arguments for preferring one over the other seem really weak.
Speed is a weak argument? Take that 100 ms and multiply that by 100000 users
running 10 transactions per second and compare it to 133 ms. Hmmm big difference.



I did say that a couple of
>extra IL instructions, run once, would not make a noticable difference in
>the running time of the program. I don't recall if you replied or not.

No you didn't but I will oblige. Depending on the types of instructions
there may be a big difference. Reference CLI.doc


>As for my opinion of .NET speed, I have not found it to be lacking at all.
> I have not done a scientific head-to-head comparison with VB, but I'm not
>doing anything that requires a great amount of CPU. Mostly drawing GUIs
>and some network operations.
Well that explains everything.

>Anyway, my design philosophy is generally to pick decent algorithms, make
>the code as clear as possible, and only worry about profiling if I notice
>an actual problem. I am most concerned with robust, maintainable, well
documented
>code. I find that usually, if you design the algorithms correctly in the
>first place, a few extra IL statements won't hurt you enough to bother with
>them.
Hmmm. Are you sure about that?


>
>In fact, I am using COM Interop quite a bit. If I were really concerned
>with speed above all else, I would just stick with VB6.
Please don't use those two in the same sentence. VB6 and speed just don't
go together. If you wanted speed you would use C++.


I'll stop there. The rest also made no sense.

"Jason Sobell \(iGadget\)" <iGadget_@hotmail.com> wrote:
>> I think maybe you are referring to another "Jason."
>
>Wasn't me
>
>Cheers,
> Jason S
>
>

Is it coincidence that you're both named Jason? Or are you the same person,
one dumber than the other?