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


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 4 of 9 FirstFirst ... 23456 ... LastLast
Results 46 to 60 of 126

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

  1. #46
    Jason Guest

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


    Dan Barclay <Dan@MVPs.org> wrote:
    >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.


    It is unfortunate that you have to put all your arguments in the form of
    an insult. It makes it very difficult to respond without cursing. But,
    in the interest of remaining civil, I will refrain.

    VB's legacy is not the language itself, per se. It is the tie ins to the
    operating system. Most stuff I wrote in Microsoft Basic circa 1988 will
    still work in VB today.

    However, stuff that uses the forms engine in VB, or the menu editor, or anything
    in the component library that does not obviously move to the next object
    model, is under the strain of legacy. You cannot pull it forward.

    If you are not using any of these things, then translating from VB6 to VB.NET
    should be a fairly straightforward operation. It will take a little time,
    but in theory there should be a line-for-line translation, as long as you
    can get around the different garbage collection schemes.

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


    Yep. Cobol is not inextricably linked with COM, which means it must support
    Variants, GUID identification for objects, and a very outdated forms engine.


    >ROTFLMAO! Your insight simply astounds me!


    Just because you don't understand it does not mean I do not know what I am
    talking about. It just simply means you don't have a clue.

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


    Visual Basic is not a language, it is a product that happens to use Basic.
    Thanks for making my point. There is no Visual Basic language without the
    Visual Basic product. The product includes heavy tie-ins to Windows.

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


    Opinion noted.

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


    To be fair, I did say VB, not Basic. VB is not Basic, if you want to get
    down to it. It is a Basic-like dialect wholly owned and controlled by Microsoft,
    with tie-ins to Windows.

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


    Bill Clinton? I knew I recognized that voice!!! Did you ever get a definition
    for the word "is?" Put your head between your legs, look back, and define
    what you see.

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


    Yes, they are, in some cases. You can always reuse them from other development
    platforms. But they will remain written in VB6 if they were written in that
    in the first place. You still have legacy libraries. What's yer point?


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


    Maybe you would like to provide a link? Or maybe you are best friends with
    the VB.NET design team? VB.NET was changed to (1)clean up a bunch of little
    nasties from VB6 and (2)to fit the .NET architecture. My personal opinion
    is that they did not go far enough, and that may eventually hurt the long-term
    viability of the language. But that is another discussion.



  2. #47
    Jason Guest

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


    Mike Mitchell <kylix_is@yahoo.co.uk> wrote:
    >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


    Those hundreds of thousands of classic VB apps are thick-client apps. They
    don't run on servers. They require a new installation for every machine
    for every new version. Business logic in these applications is generally
    pushed to the client, making security a very iffy thing.

    One of the new ways to do big applications, those that are used by hundreds
    or thousands of users, is to have the data and business logic on the server,
    and a custom GUI on the client machine. Better still, you don't necessarily
    have to do any additional installation to make this run.

    On the server, you would typically have a business logic service that wraps
    and consolidates other business logic servers, data bases, file systems,
    etc. The client app would have to go through this layer for everything.
    So, once it is written, most changes to your app are made by changing server
    code. Changes to the client code are automatically updated on the clients
    without the user ever having to install anything. The security model is
    simple and straightforward.

    Server side apps, services, are almost always multithreaded by nature. The
    one major exception to this rule is message-queue type apps, which serialize
    everything by nature. Most apps do better with the threaded model, since
    you don't block every other user when you are waiting on a resource (usually
    some I/O operation).

    Mike, just because you don't understand it, or can't comprehend why it might
    be useful to others, even necessary in some situations, doesn't mean it's
    not. Threading is very useful in some cases. In fact, some architectures
    would not be feasible without it.

    Just for your info, people who have used threads in VB5 and VB6 have not
    done so lightly. They tried everything they could to solve the problem some
    other way, but in the end, they had to use threads, for one reason or another.
    Threads in VB-classic are difficult and really dangerous, and you don't
    do anything with them unless you really, really have to.

    Just because you have not run into a problem that required threads does not
    mean that such problems do not exist. It just means you haven't done enough
    to be faced with a problem that requires threads.

  3. #48
    Ted Guest

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


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


    I did and I said nothing about just creating a thread. I think the second
    paragraph of Toms post said something like (don't quote me) "to even create
    a thread in VB6".

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

    No, I don't. Two of your books are academia and their opinion. I would
    say that of the books I used in college, 75% would be completely worthless
    to me now. And most of these don't use real world apps to document threading
    techniques. As for the others, I am curious as to the qualifications of
    these morons to even qualify a good book on threading. Except for Langer
    - I have read much of her STL stuff in CUJ.

    >It says "get Java Threads if you can't (or don't want to) afford this".



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

    And I said average is crap. So better than average is better crap, and much
    better than average is better than the average crap. There are too many books
    on the market written by people with no real world architectural skills.
    Look at the pictures and bios in the Wrox press books on Java and C#. I
    am a reviewer for wrox and I can tell you that many of the transcripts I
    have read are straight out of other books or even plagarized from other authors
    and full of errors before they hit press.

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

    And I said that VB developers who did not have threading at their disposal
    in VB6 have found a new toy. Was that so hard to understand? That..(pause)..
    meant..(pause)..that..(pause)..they..(pause)..had..(pause)..never.. done
    threading before .NET gave them the ability to.

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


    I never said anything was missing. Everything that I have seen is done correctly(so
    far) for the library. That still doesn't mean you don't have to understand
    the concepts.

    From Java Threads, somewhat, "introduces the basics of threading so that
    the developer can incorporate multiple threads into his or her application
    with relative ease, mastering the use of multiple threads and communication
    between them takes time and knowledge".

    So much for your great book.

  4. #49
    Jason Guest

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


    "Ted" <ttt@ttt.net> wrote:

    >From Java Threads, somewhat, "introduces the basics of threading so that
    >the developer can incorporate multiple threads into his or her application
    >with relative ease, mastering the use of multiple threads and communication
    >between them takes time and knowledge".
    >
    >So much for your great book.


    I read Java Threads. I thought it was very long winded. I forget what,
    but I vaguely remember that you had to read all the way through to chapter
    7 or something before you got the basic idea of threads in Java.

    There really are only a couple of things you have to know to shoot yourself
    in the foot in threads, and they should cover all of those in Chapter 1.
    Critical sections, wait, and join. How to avoid deadlocks. How to write
    mutexes. How to write a threadsafe queue object (for sending messages between
    threads). The whole book should have been about 3 chapters long.


  5. #50
    Kunle Odutola Guest

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

    Ted wrote:

    > I did and I said nothing about just creating a thread. I think the
    > second paragraph of Toms post said something like (don't quote me)
    > "to even create a thread in VB6".


    Glad to see you re-read it.

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

    > No, I don't. Two of your books are academia and their opinion.


    All the books were written by people with solid academic groundings. And
    industry experience.

    > I
    > would say that of the books I used in college, 75% would be
    > completely worthless to me now. And most of these don't use real
    > world apps to document threading techniques.


    I haven't come accross any book that does this. And I don't expect to
    either. The issues that complicate multithreading are complex enough without
    having to dig past hundreds of irrelevant lines of code to be able to see
    the issues.

    > As for the others, I am
    > curious as to the qualifications of these morons to even qualify a
    > good book on threading. Except for Langer
    > - I have read much of her STL stuff in CUJ.


    There's a popular saying about glass house dwellers and stone throwing
    Ted.......

    >> It says "get Java Threads if you can't (or don't want to) afford
    >> this".


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

    > And I said average is crap.


    In your [un-]informed opinion.

    > There
    > are too many books on the market written by people with no real world
    > architectural skills. Look at the pictures and bios in the Wrox
    > press books on Java and C#. I am a reviewer for wrox and I can tell
    > you that many of the transcripts I have read are straight out of
    > other books or even plagarized from other authors and full of errors
    > before they hit press.


    What has this got ot do with the books I posted?. Or the issue of good books
    on multithreading?
    There have always been good and bad authors. So ***?

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

    > And I said that VB developers who did not have threading at their
    > disposal in VB6 have found a new toy. Was that so hard to
    > understand? That..(pause)..
    > meant..(pause)..that..(pause)..they..(pause)..had..(pause)..never..
    > done threading before .NET gave them the ability to.


    VB6 developers found a way around the limitations of their tools and were
    able to use threads Ted. The code they wrote was similar to what a C/C++
    programmer would write if they eschewed pre-packaged libraries.

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

    >
    > I never said anything was missing. Everything that I have seen is
    > done correctly(so far) for the library. That still doesn't mean you
    > don't have to understand the concepts.


    OK. It follows that you now agree that good books on multithreading with
    Java (such as Doug Lea's) are indeed good books on multithreading in
    general. Your [irrational] opinion of Doug Lea's book has been duly noted.

    > From Java Threads, somewhat, "introduces the basics of threading so
    > that the developer can incorporate multiple threads into his or her
    > application with relative ease, mastering the use of multiple threads
    > and communication between them takes time and knowledge".
    >
    > So much for your great book.


    Nice try. First you introduce the book "Java Threads" into this discussion.
    Next you find a non-flattering quote about it. Then you try to disparage my
    judgement in recommending books by suggesting I recommended it?

    Kunle



  6. #51
    Mike Mitchell Guest

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

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

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


    What? You tried Delphi? You tried C++? You tried Java? Or you stuck
    with VB6 because everything else was too hard? If this is the real
    reason, don't be ashamed! You're in good company. That's why VB became
    the universally acclaimed language it did - because people from all
    walks of life, in all kinds of activities, could utilise it easily and
    quickly without much overhead and with minimum fuss. With that long
    litany of problems of yours, it seems to me you were going out of your
    way to break it, whereas the vast majority of users just carried on
    and used it as it was designed to be used as "The most productive tool
    for creating fast business solutions." It's because of this latter
    slogan backed up by millions of sales that I discount your "little
    list" as blatant hyperbole. For example, it is patently untrue to
    claim "Degree in rocket science required to use most Windows APIs."
    *SOME* API calls are a little harder than others, but *most* are dead
    simple and effective. Maybe you never really understood how to utilise
    VB's strengths? Maybe you were trying to use it as a working version
    of C++?

    MM

  7. #52
    Mike Mitchell Guest

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

    On 25 Sep 2002 18:31:52 -0700, "Jason" <jason@hotmail.com> wrote:

    > The programming
    >world is evolving, and VB-classic cannot do so any more.


    Says who? Why not allow "the world" to choose? Oh, no - far too
    democratic! Best make classic VB as obsolete as possible as quickly as
    possible and explain to everybody that they now must use VB.Net. That
    really is allowing people to have a choice. Not! Over here last Sunday
    400,000 people from the countryside marched through London on a
    Liberty and Livelihood protest. Most people want the freedom to do
    what they like. But the coexistence of classic VB alongside VB.Net
    simply did not figure in Microsoft's permutations for profit, ergo
    classic VB had to meet the grim reaper. They didn't care for one
    moment about the "Liberty and Livelihood" of individual programmers or
    corporate IT departments all over the world. No, the only thing that
    drove them was the mighty dollar and how to get more, more, more....

    MM

  8. #53
    Mike Mitchell Guest

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

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

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


    I don't believe they're important because (a) classic VB has been in
    use since 1991 largely without them and millions of programmers
    working for thousands of organisations have produced hundreds of
    thousands of applications to do useful work without them either. Kinda
    "proof of the pudding" in my eyes! And (b), anyone who *really* wanted
    or needed to "do" threads could have, either in later versions of VB
    or by using a different language. So, for every hundred successfully
    implemented classic VB apps that were rolled out without threads,
    maybe there was one that really should have been done using a
    different language with full thread support. So what? That wasn't the
    market that classic VB was aimed at. It was, and is, "The most
    productive tool for creating fast business solutions."

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


    Well, if even you are not now convinced it's a good idea, why are we
    arguing? I don't think threads are important; neither do you - end of
    story.

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


    God, this is like tacking to get every last whiff of a breeze! First
    they're "not a good idea", then they have "limited use", but then
    there are "some very good things" to be done! "Hey, mom! I'm so
    confused I don't want to go back to that horrid school ever again!"

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


    ...............???? (Use threads? Don't use threads? Use thre...)

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


    Fine. So use Java for those needs. And use classic VB for when threads
    aren't important. Like most of the time.

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


    If Java can do it already, why complicate the situation with YAJ (Yet
    Another Java)? This all stems from the fact that Sun wasn't willing to
    allow Microsoft to embrace and extend Java the way it wanted. If that
    *had* happened, .Net would have never been born and classic VB would
    likely be still riding free and proud as the one language used by more
    than any other.

    MM

  9. #54
    Mike Mitchell Guest

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

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

    >..... Makeing things simple enough so even a moron could be
    >at least a little productive with the tool.


    "even a moron", eh? Well, I don't think even most .Netizens would dare
    to be this patronising. You must be in a club of one if you believe
    that ordinary users of VB were equivalent to "morons".

    Sad.

    MM

  10. #55
    Mike Mitchell Guest

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

    On 25 Sep 2002 18:49:26 -0700, "Jason" <jason@hotmail.com> wrote:

    >......... Put your head between your legs, look back, and define
    >what you see.


    That would require me to bend over, and I've stopped doing that now,
    having been royally screwed over by Microsoft. It's them you meant,
    yes?

    MM

  11. #56
    Mike Mitchell Guest

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

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

    > Ugly, but possible. With VB.NET, you don't even get ugly.


    I even heard that Steve "Developers" Ballmer has lost weight recently,
    so you may be right this once.

    MM

  12. #57
    Ted Guest

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


    >> I
    >> would say that of the books I used in college, 75% would be
    >> completely worthless to me now. And most of these don't use real
    >> world apps to document threading techniques.

    >
    >I haven't come accross any book that does this. And I don't expect to
    >either. The issues that complicate multithreading are complex enough without
    >having to dig past hundreds of irrelevant lines of code to be able to see
    >the issues.


    What? Let me get this straight, you are saying that your old college books
    get used on a daily basis or even weekly? Ah well that explains a lot about
    you.

    >There's a popular saying about glass house dwellers and stone throwing
    >Ted.......

    Let the rock throwing begin.


    >>> It says "get Java Threads if you can't (or don't want to) afford
    >>> this".

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

    >> And I said average is crap.

    >
    >In your [un-]informed opinion.


    Uninformed? My theory is if I can find 10+ errors in a book that have to
    be submitted to the author, the book is crap. I have noted much more than
    that with books like Java threads. Coincidentally this was the one recommended
    by your links in earlier posts. Therefore my uninformed opinion tells me
    that if Java Threads was crap and it was highly recommended any book at below
    above average is more crap.

    >What has this got ot do with the books I posted?. Or the issue of good books
    >on multithreading?


    Nothing, but as long as the gullible are around to by books the people who
    write will continue.

    >VB6 developers found a way around the limitations of their tools and were
    >able to use threads Ted. The code they wrote was similar to what a C/C++
    >programmer would write if they eschewed pre-packaged libraries.
    >

    I honestly believe you never wrote a threaded app in your career. Well maybe
    now that you can do - createthread...start, you will.

    >> I never said anything was missing. Everything that I have seen is
    >> done correctly(so far) for the library. That still doesn't mean you
    >> don't have to understand the concepts.

    >
    >OK. It follows that you now agree that good books on multithreading with
    >Java (such as Doug Lea's) are indeed good books on multithreading in
    >general. Your [irrational] opinion of Doug Lea's book has been duly noted.

    Un-note it Kunle. Never said such a thing. In fact I think I will venture
    off to my local Barnes & Noble to have a gander at it. I will get back to
    you on it.

    >Nice try. First you introduce the book "Java Threads" into this discussion.

    I didn't introduce it your links did.

    >Next you find a non-flattering quote about it. Then you try to disparage

    my
    >judgement in recommending books by suggesting I recommended it?


    What the **** are you yapping about? This was not a non flattering quote
    about it. Read again. It is in the book itself.

    Adios


  13. #58
    Ted Guest

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


    "Jason" <jason@hotmail.com> wrote:
    >
    >"Ted" <ttt@ttt.net> wrote:
    >
    >>From Java Threads, somewhat, "introduces the basics of threading so that
    >>the developer can incorporate multiple threads into his or her application
    >>with relative ease, mastering the use of multiple threads and communication
    >>between them takes time and knowledge".
    >>
    >>So much for your great book.

    >
    >I read Java Threads. I thought it was very long winded. I forget what,
    >but I vaguely remember that you had to read all the way through to chapter
    >7 or something before you got the basic idea of threads in Java.
    >
    >There really are only a couple of things you have to know to shoot yourself
    >in the foot in threads, and they should cover all of those in Chapter 1.
    > Critical sections, wait, and join. How to avoid deadlocks. How to write
    >mutexes. How to write a threadsafe queue object (for sending messages between
    >threads). The whole book should have been about 3 chapters long.
    >


    Jason,

    Thank you very much. You put it much better than I could. I am sure Kunle
    will argue about this but I agree with you 100%. Coincidentally there are
    numerous errors with regards to synchronization that don't seem to appear
    in the Errata yet.

    Thanks

  14. #59
    Dan Barclay Guest

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

    On 25 Sep 2002 18:49:26 -0700, "Jason" <jason@hotmail.com> wrote:

    >
    >Dan Barclay <Dan@MVPs.org> wrote:
    >>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.

    >
    >It is unfortunate that you have to put all your arguments in the form of
    >an insult. It makes it very difficult to respond without cursing. But,
    >in the interest of remaining civil, I will refrain.
    >
    >VB's legacy is not the language itself, per se. It is the tie ins to the
    >operating system. Most stuff I wrote in Microsoft Basic circa 1988 will
    >still work in VB today.


    Really? Did you do any communication work at all? Maybe you wrote a
    CRC routine using Integers?

    Did you handle any binary data with 16bit (or before) Basic? If so
    you did that with $trings, which today are documented to corrupt
    binary data.

    Dunno what you wrote, but if you think it will all still work with
    VB.Net then you'd better start testing.

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

    >
    >Yep. Cobol is not inextricably linked with COM, which means it must support
    >Variants, GUID identification for objects, and a very outdated forms engine.


    Neither is straight Basic. Basic code that consists of *code* in the
    form of Subs and Functions has no inherent dependency on COM.

    >>ROTFLMAO! Your insight simply astounds me!

    >
    >Just because you don't understand it does not mean I do not know what I am
    >talking about. It just simply means you don't have a clue.


    Yea, maybe you're right. LOL

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

    >
    >Opinion noted.


    Just stating the facts.

    >To be fair, I did say VB, not Basic. VB is not Basic, if you want to get
    >down to it. It is a Basic-like dialect wholly owned and controlled by Microsoft,
    >with tie-ins to Windows.


    So, is C# a real language or is it just a part of .Net? What about
    CC++.net?

    <snip>
    >>
    >>Libraries are a business asset.

    >
    >Yes, they are, in some cases. You can always reuse them from other development
    >platforms. But they will remain written in VB6 if they were written in that
    >in the first place. You still have legacy libraries. What's yer point?


    Libraries are generally written with the intent that you can continue
    to use them as you move forward. Dunno how it is in your world
    though.

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

    >
    >Maybe you would like to provide a link?


    Sure. http://www.mvps.org/links.html

    Check with most of the VB folks on that list. They attended the
    same roundup meeting with the VB dev team that I did early in 2001
    going over exactly this issue.

    > Or maybe you are best friends with
    >the VB.NET design team?


    LOL. I wouldn't exactly call it "best friends" any more, but most of
    'em know me. Dunno if they'll all admit it though <g>. I've been
    involved with MS (VB and DOS Basics before that) for a long time, yea.
    Maybe next time you run into 'em you can ask 'em <g>.

    >VB.NET was changed to (1)clean up a bunch of little
    >nasties from VB6 and (2)to fit the .NET architecture.


    There is exactly one change that I'm aware of (DF) that was made on
    account of the .Net architecture. It is the only change I agree with.

    >My personal opinion
    >is that they did not go far enough, and that may eventually hurt the long-term
    >viability of the language. But that is another discussion.


    Good for you. Maybe, if you're lucky, they'll *keep* changing the
    language for you. It certainly looks good for you so far!

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

  15. #60
    Kunle Odutola Guest

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

    Ted wrote:
    >>> I
    >>> would say that of the books I used in college, 75% would be
    >>> completely worthless to me now. And most of these don't use real
    >>> world apps to document threading techniques.

    >>
    >> I haven't come accross any book that does this. And I don't expect to
    >> either. The issues that complicate multithreading are complex enough
    >> without having to dig past hundreds of irrelevant lines of code to
    >> be able to see the issues.

    >
    > What? Let me get this straight, you are saying that your old college
    > books get used on a daily basis or even weekly? Ah well that
    > explains a lot about you.


    It seems you have a reading comprehension issue Ted.

    > Uninformed? My theory is if I can find 10+ errors in a book that
    > have to be submitted to the author, the book is crap. I have noted
    > much more than that with books like Java threads. Coincidentally this
    > was the one recommended by your links in earlier posts. Therefore my
    > uninformed opinion tells me that if Java Threads was crap and it was
    > highly recommended any book at below above average is more crap.


    It was highly recommended in 1998 and downgraded in 1999. When better books
    emerged I will imagine. Nevertheless *you* introduced the Java Threads book
    into this discussion.

    >> What has this got ot do with the books I posted?. Or the issue of
    >> good books on multithreading?

    >
    > Nothing,


    Cool, let's skip this and keep on topic then shall we?
    <SNIP>

    >> VB6 developers found a way around the limitations of their tools and
    >> were able to use threads Ted. The code they wrote was similar to
    >> what a C/C++ programmer would write if they eschewed pre-packaged
    >> libraries.
    >>

    > I honestly believe you never wrote a threaded app in your career.
    > Well maybe now that you can do - createthread...start, you will.


    <*yawn*>

    >> OK. It follows that you now agree that good books on multithreading
    >> with Java (such as Doug Lea's) are indeed good books on
    >> multithreading in general. Your [irrational] opinion of Doug Lea's
    >> book has been duly noted.

    > Un-note it Kunle. Never said such a thing. In fact I think I will
    > venture off to my local Barnes & Noble to have a gander at it. I
    > will get back to you on it.


    Fair enough.

    >> Nice try. First you introduce the book "Java Threads" into this
    >> discussion.

    > I didn't introduce it your links did.


    They intoduce a lot of books. You selected this book as your strawman.

    >> Next you find a non-flattering quote about it. Then you try to
    >> disparage

    > my
    >> judgement in recommending books by suggesting I recommended it?

    >
    > What the **** are you yapping about? This was not a non flattering
    > quote about it. Read again. It is in the book itself.


    As long as we are care that I didn't recommend that book.

    Kunle



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