Will VB.NET be more stable than VB6? - Page 3


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 3 of 9 FirstFirst 12345 ... LastLast
Results 31 to 45 of 126

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

  1. #31
    Kunle Odutola Guest

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

    Ted wrote:
    >>> Dim runner As New Thread(AddressOf MyThreadProc)
    >>> runner.Start()

    >>
    >> It is.

    >
    > I am sorry. To start a thread is very easy, you are correct.


    Thanks for the ackowledgement Ted but, I already knew I was right (as was
    Tom). His comments were about starting a thread (re-read his post if you
    have any doubts).

    > To write a multithreaded application, well once again you are WRONG!!!


    Are you really suggesting that anyone in the thread claimed a two line code
    segment was to be considered a useful app (multithreaded or not)?.

    > Threading seems to be something that VB couldn't make easy enough for
    > VB developers. I think it was stated earlier in this thread how hard
    > it was to do threading in VB in the past.


    In some versions of VB -- it was relatively easier to do in VB5 than V6 for
    instance. Reagardless, VB has never really supported multithreading.

    >>> Unfortunately it's not that easy. Now they are tracking down us old
    >>> C++ dinosaurs to explain deadlock, race conditions, starvation,
    >>> priortization, TLS, synchronization, and the list goes on.

    >>
    >> Which you learned from a book (or asked a friend or maybe in a
    >> class) a while back right?.
    >>

    >
    > Oh then I'll just throw some books their way. Unfortunately there
    > are no books that were written with VB and threading in mind, that I
    > know of.


    Not suprising since most VB.NET books include material on multithreading
    anyways. Try Doug Lea's book. It should be easy to apply the concepts to the
    ..NET platform.

    > Unfortunately Kunle, I didn't learn from a book or even a
    > class and I **** sure know I didn't learn it from a VB developer.


    Your loss -- assuming you aren't lying through your teeth about not having
    relied on a book/article or class for learning this topic (which I believe
    you to be).

    > I have had to learn through trial and error because quite frankly there
    > are no good books on multithreading( the right way ) on the market.


    You learned all about concurrency and multithreading through trial and
    error. Really?. I believe you Ted. Really. No, no,...I mean REALLY!

    As for books, just a couple from my shelf (the nearest ones as I can't be
    bothered to get up):

    Principle of Concurrent Programming by Ben-Ari -- printed in the 80's
    Principle of Concurrent and Distributed Programming by Ben-Ari -- printed in
    the 90's
    http://stwww.weizmann.ac.il/G-CS/BENARI/

    Structured Concurrent Programming with OS applications by Holt et al --
    another from way back

    Concurrent Programming with Java by Doug Lea -- very good for concurrent
    programming patterns

    And a few links too...

    http://www.accu.org/bookreviews/publ...el_systems.htm
    http://www.langer.camelot.de/Resourc...iThreading.htm

    > Oh I am sorry we had a race condition that caused that line to go
    > berzerk.


    <*yawn*>

    > Once again, thanks Kunle for your insight. I will go ahead now and
    > update my resume to state that I now know multithreading in VB.NET.


    Once you've learned multithreading Ted, applying the concepts to a new
    system is [usually] a simple undertaking. It is certainly trivial for Java
    and .NET.

    Kunle



  2. #32
    Ted Guest

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


    >Thanks for the ackowledgement Ted but, I already knew I was right (as was
    >Tom). His comments were about starting a thread (re-read his post if you
    >have any doubts).


    Unfortunately I wasn't commenting on his post to begin with(re-read my post
    if YOU have any doubts).

    >Are you really suggesting that anyone in the thread claimed a two line code
    >segment was to be considered a useful app (multithreaded or not)?.

    I believe you came back with "It is".

    >In some versions of VB -- it was relatively easier to do in VB5 than V6

    for
    >instance. Reagardless, VB has never really supported multithreading.


    I'll put this in terms you will understand -- DGAS(don't give a ****).

    >Not suprising since most VB.NET books include material on multithreading
    >anyways. Try Doug Lea's book. It should be easy to apply the concepts to

    the
    >..NET platform.

    Yes and I would be willing to wager 95% never mention when to use multithreading
    or the dangers.

    >Your loss -- assuming you aren't lying through your teeth about not having
    >relied on a book/article or class for learning this topic (which I believe
    >you to be).

    Oh come on. I said I didn't learn from a book which was what you implied.
    Believe me.

    >You learned all about concurrency and multithreading through trial and
    >error. Really?. I believe you Ted. Really. No, no,...I mean REALLY!


    Again, DGAS.

    >
    >As for books, just a couple from my shelf (the nearest ones as I can't be
    >bothered to get up):
    >Principle of Concurrent Programming by Ben-Ari -- printed in the 80's
    >Principle of Concurrent and Distributed Programming by Ben-Ari -- printed

    in
    >the 90's
    >http://stwww.weizmann.ac.il/G-CS/BENARI/
    >
    >Structured Concurrent Programming with OS applications by Holt et al --
    >another from way back


    Another unfortunate statement. You see, my college textbooks went back to
    the FSU bookstore. Didn't need them then and haven't a need for them now.
    I now buy my books by reputable industry experts not some kook teacher.
    I am assuming this author is an instructor that you had to kiss his *** to
    get your 'A' in school?

    >Concurrent Programming with Java by Doug Lea -- very good for concurrent
    >programming patterns

    Good for concurrent programming, hmm you can read the title?

    Here's a link for you:
    http://www.accu.org/cgi-bin/accu/rvo...&file=c000307a

    This says get Java Threads. Hmm. I have that, it's a POS. Worthless. Garbage.
    I believe the comment was that it was better than average. Average is crap
    when it comes to books on this topic.

    >http://www.accu.org/bookreviews/publ...el_systems.htm
    >http://www.langer.camelot.de/Resourc...iThreading.htm


    >Once you've learned multithreading Ted, applying the concepts to a new
    >system is [usually] a simple undertaking. It is certainly trivial for Java
    >and .NET.


    Once again you continue to amaze me. The idea is about learning multithreading.
    Before you move to something as simple as Java and .NET threading you are
    assuming people already knew threading to begin with. And you should read
    the post that I was replying to.

    Now leave me alone dumbass.

  3. #33
    Mike Mitchell Guest

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

    On 24 Sep 2002 18:08:59 -0700, "Ted" <ttt@ttt.net> wrote:

    > And I really hate to agree with him.


    Ah, well. Everyone hates to agree with me, Ted! It's like when you
    have to agree with mom when she tells you to go to bed 'cos you've got
    school tomorrow.

    MM

  4. #34
    Mike Mitchell Guest

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

    On Wed, 25 Sep 2002 08:58:20 -0600, "Tom Shelton" <toms@dakcs.com>
    wrote:

    >........... Have you seen the
    >code necessary to make a thread work in VB6? It is actually easier in
    >VB5...


    Have you heard about all those hundreds of thousands of classic VB
    apps that echewed threads? Eleven years of fantastic development from
    over three million developers, yet suddenly threads are the be all and
    end all! Man, we gotta have threads! Our apps ain't done till all the
    threads run! Hey, sugar, cain't come out tonite! Gotta sync some
    threads...
    ....and then there was OOP! (Omigod...)

    MM

  5. #35
    Kunle Odutola Guest

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

    Ted wrote:

    > Unfortunately I wasn't commenting on his post to begin with(re-read
    > my post if YOU have any doubts).


    Perhaps you need to re-read your own post (and the code snippet copied from
    Tom's post).

    >> Are you really suggesting that anyone in the thread claimed a two
    >> line code segment was to be considered a useful app (multithreaded
    >> or not)?.

    > I believe you came back with "It is".


    "It is" -- as in it is all you need to start a thread.

    >> Not suprising since most VB.NET books include material on
    >> multithreading anyways. Try Doug Lea's book. It should be easy to
    >> apply the concepts to

    > the
    >> ..NET platform.

    > Yes and I would be willing to wager 95% never mention when to use
    > multithreading or the dangers.


    Hope you can afford whatever it is you've just lost on that wager.

    >> Your loss -- assuming you aren't lying through your teeth about not
    >> having relied on a book/article or class for learning this topic
    >> (which I believe you to be).

    > Oh come on. I said I didn't learn from a book which was what you
    > implied. Believe me.


    Re-read my comments. [I did add "article" which I missed before.]

    >> As for books, just a couple from my shelf (the nearest ones as I
    >> can't be bothered to get up):
    >> Principle of Concurrent Programming by Ben-Ari -- printed in the 80's
    >> Principle of Concurrent and Distributed Programming by Ben-Ari --
    >> printed

    > in
    >> the 90's
    >> http://stwww.weizmann.ac.il/G-CS/BENARI/
    >>
    >> Structured Concurrent Programming with OS applications by Holt et al
    >> -- another from way back

    >
    > Another unfortunate statement. You see, my college textbooks went
    > back to the FSU bookstore. Didn't need them then and haven't a need
    > for them now. I now buy my books by reputable industry experts not
    > some kook teacher. I am assuming this author is an instructor that
    > you had to kiss his *** to get your 'A' in school?


    <*yawn*>

    I take it you now acknowledge the existence of good books on the subject.
    You claimed there weren't any.

    >> Concurrent Programming with Java by Doug Lea -- very good for
    >> concurrent programming patterns

    > Good for concurrent programming, hmm you can read the title?


    I said "very good for concurrent programming *patterns*", Ted. Not all such
    books deal with patterns explicitly or clearly.

    > Here's a link for you:
    >

    http://www.accu.org/cgi-bin/accu/rvo...ystems&file=c0
    00307a
    >
    > This says get Java Threads. Hmm. I have that, it's a POS.


    It says "get Java Threads if you can't (or don't want to) afford this". The
    book is rated "Highly Recommended".

    > Worthless. Garbage. I believe the comment was that it was better
    > than average. Average is crap when it comes to books on this topic.


    The comment is that it is "(much) better than average". I believe this is
    due to basing it on Java.

    >> http://www.accu.org/bookreviews/publ...el_systems.htm
    >> http://www.langer.camelot.de/Resourc...iThreading.htm

    >
    >> Once you've learned multithreading Ted, applying the concepts to a
    >> new system is [usually] a simple undertaking. It is certainly
    >> trivial for Java and .NET.

    >
    > Once again you continue to amaze me. The idea is about learning
    > multithreading. Before you move to something as simple as Java and
    > .NET threading you are assuming people already knew threading to
    > begin with. And you should read the post that I was replying to.


    BTW, I didn't mean to imply you don't know multithreading (I don't know if
    you do or not). I meant:

    "Once a person has learned multithreading Ted, applying the......"

    Incidentally, what in your opinion is missing from the threading model in
    ..NET and Java that makes books/literature/classes that target these
    platforms unsuitable for learning multithreading?

    > Now leave me alone dumbass.


    <*yawn*>

    Kunle



  6. #36
    Jason Guest

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


    Mike Mitchell <kylix_is@yahoo.co.uk> wrote:
    >On 24 Sep 2002 18:08:59 -0700, "Ted" <ttt@ttt.net> wrote:
    >
    >> And I really hate to agree with him.

    >
    >Ah, well. Everyone hates to agree with me, Ted! It's like when you
    >have to agree with mom when she tells you to go to bed 'cos you've got
    >school tomorrow.
    >
    >MM


    Yeah, but the difference is that mom usually has a valid point to make, and
    it is based on years of actual experience. With you, it is more like those
    psychics who make 1,000 outlandish predictions for the coming year and then
    gloat when one of them comes true.

  7. #37
    Jason Guest

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


    Mike Mitchell <kylix_is@yahoo.co.uk> wrote:
    >On 24 Sep 2002 02:43:37 -0700, Rune Bivrin <rune@bivrin.com> wrote:
    >
    >>Mike Mitchell <kylix_is@yahoo.co.uk> wrote in
    >>news:l6d0pus56dpp3v7ii34jcm6m1lkkv0ihch@4ax.com:
    >>
    >>> 'Course, this ignores fact that VB devs "got by" for years without
    >>> worrying about threads, even managing to produce one or two useful
    >>> apps in the process...
    >>>
    >>> MM

    >>
    >>So have COBOL programmers for decades. What's your point?

    >
    >Better ask the .Netizens! They're the ones who keep talking up the
    >threads issue.
    >
    >MM


    Mike, just because YOU don't understand why threads are important, or why
    inheritance is important, or why a host of other new things are important,
    does not mean they are not important. It just means you don't understand
    why they are important.

    The people out here who are happiest about having threads are not those that
    "theoretically" think it might be a good idea to write everything using threads.
    And by the way, it's not a good idea.

    Threads have limited use on the client. Actually, there are some very good
    things you can do in a limited number of specific applications on the client.
    Servicing a socket connection that has multiple sinks and sources comes
    to mind. But for the most part, people will continue to write their client
    apps fully single threaded (or won't use threads outside of what the .NET
    framework already provides, transparently).

    On the server, though, it is a different story. Most apps that have to deal
    with 10,000 users simultaneously, or even 100, need some degree of multithreading.
    In this respect, Java kicks VB6 in the seat of the pants. VB.NET can hold
    its own against Java, allowing you to create new threads, or, in the more
    common case, allowing you to create objects that can be consumed in a free-threaded
    environment (thread-safe).

  8. #38
    Jason Guest

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


    "Eddie Burdak" <eburdak@pilatus-aircraft.com> wrote:
    >Dan,
    >
    >Dan Barclay wrote:
    >
    >Some minor points.
    >
    >>> 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!

    >
    >Bugger I missed that one. I wonder what major changes he was referring
    >to. My one and only VB3 Database program developed on a Win 3.1
    >machine runs very happily under 95, NT4 and XP. 98 and Me it wasn't
    >tried on as the wife gave up the librabry - NT3 and XP because someone
    >else took it up again.My non Database applications worked happily on
    >everything from 3.1 and upwards.
    >
    >Perhaps he may be referring to use of the Win API- I could imagine
    >that causing some grief.


    I used VB3 (ported to VB4 16) to develop commercial industrial tester applications.
    The interfaces to the equipment were VBX. There was no upgrade path.

    Device drivers we had written for custom software no longer worked either.
    These tied in to libraries that were tied to 16-bit windows.

    Yes, with simple applications that worked entirely in the VB sandbox, and
    for which Microsoft supplied all the components, the upgrade was possible.
    Ugly, but possible. With VB.NET, you don't even get ugly.


  9. #39
    Jason Guest

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


    Michael Bennett <mikey0131@mac.com> wrote:
    >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


    C++ code in .NET is inherently unsafe code (pointers and all), so you aren't
    really using .NET the way it is meant to be used. If you DO use the extensions
    to C++, it no longer fits the standard. Weird set of compromises.

    Microsoft COULD have allowed VB6 to run in .NET the same way. The VB compiler
    is, after all, just the C++ compiler warmed over. But it would require the
    .NET runtime as well as the VBRUN600.DLL, it would probably run more slowly
    than natively VB6, and it would start up more slowly. And you would lose
    most of the functionality of .NET by using it.

  10. #40
    Jason Guest

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


    "Eddie Burdak" <eburdak@pilatus-aircraft.com> wrote:
    >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


    COBOL works in .NET, and I think there is a FORTRAN compiler too. Java is
    probably better from an OO point of view, and the J# implementation is very
    capable.

    Personally, I believe that C# has a lot of staying power. It combines everything
    Microsoft learned from J++ and VB into one language, and some new stuff too.


    I do not believe that C#, and likewise VB.NET, are like VB6. I look at VB6
    and see a language that is kludged together from spare parts over a decade,
    where no one ever took the time to fix what was broken. I see a language
    that is tied to one operating system, built heavily around the strengths
    and weaknesses of COM. I see a language that is under such a heavy load
    of legacy that it can no longer adapt to even the tiniest change.

    FORTRAN has a lot of legacy, but is not tied to an OS.

    Same with COBOL.

    Neither language is particularly pretty, and there are better choices.

    Java has remained stable over a long time, and if you choose the right subset
    (and it is a fairly broad subset, given the open source framework), your
    program will run on .NET or any Java JVM.

    C# is a good language. What I mean by good is that (1)it is not tied to
    any operating system, by design, and (2)it is a clean, new design based on
    thoroughly modern concepts. If you stick to the ECMA standard language elements
    and syntax, you can write your core routines in C# and be fairly certain
    they will still be viable 10 years from now, and run on Unix and other OSs.

    VB.NET is also a fairly good language, though it has not been submitted to
    ECMA. I am a little less certain of its stability over time, but I don't
    see any reason why this language would ever be superceded by something like
    FORTRAN or COBOL. I can see lots of reasons why you might prefer FORTRAN
    or COBOL over VB6 for long-term viability, but not VB.NET.

    Even so, Mono has a VB.NET compiler in the works. So the language is probably
    here to stay.

    Remember, the emphasis for VB, up until now, has never been the language.
    It has always been about the GUI builder and the components, and automating
    repetitive tasks. Makeing things simple enough so even a moron could be
    at least a little productive with the tool. But they never really got around
    to addressing the fact that there were serious limitations in the language
    if you just happened to be a very good programmer. And they never got around
    to cleaning up the language (until now) so that it was reasonably consistent
    throughout.

    But the good news is that if you DO have legacy libraries in VB6, you can
    count on Microsoft to support the product for at least the next 10 years.
    Small consolation to those seeking an upgrade path, but there are some architectural
    decisions in VB6 that just can't be fixed. Sorry. So that kind of dooms
    the language.

  11. #41
    Jason Guest

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


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


    I guess I should stick to the really evil stuff, such as:

    The code is inherently unsafe, making it unsuitable for .NET.
    The garbage collection schemes don't match.
    Forms engines and components aren't even close, and need to be destroyed
    and forgotten.
    Empty, Null, Nothing, 0.
    Variant Arrays versus Safe Arrays.
    Varying support for Type.
    Global Multiuse objects and all the problems there.
    That nasty, kludgey ActiveX Control thing.
    Degree in rocket science required to use most Windows APIs.
    The fact that you have to use Windows APIs a lot to accomplish things that
    should have been fixed long ago. Like try making your own Collection.
    The menu editor and object model, unsuitable for anything but the simplest
    of apps.

    Speaking of reconsidering vendors, until .NET came out, I was trying every
    way I could to drop VB6!


  12. #42
    Dan Barclay Guest

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

    On 25 Sep 2002 15:56:43 -0700, "Jason" <jason@hotmail.com> wrote:

    >
    >"Eddie Burdak" <eburdak@pilatus-aircraft.com> wrote:
    >>Dan,
    >>
    >>Dan Barclay wrote:
    >>
    >>Some minor points.
    >>
    >>>> 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!

    >>
    >>Bugger I missed that one. I wonder what major changes he was referring
    >>to. My one and only VB3 Database program developed on a Win 3.1
    >>machine runs very happily under 95, NT4 and XP. 98 and Me it wasn't
    >>tried on as the wife gave up the librabry - NT3 and XP because someone
    >>else took it up again.My non Database applications worked happily on
    >>everything from 3.1 and upwards.
    >>
    >>Perhaps he may be referring to use of the Win API- I could imagine
    >>that causing some grief.

    >
    >I used VB3 (ported to VB4 16) to develop commercial industrial tester applications.
    > The interfaces to the equipment were VBX. There was no upgrade path.


    I used VB3 for a commercial platform application having to interface
    to custom hardware and host interfaces only available in 16bit DLL's.
    You call across the interface, wrapping in VB4/16COM if necessary,
    until the interfaces are available in your "current native"
    environment. If you've wrapped these interface calls in a single
    wrapper function it's a piece of cake.

    Before that we had to connect to custom hardware and network
    interfaces in DOS. We went through the same process when we moved to
    Windows, wrote some of the old hardware code ourselves, and put it in
    our (existing) wrappers. No big deal so long as the rest of your
    code doesn't have to be rewritten.

    Compared to rewriting core business libraries, this issue is trivial.
    I've been down that road many times. ****, we've *still* got
    customers that are tied to a particular communications process who's
    only access is via a 16bit DLL. FWIW, it's the *only* valid use I've
    found for VB4/16, but it's damned important.

    >Device drivers we had written for custom software no longer worked either.
    > These tied in to libraries that were tied to 16-bit windows.
    >
    >Yes, with simple applications that worked entirely in the VB sandbox, and
    >for which Microsoft supplied all the components, the upgrade was possible.
    > Ugly, but possible. With VB.NET, you don't even get ugly.


    With VB.Net you do it exactly the same way you did it last time.
    Instead of VBX's call 'em COM or OCX's. You call across the
    interface. If the custom software is under your control you can
    rewrite it when you get time, if it's not then you're at the mercy of
    the vendor and have to wait until they provide a native solution. In
    the interim, you access it the same way you access anything else
    across the boundary.

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

  13. #43
    Dan Barclay Guest

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

    On 25 Sep 2002 16:21:48 -0700, "Jason" <jason@hotmail.com> wrote:

    >I look at VB6
    >and see a language that is kludged together from spare parts over a decade,
    >where no one ever took the time to fix what was broken. I see a language
    >that is tied to one operating system, built heavily around the strengths
    >and weaknesses of COM. I see a language that is under such a heavy load
    >of legacy that it can no longer adapt to even the tiniest change.


    It's unfortunate that you have no friggin' idea what you're talking
    about. The core Basic language was valid from early implementations
    and most of it was unchanged. Many code fragments from CP/M versions
    still worked and almost all *could* work if they hadn't broken things
    (completely unrelated to platforms) along the way.

    So, you believe VBClassic was under a heavy load of legacy... as
    opposed to COBOL or FORTRAN?

    ROTFLMAO! Your insight simply astounds me!

    >FORTRAN has a lot of legacy, but is not tied to an OS.


    Nor is Basic. Basic is the *language*, VB is a *product* that
    happened to use Basic.

    >Same with COBOL.


    Same for Basic.

    >Neither language is particularly pretty, and there are better choices.


    Basic is not a better choice. They keep breaking code. COBOL or
    FORTRAN would be far better for applications expected to have long
    lives.

    <snip>
    >Remember, the emphasis for VB, up until now, has never been the language.
    > It has always been about the GUI builder and the components, and automating
    >repetitive tasks. Makeing things simple enough so even a moron could be
    >at least a little productive with the tool. But they never really got around
    >to addressing the fact that there were serious limitations in the language
    >if you just happened to be a very good programmer. And they never got around
    >to cleaning up the language (until now) so that it was reasonably consistent
    >throughout.


    What a load of crap. Basic (the language) went through very serious
    upgrading in late DOS versions, before there was a GUI at all.

    >But the good news is that if you DO have legacy libraries in VB6, you can
    >count on Microsoft to support the product for at least the next 10 years.


    LOL! How do you define "library"?? When you get through with that,
    maybe you'd want to define "support".

    What do you do with a library, if not create new or extended
    applications with it? Perhaps you're thinking about abandoning legacy
    *applications* as opposed to libraries.

    Libraries are a business asset.

    > Small consolation to those seeking an upgrade path, but there are some architectural
    >decisions in VB6 that just can't be fixed. Sorry. So that kind of dooms
    >the language.


    The architecture had essentially *nothing* to do with the changes to
    Basic with VB.Net. Ask the VB dev team if you don't want to believe
    me. They decided to make a few minor "cleanup" changes and it simply
    got out of hand.

    You're spinning an elegant story, but it's simply wrong.

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

  14. #44
    Dan Barclay Guest

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

    Jason, you're embarrassing yourself.

    On 25 Sep 2002 16:33:53 -0700, "Jason" <jason@hotmail.com> wrote:

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

    >
    >I guess I should stick to the really evil stuff, such as:
    >
    >The code is inherently unsafe, making it unsuitable for .NET.


    Basic was the *only* safe language, until VB.net. Basic has had
    "managed code" since CP/M versions. You had to make explicit low
    level calls to get outside it.

    >The garbage collection schemes don't match.


    Garbage collection schemes, and how they work, aren't important. The
    important point of garbage collection is that it works, not how it
    works.

    >Forms engines and components aren't even close, and need to be destroyed
    >and forgotten.


    ***?

    >Empty, Null, Nothing, 0.
    >Variant Arrays versus Safe Arrays.
    >Varying support for Type.
    >Global Multiuse objects and all the problems there.
    >That nasty, kludgey ActiveX Control thing.
    >Degree in rocket science required to use most Windows APIs.
    >The fact that you have to use Windows APIs a lot to accomplish things that
    >should have been fixed long ago. Like try making your own Collection.
    >The menu editor and object model, unsuitable for anything but the simplest
    >of apps.


    Yada, yada, yada. Man, you're clueless. Have you even done any
    serious work with this stuff? Sheesh.

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

  15. #45
    Jason Guest

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


    Dan Barclay <Dan@MVPs.org> wrote:
    >Yada, yada, yada. Man, you're clueless. Have you even done any
    >serious work with this stuff? Sheesh.
    >
    >Dan
    >Language Stability is a *feature* I wish VB had!
    > (#6)
    >Error 51
    >Error 3
    >Error 9
    >....


    I'm clueless as to why you think I am clueless. Yes, I have done serious
    work. In fact, I still use VB6 regularly. There are some great things about
    it, but there are also some serious limitations, and numerous bad design
    decisions.

    There are reasons why the number of VB job postings is far below that of
    Java. There are reasons why Java is used in Computer Science classes, and
    VB is not. Get your head out of the sand and take a look around. The programming
    world is evolving, and VB-classic cannot do so any more. It is a dinosaur
    in a mammal's world.

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