Microsoft's C++ bigotry - Page 40


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 40 of 43 FirstFirst ... 303839404142 ... LastLast
Results 586 to 600 of 633

Thread: Microsoft's C++ bigotry

  1. #586
    Patrick Troughton Guest

    Re: Microsoft's C++ bigotry


    Hi Kent,

    "Kent" <kp@kp.org> wrote:
    >
    >So that old VB source will still compile under VB.Net.


    No, you don't.

    >We've been down this
    >road seemingly 100s of times, check the other posts.


    Exactly.

    >It's always been bad practice to use gotos the sudden realization that the
    >language needed to be "purified" is what has come into question.


    Once MS decided to port VB to the .NET platform, they realized that there
    was no way to make it 100% compatible with old VB6. Because there was no
    way for it to be compatibile, they realized it was a great chance to simplify
    and modernize the language to make it easier to use. It was a courageous
    decision to be sure, but in hindsight, it was the right one. If anything,
    there is too much compatibility with VB6. For example....they got rid of
    GoSub (good) but kept Goto (bad)....they got rid of Let (good) but kept (REM)....they
    added the new Return statement syntax to return values from a function, but
    kept the old FunctionName = ReturnValue syntax. For those of you who think
    they cleaned up the language too much, I say they cleaned it up too little.
    It's an improvement over VB6 though. I wish they would have went further....opportunities
    like this only come around once in a decade...

    /Pat
    ----------------
    Show me the XML.
    ----------------

  2. #587
    Patrick Troughton Guest

    Re: Microsoft's C++ bigotry


    Hi Arron,

    "Arron" <s_drac2@hotmail.com> wrote:
    >
    >I thought goto and gosub were bad programming practice and were now deeply
    >frowned on?


    They are.

    >why would you need one?


    You don't.

    /Pat
    ----------------
    Show me the XML.
    ----------------


  3. #588
    Kerry Moorman Guest

    Re: Microsoft's C++ bigotry


    Patrick,

    You wrote:
    >
    >Once MS decided to port VB to the .NET platform, they realized that there
    >was no way to make it 100% compatible with old VB6. Because there was no
    >way for it to be compatibile, they realized it was a great chance to >simplify

    and modernize the language to make it easier to use.
    >snip


    The only language feature I'm ever interested in is can I make money using
    the language. If I can make money with VB.Net then I couldn't care less what
    VB6 language features were kept, dropped, changed, etc.

    However, this claim that VB6 could not be 100% ported to .Net seems disingenuous
    to me.

    A major goal of .Net is to allow an extremely wide range of languages to
    run under it. If Eiffel, for example, can be implemented under .Net and still
    retain multiple inheritance, generics, design-by-contract, etc., then I think
    it is safe to say that VB6 could have been 100% ported to .Net.

    Again, I don't care that VB6 was not 100% ported to .Net. But the idea that
    it could not be 100% ported just doesn't seem to make sense, given the other
    languages that have been ported.

    Kerry Moorman


  4. #589
    Patrick Troughton Guest

    Re: Microsoft's C++ bigotry


    Hi Kerry,

    I haven't used Eiffel so I can't comment on it.

    However, the idea that VB6 could have somehow been grafted onto the .NET
    platform with 100% compatibility is a case of revisionism. There are far
    too many differences between the platforms to make this possible. For example,
    the forms packages are completely different. There are literally thousands
    and thousands of differences...everything from different names for properties,
    events and methods...to missing controls...to completely different arguments
    for event procedures with different behaviors. There is no deterministic
    finalization. Even some events fire in different order. There was no way
    to account for every single one of these differences and still make it work
    flawlessly. What's more, one of the key design goals was to make VB.NET a
    first class member of the .NET platform with full access to all its features.
    Even if MS dropped the design goal of VB being a first class language and
    spent 10 years perfecting a monstrous compatibility layer, VB would have
    been hopelessly slow and buggy and still not 100% compatible. Realizing the
    goal of 100% compatibility was not achievable or even desirable, they decided
    to take the opportunity to modernize the language...a correct decision IMHO.


    Don't take this as insult (it's not meant as one)but many of the .NOTters
    are victims of their own ignorance. I've used both products quite a bit,
    and I can tell you where significant compatibility issues exist and where
    they don't. The things the .NOTters typically complain about, such as Wend
    => End While and 32-bit Integers are easily upgraded by the Upgrade Wizard.
    These are non-issues. Other frequent complaints such as a lack of GoSub could
    also be easily upgraded by the Upgrade Wizard. Again, this is a non-issue.
    The *real* compatibility issues are rarely talked about in this newsgroup.

    If there's anything that MS could do better, it would be to improve the Upgrade
    Wizard and compatibility namespace. For example, the Upgrade Wizard doesn't
    upgrade VB6 OLE drag-and-drop to .NET drag-and-drop. Why not? The two models
    are nearly identical. The compatibility namespace has no Printer, Printers
    or Clipboard objects. I see no technical reason why these could not be implemented.


    I only have a couple contacts at MS and I've done my best to make this case
    to them. Whether my suggestions are falling on deaf ears, I cannot say. With
    the upcoming release of VB.NET 1.1, the Upgrade Wizard will have some improvements
    (such as the ability to upgrade user controls), but there's still a long
    way to go. It should be noted that no matter how good the Upgrade Wizard
    is, or how vast the compatibility library is, it will never do 100% of the
    job. There will always be a certain percentage of your code that will require
    manual changes. But I believe that whatever can be automated, should be automated.

    /Pat
    ----------------
    Show me the XML.
    ----------------

    "Kerry Moorman" <kmoorman@insightbb.com> wrote:
    >
    >Patrick,
    >
    >You wrote:
    >>
    >>Once MS decided to port VB to the .NET platform, they realized that there
    >>was no way to make it 100% compatible with old VB6. Because there was no
    >>way for it to be compatibile, they realized it was a great chance to >simplify

    >and modernize the language to make it easier to use.
    >>snip

    >
    >The only language feature I'm ever interested in is can I make money using
    >the language. If I can make money with VB.Net then I couldn't care less

    what
    >VB6 language features were kept, dropped, changed, etc.
    >
    >However, this claim that VB6 could not be 100% ported to .Net seems disingenuous
    >to me.
    >
    >A major goal of .Net is to allow an extremely wide range of languages to
    >run under it. If Eiffel, for example, can be implemented under .Net and

    still
    >retain multiple inheritance, generics, design-by-contract, etc., then I

    think
    >it is safe to say that VB6 could have been 100% ported to .Net.
    >
    >Again, I don't care that VB6 was not 100% ported to .Net. But the idea that
    >it could not be 100% ported just doesn't seem to make sense, given the other
    >languages that have been ported.
    >
    >Kerry Moorman
    >



  5. #590
    Kerry Moorman Guest

    Re: Microsoft's C++ bigotry


    Patrick,

    You wrote:

    >
    >I haven't used Eiffel so I can't comment on it.
    >
    >However, the idea that VB6 could have somehow been grafted onto the .NET
    >platform with 100% compatibility is a case of revisionism. There are far
    >too many differences between the platforms to make this possible.
    >snip


    The problem with this line of reasoning is that it makes the .Net team's
    goal of being able to support a wide range of languanges seem like a failure.

    If VB6, with MS's intimate knowledge of the product, could not be 100% ported
    to .Net, then .Net can't claim to support a wide range of languages.

    But we know that .Net can support languages with multiple inheritance and
    generics when the .Net platform itself doesn't have multiple inheritance
    or generics. If languages with these features can be 100% ported to .Net
    it just defies common sense that VB6 could not be 100% ported.

    Again, keep in mind that I don't care that VB6 was not 100% ported to .Net.
    That's not an issue with me. And MS may have had great reasons for deciding
    to "clean up" VB6 as it was converted to VB.Net. I don't have any problems
    with the changes. But the idea that MS COULD NOT 100% port VB6 to .Net looks
    really bad for either for the .Net platform itself or for the team charged
    with doing the port.

    Your best argument is that the porting team wanted to make VB.Net much more
    than VB6 ever was and that's the reason for the changes.

    Kerry Moorman


  6. #591
    Bob Butler Guest

    Re: Microsoft's C++ bigotry

    "Kerry Moorman" <kmoorman@insightbb.com> wrote in message
    news:3e677e51$1@tnews.web.devx.com
    <cut>
    > Your best argument is that the porting team wanted to make VB.Net
    > much more than VB6 ever was and that's the reason for the changes.


    The quote "Because there was no way for it to be [100%] compatibile, they
    realized it was a great chance to simplify [sic] and modernize [sic] the
    language" is probably the closest to the truth.

    The one thing in VB 6.0 that was reasonably not feasible in VB.Net 1.0 was
    deterministic finalization for objects. That makes the argument that 100%
    compatibility wasn't possible true. The argument that the majority of the
    changes were required because of platform differences is simply ludicrous.




  7. #592
    Patrick Troughton Guest

    Re: Microsoft's C++ bigotry


    Hi Kerry,

    Well, first of all Eiffel is a fully OO language whereas VB6 wasn't. But
    I hope you don't mind me asking a few questions...

    How many Eiffel programs have you been able to load and run successfully
    under .NET? I assume that all you programs worked without any compilation
    or run-time errors? What sort of testing did your company perform to verify
    that each program still worked? Can you tell me how many lines of codes each
    of your Eiffel programs have? Finally, what sort of forms package does Eiffel
    use, what differences exist between Eiffel's forms package and .NET's forms
    package, and how does Eiffel.NET's compiler handle these differences?

    /Pat
    ----------------
    Show me the XML.
    ----------------

    "Kerry Moorman" <kmoorman@insightbb.com> wrote:
    >
    >Patrick,
    >
    >You wrote:
    >
    >>
    >>I haven't used Eiffel so I can't comment on it.
    >>
    >>However, the idea that VB6 could have somehow been grafted onto the .NET
    >>platform with 100% compatibility is a case of revisionism. There are far
    >>too many differences between the platforms to make this possible.
    >>snip

    >
    >The problem with this line of reasoning is that it makes the .Net team's
    >goal of being able to support a wide range of languanges seem like a failure.
    >
    >If VB6, with MS's intimate knowledge of the product, could not be 100% ported
    >to .Net, then .Net can't claim to support a wide range of languages.
    >
    >But we know that .Net can support languages with multiple inheritance and
    >generics when the .Net platform itself doesn't have multiple inheritance
    >or generics. If languages with these features can be 100% ported to .Net
    >it just defies common sense that VB6 could not be 100% ported.
    >
    >Again, keep in mind that I don't care that VB6 was not 100% ported to .Net.
    >That's not an issue with me. And MS may have had great reasons for deciding
    >to "clean up" VB6 as it was converted to VB.Net. I don't have any problems
    >with the changes. But the idea that MS COULD NOT 100% port VB6 to .Net looks
    >really bad for either for the .Net platform itself or for the team charged
    >with doing the port.
    >
    >Your best argument is that the porting team wanted to make VB.Net much more
    >than VB6 ever was and that's the reason for the changes.
    >
    >Kerry Moorman
    >



  8. #593
    Kerry Moorman Guest

    Re: Microsoft's C++ bigotry


    Patrick,

    You wrote:

    >Well, first of all Eiffel is a fully OO language whereas VB6 wasn't. But
    >I hope you don't mind me asking a few questions...
    >
    >How many Eiffel programs have you been able to load and run successfully
    >under .NET? I assume that all you programs worked without any compilation
    >or run-time errors? What sort of testing did your company perform to verify
    >that each program still worked? Can you tell me how many lines of codes

    each
    >of your Eiffel programs have? Finally, what sort of forms package does Eiffel
    >use, what differences exist between Eiffel's forms package and .NET's forms
    >package, and how does Eiffel.NET's compiler handle these differences?
    >


    Hey, don't confuse me with an Eiffel programmer! Remember, I said that I
    was only interested in languages which I could use to make money!

    But if you are really interested in answers to your questions you should
    check out:

    http://www.eiffel.com/developers/faq...patible-studio

    and

    archive.eiffel.com/doc/manuals/technology/bmarticles/sd/dotnet.html

    The first article listed above states:

    "Eiffel for .NET can be used in exactly the same way as classic Eiffel and
    no extra language constructs are required to produce applications."

    So it appears that Eiffel Software was indeed able to port a language with
    multiple inheritance and generics to the .Net platform without giving anything
    up.

    Again, I'm anything but a .Not-er. Learning new languages and techniques
    has never been a problem for me. I just think that, given the myriad languages
    that have been successfully ported to .Net, claiming that VB6 could not have
    been ported is disingenuous. I suspect that a committed group of developers
    could have ported VB6 to .Net with most (but maybe not 100%) of the VB6 features
    intact. Its just that for various reasons the MS developers were not committed
    to this type of port.

    Kerry Moorman




  9. #594
    David Rothgery Guest

    Re: Microsoft's C++ bigotry


    "Kerry Moorman" <kmoorman@insightbb.com> wrote in message
    news:3e677e51$1@tnews.web.devx.com...
    >
    > Patrick,
    >
    > You wrote:
    >
    > >
    > >I haven't used Eiffel so I can't comment on it.
    > >
    > >However, the idea that VB6 could have somehow been grafted onto the .NET
    > >platform with 100% compatibility is a case of revisionism. There are far
    > >too many differences between the platforms to make this possible.
    > >snip

    >
    > The problem with this line of reasoning is that it makes the .Net team's
    > goal of being able to support a wide range of languanges seem like a

    failure.
    >
    > If VB6, with MS's intimate knowledge of the product, could not be 100%

    ported
    > to .Net, then .Net can't claim to support a wide range of languages.


    It's more that
    - VB6 lacked certain basic features necessary to the .NET framework (single
    inheritence, exception handling, etc.), so the language had to be changed,
    or working with .NET would be about as much fun as working with COM in C.
    - A very large percentage of VB6 code was tightly integrated with the VB6
    forms package, which doesn't correspond exactly to the .NET forms package.
    - VB6 objects are by definition COM objects, so all the issues that affect
    COM interop also affect preserving VB6 semantics in a VB6.NET.

    I don't know all that much about Eiffel, but it's my understanding that
    - Eiffel already supported all the OO features the .NET framework depends on
    - Eiffel is not tightly bound to one particular forms package
    - Eiffel is not tightly bound to an object model that's fundamentally
    incompatible with .NET




  10. #595
    Patrick Troughton Guest

    Re: Microsoft's C++ bigotry


    Hi Kerry,

    "Kerry Moorman" <kmoorman@insightbb.com> wrote:
    >
    >http://www.eiffel.com/developers/faq...patible-studio
    >
    >and
    >
    >archive.eiffel.com/doc/manuals/technology/bmarticles/sd/dotnet.html


    The problem with those links is that they are marketing articles from a company
    that just so happens to sell an Eiffel implementation for .NET. And again,
    Eiffel was already fully OO whereas VB6 wasn't.

    >Again, I'm anything but a .Not-er. Learning new languages and techniques
    >has never been a problem for me. I just think that, given the myriad languages
    >that have been successfully ported to .Net, claiming that VB6 could not

    have
    >been ported is disingenuous.


    It's a lot more complicated that you think. How would you handle a lack of
    deterministic finalization? What would you do about events firing out of
    order? How would handle the fact that Windows Forms don't support Twips?
    How would you handle the fact that ListBoxes simply don't have the same properties
    as VB6? Take these issues and multiply them a few thousand. According to
    "Upgrading VB6 to VB.NET", Microsoft did at first try to develop up a huge
    compatibility layer...

    <quote>
    Visual Basic .NET was being developed to support the notion of “Visual Basic
    6 sourced” projects that allowed you to edit and compile Visual Basic 6 projects
    in Visual Basic .NET. These projects would have a compatibility switch turned
    on, meaning that the language would be backward compatible with Visual Basic
    6 and would even have access to the old Visual Basic 6 forms package.

    By the end of 1999, it was obvious that this strategy wasn’t working. Little
    differences were slipping through: The old forms package could not be fully
    integrated into .NET, and the Visual Basic 6 sourced projects could not use
    some of the new features of the .NET platform. At that point Microsoft made
    the decision to break compatibility and instead concentrate on ensuring that
    people could upgrade their projects from Visual Basic 6 to Visual Basic .NET.
    </quote>

    >I suspect that a committed group of developers
    >could have ported VB6 to .Net with most (but maybe not 100%) of the VB6

    features
    >intact.


    If its so easy, then why hasn't anyone done so? I already pointed out a few
    objects that MS left out of the compatibility namespace such as a Printers
    collection and Clipboard object. That's as good of a place to start as any.

    /Pat
    ----------------
    Show me the XML.
    ----------------

  11. #596
    Kerry Moorman Guest

    Re: Microsoft's C++ bigotry


    David,

    You wrote:

    >It's more that
    >- VB6 lacked certain basic features necessary to the .NET framework (single
    >inheritence, exception handling, etc.), so the language had to be changed,
    >or working with .NET would be about as much fun as working with COM in C.
    >- A very large percentage of VB6 code was tightly integrated with the VB6
    >forms package, which doesn't correspond exactly to the .NET forms package.
    >- VB6 objects are by definition COM objects, so all the issues that affect
    >COM interop also affect preserving VB6 semantics in a VB6.NET.
    >


    Keep in mind that early in the design process the .Net team assembled people
    from the various language communities with the specific purpose of making
    sure that the design of .Net did not inadvertently rule out the future porting
    of languages to .Net. The ability to port a large number of languages to
    the .Net platform was a specific early design goal. It just seems to me that
    if porting VB6 to .Net had been high on the list, more could have been done
    at this stage.

    You also wrote:

    >- Eiffel is not tightly bound to an object model that's fundamentally
    >incompatible with .NET
    >


    Well, none of us need to know much about Eiffel to know that 100% porting
    of multiple inheritance to .Net's single inheritance object model required
    a load of planning and work. All I'm saying is that I don't think MS was
    interested enough to do that planning and work for VB6 under .Net.

    Really, this is all beside the point at this stage. Its just that for me
    the idea that for technical reasons the closest MS could get to porting VB6
    to .Net is VB.Net just does not ring true.

    Is VB.Net way more powerful than VB6? Yes.

    Is VB.Net easy to learn and use, like VB6? For me, yes.

    Is VB.Net the best that MS could have done to port VB6 to .Net? I seriously
    doubt it. That's why I don't think that was their goal.

    Kerry Moorman





  12. #597
    Kerry Moorman Guest

    Re: Microsoft's C++ bigotry


    Patrick,

    You wrote:

    >The problem with those links is that they are marketing articles from a

    company
    >that just so happens to sell an Eiffel implementation for .NET. And again,
    >Eiffel was already fully OO whereas VB6 wasn't.
    >


    You did notice that the author of the second article I mentioned was Bertrand
    Meyer didn't you?

    You also wrote:

    >If its so easy, then why hasn't anyone done so? I already pointed out a

    few
    >objects that MS left out of the compatibility namespace such as a Printers
    >collection and Clipboard object. That's as good of a place to start as any.


    I certainly never meant to imply that the task was easy. Porting multiple
    inheritance to the single inheritance object model of .Net wasn't easy either.
    But it was accomplished because the developers made it a high enough priority.

    I still can't help but think that if:

    1. A fundamental design goal of .Net was to insure that a wide range of languages
    could be ported to the platform.

    and

    2. VB6 was at the time the most widely used language in business and industry.

    Then, since VB6 can't be ported to .Net, the design goals of .Net were not
    met.

    Does this bother me? Not if I can make as much money with VB.Net as I did
    with VB6!

    Kerry Moorman


  13. #598
    Patrick Troughton Guest

    Re: Microsoft's C++ bigotry


    Hi Kerry,

    >You did notice that the author of the second article I mentioned was Bertrand
    >Meyer didn't you?


    No, I'm not familiar with Bertrand Meyer. I take it he's some Eiffel dude?


    >1. A fundamental design goal of .Net was to insure that a wide range of

    languages
    >could be ported to the platform.


    Yes, language independence was a goal, that doesn't mean the goal was that
    all languages can be ported to .NET without any changes whatsoever. As I
    said, I don't know Eiffel so I can't really comment on it, but I used to
    use Cobol many years ago and I have dabbled in Java. So I looked it up and
    neither Java or Cobol are 100% compatible either. For example....

    J#....
    ...Creating and hosting applets in a browser is not supported.
    ...Java Native Interface is not supported.
    ...Raw Native Interface is not supported.
    ...Remote Method Invocation is not supported.
    ...Operator overloading is not supported.
    ...Implicit and explicit conversions between types using the op_Implicit
    and op_Explicit conversion operators are not supported.
    ...Creating Value types is not supported.
    ...Creating Custom attributes is not supported.
    ...Creating Enumerations is not supported.

    NETCobol....
    ...Print files (ASSIGN TO PRINTER) are not supported.
    ...The SCREEN SECTION is not supported.
    ...SORT/MERGE is not supported.
    ...COBOL REPORT WRITER module is not supported.
    ...Nested programs are not supported.
    ...TYPEDEF STRONG is not supported.
    ...ENTRY statements are not supported.
    ...ALTER statements are not supported.
    ...The "STOP literal" statement, which would display a message to an operator
    and pause execution pending a response, is not supported.
    ...ASCII text files are not supported.

    These are by no means comprehensive lists.

    So your hypothesis that all other .NET languages were ported with 100% compatibility
    is simply not correct.

    BTW, according to this article, it looks like there are some differences
    between Eiffel and Eiffel for .NET after all...

    http://docs.eiffel.com/technologies/...mitations.html

    Now, I'm not in any way saying that MS couldn't have done a better job with
    VB.NET. I think they can. But I believe the best way to improve compatibility
    is by continuing to work on the Upgrade Wizard and expanding the compatibility
    namespace. With VB.NET 1.1, for example, the Upgrade Wizard can now handle
    user controls, code snippets and it also has a few minor fixes. Is it a step
    in the right direction? Absolutely. Is it enough? No.

    BTW, I had an opportunity to chat with some MS people last week and one of
    the first things I brought up was the Upgrade Wizard....

    /Pat
    ----------------
    Show me the XML.
    ----------------

  14. #599
    David Rothgery Guest

    Re: Microsoft's C++ bigotry


    "Patrick Troughton" <Patrick@Troughton.com> wrote in message
    news:3e67b87a$1@tnews.web.devx.com...
    >
    > Hi Kerry,
    >
    > >You did notice that the author of the second article I mentioned was

    Bertrand
    > >Meyer didn't you?

    >
    > No, I'm not familiar with Bertrand Meyer. I take it he's some Eiffel dude?


    He's the guy behind Eiffel (at least as much as Strousoup is behind C++, or
    Larry Wall is behind Perl), but he's also a pretty big name in OO theory in
    general, though I can't remember what book/article is his major claim to
    fame at the moment.

    > >1. A fundamental design goal of .Net was to insure that a wide range of

    > languages
    > >could be ported to the platform.

    >
    > Yes, language independence was a goal, that doesn't mean the goal was that
    > all languages can be ported to .NET without any changes whatsoever. As I
    > said, I don't know Eiffel so I can't really comment on it, but I used to
    > use Cobol many years ago and I have dabbled in Java. So I looked it up and
    > neither Java or Cobol are 100% compatible either. For example....
    >
    > J#....


    These seem to have a bit of a split personality.

    This group are Java features that J# doesn't support...

    > ..Creating and hosting applets in a browser is not supported.
    > ..Java Native Interface is not supported.
    > ..Raw Native Interface is not supported.
    > ..Remote Method Invocation is not supported.


    .... while the are things that the .NET framework supports, but J# doesn't

    > ..Operator overloading is not supported.
    > ..Implicit and explicit conversions between types using the op_Implicit
    > and op_Explicit conversion operators are not supported.
    > ..Creating Value types is not supported.
    > ..Creating Custom attributes is not supported.
    > ..Creating Enumerations is not supported.



    --
    Dave Rothgery
    drothgery@alum.wpi.edu



  15. #600
    Eddie Burdak Guest

    Re: Microsoft's C++ bigotry

    Patrick,

    Patrick Troughton wrote:
    <Snip>
    :: For those of you who think they cleaned up the language too much, I
    :: say they cleaned it up too little. It's an improvement over VB6
    :: though. I wish they would have went further....opportunities like
    :: this only come around once in a decade...

    You're right. if they are going to clean up the language they should
    have gone the whole hog. Why do only half a job? Just document it show
    what depreciated and give an example of the one and only way.

    Eddie


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center