Will VB.NET be more stable than VB6?


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 1 of 9 123 ... LastLast
Results 1 to 15 of 126

Thread: Will VB.NET be more stable than VB6?

  1. #1
    Jason Guest

    Will VB.NET be more stable than VB6?


    This question was asked in an earlier post, and I thought it was interesting,
    so I am giving it its own topic.

    MY OPINION:
    Yes.

    WHY?
    I've been programming VB for a long time (since 1993). In that time, I have
    been able to compare it to other mainstream languages like C++ and Java.


    VB had many firsts:
    * Pointerless
    * Garbage collection
    * Component model for reuse
    * Very nice GUI support, which is why it is relevant even today.

    But it was not a complete idea when it was introduced. Here is a list of
    some of the problems:
    * Variant Arrays versus SafeArrays.
    * Nasty API call syntax.
    * Object models that are WAY past their prime:
    * Menu support
    * Forms (all controls are public, etc.)
    * Relies on functions for many things that should be methods on objects.
    * Poor support for threaded applications.
    * Many last minute additions that became "legacy" once they had shipped.

    The problem with VB6 was that in order to fix it, you had to break it. It
    was saddled with so much legacy that there was just no way to go forward
    with the modern Computer Science ideas, that include:
    * a different form of garbage collection
    * Just-In-Time compilation (important for security)
    * redesigned frameworks (that cover a lot more than old VB ever did)

    VB6, and all its predecessors, were so tied in to Windows that any major
    change to Windows broke the language. Look at VB4-16 to VB4-32. Out with
    the VBX, in with the OCX.

    Yes, things have been relatively stable since then, but Microsoft is again
    moving Windows in a different direction.

    With .NET, DLLs are a thing of the past. It supports them, but does not
    use them natively. COM is supported for legacy purposes, but .NET does not
    use COM internally. Obviously, .NET calls Windows APIs, but they are buried
    pretty deep inside the framework. .NET is a whole new ballgame.

    WHICH GETS ME TO MY POINT:
    VB.NET is a redesign, made to fit into the new world - in a way that VB6
    cannot. This may well give VB.NET a new lease on life. It is certainly
    easier for new programmers to pick up - you know, the ones who learned nothing
    but Java in college? It does not have all the little rules to remember and
    gotchas to work around that you find in classic VB. It is a prettier, simpler
    language.

    BUT ALSO, VB.NET compiles to IL, which is most likely going to be supported
    at this level in all future versions of the CLR. That means that even if
    you never get another version of the language, you can still compile and
    run on the latest CLR.

    If Microsoft introduces another version of VB.NET that is incompatible with
    this one, language-wise, you will still be able to use the two languages
    together in an application. They are both .NET languages.

    But even so, I believe that the latest version of VB.NET, sans the compatibility
    features - YUCK - is a pretty clean language. That means that it can be
    extended and expanded quite a bit before it gets ugly.

    VB-classic, in contrast, started ugly (no OO features), and then just got
    uglier from there. Right now, to anyone who knows Java, or Perl, of just
    about any other language, VB-classic is scary-ugly.

    BUT AS LONG AS MICROSOFT SUPPORTS THE .NET CLR, VB.NET WILL CONTINUE TO BE
    A VIABLE LANGUAGE, and Microsoft will be able to support it with full backward
    compatibility.

    What happens when another paradigm shift comes along (like 16-bit --> 32-bit
    --> JIT)??? Hey, even C++ can't move to .NET without breaking compatibility.
    The next big paradigm shift will probably break backward compatibility as
    well. Nothing you can do about it, since no one knows what the new ideas
    will be, so they can't plan for them.

    When will that be? 5 years? 10 years? Who knows? But I do believe that
    as long as .NET exists, VB.NET will be supported, enhanced, and backward
    compatible.

    :-)

  2. #2
    Jason Guest

    Re: Will VB.NET be more stable than VB6?


    "Jay King" <nemopsj@aol.com> wrote:
    >Every problem you listed was only experienced by people who dont have a
    >clue. Esp the thing about the arrays, if you cant figure out hwo to use
    >variant arrays you have issues.
    >"Jason" <jason@hotmail.com> wrote in message news:3d8e8c8e$1@10.1.10.29...


    These aren't "problems," they are "design flaws." If you started to design
    a new language, you would not begin with the premise that you needed two
    sorts of arrays with slightly different rules for each.

    For new programmers, this, along with a whole bunch of other problems like
    it, adds up to a lot of extra stuff to learn with absolutely no gain to productivity.


    Every one of these design decisions was made for a good reason. But over
    time, they all add a lot of complexity to the language.

    Let me be more specific on some of these things:

    Functions for manipulating strings:
    Mid$
    Left$
    UCase$
    LCaseS
    StrConv

    Functions for manipulating files:
    Open
    Close
    Get
    Put
    Line Input
    Input

    Why are all these things functions? Because they were functions in Basic
    20 years ago! My TRS80 Model 100 supports all these functions, using the
    original version of Microsoft Basic.

    Strings are objects. Files are objects. But in VB-classic, they are data
    structures, or something that is not quite an object. Legacy.

    As far as not knowing about how to use Variant Arrays - I know how to use
    them very well. I also know most of the things about them that cause beginners
    the most grief. Have you found any of these things yet, or are you still
    learning the language?

  3. #3
    Jay King Guest

    Re: Will VB.NET be more stable than VB6?

    Every problem you listed was only experienced by people who dont have a
    clue. Esp the thing about the arrays, if you cant figure out hwo to use
    variant arrays you have issues.
    "Jason" <jason@hotmail.com> wrote in message news:3d8e8c8e$1@10.1.10.29...
    >
    > This question was asked in an earlier post, and I thought it was

    interesting,
    > so I am giving it its own topic.
    >
    > MY OPINION:
    > Yes.
    >
    > WHY?
    > I've been programming VB for a long time (since 1993). In that time, I

    have
    > been able to compare it to other mainstream languages like C++ and Java.
    >
    >
    > VB had many firsts:
    > * Pointerless
    > * Garbage collection
    > * Component model for reuse
    > * Very nice GUI support, which is why it is relevant even today.
    >
    > But it was not a complete idea when it was introduced. Here is a list of
    > some of the problems:
    > * Variant Arrays versus SafeArrays.
    > * Nasty API call syntax.
    > * Object models that are WAY past their prime:
    > * Menu support
    > * Forms (all controls are public, etc.)
    > * Relies on functions for many things that should be methods on objects.
    > * Poor support for threaded applications.
    > * Many last minute additions that became "legacy" once they had shipped.
    >
    > The problem with VB6 was that in order to fix it, you had to break it. It
    > was saddled with so much legacy that there was just no way to go forward
    > with the modern Computer Science ideas, that include:
    > * a different form of garbage collection
    > * Just-In-Time compilation (important for security)
    > * redesigned frameworks (that cover a lot more than old VB ever did)
    >
    > VB6, and all its predecessors, were so tied in to Windows that any major
    > change to Windows broke the language. Look at VB4-16 to VB4-32. Out with
    > the VBX, in with the OCX.
    >
    > Yes, things have been relatively stable since then, but Microsoft is again
    > moving Windows in a different direction.
    >
    > With .NET, DLLs are a thing of the past. It supports them, but does not
    > use them natively. COM is supported for legacy purposes, but .NET does

    not
    > use COM internally. Obviously, .NET calls Windows APIs, but they are

    buried
    > pretty deep inside the framework. .NET is a whole new ballgame.
    >
    > WHICH GETS ME TO MY POINT:
    > VB.NET is a redesign, made to fit into the new world - in a way that VB6
    > cannot. This may well give VB.NET a new lease on life. It is certainly
    > easier for new programmers to pick up - you know, the ones who learned

    nothing
    > but Java in college? It does not have all the little rules to remember

    and
    > gotchas to work around that you find in classic VB. It is a prettier,

    simpler
    > language.
    >
    > BUT ALSO, VB.NET compiles to IL, which is most likely going to be

    supported
    > at this level in all future versions of the CLR. That means that even if
    > you never get another version of the language, you can still compile and
    > run on the latest CLR.
    >
    > If Microsoft introduces another version of VB.NET that is incompatible

    with
    > this one, language-wise, you will still be able to use the two languages
    > together in an application. They are both .NET languages.
    >
    > But even so, I believe that the latest version of VB.NET, sans the

    compatibility
    > features - YUCK - is a pretty clean language. That means that it can be
    > extended and expanded quite a bit before it gets ugly.
    >
    > VB-classic, in contrast, started ugly (no OO features), and then just got
    > uglier from there. Right now, to anyone who knows Java, or Perl, of just
    > about any other language, VB-classic is scary-ugly.
    >
    > BUT AS LONG AS MICROSOFT SUPPORTS THE .NET CLR, VB.NET WILL CONTINUE TO BE
    > A VIABLE LANGUAGE, and Microsoft will be able to support it with full

    backward
    > compatibility.
    >
    > What happens when another paradigm shift comes along (like 16-bit -->

    32-bit
    > --> JIT)??? Hey, even C++ can't move to .NET without breaking

    compatibility.
    > The next big paradigm shift will probably break backward compatibility as
    > well. Nothing you can do about it, since no one knows what the new ideas
    > will be, so they can't plan for them.
    >
    > When will that be? 5 years? 10 years? Who knows? But I do believe that
    > as long as .NET exists, VB.NET will be supported, enhanced, and backward
    > compatible.
    >
    > :-)




  4. #4
    Miha Markic Guest

    Re: Will VB.NET be more stable than VB6?

    Yeah, like threads support...

    "Jay King" <nemopsj@aol.com> wrote in message news:3d8e904e$1@10.1.10.29...
    > Every problem you listed was only experienced by people who dont have a
    > clue.




  5. #5
    Jay King Guest

    Re: Will VB.NET be more stable than VB6?

    Obviously im not still learning the language..
    "Jason" <jason@hotmail.com> wrote in message news:3d8e92ca$1@10.1.10.29...
    >
    > "Jay King" <nemopsj@aol.com> wrote:
    > >Every problem you listed was only experienced by people who dont have a
    > >clue. Esp the thing about the arrays, if you cant figure out hwo to use
    > >variant arrays you have issues.
    > >"Jason" <jason@hotmail.com> wrote in message

    news:3d8e8c8e$1@10.1.10.29...
    >
    > These aren't "problems," they are "design flaws." If you started to

    design
    > a new language, you would not begin with the premise that you needed two
    > sorts of arrays with slightly different rules for each.
    >
    > For new programmers, this, along with a whole bunch of other problems like
    > it, adds up to a lot of extra stuff to learn with absolutely no gain to

    productivity.
    >
    >
    > Every one of these design decisions was made for a good reason. But over
    > time, they all add a lot of complexity to the language.
    >
    > Let me be more specific on some of these things:
    >
    > Functions for manipulating strings:
    > Mid$
    > Left$
    > UCase$
    > LCaseS
    > StrConv
    >
    > Functions for manipulating files:
    > Open
    > Close
    > Get
    > Put
    > Line Input
    > Input
    >
    > Why are all these things functions? Because they were functions in Basic
    > 20 years ago! My TRS80 Model 100 supports all these functions, using the
    > original version of Microsoft Basic.
    >
    > Strings are objects. Files are objects. But in VB-classic, they are data
    > structures, or something that is not quite an object. Legacy.
    >
    > As far as not knowing about how to use Variant Arrays - I know how to use
    > them very well. I also know most of the things about them that cause

    beginners
    > the most grief. Have you found any of these things yet, or are you still
    > learning the language?




  6. #6
    Jay King Guest

    Re: Will VB.NET be more stable than VB6?

    Its called API
    "Miha Markic" <miham@pleasenospam.spin.si> wrote in message
    news:3d8ec488@10.1.10.29...
    > Yeah, like threads support...
    >
    > "Jay King" <nemopsj@aol.com> wrote in message

    news:3d8e904e$1@10.1.10.29...
    > > Every problem you listed was only experienced by people who dont have a
    > > clue.

    >
    >




  7. #7
    Vlad Ivanov Guest

    Re: Will VB.NET be more stable than VB6?


    Thanks for pointing out to me the true evil source of horrible problems that
    warranted ****ing up the language so much as to make all my codebase absolute
    to the point of forcing me to reconsider vendors.

    There was ofcourse the possible route of gradually upgrading a popular and
    powerful language through careful redesign, deprecation and such. By why
    beat around the bush, right? Evil such as this listed here needs radical
    measures.

    >Let me be more specific on some of these things:
    >
    >Functions for manipulating strings:
    > Mid$
    > Left$
    > UCase$
    > LCaseS
    > StrConv
    >
    >Functions for manipulating files:
    > Open
    > Close
    > Get
    > Put
    > Line Input
    > Input
    >


  8. #8
    Eddie Burdak Guest

    Re: Will VB.NET be more stable than VB6?

    Jason,

    <Mega snip .. sorry>

    > What happens when another paradigm shift comes along (like

    16-bit --> 32-bit
    > --> JIT)??? Hey, even C++ can't move to .NET without breaking
    > compatibility. The next big paradigm shift will probably break
    > backward compatibility as well. Nothing you can do about it, since
    > no one knows what the new ideas will be, so they can't plan for

    them.
    >
    > When will that be? 5 years? 10 years? Who knows? But I do

    believe
    > that as long as .NET exists, VB.NET will be supported, enhanced, and
    > backward compatible.


    And there's the crux. In 10 years the code gets broken again. It makes
    languages like COBOL and FORTRAN look good. Perhaps the hard core
    routines needs to be written in these languages and compiled to DLL's
    and the new .NEXT thingy used just as a front end.

    Eddie


  9. #9
    Howard Kaikow Guest

    Re: Will VB.NET be more stable than VB6?

    Fortran has much changed over the years.

    --
    http://www.standards.com/; Programming and support for Word macros,
    including converting from WordBasic to VBA; Technical reviewing; Standards;
    Product functional/design/specifications
    ------------------------------------------------
    "Eddie Burdak" <eburdak@pilatus-aircraft.com> wrote in message
    news:3d8f2cd6$1@10.1.10.29...
    > Jason,
    >
    > <Mega snip .. sorry>
    >
    > > What happens when another paradigm shift comes along (like

    > 16-bit --> 32-bit
    > > --> JIT)??? Hey, even C++ can't move to .NET without breaking
    > > compatibility. The next big paradigm shift will probably break
    > > backward compatibility as well. Nothing you can do about it, since
    > > no one knows what the new ideas will be, so they can't plan for

    > them.
    > >
    > > When will that be? 5 years? 10 years? Who knows? But I do

    > believe
    > > that as long as .NET exists, VB.NET will be supported, enhanced, and
    > > backward compatible.

    >
    > And there's the crux. In 10 years the code gets broken again. It makes
    > languages like COBOL and FORTRAN look good. Perhaps the hard core
    > routines needs to be written in these languages and compiled to DLL's
    > and the new .NEXT thingy used just as a front end.
    >
    > Eddie
    >




  10. #10
    Patrick Troughton Guest

    Re: Will VB.NET be more stable than VB6?


    Just to avoid misunderstandings....most (if not all) of the aforementioned
    functions are still in VB.NET. That is, you can still use Mid, Left, UCase,
    etc.. The same goes for the I/O functions except some of them have been renamed
    (Open is now FileOpen, Close is now FileClose, etc.).

    /Pat
    ---------------------------
    Get .NET, it's hella phat.
    ---------------------------

    "Vlad Ivanov" <vb.@127.0.0.1> wrote:
    >
    >Thanks for pointing out to me the true evil source of horrible problems

    that
    >warranted ****ing up the language so much as to make all my codebase absolute
    >to the point of forcing me to reconsider vendors.
    >
    >There was ofcourse the possible route of gradually upgrading a popular and
    >powerful language through careful redesign, deprecation and such. By why
    >beat around the bush, right? Evil such as this listed here needs radical
    >measures.
    >
    >>Let me be more specific on some of these things:
    >>
    >>Functions for manipulating strings:
    >> Mid$
    >> Left$
    >> UCase$
    >> LCaseS
    >> StrConv
    >>
    >>Functions for manipulating files:
    >> Open
    >> Close
    >> Get
    >> Put
    >> Line Input
    >> Input
    >>



  11. #11
    Vlad Ivanov Guest

    Re: Will VB.NET be more stable than VB6?


    Thats really not the problem. Problem is that my project files simply don't
    open in VB.Net (They are based around Usercontrols, i have described that
    issue before).

    I wonder - what is the delay?


    "Patrick Troughton" <vb.@127.0.0.1> wrote:
    >
    >Just to avoid misunderstandings....most (if not all) of the aforementioned
    >functions are still in VB.NET. That is, you can still use Mid, Left, UCase,
    >etc.. The same goes for the I/O functions except some of them have been

    renamed
    >(Open is now FileOpen, Close is now FileClose, etc.).
    >
    >/Pat
    >---------------------------
    >Get .NET, it's hella phat.
    >---------------------------
    >
    >"Vlad Ivanov" <vb.@127.0.0.1> wrote:
    >>
    >>Thanks for pointing out to me the true evil source of horrible problems

    >that
    >>warranted ****ing up the language so much as to make all my codebase absolute
    >>to the point of forcing me to reconsider vendors.
    >>
    >>There was ofcourse the possible route of gradually upgrading a popular

    and
    >>powerful language through careful redesign, deprecation and such. By why
    >>beat around the bush, right? Evil such as this listed here needs radical
    >>measures.
    >>
    >>>Let me be more specific on some of these things:
    >>>
    >>>Functions for manipulating strings:
    >>> Mid$
    >>> Left$
    >>> UCase$
    >>> LCaseS
    >>> StrConv
    >>>
    >>>Functions for manipulating files:
    >>> Open
    >>> Close
    >>> Get
    >>> Put
    >>> Line Input
    >>> Input
    >>>

    >



  12. #12
    Michael Bennett Guest

    Re: Will VB.NET be more stable than VB6?

    In article <3d8e8c8e$1@10.1.10.29>, jason@hotmail.com says...
    > Hey, even C++ can't move to .NET without breaking compatibility.

    Are you sure about this?
    I read in CUJ that if you don't violate the One Definition Rule C++
    compiles fine with the /CLR switch
    Not a C/C++ programmer so I can't personally verify this.

    Michael

  13. #13
    Dan Barclay Guest

    Re: Will VB.NET be more stable than VB6?

    Jason,

    Sorry, but you don't seem to understand VB as a product, or Basic as a
    language.

    On 22 Sep 2002 20:37:50 -0700, "Jason" <jason@hotmail.com> wrote:

    >
    >This question was asked in an earlier post, and I thought it was interesting,
    >so I am giving it its own topic.
    >
    >MY OPINION:
    >Yes.
    >
    >WHY?
    >I've been programming VB for a long time (since 1993). In that time, I have
    >been able to compare it to other mainstream languages like C++ and Java.
    >
    >
    >VB had many firsts:
    >* Pointerless
    >* Garbage collection


    VB first? "Managed code" as it's known now was available with CP/M
    versions of Basic.

    >* Component model for reuse
    >* Very nice GUI support, which is why it is relevant even today.


    Yup, nice, but very important compared to a reusable code library.
    Components and GUI can be reproduced from simple core libraries in a
    matter of minutes.

    >VB6, and all its predecessors, were so tied in to Windows that any major
    >change to Windows broke the language.


    You have *got* to be kidding!

    > Look at VB4-16 to VB4-32. Out with
    >the VBX, in with the OCX.


    Absolutely wrong, with regard to most business code. What does VBX or
    OCX have to do with Basic code? Nothing. Vendors that cared created
    OCX's that worked the same way their VBX's worked such that zero
    effort was required in VB to upgrade.

    Most code is in raw Basic language syntax, using the various component
    models for wrappers only. Moving from DOS to Win16, then Win16 to
    Win32 was accomplished fairly easily. Code itself could be written in
    the earlier version in a way that let it work in the later version.

    The changes themselves had little or nothing to do with the OS
    platform!

    >WHICH GETS ME TO MY POINT:
    >VB.NET is a redesign, made to fit into the new world - in a way that VB6
    >cannot.


    ROTFLMAO!

    >When will that be? 5 years? 10 years? Who knows? But I do believe that
    >as long as .NET exists, VB.NET will be supported, enhanced, and backward
    >compatible.


    Oooowww... this is so funny it hurts! LOL!

    Dan
    Language Stability is a *feature* I wish VB had!
    (#6)
    Error 51
    Error 3
    Error 9
    ....

  14. #14
    Tom Shelton Guest

    Re: Will VB.NET be more stable than VB6?


    "Jay King" <nemopsj@aol.com> wrote in message news:3d8ec5b3$1@10.1.10.29...
    > Its called API


    Have you actually tried to use the API for this? It isn't as easy as you
    would seem to state here. In VB.NET is a simple matter of:

    Dim runner As New Thread(AddressOf MyThreadProc)
    runner.Start()

    In VB6, you need to do all kinds of nasty lowlevel work to make sure you can
    even start the thread... VB.NET is much better to work with if you need to
    use threads... Believe me, this comes from a very recent, bitter, and
    continuing ****...

    Tom Shelton



  15. #15
    Eddie Burdak Guest

    Re: Will VB.NET be more stable than VB6?

    Howard,
    Howard Kaikow wrote:
    > Fortran has much changed over the years.


    Yes since 77 there has been 90/95 and now there are some .NET versions
    flying around.

    But the compilers will still happily let me mod my 77 code and
    re-compile in the new compiler - unfortunately the same can't be said
    of VB. Hence perhaps keeping the core in something that has been
    around for a long time is not such a bad thing and use the .NEXT as a
    front end

    Eddie



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