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


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 5 of 9 FirstFirst ... 34567 ... LastLast
Results 61 to 75 of 126

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

  1. #61
    Jonathan West Guest

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


    "Dan Barclay" <Dan@MVPs.org> wrote in message
    news:rcf6pu4pf4hjo9mhdjlkpk4buqaujfaidi@4ax.com...
    >
    > >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.
    >


    To be fair, I've been able to identify one more, arguably two more. The
    definite one is the loss of mixed-visibility properties. The arguable one is
    the loss of default parameterless properties.

    --
    Regards
    Jonathan West


  2. #62
    Dan Barclay Guest

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

    On Thu, 26 Sep 2002 21:55:38 +0100, "Jonathan West" <jwest@mvps.org>
    wrote:

    >
    >"Dan Barclay" <Dan@MVPs.org> wrote in message
    >news:rcf6pu4pf4hjo9mhdjlkpk4buqaujfaidi@4ax.com...
    >>
    >> >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.
    >>

    >
    >To be fair, I've been able to identify one more, arguably two more. The
    >definite one is the loss of mixed-visibility properties. The arguable one is
    >the loss of default parameterless properties.


    Could be. I wasn't even aware of those changes... I don't use those
    features so I wouldn't have noticed. If they are changes, and the old
    behavior could not be implemented in the new environment, they are
    valid changes IMHO. Otherwise they're not valid.

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

  3. #63
    Karl E. Peterson Guest

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

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

    >>
    >> To be fair, I've been able to identify one more, arguably two more.
    >> The definite one is the loss of mixed-visibility properties. The
    >> arguable one is the loss of default parameterless properties.

    >
    > Could be. I wasn't even aware of those changes... I don't use those
    > features so I wouldn't have noticed. If they are changes, and the old
    > behavior could not be implemented in the new environment, they are
    > valid changes IMHO. Otherwise they're not valid.


    I was actually under the impression that the "platform" supported them, but C#
    didn't.

    Later... Karl
    --
    [Microsoft Basic: 1976-2001, RIP]


  4. #64
    Paul Clement Guest

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

    On Thu, 26 Sep 2002 21:55:38 +0100, "Jonathan West" <jwest@mvps.org> wrote:


    "Dan Barclay" <Dan@MVPs.org> wrote in message
    news:rcf6pu4pf4hjo9mhdjlkpk4buqaujfaidi@4ax.com...
    >
    > >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.
    >

    To be fair, I've been able to identify one more, arguably two more. The
    definite one is the loss of mixed-visibility properties. The arguable one is
    the loss of default parameterless properties.

    Amen to both of those.


    Paul ~~~ pclement@ameritech.net
    Microsoft MVP (Visual Basic)

  5. #65
    Jason Guest

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


    "Ted" <ttt@ttt.net> wrote:
    >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


    I never really bother with the errors, or the errata. I always assume computer
    books are full of mistakes. Even if the authors don't put them in, the typesetters
    and editors, technical geniuses that they are, always add a bunch.

    When Java Threads came out, it was the best thing going. It was the only
    thing going.

    The real problem with threads, as I see it, is two fold:
    (1) There is no way known to man to prevent deadlocks, or to guarantee that
    object access is safe across threads (without destroying performance). Java
    can protect you from pointers, but not from stupid thread mistakes.

    (2) Most programmers find it hard to think about things happening in parallel,
    since almost everything they have ever worked on was single threaded. So
    they tend to make mistakes.

    Threads are simpler to use than ever before, but that don't mean you can't
    crash your program or corrupt data by misusing them! ;-)

  6. #66
    Jason Guest

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


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


    Dan, I just have to come out and say it. If you think that VB6 is a "good"
    language, then I think you are leading a very sheltered life, and you should
    get out more.

    VB6 is losing old programmers to Java in droves. VB6 is not picking up new
    programmers. If VB6 were supported in .NET, then everyone would be moving
    to C# for new development, and scripting would be done in JavaScript. Well,
    apparently except for you and MM.

    It is nice to have old code. It is nice to be able to reuse code. You can
    do both with VB6 and .NET. You just can't develop new stuff in .NET using
    classic-VB syntax.

    Why is this such a big deal? Why are you so passionate about taking this
    archaic language forward?

    Ah, I am wasting my carpal tunnel syndrome on deaf eyes.

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


    Language stability is a feature that VB6 will have from now on! Be happy!
    You are getting EXACTLY what you asked for! VB6 is now the most "stable"
    version of VB you can buy! Congratulations!

    As for me, I liked it when they changed VB3 to VB4 and added a bunch of new
    features. I rewrote a ton of code to take advantage of them, simplifying
    and shrinking the code I was working on by a lot.

    I could not wait for VB5 to come out, then I could not wait for the first
    service pack to fix all the bugs, then the second service pack... but I liked
    the new features, and I wanted more.

    VB6 added more features, and I was glad for them, but it was clear by that
    time that the language was falling behind in simplicity and power (for certain
    types of apps, at least - not GUIs) to Java.

    So you tell me, Stability Boy, how do you take a language with 10 years of
    legacy add-ons and make it compete with Java, C# (yep, competition there
    too), and JavaScript? The answer, of course, is YOU CAN'T. There would
    be no new VB6.NET development, only legacy-code, and the language would die
    within a year or two, and you would still be complaining about how Microsoft
    does not care about you.

    You bet I hope they keep improving the language! Mainly, though, I hope
    they improve C# a bit. :-)


  7. #67
    Jason Guest

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


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


    Learn to read. VB has always had multiple levels of users, but Microsoft
    spent a lot of effort making the language simple enough so even you could
    use it for simple things. It is, for instance, very easy to make a form
    that contains a button that pops up a message box. It requires you to write
    only one line of code, in fact.

    Nowhere, NOWHERE, did I say that the ordinary users of VB were morons. You,
    on the other hand, are obviously not an ordinary user.

  8. #68
    Jason Guest

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


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


    This statement simply shows that you don't have a clue where business architectures
    are headed. VB-classic was good for the old kind, but the new kind work
    a bit differently. They require that some of the code reside on these machines
    called "servers." Have you heard of that term? What about networks? Communications
    protocols? .NET handles these sorts of things for you almost automagically,
    but if you are using VB6, you are pretty much on your own. And the event
    driven, single-threaded WinSock implementation is a nightmare for anything
    complex.

    And again, in server-side code, you cannot get along without threads. You
    can hide it in COM+, but it's actually a lot simpler just to manage your
    own threads in most cases.

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


    How about I put some words in YOUR mouth for a change.

    Said MM - "I am an ignorant wanna-be programmer."

    Said Jason - "I think threads are VERY important."

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


    Good idea. You don't understand fundamental theoretical CompSci concepts,
    nor how they are applied in the real world. Maybe having to apply programming
    skills for a grade would motivate you to become less ignorant.

    Call me patronizing! Hah!

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


    See, you still don't understand. No experience. No understanding. If you
    did any real programming, you would know that there are some things that
    just scream for threads, and other things where they just kill you.

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


    Except Java doesn't talk to VB-classic very well. And there are no standard
    protocols developed. And Web Services is a long way from being standardized
    or secure. And VB-classic does not support them well anyway. Not to mention
    the fact that Web Services don't support asychronous callbacks (think chat
    program), so if you ever need that you are out of luck.

    Again, you are making very simple statements that show your total lack of
    knowledge about anything but a small subset of programming problems.


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


    No, you are again making some very big assumptions. Java has many technical
    deficiencies, which, if you ever used it to do something real, you would
    realize right away. Great language. Mediocre framework. Makes some very
    simple things almost impossible.

    Microsoft needs a development platform that addresses PDA, Desktop, and Server
    needs, running the gamut for all applications but device drivers and core
    OS components (where C++ continues to rule). Java can't do this.

    The "standard" for PDAs (there have been several) is still being developed
    and solidified.

    Java has not taken off on the desktop, and given the current direction, it
    will NEVER be able to produce programs that are comparable to VB6 in look/feel
    or responsiveness. Plus, by definition Java can't do simple things like
    access the registry or determine the amount of free space on a hard drive.

    Java is stable and solid in server applications, and with the 1.4 release,
    it finally has a decent, scalable sockets library. Took 'em long enough.
    Not blazingly fast, and does not tie in to the Windows Event Logs when running
    in Windows. Usually requires a text editor to configure server apps of any
    complexity, so expect to write a lot of documentation.

    So I think Microsoft would have gone this way regardless. Sun really handicapped
    Java for Windows development. They can do that, though. Most people at
    Sun refuse to use Java, and there are still no major applications that are
    100% Java, other than some development environments (JBuilder). Why would
    a smart company like Microsoft bet the company on a platform with all those
    weaknesses controlled by a company whose main focus is on hardware sales?



  9. #69
    Jason Guest

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


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


    400,000 people marched to protest VB.NET? No....

    The "world" has chosen. The "world" was involved in the decision to make
    VB.NET not be backwards compatible. Unfortunately for you, 50% + 1 vote
    makes a majority.

    Anyway, ALL YOUR OLD CODE STILL RUNS UNDER VB6. Are you that bad a programmer
    that you can't write NEW code in VB.NET, or are you planning on going through
    life without writing another line of code, just porting the old stuff forward
    forever? You know, some of us programmers actually write code because we
    have new ideas and new problems to solve. You should try it.

    And stop preaching about profit and greed. If you weren't greedy, you wouldn't
    be a programmer. Programmers, most of them anyway, expect to be paid for
    their services. That is just plain greedy. You should program for free.
    Actually, judging from your discussions here, you should be paying people
    to accept your code.

    As to the "coexistence of VB alongside VB.NET," are you that much of an idiot?
    They work together just fine. You just can't port VB6 code into Visual
    Studio 7. So what? I can run my old VB6 apps on a machine with .NET installed.
    I can write DLLs in .NET and use them in VB6. I can write DLLs and ActiveX
    controls in VB6 and use them in .NET.

    It's "programmers" like you who can't understand simple concepts that give
    the whole profession a bad name.


  10. #70
    Jason Guest

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


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


    Maybe you have never written an application that is considered "production-quality."
    Yes, I have used it as a working version of C++, and I have also used it
    to do "good enough," quick-and-dirty solutions.

    I understand VBs strengths very well. I am also VERY familiar with its many
    weaknesses. These are weaknesses that some newer languages don't have, and
    VB.NET and C# have virtually none of them. In fact, the quick-and-dirty
    apps you do in C# are every bit as good as the C++-like production quality
    apps that you sweat over in VB6, with only a fraction of the work.

    Mike, as long as you stick to very simple apps, you really don't need anything
    other than VB6. That way, you won't have to learn anything new, which is
    possibly the real reason why you refuse to pick up .NET?

    Again, until you have tried using .NET to develop business apps, you really
    have nothing to say about whether it is better or worse than VB6. I say
    it is better, and I have actual experience with the tool. You say it is
    worse - but you have yet to install the tool, being content to hold on to
    your beliefs and prejudices despite the fact that you are just plain wrong.

    VB6 was a great tool in its day. That day is over. There is now a better
    tool for GUI development on Windows, and numerous better tools for development
    in other venues. You don't have to believe it, and you don't have to like
    it, but facts is facts.

  11. #71
    Phil Weber Guest

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

    > The "world" was involved in the decision to make VB.NET
    > not be backwards compatible.


    Jason: It was? No one offered me backwards compatibility as an option.
    --
    Phil Weber



  12. #72
    Kunle Odutola Guest

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

    Jason wrote:

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

    >
    > Language stability is a feature that VB6 will have from now on!


    ROFLMAO-ASMT!!

    Kunle



  13. #73
    Mike Mitchell Guest

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

    On 27 Sep 2002 23:07:45 -0700, "Jason" <jason@hotmail.com> wrote:

    >400,000 people marched to protest VB.NET? No....
    >
    >The "world" has chosen. The "world" was involved in the decision to make
    >VB.NET not be backwards compatible. Unfortunately for you, 50% + 1 vote
    >makes a majority.


    What *are* you going on about? What is this "world" of which you
    speak? Oh, the "world" according to Bill Gates' empire, yes? The
    reason why VB.Net is not backwards compatible is very simple:
    Microsoft did not want to make it so. The reason for that is, they
    wanted to ensure that all future programming will be done within the
    ..Net framework. (Warning to FoxPro users: Don those hard hats now!)
    Because only through .Net will Microsoft even stand a chance of
    controlling the market and thus dictating its future remuneration. As
    Dan keeps pointing out, it's all about money. Microsoft can no longer
    depend on a license to print money courtesy of new PC sales, and so it
    has to think of the future. What they came up with was .Net, and it
    was serendipitous that the technological basis for it happened to
    coincide with Sun's refusal to allow Microsoft to ride roughshod over
    the sunlit uplands of Java. Basically, Microsoft decided that they
    needed to reinvent the Gillette way of doing business: Produce a
    method by which consumers can be charged over and over again for
    repeat sales. That item or service will be, say, a few elements of
    code, perhaps a sort routine. Instead of the consumer getting to buy
    the sort routine once and thereafter being permitted to use it over
    and over again for all eternity, the new way will be to download the
    sort routine over and over again for all eternity. Notice the
    difference? The downloading consumer didn't buy it up front! And so
    the download mechanism can have its own built-in purchase scheme, one
    where the consumer pays for each download separately. Fundamentally,
    like the Gillette school of thought, this is no different from buying
    replacement razor blades. Most men (and a few women) will happily buy
    new blades every week or so because they're cheap (the blades, I mean)
    and we all like a clean shave.

    But there *is* a fundamental difference. The new model *is* a trick.
    It *is* contrived to part you the consumer from your cash. The
    difference is that when you apply a new razor blade to your overnight
    stubble, you are "consuming" a resource. Your beard grew as a result
    of nature. Your blade becomes dull through scraping it across those
    hairs. After two to three uses the blade is useless.

    But the sort routine? Does it become useless after two or three uses?
    What about after two or three hundred uses, or two or three hundred
    thousand uses?

    By equating downloading with dynamic, state-of-the-art technology and
    meeting head-on the thrusting pace of change, consumers are being
    duped into thinking that it must be the model for the future. And,
    heck, the micropayments are dead cheap!

    However, whereas the mighty Gillette now has to compete with the likes
    of Bic and all the other cheap disposable razor technologies,
    Microsoft wants to remove all of its own competition at all costs. No
    back doors. No side entrances. No chance for others to use, say, VB6
    for talking to this or that "web" service. Because anything that does
    not use .Net is by definition not controllable. And if it is not the
    latter, then how can the finance guys predict the success of the
    payment-by-download method? Ideally, you'd want to be able to control
    the whole life experience, so what better way to do it than removing
    all spare keys from the ex-wives?

    You, Jason, are falling for this hook, line and sinker! Judging by the
    kinds of statements recently that seek to talk up the .Net philosophy,
    you are still in a minority, however. Others, me for example, would
    prefer to have nothing to do with it because there are many
    alternatives that do not included putting all one's eggs into the
    Microsoft basket, only to find that the basket is of a special design
    where one has to pay to get the eggs back out later.

    It's your choice!

    >Anyway, ALL YOUR OLD CODE STILL RUNS UNDER VB6. Are you that bad a programmer
    >that you can't write NEW code in VB.NET, or are you planning on going through
    >life without writing another line of code, just porting the old stuff forward
    >forever? You know, some of us programmers actually write code because we
    >have new ideas and new problems to solve. You should try it.


    I liked that "You should try it." rider at the end! I don't know what
    it means. It is an enigma, and like all enigmas to a curious person
    such as myself, truly fascinating. As an explorer might once have
    sailed the oceans in search of something new, I scan that short
    sentence in vain to see any sign of significance. "You should try it."
    I let those four syllables bounce around in my brain for a while,
    hoping that random juxtaposition might engender more coherence. But
    no, it remains as enigmatic a sentence as when it started out as a
    fleeting miasma of inspiration on your train of thought.

    But let's look at other sentences: The one, for example, that starts:
    "Are you a bad programmer...." This I see frequently from the
    evangelists for .Net. It is the argument that goes: ".Net = Good;
    Everything Else = Bad". In common with so much of the black and white
    thinking that accompanies the .Netizens outlook on life, this Good/Bad
    continuum even stretches to the programmers involved. Thus, by
    extrapolation, .Net Programmers = Good; Every Other Programmer = Bad"
    This is really just a cheap form of advertising that uses knocking
    copy to damage the competition - largely banned in Europe, but no
    doubt, judging by the farce that serves for political debate in the
    US, fully permitted across the pond.

    So, if I were to suddenly start becoming a "friend" of .Net, I would
    just as suddenly lose pariah status amongst those proponents of
    knocking copy. Well, maybe not quite so suddenly. Maybe I'd have to
    spend 40 days and nights in the wilderness that finally ends up
    flowing into One Microsoft Way, where a welcoming crowd of .Net Angels
    would be waiting, harps at the ready and cruise missiles in the wings,
    to echo "My .Net right or wrong" and give me a pat on the back and a
    free copy of Slate (which actually contains an interesting view on the
    hawks and their stance on Iraq: http://slate.msn.com/?id=2071538).

    But, Jason, you equate "bad" with the inability to write new code!
    What happened to willingness and unwillingness here?!! Surely, you
    must, if you believe in the diversity of views generally held, and
    allowed to be held, in a democracy, then you must admit to allowing
    others their preference for just plain old disinterest! Or does voting
    for either Bush or Gore automatically make the one or the other voter
    "good" or "bad", depending on your particular camp? Its the
    Black/White issue all over again! Them/Us. Good/Bad. .Net/.Not.

    Now wouldn't it be a jolly good idea if one could plan on going
    through life without writing another line of code, by just porting the
    old stuff forward forever? I mean, in an ideal world, would you *want*
    to write new code just because? Or maybe because it provides you with
    an intellectual challenge? For those of us who write business
    applications (and that includes the many diverse examples from the
    "Basic Heroes" columns), we get enough intellectual stimulation as it
    is just by keeping up with the weekly changes that emanate from
    Microsoft! Our Shangri-la would be a place where all code only needs
    to be written once, and thereafter only roll-outs ensue, along with
    the approbation, of course, and the free drinks at celebratory launch
    parties, preferably on desert islands surrounded by palm trees and
    nocturnal naughtiness. I reckon, every Monday would be Roll-out
    Preparation Day, followed by the actual roll-out on Tuesday, the
    emergency bug-fixes on Wednesday, travel to the Holiday Inn for the
    meeting with the company big-wigs on Thursday, and the final launch
    bash on Friday, allowing Saturday and Sunday for the alcohol to
    disperse and any residual stupor to evaporate, ready for Monday again.
    (Sorry? What was that? This is what .Netizens understand by XCOPY...?)

    So why would it make sense to write new code if the old code works?
    The old code that not only works, but has also been bug-fixed? Don't
    you believe that old code, as long as it works, must be inherently
    more reliable, more stable, and more efficient that new code? Could it
    be that the huge UNreliability of most code nowadays (e.g.
    Microsoft's) is because people just won't stop tweaking it? They keep
    fiddling, like a cuckold hoping for bodily signs of requited love, in
    case they may suddenly hit upon the secret that's alluded them so far.
    They are forever trying to fix what ain't broke. Their ministrations
    cause distension and bloat - no software ever gets smaller! Contrast
    this never-ending adventure in search of "new", "novel", "rewrite"
    with "bad" programmers, who take what's already there and build upon
    it. Isn't that really what *good* programmers do by adopting the
    policy of continual improvement?

    But maybe you believe that rewriting is good for its own sake. That
    code should be rewritten now and again, because that exercise will
    inevitably make the code "good" again, like a refreshing shower. If
    so, you're an ideal candidate for the Gillette school of thought,
    where the "razor blades" of code are magically deemed to have worn out
    and need replacing. If you can afford to attend that school despite
    the continuous drip-feed of micropayments, that is.

    And if you have new ideas and new problems to solve, thus
    necessitating, in your view, that (new?) code to be written, so what?
    Once, all code was "new" in the sense that it didn't exist before.
    Most "new" ideas in computing are not new at all; they are just
    revamps of existing technologies dressed up in new marketing clothes
    to sell to the punters. Look at some of the fundamentals of computing,
    like TCP/IP, Boolean algebra, files, GIF/JPEG/TIF structures, and very
    many more. Most if not all of those are eons old, Boolean stretching
    way back. It's not like we need a new picture format every month, or a
    new sort routine. We don't need most of the wheel reinventions. But we
    are forced, largely, to accept them because people like you believe
    that "new" means "good" and thus we "should try them".

    >And stop preaching about profit and greed. If you weren't greedy, you wouldn't
    >be a programmer.


    Are Linux programmers greedy? Can no one who is greedy become a Linux
    programmer? You must truly be greedy if you equate ordinary recompense
    with greed! Greedy means: taking more than you need; being selfish;
    having an unreasonable desire to covet. It does not mean earning a
    fair day's pay. We know now how widespread greed is in corporate
    America. The newspapers have been full of little else over the past
    few months. American greed has led to the biggest bankrupties in
    history, and there's probably still more to come. And like most things
    in society, we are all tainted. When hubby comes home with stories of
    how his company "got one over" on a competitor, a nod and a wink
    signifying some nefarious sleight of hand in the way the misdeed was
    contrived, this will be noted by the kids, who will begin to believe
    that this is the right way to live. And thus one generation of the
    moderately greedy begets the next of excessively greedy and so the
    cycle is repeated throughout the decades until 2002, when even the
    politicians become tainted, the very upholders and proponents of
    democracy, the single bulwark between democracy and anarchy, are
    implicated and the people suddenly wake up and demand a rebalance.
    Trouble is, when you can't even trust the auditors, who else is there?

    This is why I and many others "preach" about greed. It's bad. It's a
    sin. Get over it!

    > Programmers, most of them anyway, expect to be paid for
    >their services. That is just plain greedy.


    Don't be silly. Of course it isn't! Expecting to be paid for one's
    services is as old as humanity and not to be mistaken for greed. Of
    course, this would suit those who aspire to greed, as it would somehow
    imbue them with righteous justification to maintain that goal. What
    we, as programmers, do in terms of remuneration for our efforts is
    absolutely no different from digging a ditch for the farmer and
    getting paid by the metre. At the end of the day the farmer measures
    out the length dug, does a simple multiplication, and we go home with
    our fair dues. Of course, if we had already arranged for all other
    ditch diggers in the vicinity to suffer an untimely demise, perhaps by
    encouraging them to dig their ditch too deep and then suffer the fatal
    ignominy of having it fall in and bury them, then we could demand of
    the farmer that he pay us double the negotiated fee. The farmer might
    grumble, but faced with a shortage of ditches and impending floods,
    what alternatives does he have? We know that; we know he knows that.
    But sooner or later, the greed button will be pushed one too many
    times and the farmer will take our shovel, beat us roundly over the
    head with it, utter a few choice words of epithet, and then turn to
    the new army of ditch diggers he has found across the frontier.

    > You should program for free.


    Here's another one of those "You should..." missives. Like Papal
    bulls, they smack of religious fervour - this time for the god of
    ..Net!

    > Actually, judging from your discussions here, you should be paying people
    >to accept your code.


    Amazing how not agreeing with someone can affect their whole outlook
    on things!

    >As to the "coexistence of VB alongside VB.NET," are you that much of an idiot?
    > They work together just fine.


    You misunderstood. I am looking for coexistence not as the physical
    coexistence on the same machine, but in terms of equal marketing
    stature. That is, classic VB should be allowed to continue, should be
    promoted as an alternative to .Net for the benefit of the millions of
    programmers who bought into the original VB promise, and not summarily
    sentenced to an afterlife of obscurity and denigration, such as that
    heaped upon it by The Chosen Few, such as yourself.

    > You just can't port VB6 code into Visual
    >Studio 7. So what? I can run my old VB6 apps on a machine with .NET installed.
    > I can write DLLs in .NET and use them in VB6. I can write DLLs and ActiveX
    >controls in VB6 and use them in .NET.
    >
    >It's "programmers" like you who can't understand simple concepts that give
    >the whole profession a bad name.


    Ooer! I expect even FoxPro programmers will be quaking in their boots!
    Not to mention those who write microcode for Intel CPUs, or production
    control engineers programming their latest EPROM. All of them by
    inference totally rotten to the core, and all because MM refuses to
    "see" the Emperor's new clothes!

    YeahRight!

    MM

  14. #74
    Mike Mitchell Guest

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

    On 27 Sep 2002 23:23:27 -0700, "Jason" <jason@hotmail.com> wrote:

    >Maybe you have never written an application that is considered "production-quality."
    > Yes, I have used it as a working version of C++, and I have also used it
    >to do "good enough," quick-and-dirty solutions.


    Here's a free clue: Use classic VB as the "most productive tool for
    creating fast business solutions", i.e. as per its targeted market.
    and you won't get bogged down in all the kinds of complications you
    suffer when you try to use it as a working version of C++, something
    it was never designed to be. As for "good enough" applications, surely
    they are good enough? Or maybe not? You appear to imply that "good
    enough" means kludgy, rushed applications that will break at the
    merest hint of user ineptitude, whereas the apps written while using
    VB as a working version of C++ are anything but a kludge, being
    thoroughly designed, tested and debugged applications at the pinnacle
    of achievement.

    Why cannot classic VB be used to scale that mighty mountain of
    achievement? Do you know, I rather believe it has - in the hands of
    others over the past eleven years! And without needing to descend to
    the non-RAD level of C++ either.

    >I understand VBs strengths very well. I am also VERY familiar with its many
    >weaknesses. These are weaknesses that some newer languages don't have, and
    >VB.NET and C# have virtually none of them. In fact, the quick-and-dirty
    >apps you do in C# are every bit as good as the C++-like production quality
    >apps that you sweat over in VB6, with only a fraction of the work.


    I still don't know what you mean with "C++-like production quality
    apps". Are production quality apps not achievable in anything but
    C++-like languages? Did no FoxPro developer ever deliver a production
    quality app? What about all the apps written with PowerBuilder,
    Delphi, et al? Were none of those of production quality? Do you really
    believe that classic VB developers "sweated" for eleven years to
    produce apps of quality whenever their apps were not "very simple"? I
    tend to believe that they sweated when they were trying to use VB as a
    working version of C++, but when they were not and instead using VB in
    the manner intended they were having a ball! I know I did and I expect
    there were millions like me. This idea that the only way VB could be
    made to deliver functionality was by low-level inteference along the
    lines of C++ is nothing more or less than propaganda, as blatantly
    transparent as a classic Label with its BackStyle property set to
    zero. (By the way, is that capability still provided in VB.Net?)

    >Mike, as long as you stick to very simple apps, you really don't need anything
    >other than VB6. That way, you won't have to learn anything new, which is
    >possibly the real reason why you refuse to pick up .NET?


    But VB6 as well as its ancestor versions was used to write powerful
    apps as well, thousands of them, not just the "very simple" ones,
    which, I suppose, equate to your "good enough" ones. And when you try
    to tell me the "real" reason why I refuse to pick up .Net, you imply
    that everything I say and write against it is in some way not real,
    that I sit here for hours at a time merely because it's better than
    watching paint dry. I should have thought that my reasons by now had
    become as real as breathing to most people who visit this newsgroup.
    Surely with so many genuinely real reasons to advance I have
    absolutely no need to fabricate ones? The messages I'm getting are
    that you want to use VB as a working version of C++, ergo you move to
    VB.Net; classic VB while good enough for "very simple" apps causes you
    to sweat over delivering production quality; and you have to learn
    something new if your work is to be worth anything. Correct me on the
    details by all means, but I believe that is the gist of your thinking
    here.

    >Again, until you have tried using .NET to develop business apps, you really
    >have nothing to say about whether it is better or worse than VB6. I say
    >it is better, and I have actual experience with the tool. You say it is
    >worse - but you have yet to install the tool, being content to hold on to
    >your beliefs and prejudices despite the fact that you are just plain wrong.


    Am I plain wrong to see all that existing VB code and seeing the mark
    of the cross against it? How many hundreds of hours have programmers
    poured into developing their routines? Maybe some pet routines
    comprise several functions, a whole bunch of code in fact. And all of
    it, in computing terms, equally explicable in C, in MASM, in Pascal.
    But all of it needing to be rewritten if taken into those different
    languages. And VB.Net is no different in this respect from those
    different languages. For the purposes of software reuse it is as
    different as if it were *REALLY* C# or J#. NO OTHER version of
    Microsoft B.A.S.I.C. has differed quite as much. No software reuse is
    possible now. VB programmers will have to rewrite millions, literally,
    of lines of code if they want to take with them those precious nuggets
    panned from the hundreds of hours of brainwork late into the night
    while junior grows and loses his first tooth, learns to walk, or goes
    on his first date. Perhaps you have nothing to lose.

    >VB6 was a great tool in its day. That day is over. There is now a better
    >tool for GUI development on Windows, and numerous better tools for development
    >in other venues. You don't have to believe it, and you don't have to like
    >it, but facts is facts.


    I'll just leave that last paragraph to be regarded as graffiti on the
    tomb of classic VB 1991 - 2002.

    MM

  15. #75
    Kunle Odutola Guest

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

    Mike Mitchell wrote:

    > The
    > reason why VB.Net is not backwards compatible is very simple:
    > Microsoft did not want to make it so.


    Given that Microsoft created, owns and controls VB future on behalf of it's
    customers, what other reason is relevant?

    Don't like it?. Write your own development tool. These guys have done (or
    are doing) just that....

    www.xbasic.org
    http://sf.net/projects/yabasic/
    http://basic.foundries.sourceforge.net/

    Cheers,

    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