Some further comments on DotNet


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 4 of 4

Thread: Some further comments on DotNet

  1. #1
    John Butler Guest

    Some further comments on DotNet

    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






  2. #2
    Rob Teixeira Guest

    Re: Some further comments on DotNet


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



  3. #3
    Joe \Nuke Me Xemu\ Foster Guest

    Re: Some further comments on DotNet

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



  4. #4
    Joe \Nuke Me Xemu\ Foster Guest

    Re: Some further comments on DotNet

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



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center