Another Language


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 1 of 18 12311 ... LastLast
Results 1 to 15 of 261

Thread: Another Language

  1. #1
    Steven Bell Guest

    Another Language


    It all boils down to one thing: Learning a new language.

    In essence, learning to adapt Visual Basic 6.0 applications (a majority of
    which are client server) to "upgrade" to VB.NET is the same as learning a
    new language.

    So, why bother with an unknown like VB.NET? (Rhetorical Question #1)

    Why not learn another unknown like C#? (Rhetorical Question #2)

    Or a known language like Java? (Rhetorical Question #3)

    I have been programming Visual Basic since 1994, am an MCSD with a focus
    on Visual Basic. I have 18+ years in the programming industry and have now
    moved up to being a CIO in a start-up venture. If I am having to figure
    out where my software-development company is going to go with this stuff...well,
    that's bad. It leads to: What will I have to learn and is it profitable
    for me to learn it (i.e. is it worth my valuable time)? What will I have
    to force my existing staff to learn? AND what kind of people will I be hiring?


    An additional, and I might add: very interesting, side effect is whether
    I continue with the MCSD program. The answer at this moment is a reluctant
    no. The reason: I will not pay for my employees to re-take the entire plethora
    of exams (they will have to do it now on the own time and money), I will
    not do so (not worth my time, it has absolutely no bearing on reality anymore).

    Finally, the majority of application work that I find (especially in the
    Dallas/Ft. Worth area) is Visual Basic 6.0 client/server or browser/server
    applications. VB.NET does NOT address this. At all.

    There! I vented. Just and FYI for you career minded folk out there. I
    am a consultant and employer and I see no immediate or future need for VB.NET.
    If Microsoft insists, in this huge paradigm shift, then it looks like a
    golden opportunity for another company to produce a VB look-alike. Perhaps
    a cross-platform VB look-alike...ah, well, I can always dream.

    Steven Bell
    CIO
    Momentium Technologies
    Dalls, TX

  2. #2
    Rob Teixeira Guest

    Re: Another Language


    "Steven Bell" <sbell@momentiumtech.com> wrote:

    [snip rhetorical vent]

    >An additional, and I might add: very interesting, side effect is whether
    >I continue with the MCSD program. The answer at this moment is a reluctant
    >no. The reason: I will not pay for my employees to re-take the entire

    plethora
    >of exams (they will have to do it now on the own time and money), I will
    >not do so (not worth my time, it has absolutely no bearing on reality anymore).


    But you already had to retake the tests for previous versions every time
    a new one came out. I don't understand how this is different?
    To keep the VB certification current, you had to take the VB3.0, VB4.0, VB5.0,
    and VB6.0 tests. If there was a VB 7 that looked *exactly* like VB 6.0 but
    with some new additions, they you'd have to take that exam as well. So I
    don't see the difference.
    But to be honest, I've never seen the "reality" bearing of the tests in the
    first. That's another ball of wax.

    >Finally, the majority of application work that I find (especially in the
    >Dallas/Ft. Worth area) is Visual Basic 6.0 client/server or browser/server
    >applications. VB.NET does NOT address this. At all.


    How can you possibly say that? What are doing with client/server or browser/server
    in VB6 that you can't do in VB.NET?
    VB.NET uses the Winforms namespace in the Framework, which is a drastic improvement
    on the old VB "rich" client forms/controls package. Remoting in VB.NET is
    far superior to DCOM. Transaction support is also much better and you can
    take full advantage of COM+ since the product is free-threaded and supports
    object pooling.

    >There! I vented. Just and FYI for you career minded folk out there. I
    >am a consultant and employer and I see no immediate or future need for VB.NET.


    My opinion is far different, but I don't think we'd agree further unless
    we get some common ground here.

    > If Microsoft insists, in this huge paradigm shift, then it looks like a
    >golden opportunity for another company to produce a VB look-alike. Perhaps
    >a cross-platform VB look-alike...ah, well, I can always dream.


    Perhaps, but I don't see a need for that.

    If anything, someone will produce a cross-platform CLR and your VB.NET code
    would work with that.

    -Rob

  3. #3
    Mike Mitchell Guest

    Re: Another Language

    On 29 Apr 2001 05:49:23 -0700, "Steven Bell" <sbell@momentiumtech.com>
    wrote:

    >Finally, the majority of application work that I find (especially in the
    >Dallas/Ft. Worth area) is Visual Basic 6.0 client/server or browser/server
    >applications. VB.NET does NOT address this. At all.


    Well, Steven, I keep telling 'em the same thing, but do they listen?
    Do they hear? Know those three wise monkeys with their hands covering
    their ears, their eyes, their mouths? Recognise a parallel here?

    MM

  4. #4
    Mike Mitchell Guest

    Re: Another Language

    On 29 Apr 2001 06:05:13 -0700, "Rob Teixeira" <RobTeixeira@@msn.com>
    wrote:

    >
    >>Finally, the majority of application work that I find (especially in the
    >>Dallas/Ft. Worth area) is Visual Basic 6.0 client/server or browser/server
    >>applications. VB.NET does NOT address this. At all.

    >
    >How can you possibly say that? What are doing with client/server or browser/server
    >in VB6 that you can't do in VB.NET?
    >VB.NET uses the Winforms namespace in the Framework, which is a drastic improvement
    >on the old VB "rich" client forms/controls package. Remoting in VB.NET is
    >far superior to DCOM. Transaction support is also much better and you can
    >take full advantage of COM+ since the product is free-threaded and supports
    >object pooling.


    I dunno. What's a guy supposed to do? You show him all these goodies,
    and *still* he likes classic VB more. What will it take to convince
    him? Me? Thousands of others?

    MM

  5. #5
    Paul Mc Guest

    Re: Another Language



    >Finally, the majority of application work that I find (especially in the
    >Dallas/Ft. Worth area) is Visual Basic 6.0 client/server or >browser/server

    applications. VB.NET does NOT address this. At all.

    Well this gives me a giggle. VB.Net does not address browser/server apps
    huh? Have you actually seen VB.Net?

    >Well, Steven, I keep telling 'em the same thing, but do they listen?
    >Do they hear? Know those three wise monkeys with their hands covering
    >their ears, their eyes, their mouths? Recognise a parallel here?


    Actually I recognise a parrallel. Perhaps not exactly the one you are attempting
    to imply, ironically enough....

    And yes, we do listen - well, read. It is just that we know otherwise - having,
    you know, actually spent some time and effort to get to know the subject
    matter.

    Paul Mc

  6. #6
    Jay Glynn Guest

    Re: Another Language

    Steven,

    > Finally, the majority of application work that I find (especially in the
    > Dallas/Ft. Worth area) is Visual Basic 6.0 client/server or browser/server
    > applications. VB.NET does NOT address this. At all.


    Your not looking close enough. .NET in general address this in many ways.

    --
    Jay Glynn
    Introducing .NET




  7. #7
    Zane Thomas Guest

    Re: Another Language

    On 29 Apr 2001 15:54:29 -0700, "Paul Mc" <paulmc@nospam.thehub.com.au>
    wrote:

    >Have you actually seen VB.Net?


    Is there really any serious question?


    ---
    Ice Z - Straight Outta Redmond

  8. #8
    Rob Teixeira Guest

    Re: Another Language


    You don't know that. He hasn't posted anything since.
    But so what? I haven't shown him anything. I just told him about it. I'd
    be skepticle too in his shoes. If he really IS smart, he'll see for himself,
    then make an informed decision (unlike some people I know...)

    If anyone still thinks that .NET is nothing but webservices, then there are
    a few bridges I'd like to sell them. Of course, I also partly blame the MS
    marketing machine for not properly presenting the product either. Still,
    their mistake is no reason for anyone's continued and prepetual ignorance.

    -Rob

    kylix_is@hotmail.com (Mike Mitchell) wrote:
    >On 29 Apr 2001 06:05:13 -0700, "Rob Teixeira" <RobTeixeira@@msn.com>
    >wrote:
    >
    >>
    >>>Finally, the majority of application work that I find (especially in the
    >>>Dallas/Ft. Worth area) is Visual Basic 6.0 client/server or browser/server
    >>>applications. VB.NET does NOT address this. At all.

    >>
    >>How can you possibly say that? What are doing with client/server or browser/server
    >>in VB6 that you can't do in VB.NET?
    >>VB.NET uses the Winforms namespace in the Framework, which is a drastic

    improvement
    >>on the old VB "rich" client forms/controls package. Remoting in VB.NET

    is
    >>far superior to DCOM. Transaction support is also much better and you can
    >>take full advantage of COM+ since the product is free-threaded and supports
    >>object pooling.

    >
    >I dunno. What's a guy supposed to do? You show him all these goodies,
    >and *still* he likes classic VB more. What will it take to convince
    >him? Me? Thousands of others?
    >
    >MM



  9. #9
    Larry Linson Guest

    Re: Another Language


    Gee, it's amazing to me that the proponents of VB.NET seem to be able only
    to deprecate those who aren't thrilled with it, but not to explain _how_
    it is better for, or makes it easier to develop, standalone and client-server
    applications. But, I agree with the statement that it _does_ address standalone
    applications, client-server, and browser-server applications, in its way.
    (So do a goodly list of other tools, see below for some that I opted not
    to use in the past.)

    It certainly doesn't provide the compiled code that was such a terrific thing
    not long ago when Microsoft got around to it, and a number of other useful
    features -- like variants. It certainly does require an object-oriented view
    if you are to make good (not just best) use of it. It certainly does require
    a significant re-learning process. And, I'd emphasize again, no one has convinced
    me that it addresses the standalone and client-server areas any _better_
    than previous versions, and those are the ones clients have called on me
    to handle since 1991. And, I am eager to be convinced... I keep being told
    that it handles the "small stuff" just fine, but what I read, and what I
    hear applauded, are all the things that make it better for huge, team-developed,
    code-intensive, distributed applications.

    Prior to 1991, I _was_ involved with Enterprise-wide, some international-in-scope,
    distributed applications of enormous magnitude, even before IBM introduced
    the PC (without a single "object" in any of those, FYI). But, after I retired
    from IBM, I was quite happy to solve a different class of business problems
    and I was quite happy to have tools like 'classic VB' and Access that would
    let me solve them with a minimum of fuss and bother.

    I'll say it again, because it's true: Microsoft has taken the most popular
    and successful Development Tool of all time and turned it into just another
    object-oriented language. If I'd wanted to develop standalone and client
    applications in an object-oriented language, there were a plethora available.
    But, I didn't opt for Delphi, I didn't opt for C++ Builder, I didn't opt
    for JBuilder, for Pascal, for C++, or one of the others.

    I'll say this again, too: object oriented tools can be very useful for code-intensive
    environments, but my appreciation of VB and Access was because they didn't
    _have to be_ code-intensive environments. I could be wrong, but it certainly
    appears to me that VB.NET, by its nature, is going to be a more code-intensive
    environment than classic VB.

    VB.NET has pulled the rug out from under a very significant portion (while
    I don't have figures, my guess from the user groups to which I belong would
    be, the majority) of VB developers.

    If VB.NET's not, as its proponents claim, a new language with a few familiar
    statements, it is certainly much different than "classic VB". It is going
    to cost those who move to it an investment in learning and adjusting their
    'paradigm' to take advantage of the object orientation. I speak from long
    experience: in my 43 years in the computer business, I've learned language
    after language. The difference? Before, there was a _reason_, there was some
    benefit to each, not just because "the language had to change" because the
    vendor decided it should, nor because a group of elitists decided that it
    had too many flaws, despite it being useful and perfectly well-suited to
    the applications at hand. Always before, when I experienced this significant
    a change, the vendor/author at least had the honesty to give the new language
    a new name.

    Perhaps, because of those long years, and, perhaps, because I saw the beginnings
    of objects and wasn't impressed (because OO simply codified and partially
    automated what had been good programming practices since the beginning),
    I'll be dismissed as just another old codger who ought to give it up because
    the world is changing around him. But, perhaps someone will see that the
    old codger has lived through a few 'world changing around him' times, has
    been there, done that, and got the T-shirt (which says, "Change for change's
    sake isn't new, it's just bad.", said with apologies to Bill Vaughn for coopting
    and reversing his refrain).


    "Paul Mc" <paulmc@nospam.thehub.com.au> wrote:
    >
    >
    >>Finally, the majority of application work that I find (especially in the
    >>Dallas/Ft. Worth area) is Visual Basic 6.0 client/server or >browser/server

    >applications. VB.NET does NOT address this. At all.
    >
    >Well this gives me a giggle. VB.Net does not address browser/server apps
    >huh? Have you actually seen VB.Net?
    >
    >>Well, Steven, I keep telling 'em the same thing, but do they listen?
    >>Do they hear? Know those three wise monkeys with their hands covering
    >>their ears, their eyes, their mouths? Recognise a parallel here?

    >
    >Actually I recognise a parrallel. Perhaps not exactly the one you are attempting
    >to imply, ironically enough....
    >
    >And yes, we do listen - well, read. It is just that we know otherwise -

    having,
    >you know, actually spent some time and effort to get to know the subject
    >matter.
    >
    >Paul Mc



  10. #10
    Paul Mc Guest

    Re: Another Language


    >Gee, it's amazing to me that the proponents of VB.NET seem to be able only
    >to deprecate those who aren't thrilled with it, but not to explain _how_
    >it is better for, or makes it easier to develop, standalone and client-server
    >applications.


    Larry,

    I was not deprecating the opposing camp for simply disagreeing - I was taking
    issue mainly with the following statement: (Quote) "Know those three wise
    monkeys with their hands covering
    their ears, their eyes, their mouths? Recognise a parallel here?" (EndQuote)
    <- this made in reference to those of us who argue the pro .Net case. Sound
    particularly constructive to you? I replied that I hear them, I listen -
    but do not agree.

    I welcome and enjoy a good, technical disagreement. I do not repect arguments
    along the lines of "I haven't really taken the time to fully understand it
    but it looks quite different so it is a bad thing."

    >I keep being told that it handles the "small stuff" just fine, but what

    I >read, and what I
    >hear applauded, are all the things that make it better for huge, team-developed,
    >code-intensive, distributed applications.


    Fair comment. The greatest advances IMHO are those that will be used in the
    much larger, structured developments, specifically those that use the component
    based paradigm. This arena is where the new OO features, cross-language
    capabilities, and other stuff can really be taken advantage of.

    As for small stuff, I do not see why the new capabilities cannot make life
    easier. I have half rewritten my basic "small stuff" library into .Net -
    mostly as a learning exercise. I found that I could do a many things in different
    and exciting ways - but have not yet come across anything that I could not
    do. Sure, it is going to take me time to capitalise on the changes, and really
    understand them, but you can bet that I will. Just like with the current
    VB incarnation.

    Most of the VB.Net opposition takes two forms.

    A) Is that the changes and different capabilities are not worth the lack
    of backwards compatibility. I see this (who wouldn't) as a fair complaint.
    It is certainly going to cost me a lot of time (read money) to make the transition.
    Nevertheless, I personally disagree with this argument. I am willing to cop
    the losses, because I like what I see, and enjoy the greater freedom and
    flexibility that .Net is offering.


    B) Is that sad kind of opposition to change because it is change. I have
    no truck with this camp - they offer nothing constructive and are the most
    likely to engage in vindictive personal attacks. This type of argument gains
    nothing - it just enflames people.


    Personally, I love Current.VB. It is a great language. I also love New.VB
    -it is also a great language.

    Paul Mc

  11. #11
    Larry Linson Guest

    Re: Another Language


    "Paul Mc" <paulmc@nospam.thehub.com.au> wrote:

    > I was not deprecating the opposing camp for simply disagreeing - I was
    > taking issue mainly with the following statement: (Quote) "Know those
    > three wise monkeys with their hands covering their ears, their eyes,
    > their mouths? Recognise a parallel here?" (EndQuote)
    > <- this made in reference to those of us who argue the pro .Net case.
    > Sound particularly constructive to you? I replied that I hear them, I
    > listen - but do not agree.
    >
    > I welcome and enjoy a good, technical disagreement. I do not repect
    > arguments along the lines of "I haven't really taken the time to fully
    > understand it but it looks quite different so it is a bad thing."


    I was not just speaking of your response, although I must admit that it certainly
    was not clear to me that you were just responding to the "monkey thing".
    And, I think there is some truth that _many_ of the VB.NET supporters do
    _not_, in fact, acknowledge valid objections, but dismiss them as the maunderings
    of those too dim-witted, or too lazy, to "move forward". I apologize if I
    gave the impression that yours was the only one, but it did seem to me to
    follow that pattern.

    > As for small stuff, I do not see why the new capabilities cannot make
    > life easier. I have half rewritten my basic "small stuff" library
    > into .Net - mostly as a learning exercise. I found that I could do a
    > many things in different and exciting ways - but have not yet come
    > across anything that I could not do. Sure, it is going to take me time
    > to capitalise on the changes, and really understand them, but you can


    >bet that I will. Just like with the current VB incarnation.


    I'll also have to admit that at least twenty or so years ago, I became jaded
    on "doing things in different and exciting ways". I look for being able to
    do something I can't do now (that I need to do), for being able to do something
    that I do now simpler or quicker or easier, for something I do now being
    a better something, or for a tool that does something for me that I now to
    have to do for myself. Before anyone "calls me on the subject", no, I have
    not installed and used VB.NET. I have read a good deal on the subject, I
    have carefully examined a number of examples, and I've paid close attention
    in a number of presentations about it. So far, I fail to see anything that
    fits one of the categories I describe, for the kind of applications that
    I do.

    I've asked our local Microsoft developer contact to do a presentation to
    the VB SIGs (of which I am a member) or the Application Developer Issues
    SIG (of which I am co-leader) for a presentation on VB.NET for standalone
    and straight client-server. We haven't been able to arrange that just yet,
    though he continues to assure me that "it handles those just fine". Of course,
    in my not-so-humble opinion, Access 97 and later and all the versions of
    32-bit VB "handle those just fine", too.

    I don't have any vested interest in investing time and energy to learn something
    new that only does what I'm doing now, as well, but differently, particularly
    if there's also a chance that it will do what I'm doing now, only not quite
    as well. It is in this regard that I mention managed (tokenized) code --
    I remember the "discompiler" for tokenized VB. It's only because no one has,
    so far, given Access applications credit for being worth stealing that there
    has not been one for the 'compiled' (tokenized) .MDE.

    If I'd only wanted to do "different and exciting" there have been for a long
    time that list of alternatives that I could have done. Some would have allowed
    me to get "closer to the metal", but for solving general business problems,
    usually database or, at least, data-based, problems, I don't need to get
    closer to the metal. The only API calls that I use with any regularity are
    those for GetOpenFileName and GetSaveFileName of the Windows Common Dialog
    -- IMNSHO, as easy or easier than the custom control for WCD, and no extras
    to include in distribution, and, occasionally the BrowseForFolder API. I
    can, and have, used a few others, but my need is rare. I also do not find
    them difficult to use, so wrapping them in classes does not seem to have
    any benefit to me (as it is claimed to have for everyone).

    To me, it is clear, for changes and different capabilities to have the remote
    possibility of being worth the lack of backward compatibility, they must
    represent to me an improvement. And, as I've described above, they seem,
    at best, to allow me to do what I do as well, and, if not "at best", perhaps
    not so well as I can now.

    To me, it seems obvious, that whatever benefits .NET will bring to the VB
    developer are going to be limited to the ones who do "code intensive" work,
    and those whose applications or components will operate in the server-side
    environment with .NET servers of various kinds installed. And, others far
    more knowledgeable than I have questioned the benefits of .NET over some
    other, e.g., UNIX with Java, etc., environments. But, clearly, what's being
    touted is "server-centric" and it is not so clear that the people who buy
    and use hardware and software are nearly as enthusiastic about that change
    to the paradigm as the people who will benefit most from a move to "application
    service providers". As for me, I have long been a "power to the users" advocate,
    cheering and supporting putting power on the desktop, and chuckling behind
    my hand at the futile attempts to replace the powerful PCs with network appliances.
    I spent 'way too many years writing applications supporting dumb terminals,
    glass teletypes, and even controller-programmed terminals such as the 3270
    and 3790 family to be enthusiastic about a regression to "thin client".

    > Personally, I love Current.VB. It is a great language. I also love
    > New.VB -- it is also a great language.


    Classic VB, is not "a language" by my definition -- it is a Development Tool,
    one that includes a language, and I agree that it is a great Development
    Tool. I do agree that VB.NET is only a language, but I believe it is far,
    far too early to determine whether it will be a great one.

    I certainly believe that it is going to have far fewer users/developers than
    classic VB. I know many, and read of many others, who have no intention of
    moving to VB.NET, and a good many others who, instead of re-learning almost
    from scratch, are going to the .NET environment, but moving to C# instead
    of VB.NET. Despite your and others' advocacy, it is possible that VB.NET
    will not really maintain enough users to keep Microsoft interested in continuing
    it. The Boys and Girls in Redmond demonstrated back in nineteen-ought-ninety-something
    that lack of a groundswell will prevent a second release or continuing support
    -- heard anything about VB-DOS lately? Did anyone ever hear about VB-DOS
    2.0?

    I certainly would expect those in the business of supporting and enhancing
    Microsoft's software to be enthusiastic about it. Our colleagues who train,
    and our colleagues who write libraries and controls have little choice in
    the matter. For example, I do not, for a moment, doubt Zane's enthusiasm,
    but considering the business that Mabry is in, would he not have to be at
    least supportive even if he had some serious reservations?

  12. #12
    Gregor R. Peisker Guest

    Re: Another Language

    Hi Larry,

    > I certainly believe that it is going to have far fewer users/developers than
    > classic VB. I know many, and read of many others, who have no intention of
    > moving to VB.NET, and a good many others who, instead of re-learning almost
    > from scratch, are going to the .NET environment, but moving to C# instead
    > of VB.NET. Despite your and others' advocacy, it is possible that VB.NET
    > will not really maintain enough users to keep Microsoft interested in continuing
    > it. The Boys and Girls in Redmond demonstrated back in nineteen-ought-ninety-something
    > that lack of a groundswell will prevent a second release or continuing support
    > -- heard anything about VB-DOS lately? Did anyone ever hear about VB-DOS
    > 2.0?


    If that analogy is to make sense, you'd have to liken VB-DOS to "VB7", not VB.NET.

    Regards,
    Gregor



  13. #13
    Gregor R. Peisker Guest

    Re: Another Language

    Hi Larry,

    > It certainly does require an object-oriented view
    > if you are to make good (not just best) use of it.


    IMO, that is certainly not so. You can still write functional programs, and just "use" classes like
    in old VB6 (though classes come up more often).

    As for "best use", things are different, of course.

    Regards,
    Gregor



  14. #14
    Gary Nelson Guest

    Re: Another Language

    Gregor,

    >
    > If that analogy is to make sense, you'd have to liken VB-DOS to "VB7", not

    VB.NET.
    >


    I believe both analogies are good. VB7 will exist just as VB-DOS 2 existed.
    If MS continues putting more emphasis on C# than on VB.Net, which obviously
    it will do, VB.Net will probably end up as VB-DOS.

    At this moment any flavor of VB has a very uncertain future.

    Gary



  15. #15
    Ian Lowe Guest

    Re: Another Language

    Hi, Larry,

    <snip>
    > ...I became jaded
    > on "doing things in different and exciting ways". I look for being able to
    > do something I can't do now (that I need to do),


    There are many things that VB.NET gives you access to that VB6 doesn't.
    However, your programmes don't _need_ this, any more than the procedural
    programmes pre-classes in VB needed classes. However, the addition of
    classes gave you increased power and flexibility. In the same way, the
    addition of full threading support, structured error handling, and the rest
    are not _needed_, but neither was a GUI.

    > for being able to do something
    > that I do now simpler or quicker or easier


    Now here is where .NET can shine. Since I've started using .NET, I've found
    that many things are much simpler than before. Whether its OO techniques
    which needed to be faked or hacked in VB6, screen drawing, or one of the
    dozens of other framework enhancements, .NET makes many, many things easier.

    And don't be fooled by the apparently far more verbose syntax you may see in
    samples or see others complaining about. Although the syntax might look
    bloated at first viewing, once you've used .NET and gotten used to the more
    OO approach, the syntax actually becomes very clear and clean.

    > for something I do now being
    > a better something, or for a tool that does something for me that I now to
    > have to do for myself.


    OK, how about control anchoring, multi-line statement completion, full
    support for implementation inheritance freeing you from faking it using
    hidden composition, forms-based centralised error handling (ie, you can
    redirect all unhandled errors to a single procedure with a single
    statement), xcopy deployment, and more. VB.NET, imo, adds significant value.

    > Before anyone "calls me on the subject", no, I have
    > not installed and used VB.NET. I have read a good deal on the subject, I
    > have carefully examined a number of examples, and I've paid close

    attention
    > in a number of presentations about it. So far, I fail to see anything that
    > fits one of the categories I describe, for the kind of applications that
    > I do.


    I highly recommend trying the Beta, especially after Beta 2 is released
    (assuming that it is also a public beta). I have liked everything that .NET
    has to offer so far, and have found that it makes programming easier, once
    you learn the differences.

    <snip>
    > To me, it seems obvious, that whatever benefits .NET will bring to the VB
    > developer are going to be limited to the ones who do "code intensive"

    work,
    > and those whose applications or components will operate in the server-side
    > environment with .NET servers of various kinds installed.


    By "code intensive", I take you to mean multiple programmers working on
    "enterprise" level applications. I don't work in that world either, but
    VB.NET will make my life easier. Xcopy deployment alone will save me tons of
    time and free me from the paltry offerings available through HTML and
    intranet systems.

    <snip>
    > Classic VB, is not "a language" by my definition -- it is a Development

    Tool,
    > one that includes a language, and I agree that it is a great Development
    > Tool. I do agree that VB.NET is only a language, but I believe it is far,
    > far too early to determine whether it will be a great one.


    VB.NET is a language, development environment (the IDE's cool!), and
    framework. You could certainly use VB.NET without the development
    environment (via command-line compilers), but the IDE does/will add value.

    <snip>

    Ian.



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