Microsoft's C++ bigotry - Page 41


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 41 of 43 FirstFirst ... 313940414243 LastLast
Results 601 to 615 of 633

Thread: Microsoft's C++ bigotry

  1. #601
    Kent Guest

    Re: Microsoft's C++ bigotry


    Sure and then they should have changed the name. I'm sure they'll get around
    to making the changes you all want in a future version, just to break everyone
    elses code.

    They seem to enjoy that.

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



  2. #602
    Kent Guest

    Re: Microsoft's C++ bigotry


    "David Rothgery" <drothgery@alum.wpi.edu> wrote:

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


    J# is supposed to woo in Java developers. Java developers will expect all
    of the Java stuff to be there.


  3. #603
    Kent Guest

    Re: Microsoft's C++ bigotry


    Kerry,

    Don't expect anyone here to give you props for your point of view. They
    get pretty sensitive about their VB.Net.

    You're right. It has been pointed out by many here, that a lot of the changes
    made to VB.Net were made only for the sake of making the change.

    There are too many M$ cheerleaders here who for whatever reason think that
    criticizing M$ is off limits and an act of blasphemy.

    Pat seems to be particularly religious about it.

    As for whether or not you will be able to make an equal living using VB.Net
    remains to be seen. VB developers are going to see very strong competition
    from the C# developers that will now be able to move in on their territory.
    This works the other way as well. I think this will drive the salaries
    down on both sides.

    Kent

    "Kerry Moorman" <kmoorman@insightbb.com> wrote:
    >
    >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
    >



  4. #604
    Patrick Troughton Guest

    Re: Microsoft's C++ bigotry


    Hi Kent,

    Maybe you didn't read my posts carefully? These aren't opinions, these are
    according to each vendor's own admission. If you think their documentation
    is incorrect, you should contact each vendor and let them know which parts
    are mistaken. Personally, I have no reason to believe their documentation
    is incorrect....

    <quote>
    26.What features are not supported in NetCOBOL for .NET?
    A: The following are limitations in this version:

    Print files (ASSIGN TO PRINTER) are not supported. If you want to use print
    files we recommend that you compile your print programs using NetCOBOL for
    Windows V6 and call this unmanaged code from your NetCOBOL for .NET managed
    code.
    The SCREEN SECTION is not supported. Your NetCOBOL for .NET applications
    should use Win Forms or Web Forms for interfacing with your users.
    SORT/MERGE is not supported. As with print files compile your SORT/MERGE
    programs with the Windows COBOL compiler (e.g. NetCOBOL for Windows V6) and
    call the unmanaged code from your NetCOBOL for .NET managed code.
    The COBOL REPORT WRITER module is not supported.
    Nested programs are not supported.
    TYPEDEF STRONG is not supported.
    ENTRY statements are not supported. Code that relies on ENTRY points should
    be restructured so that each separate ENTRY point becomes a method.
    ALTER statements are not supported. ALTER was declared obsolete in the 1985
    COBOL standard.
    A GO TO statement without a procedure name (used as the target of an ALTER
    statement) is not supported.
    The "STOP literal" statement, which would display a message to an operator
    and pause execution pending a response, is not supported.
    NetCOBOL for .NET only supports the COBOL file system. It does not support
    other file systems, such as Btrieve.
    </quote>

    http://www.adtools.com/products/wind...tcobol.html#15

    <quote>
    The following features, which may be supported by other languages targeting
    the .NET Framework common language runtime, are not supported in Visual J#:


    Operator overloading and the .NET Framework semantics associated with operator
    overloading.
    Implicit and explicit conversions between types using the op_Implicit and
    op_Explicit conversion operators.
    Support for defining the following .NET Framework constructs:
    Value types
    Custom attributes
    Enumerations
    Seamless coercion between Java-language data types and .NET Framework data
    types.
    Compiler checking for CLS compliance (CLSCompliantAttribute Class)
    Independent implementation for all methods of an interface in a type.
    </quote>

    http://msdn.microsoft.com/library/en...asp?frame=true

    <quote>
    Unsupported Class Libraries and Features
    The following features are not supported in Visual J#:

    Remote Method Invocation (RMI), Java Native Interface (JNI), and Raw Native
    Interface (RNI) technologies.
    Applet development. There is also no support for running applets in browsers.

    Loading classes from bytecode (.class files). However, there is support to
    load classes from Microsoft intermediate language (MSIL) assemblies.
    The CLASSPATH variable. An alternate mechanism is provided to locate and
    load classes and resources at run time. See No Support for CLASSPATH Variable
    for more information.
    </quote>

    http://msdn.microsoft.com/library/en...asp?frame=true

    <quote>
    Differences between Eiffel, Eiffel for .NET and .NET
    Differences between Eiffel and Eiffel for .NET
    Limitation of Eiffel for .NET in version 5.2
    Most of the Eiffel mechanisms are supported in 5.2. All missing features
    listed below are planned for addition in future releases:
    No creation of Eiffel expanded class support
    Partial implementation of generic conformance (same as what was supported
    up to and including ISE Eiffel 4.2).

    Eiffel for .NET supports:
    Multiple Inheritance
    Design By Contract
    Exception handling
    Genericity
    Covariance
    Compilation of any existing Eiffel libraries as long as it does not include
    C externals that call into the ISE C runtime

    Added to Eiffel and Eiffel for .NET
    The following syntax can be used to declare .NET custom attributes on Eiffel
    entities (features and classes):

    empty: BOOLEAN is
    indexing
    description: "Is Current empty?"
    attribute: create {SYSTEM_OBSOLETEATTRIBUTE}.make_obsoleteattribute_1 ("Use
    `is_empty' instead") end
    obsolete
    "Use is_empty instead"
    do
    Result := is_empty
    end
    The previous example shows the declaration of the obsolete feature empty
    . The custom attribute defined by SYSTEM_OBSOLETEATTRIBUTE is used to ensure
    that any consumer of the resulting assembly will see the feature as being
    obsolete. The custom attribute is defined in the indexing clause attribute.
    The definition consists of a creation expression that creates the custom
    attribute with the right parameters.
    Differences between Eiffel for .NET and .NET
    Covariance
    The CLR (Common Language Runtime) does not support covariance due to the
    type safety issue that full covariance implies (known as polymorphic CATCALLS
    in Eiffel). Although very rare, CATCALLS are not suitable to .NET where safety
    is one of the primary goals.
    Eiffel for .NET implements a safe variant of covariance that will always
    perform a check on the types to avoid a CATCALL. So when a CATCALL is going
    to be performed a `Invalid Cast Exception' will be raised by the CLR instead
    of an unexpected behavior as it is currently done in Eiffel.
    Another advantage of Eiffel for .NET's implementation of covariance is that
    it can be easily understood by CLS compliant consumer tools. These tools
    will actually benefit from the Eiffel for .NET covariance.
    Genericity
    The CLR does not support generics at all, so that the following Eiffel for
    .NET classes:
    LIST [ANY]
    LIST [INTEGER]

    will actually be generated as:
    LIST_ANY
    LIST_Int32

    Meaning that if one wants to reuse an Eiffel generic class from another language
    than Eiffel for .NET, one has to use either LIST_ANY or LIST_Int32.
    Enum types
    Eiffel for .NET supports .NET enum types implicitly. From the point of view
    of Eiffel, they are just considered as expanded classes. The only difference
    is in the code generation. Eiffel for .NET cannot declare new enum types
    yet.
    ByRef
    Eiffel does not have the notion of `byref' argument passing. At the moment,
    Eiffel for .NET cannot call nor can it redefine a feature that has a byref
    argument.
    </quote>

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

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

    "Kent" <kp@kp.org> wrote:
    >
    >Kerry,
    >
    >Don't expect anyone here to give you props for your point of view. They
    >get pretty sensitive about their VB.Net.
    >
    >You're right. It has been pointed out by many here, that a lot of the changes
    >made to VB.Net were made only for the sake of making the change.
    >
    >There are too many M$ cheerleaders here who for whatever reason think that
    >criticizing M$ is off limits and an act of blasphemy.
    >
    >Pat seems to be particularly religious about it.
    >
    >As for whether or not you will be able to make an equal living using VB.Net
    >remains to be seen. VB developers are going to see very strong competition
    >from the C# developers that will now be able to move in on their territory.
    > This works the other way as well. I think this will drive the salaries
    >down on both sides.
    >
    >Kent



  5. #605
    Tom Shelton Guest

    Re: Microsoft's C++ bigotry


    "Kent" <kp@kp.org> wrote in message news:3e6896bd@tnews.web.devx.com...
    >
    > "David Rothgery" <drothgery@alum.wpi.edu> wrote:
    >
    > >.... while the are things that the .NET framework supports, but J#

    doesn't
    >
    > J# is supposed to woo in Java developers. Java developers will expect all
    > of the Java stuff to be there.


    Not really... I think it is meant as a migration path for those poor
    unfortunate souls that got sucked in by J++, and then screwed because of
    Sun's well known lawsuit. It is like 1.14 compatable... Not exactly a
    modern Java implementation. I think C# was more the "woo Java developers"
    language.

    Tom Shelton



  6. #606
    Kent Guest

    Re: Microsoft's C++ bigotry


    Tom,

    J# is advertised in many Java publications and even on DevX's Java zone.
    It is in part at least clearly intended to woo in Java developers.

    I will hand it to Microsoft though. Porting from J++ to J# is pretty easy.

    Kent

    "Tom Shelton" <toms@dakcs.com> wrote:
    >
    >"Kent" <kp@kp.org> wrote in message news:3e6896bd@tnews.web.devx.com...
    >>
    >> "David Rothgery" <drothgery@alum.wpi.edu> wrote:
    >>
    >> >.... while the are things that the .NET framework supports, but J#

    >doesn't
    >>
    >> J# is supposed to woo in Java developers. Java developers will expect

    all
    >> of the Java stuff to be there.

    >
    >Not really... I think it is meant as a migration path for those poor
    >unfortunate souls that got sucked in by J++, and then screwed because of
    >Sun's well known lawsuit. It is like 1.14 compatable... Not exactly a
    >modern Java implementation. I think C# was more the "woo Java developers"
    >language.
    >
    >Tom Shelton
    >
    >



  7. #607
    Tom Shelton Guest

    Re: Microsoft's C++ bigotry


    "Kent" <kp@kp.org> wrote in message news:3e68d626$1@tnews.web.devx.com...
    >
    > Tom,
    >
    > J# is advertised in many Java publications and even on DevX's Java zone.
    > It is in part at least clearly intended to woo in Java developers.
    >
    > I will hand it to Microsoft though. Porting from J++ to J# is pretty

    easy.
    >
    > Kent


    Maybe they are advertising it there, but what Java developer in their right
    mind would go from 1.4x to 1.14 compatability? To be honest, the only use I
    see for J# is porting from J++.

    Tom Shelton

    > "Tom Shelton" <toms@dakcs.com> wrote:
    > >
    > >"Kent" <kp@kp.org> wrote in message news:3e6896bd@tnews.web.devx.com...
    > >>
    > >> "David Rothgery" <drothgery@alum.wpi.edu> wrote:
    > >>
    > >> >.... while the are things that the .NET framework supports, but J#

    > >doesn't
    > >>
    > >> J# is supposed to woo in Java developers. Java developers will expect

    > all
    > >> of the Java stuff to be there.

    > >
    > >Not really... I think it is meant as a migration path for those poor
    > >unfortunate souls that got sucked in by J++, and then screwed because of
    > >Sun's well known lawsuit. It is like 1.14 compatable... Not exactly a
    > >modern Java implementation. I think C# was more the "woo Java

    developers"
    > >language.
    > >
    > >Tom Shelton
    > >
    > >

    >




  8. #608
    David Rothgery Guest

    Re: Microsoft's C++ bigotry


    "Tom Shelton" <toms@dakcs.com> wrote in message
    news:3e68d0e3$1@tnews.web.devx.com...
    >
    > "Kent" <kp@kp.org> wrote in message news:3e6896bd@tnews.web.devx.com...
    > >
    > > "David Rothgery" <drothgery@alum.wpi.edu> wrote:
    > >
    > > >.... while the are things that the .NET framework supports, but J#

    > doesn't
    > >
    > > J# is supposed to woo in Java developers. Java developers will expect

    all
    > > of the Java stuff to be there.

    >
    > Not really... I think it is meant as a migration path for those poor
    > unfortunate souls that got sucked in by J++, and then screwed because of
    > Sun's well known lawsuit. It is like 1.14 compatable... Not exactly a
    > modern Java implementation. I think C# was more the "woo Java developers"
    > language.


    It's been argued that one of the major reasons J# exists is for academia. A
    lot of colleges teach introductory CS classes in Java these days, and JDK
    1.14 is Good Enough for that. Microsoft wants CS students using VS.NET.

    --
    Dave Rothgery
    drothgery@alum.wpi.edu



  9. #609
    blob Guest

    Re: Microsoft's C++ bigotry


    Microsoft wants CS students using VS.NET.

    MS wants CS students using "C#".

  10. #610
    Mike Mitchell Guest

    Re: Microsoft's C++ bigotry

    On 6 Mar 2003 08:58:57 -0800, "Kerry Moorman" <kmoorman@insightbb.com>
    wrote:

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


    Another way of looking at it is that Microsoft wanted to get shot of
    Visual Basic altogether, over a period of time, and make C# THE
    language of choice for programming in Windows into the future. This
    would entail slowly winding down the existing usage base by attrition
    by making the new version fundamentally different from the classic
    product, thus causing huge numbers of existing VB programmers to look
    elsewhere or give up writing application software altogether. Then,
    once that had happened, it would be easier to convert the few
    stragglers to C# - in fact, many have been saying here that they find
    C# "better" than VB.Net, even though they were once committed VB'ers.
    Others have said how they no longer really miss break-edit-continue.
    These must be exactly the kind of customers MS is looking to convert
    to C#!

    Because I just cannot see how it can make any sense to introduce a
    fundamentally new paradigm, i.e. .Net, yet want to stay with some sop
    to the past in the guise of VB.Net if thereby you're guaranteed to
    lose huge swathes of programmers in the process of conversion. It's
    like keeping propellers on a modern jet airplane just for nostaligic
    reasons. And let's face it, VB.Net appears to be very much a backwater
    nowadays. People only ever seem to be talking about Java (or
    Websphere).

    MM

  11. #611
    Mike Mitchell Guest

    Re: Microsoft's C++ bigotry

    On 6 Mar 2003 12:00:23 -0800, "Kerry Moorman" <kmoorman@insightbb.com>
    wrote:

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


    And can you? <g>

    MM

  12. #612
    Mike Mitchell Guest

    Re: Microsoft's C++ bigotry

    On 6 Mar 2003 13:07:06 -0800, "Patrick Troughton"
    <Patrick@Troughton.com> wrote:

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


    Oh, man! He is the *father dude*! He is the bloke wot designed it!

    MM

  13. #613
    Tom Shelton Guest

    Re: Microsoft's C++ bigotry


    "Mike Mitchell" <kylix_is@yahoo.co.uk> wrote in message
    news71i6vc9mjhlo7jl7s4vm3h22te0bck44v@4ax.com...
    > On 6 Mar 2003 12:00:23 -0800, "Kerry Moorman" <kmoorman@insightbb.com>
    > wrote:
    >
    > >Does this bother me? Not if I can make as much money with VB.Net as I

    did
    > >with VB6!

    >
    > And can you? <g>


    You say the sallary survey right.... VB.NET programmers do make more on
    average then VB.CLASSIC programmers. Of course, that's assuming you have a
    job right now

    Tom Shelton



  14. #614
    Mike Mitchell Guest

    Re: Microsoft's C++ bigotry

    On Thu, 6 Mar 2003 11:17:46 -0800, "David Rothgery"
    <drothgery@alum.wpi.edu> 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,


    Yeah? So obviously Microsoft went completely the wrong way about it!

    Consider what they could have done.

    1. Concentrate on their Java killer, .Net, and get it to market pronto
    with the one language C#.

    2. Announce at the launch of .Net that their exciting new platform and
    development system for nifty web services - the thing of the future
    (okay, so I wear a different hat occasionally, so shoot me) - would
    include C# out of the box and that they were working on introducing
    other languages on an ongoing basis.

    3. While .Net was bedding down amongst the C# community, produce one
    or more interim versions of VB6, e.g. 6.5, 7.0, 7.5, with each version
    steadily moving more towards the .Net paradigm internally (outwardly
    maintaining full compatibility with previous classic VB versions as
    per usual).

    4. After, say, two years, by which time the new .Net would have been
    seen to succeed and may by now have enjoyed wide acceptance, they
    could have announced VB.Net with as near as dammit full compatibility
    with VB7.5. Result? VB programmers would have not seen anything like
    such an insurmountable problem in moving over to .Net, because they
    would have largely seen the migration as just more of the same kind of
    upgrade that they had entertained since VB1.

    MM

  15. #615
    Tom Shelton Guest

    Re: Microsoft's C++ bigotry


    "Mike Mitchell" <kylix_is@yahoo.co.uk> wrote in message
    news:r90i6v4mgflhlpf8emqohp0ob83oa8ock4@4ax.com...
    > On 6 Mar 2003 08:58:57 -0800, "Kerry Moorman" <kmoorman@insightbb.com>
    > wrote:
    >
    > >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.

    >
    > Another way of looking at it is that Microsoft wanted to get shot of
    > Visual Basic altogether, over a period of time, and make C# THE
    > language of choice for programming in Windows into the future. This
    > would entail slowly winding down the existing usage base by attrition
    > by making the new version fundamentally different from the classic
    > product, thus causing huge numbers of existing VB programmers to look
    > elsewhere or give up writing application software altogether. Then,
    > once that had happened, it would be easier to convert the few
    > stragglers to C# - in fact, many have been saying here that they find
    > C# "better" than VB.Net,


    Not better exactly, at least for me. It's just that I prefer C-style
    syntax.

    > even though they were once committed VB'ers.
    > Others have said how they no longer really miss break-edit-continue.
    > These must be exactly the kind of customers MS is looking to convert
    > to C#!


    I don't miss BEC because, I don't really use it that often now. But, it is
    supposed to be in V2 of the framework, and it won't be just a VB.NET
    feature.

    > Because I just cannot see how it can make any sense to introduce a
    > fundamentally new paradigm, i.e. .Net, yet want to stay with some sop
    > to the past in the guise of VB.Net if thereby you're guaranteed to
    > lose huge swathes of programmers in the process of conversion. It's
    > like keeping propellers on a modern jet airplane just for nostaligic
    > reasons. And let's face it, VB.Net appears to be very much a backwater
    > nowadays. People only ever seem to be talking about Java (or
    > Websphere).


    Yep, that was what was happening with VB - as early as 2000 from the
    articles I've seen. That is the reason for .NET and VB.NET.

    Tom Shelton



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