Some further comments on DotNet

[John Butler]

Well..I've been slowly struggling my way further into VB.NET and C# and
thought I'd throw some more comments out....might just stop the ranting
going on some threads down...which is now so advanced my newsreader can't
follow it anymore (well...it IS Outlook Express <grin>)

My earlier negativity about DotNet aside, and my continuing dislike of
Microsoft's attitude aside, I wanted to say that I certainly think there are
some very nice improvements...some of which only become visible as you get
more into it....and I am nowhere *near* getting into it in any big way.

The VB6 Classic vs Visual Fred etc debate continues to rage, but I hereby
offer up my feelings on the war as it stands:

IF you were/are a straight VB6 programmer, using procedures and functions
and developing "classic" apps, then perhaps the benefits don't stand out as
easily...and people like MM obviously fall into this category. Although the
framework offers enhancements and stuff to simplify what were once (to most
VB programmers) arcane cludges (API calls etc), it id going to be harder to
like DotNet, given what one has to give up by leaving VB6 (and all those
good things have been well discussed, so I'm not rehashing them..).

However, *IF* you have been trying, in recent months/years to use a more
COM/DNA-oriented approach, use classes effectively and follow documented
three/n-tier programming concepts...then my (limited) experience so far, is
that the DotNet platform is definitely a big step forward. Leaving behind
language compatibility (which _is_ a problem, in my mind)...what is very
apparent to me, is that doing some things the way I have been trying to do
them in VB6, is going to be a *lot* easier in DotNet.

A lot of the technologies I am using on a daily basis (VB, COM, ASP,
VBScript, Javascript, ADO etc) have been bolted together over the last few
years. Much of it may have reached an element of maturity...but I certainly
don't find it a breeze to assemble a system using all these components
together. I'm tired of seeing "Automation Error -2334943094" when I should
be seeing a proper message telling me what went wrong. I could go on, but my
hopefully I've made my point:

If you are involved in more than nuts-and-bolts Windows applications, and
are trying to write apps which talk to browsers on the front-end, get data
from SQL servers, process stuff in the middle layer etc, then DotNet is, I
now see, definitely much, much better. This is where re-designing something
from the ground up has helped. All the bolted together stuff is now solidly
built-in, and has been thought through well.

As I'm bumping into my normal daily problems with "classic" stuff, I'm
starting to go.."oh, but I wouldn't have this problem in DotNet
because...XYZ". Which has had me smiling...since I was initially fairly
critical of it.

I've already spent more time on this post than I intended...but I hope I've
made a point here, that might ring true for others. I'm not yet ready to
buy or wear my BORG.NET badge....but I am certainly starting to grokk why it
will be good for me to do so <grin>

rgds
John Butler

[Rob Teixeira]

This is precisely the point I hit right about last November/December.
I was a bit miffed at some of the differences between the versions, but what
you said clearly began to ring true the more I used VB.NET - that is, for
every point that was difficult in converting VB6 code to VB.NET, I found
that the solution was more to the effect of, there's a much better way to
implement this in VB.NET than there ever was in VB6, and emulating the solution
from VB6 was not they way to do it.
I really began to appreciate this fact after migrating a project that was
roughly 75k of code with 12 libraries. I ended up throwing away most of my
libraries, which were there mostly created due to a VB limitation or as a
wrapper for system calls, and whose functionality was already embedded in
the framework for .NET.
The application itself became much simpler, since I was able to eliminate
a lot of "hack" code or "vb-isms", particularly in the UI and where the designers
tried to implement OO paterns (where VB's OO implementation failed to cover
completely).
Just the ability to use the sockets-related classes cut thousands of lines
of unreadable (and un-VB-like) code.
Also note that I was able to do this by myself in my spare time over the
perioud of a few months.

So I toss my vote the same way others who worked with VB.NET extensively
have: don't port, re-design. If you're working mid-way through a VB6 project,
don't change now - finish the current version and start planning the next
one in .NET if that's the route you want to take.

Of course, the obvious point that jumps out is that this doesn't help someone
who wants to take a large amount of code and just toss it at the VB.NET compiler.
There I concede. I'll leave the rest of this argument open for discussion.
My viewpoints certainly won't be too welcome to those who haven't actually
tried

-Rob


"John Butler" <jrbutler@nospambtclick.com> wrote:
>Well..I've been slowly struggling my way further into VB.NET and C# and
>thought I'd throw some more comments out....might just stop the ranting
>going on some threads down...which is now so advanced my newsreader can't
>follow it anymore (well...it IS Outlook Express <grin>)
>
>My earlier negativity about DotNet aside, and my continuing dislike of
>Microsoft's attitude aside, I wanted to say that I certainly think there
are
>some very nice improvements...some of which only become visible as you get
>more into it....and I am nowhere *near* getting into it in any big way.
>
>The VB6 Classic vs Visual Fred etc debate continues to rage, but I hereby
>offer up my feelings on the war as it stands:
>
>IF you were/are a straight VB6 programmer, using procedures and functions
>and developing "classic" apps, then perhaps the benefits don't stand out
as
>easily...and people like MM obviously fall into this category. Although
the
>framework offers enhancements and stuff to simplify what were once (to most
>VB programmers) arcane cludges (API calls etc), it id going to be harder
to
>like DotNet, given what one has to give up by leaving VB6 (and all those
>good things have been well discussed, so I'm not rehashing them..).
>
>However, *IF* you have been trying, in recent months/years to use a more
>COM/DNA-oriented approach, use classes effectively and follow documented
>three/n-tier programming concepts...then my (limited) experience so far,
is
>that the DotNet platform is definitely a big step forward. Leaving behind
>language compatibility (which _is_ a problem, in my mind)...what is very
>apparent to me, is that doing some things the way I have been trying to
do
>them in VB6, is going to be a *lot* easier in DotNet.
>
>A lot of the technologies I am using on a daily basis (VB, COM, ASP,
>VBScript, Javascript, ADO etc) have been bolted together over the last few
>years. Much of it may have reached an element of maturity...but I certainly
>don't find it a breeze to assemble a system using all these components
>together. I'm tired of seeing "Automation Error -2334943094" when I should
>be seeing a proper message telling me what went wrong. I could go on, but
my
>hopefully I've made my point:
>
>If you are involved in more than nuts-and-bolts Windows applications, and
>are trying to write apps which talk to browsers on the front-end, get data
>from SQL servers, process stuff in the middle layer etc, then DotNet is,
I
>now see, definitely much, much better. This is where re-designing something
>from the ground up has helped. All the bolted together stuff is now solidly
>built-in, and has been thought through well.
>
>As I'm bumping into my normal daily problems with "classic" stuff, I'm
>starting to go.."oh, but I wouldn't have this problem in DotNet
>because...XYZ". Which has had me smiling...since I was initially fairly
>critical of it.
>
>I've already spent more time on this post than I intended...but I hope I've
>made a point here, that might ring true for others. I'm not yet ready to
>buy or wear my BORG.NET badge....but I am certainly starting to grokk why
it
>will be good for me to do so <grin>
>
>rgds
>John Butler
>
>
>
>
>

[Joe \Nuke Me Xemu\ Foster]

"John Butler" <jrbutler@nospambtclick.com> wrote in message <news:3ba13f3b$1@news.devx.com>...

> If you are involved in more than nuts-and-bolts Windows applications, and
> are trying to write apps which talk to browsers on the front-end, get data
> from SQL servers, process stuff in the middle layer etc, then DotNet is, I
> now see, definitely much, much better. This is where re-designing something
> from the ground up has helped. All the bolted together stuff is now solidly
> built-in, and has been thought through well.

Is it worth leaving the "nuts-and-bolts Windows applications" devs out
in the cold?

> As I'm bumping into my normal daily problems with "classic" stuff, I'm
> starting to go.."oh, but I wouldn't have this problem in DotNet
> because...XYZ". Which has had me smiling...since I was initially fairly
> critical of it.

Anything worth back-porting, as Karl did with StringBuffer^H^H^HBuilder?

> I've already spent more time on this post than I intended...but I hope I've
> made a point here, that might ring true for others. I'm not yet ready to
> buy or wear my BORG.NET badge....but I am certainly starting to grokk why it
> will be good for me to do so <grin>

Resistance is futile?

--
Joe Foster <mailto:jlfoster%40znet.com> "Regged" again? <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!

[Joe \Nuke Me Xemu\ Foster]

"Rob Teixeira" <RobTeixeira@@msn.com> wrote in message <news:3ba65732$1@news.devx.com>...

> So I toss my vote the same way others who worked with VB.NET extensively
> have: don't port, re-design. If you're working mid-way through a VB6 project,
> don't change now - finish the current version and start planning the next
> one in .NET if that's the route you want to take.

Would the applications have reaped similar benefits by doing a similar
re-design/re-factoring while leaving them in VB Classic?

> Of course, the obvious point that jumps out is that this doesn't help someone
> who wants to take a large amount of code and just toss it at the VB.NET compiler.
> There I concede. I'll leave the rest of this argument open for discussion.

What's a few "TODO"s per screenful of "migrated" code?

> My viewpoints certainly won't be too welcome to those who haven't actually
> tried

Liar =^)

--
Joe Foster <mailto:jlfoster%40znet.com> Auditine Addict <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!