DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 2 of 3 FirstFirst 123 LastLast
Results 16 to 30 of 35

Thread: Re: Is C# going to take over? Or is MS going to continue their VC++

  1. #16
    Danny Kalev Guest

    Re: Is C# going to take over? Or is MS going to continue their VC++



    James wrote:
    >
    > >I wonder how all these "benchmarks" always prove that a very carefully
    > >crafted obfuscated code that runs under very specific settings appears
    > >to be faster than native assembly. Seriously, do you believe C#, which
    > >is built on top of C++ can be faster than C++? Let's be realistic. We've
    > >heard exactly the same claims from Java buffs for seven years, and still
    > >Java is s-l-o-w.

    >
    > You must remember the C# is compiled to native code (Java compiles to byte
    > code) using a JIT compiler. Why can’t C# be as fast as C++? Indeed, it could
    > execute faster as the JIT compiler will optimised for the characteristics
    > of an individual machine.


    So are COBOL and VB. The issue is not whether the code is compiled to
    assembly; that's only the first step. It has to do with the underlying
    object model, memory model, runtime libraries compiler optimizations and
    so on. Ask any Fortran programmer why he or she wouldn't replace it with
    any other programming languages. Java, btw, can also be compiled to
    native assembly at least under some IDEs. There's more to performance
    than an .exe extension.


    >
    > >I don't make such a distinction because C++ doesn't make it either.
    > >We're talking about programming languages in general, not what's best
    > >for developing a ComboBox on Windows 3000. If you're confining the
    > >domain of discussion to this realm, then I don't see how C# is going to
    > >replace C++ anyway.

    >
    > The C++ language may not make a distinction but software analysis, design
    > and development does !!!
    >
    > I would regard a ComboBox (or a TextBox, Button, Scrollbar etc.) as part
    > of the primitive set of GUI components provided by an operating system and
    > hence system development.


    And what about all other things which aren't ComboBoxes (and I don't
    mean Dialog Boxes) -- thread support, VMM, hardware interfacing, kernel
    modules and in short -- just about anything that a programming language
    such as C++ can do?

    >
    > >It does make a difference if you have 100 of salesperson using the same
    > >server at once.

    >
    > Believe me it doesn’t (remember that the data access components (ADO) are
    > written in C++). It comes down to performance tuning the server and database
    > (for example, by adding indexes).


    It surely does. Look at CNN's site during a crisis. When the server has
    to deal with 1000,000 hits per minute or 100,000,000, performance is
    everything that matters, especially in Web-based environments.

    ADO is a bad example. It only proves that you can write suckable code
    with C++. Then again, you could not. I wouldn't take ADO or any other MS
    toy feature as an exemplary framework.


    >
    > >Actually, I'd think of VB as the GUI glue. The real core application
    > >should be written in C++ or a similar high performance language unless
    > >you really have 100,000 to spare for a mainframe.

    >
    > Yes, but not just the GUI glue. The glue for ALL components not just GUI
    > ones like: ADO, MSMQ, MSXML etc. – all written in C++ and glued together
    > in VB – rapid/component based development.


    In some cases, VB is the glue. In most other cases, it's completely
    useless. How much VB code is used in IE for example?

    >
    > >We're talking about ANSI C++. The products you listed are not distinct
    > >programming languages, mind you, but implementations of the same
    > >language, which only proves the point that C++ is ubiquitously
    > >available, as opposed to VB and C#. When was the last time you saw an
    > >IBM compiler running VB code?

    >
    > Vendor specific implementations of same language – that’s my point. You will
    > find very few C++ applications that are truly ANSI C compliant and therefore
    > not portable (by the way, I think IBM have released the own version of VB).


    We're not dealing with percent counting. The fact is that if you truly
    want to write portable code, you can do that in C/C++. Can you do that
    in VB? IBM tried to do something with VB. It was such a colossal failure
    that they eliminated any relic of that disastrous piece of trash. The
    funny thing is that they aimed at the Linux community --as if Linux
    programmer would ever really use such a thing in the first place...
    Let's be serious for a minute. VB is a Windows only language, period.


    >
    > >Again, it depends on which type of application development you're
    > >talking about. I haven't seen components used in database engines,
    > >compilers or OS kernels yet.

    > This is system development, I am talking spcifically about using C++ for
    > Application Development.


    And I'm talking specifically about programing in general. The original
    question, IIRC, was whether C# would replace C++. The answer is "no".

    >
    > >Again, you're confining the discussion to a very narrow (and quite
    > >obsolete) type of applications. Who uses DCOM these days? People who
    > >need components could use CORBA, C# or even Java. Then again, they might
    > >use VC++ too. The point is that many applications don't and will never
    > >use components.

    >
    > No, my discussion spcifically about using C++ for Application Development
    > (COM/DCOM was just an example of a technology that was supported by one platform
    > and not another).


    So what's your point here? you can use DCOM in VC++.

    >
    > My general point is that application development nowadays incorporates some
    > degree of RAD and this leads to component-based development. In which case
    > any third-party components and techonologies must also be portable.


    Application Development has always incorporated RAD or quasi RAD tools.
    Back in the 1970s there were screen/menu generators and in the 80's
    people spoke of 4 GL (fourth generation languages) that would replace
    ordinary programming languages. The thing is that the RAD tools only
    provide the veneer (and often, not ideally). They are frequently
    replaced by the next big thing while real programming languages last for
    decades.

    >
    > >So what you're saying is that C++ is disappearing while VB is here to
    > >stay? Gee! Bill Gates and Linus Torvalds should seriously consider
    > >rewriting Linux and Windows in VB!

    >
    > No, I'm saying C++ for application development will descline significantly,
    > replaced by either VB.NET or C# (both equally powerful).


    Let's wait and see. My bet is that VB's days are numbered.

    >
    > >That's what they want you to believe. Since they are the only vendor
    > >selling development tools for this language, rest assured that they will
    > >change it as they please, ECMA standard or not. And they will certainly
    > >do so because the language is still immature and will undergo the
    > >natural course of a language evolution, as every programming language
    > >does. Java only recently (2002) introduced assertions. Something we've
    > >had in C since the early 1970s (so much for "a new technology", btw). C#
    > >is no different. If you want a more compelling example, look at the
    > >evolution of VB in the past decade.

    >
    > Not so, I believe they will no abide by the ECMA standards.


    Again, let's wait and see. I find it hard to see the value of a rash
    standard of a beta product. C# will change and quite a lot in the coming
    months and years not because M$ doesn't want to violate the so-called
    standard but because they will have no choice. That's what happens when
    one rushes to standardize a new, half-baked programming language.

    >
    > >It isn't an upgrade, it's just different, and not necessarily better.
    > >For starters, it uses a GC which is the anathema of determinacy. As
    > >opposed to what most people think, GC introduces many problems (the lack
    > >of destructors is only a minor example), outstanding memory (Java
    > >programmers can tell you about that) and so on and so forth. Managed C++
    > >isn't better than C++, it's just different.

    >
    > I wasn't suggesting managed C++ is better that C++. I personally think it's
    > there solely for legacy C++ code.


    Or for those who wouldn't use C# and VB.

    >
    > >No offense, but it's obvious that you haven't done any serious C++
    > >programming and your conclusions are based on your own experience with
    > >VB. That's why you're so easily convinced that C# is the best thing
    > >since sliced bread. Trust me, it isn't. I do agree with you about one
    > >thing though: C++ is certainly not for everybody. Quoting Bjarne
    > >Stroustrup, "it's for serious programmers".

    >
    > My conclusions are based on 10 years experience in application development
    > and IT consultancy. Again I repeat my claim: "For application development,
    > yes. There are no significant advantages of using C++ over C# (or VB.NET)."
    >
    > >Delphi? you gotta be kidding me. It was buried at least twice, ages ago.
    > >Again, you have to understand that there's more to programming than
    > >splash screens and dialog boxes.

    > You give a number of emotive statements like above, yet fail it provide any
    > technical, economic justifications of why C++ is better.


    I just did that and I'll do it again: performance, portability,
    stability (I'm talking about the language's specification), ubiquitous
    availability, general purpose applicability and one thing I didn't
    mention is the fact that the language isn't subjected to the whims of
    one company's marketing department or another (I'm not talking about M$
    in particular, Sun is just as bad in this regard). Delphi is very much
    dead, emotional or not. Not that I have anything against it personally,
    it's just that if we're talking Application Development on Windows, even
    VB's future seems brighter than Delphi...


    Danny

  2. #17
    James Guest

    Re: Is C# going to take over? Or is MS going to continue their VC++


    Danny Kalev <dannykk@inter.net.il> wrote:
    >
    >
    >James wrote:
    >>
    >> >I wonder how all these "benchmarks" always prove that a very carefully
    >> >crafted obfuscated code that runs under very specific settings appears
    >> >to be faster than native assembly. Seriously, do you believe C#, which
    >> >is built on top of C++ can be faster than C++? Let's be realistic. We've
    >> >heard exactly the same claims from Java buffs for seven years, and still
    >> >Java is s-l-o-w.

    >>
    >> You must remember the C# is compiled to native code (Java compiles to

    byte
    >> code) using a JIT compiler. Why can’t C# be as fast as C++? Indeed, it

    could
    >> execute faster as the JIT compiler will optimised for the characteristics
    >> of an individual machine.

    >
    >So are COBOL and VB. The issue is not whether the code is compiled to
    >assembly; that's only the first step. It has to do with the underlying
    >object model, memory model, runtime libraries compiler optimizations and
    >so on. Ask any Fortran programmer why he or she wouldn't replace it with
    >any other programming languages. Java, btw, can also be compiled to
    >native assembly at least under some IDEs. There's more to performance
    >than an .exe extension.


    And so is C/C++. As I mentioned, it depends on optimisation (among other
    thing). Just look at the performance differences between C++ compilers; there
    are a number of areas where VC++ performance suffers against other C++ compilers.
    There is no reason why C# cannot be as fast as C++ given a well written compiler.
    I gave a URL previously of some performance tests comparisons. You disagree
    with them but haven’t provided any opposing data.


    >> >I don't make such a distinction because C++ doesn't make it either.
    >> >We're talking about programming languages in general, not what's best
    >> >for developing a ComboBox on Windows 3000. If you're confining the
    >> >domain of discussion to this realm, then I don't see how C# is going

    to
    >> >replace C++ anyway.

    >>
    >> The C++ language may not make a distinction but software analysis, design
    >> and development does !!!
    >>
    >> I would regard a ComboBox (or a TextBox, Button, Scrollbar etc.) as part
    >> of the primitive set of GUI components provided by an operating system

    and
    >> hence system development.

    >
    >And what about all other things which aren't ComboBoxes (and I don't
    >mean Dialog Boxes) -- thread support, VMM, hardware interfacing, kernel
    >modules and in short -- just about anything that a programming language
    >such as C++ can do?


    Again this is all system development functionality. I keep stressing this
    point: I am talking specifically about Application Development.


    >> >It does make a difference if you have 100 of salesperson using the same
    >> >server at once.

    >>
    >> Believe me it doesn’t (remember that the data access components (ADO)

    are
    >> written in C++). It comes down to performance tuning the server and database
    >> (for example, by adding indexes).

    >
    >It surely does. Look at CNN's site during a crisis. When the server has
    >to deal with 1000,000 hits per minute or 100,000,000, performance is
    >everything that matters, especially in Web-based environments.


    Having worked on a number internet project, it really doesn’t matter. It
    comes down to load balancing, server replication etc. Even going through
    a process of database de-normalisation would yield a better performance.
    How would an ADO method call, or a DB stored procedure call work faster in
    C++ rather than VB or C#?


    >ADO is a bad example. It only proves that you can write suckable code
    >with C++. Then again, you could not. I wouldn't take ADO or any other MS
    >toy feature as an exemplary framework.


    Another [inaccurate] emotive statement.


    >> >Actually, I'd think of VB as the GUI glue. The real core application
    >> >should be written in C++ or a similar high performance language unless
    >> >you really have 100,000 to spare for a mainframe.

    >>
    >> Yes, but not just the GUI glue. The glue for ALL components not just GUI
    >> ones like: ADO, MSMQ, MSXML etc. – all written in C++ and glued together
    >> in VB – rapid/component based development.

    >
    >In some cases, VB is the glue. In most other cases, it's completely
    >useless. How much VB code is used in IE for example?


    IE is probably a bad example as it could be regarded as part of the operating
    system (depending on you point of view) and hence system development. A better
    example would be Microsoft Word. In this case, I believe that if Microsoft
    were starting from scratch they would probably use C#. And remeber were are
    talking about VB.NET


    >> >We're talking about ANSI C++. The products you listed are not distinct
    >> >programming languages, mind you, but implementations of the same
    >> >language, which only proves the point that C++ is ubiquitously
    >> >available, as opposed to VB and C#. When was the last time you saw an
    >> >IBM compiler running VB code?

    >>
    >> Vendor specific implementations of same language – that’s my point. You

    will
    >> find very few C++ applications that are truly ANSI C compliant and therefore
    >> not portable (by the way, I think IBM have released the own version of

    VB).
    >
    >We're not dealing with percent counting. The fact is that if you truly
    >want to write portable code, you can do that in C/C++. Can you do that
    >in VB? IBM tried to do something with VB. It was such a colossal failure
    >that they eliminated any relic of that disastrous piece of trash. The
    >funny thing is that they aimed at the Linux community --as if Linux
    >programmer would ever really use such a thing in the first place...
    >Let's be serious for a minute. VB is a Windows only language, period.


    I accept that you can write portable C++ code but this has to be defined
    as a requirement from the beginning. My argument here is that where this
    isn’t specified from the outset, the code is not portable because there is
    a tendency to use vendor specific functionality (like COM). In most cases
    application written in C++ are NOT portable.


    >> >Again, it depends on which type of application development you're
    >> >talking about. I haven't seen components used in database engines,
    >> >compilers or OS kernels yet.

    >> This is system development, I am talking spcifically about using C++ for
    >> Application Development.

    >
    >And I'm talking specifically about programing in general. The original
    >question, IIRC, was whether C# would replace C++. The answer is "no".


    I don't they want a single word answer. Remember, I qualified by statement
    with 'in the area Application Development'.


    >> >Again, you're confining the discussion to a very narrow (and quite
    >> >obsolete) type of applications. Who uses DCOM these days? People who
    >> >need components could use CORBA, C# or even Java. Then again, they might
    >> >use VC++ too. The point is that many applications don't and will never
    >> >use components.

    >>
    >> No, my discussion spcifically about using C++ for Application Development
    >> (COM/DCOM was just an example of a technology that was supported by one

    platform
    >> and not another).

    >
    >So what's your point here? you can use DCOM in VC++.


    No! My point is that using platform specific technologies results in non-portable
    code!

    >> My general point is that application development nowadays incorporates

    some
    >> degree of RAD and this leads to component-based development. In which

    case
    >> any third-party components and techonologies must also be portable.

    >
    >Application Development has always incorporated RAD or quasi RAD tools.
    >Back in the 1970s there were screen/menu generators and in the 80's
    >people spoke of 4 GL (fourth generation languages) that would replace
    >ordinary programming languages. The thing is that the RAD tools only
    >provide the veneer (and often, not ideally). They are frequently
    >replaced by the next big thing while real programming languages last for
    >decades.


    Again, not true. RAD has only come about through component based development
    and component reuse. Neither do they 'only provide the veneer'. They integrate
    components (mostly written is C/C++). I'm not sure ehat you mean by 'real'
    (another emotive statement), but languages like VB and Delphi have evolved
    and continue to. C++ has not.

    >> >So what you're saying is that C++ is disappearing while VB is here to
    >> >stay? Gee! Bill Gates and Linus Torvalds should seriously consider
    >> >rewriting Linux and Windows in VB!

    >>
    >> No, I'm saying C++ for application development will descline significantly,
    >> replaced by either VB.NET or C# (both equally powerful).

    >
    >Let's wait and see. My bet is that VB's days are numbered.


    But can you justify your opinion?


    >> >That's what they want you to believe. Since they are the only vendor
    >> >selling development tools for this language, rest assured that they will
    >> >change it as they please, ECMA standard or not. And they will certainly
    >> >do so because the language is still immature and will undergo the
    >> >natural course of a language evolution, as every programming language
    >> >does. Java only recently (2002) introduced assertions. Something we've
    >> >had in C since the early 1970s (so much for "a new technology", btw).

    C#
    >> >is no different. If you want a more compelling example, look at the
    >> >evolution of VB in the past decade.

    >>
    >> Not so, I believe they will no abide by the ECMA standards.

    >
    >Again, let's wait and see. I find it hard to see the value of a rash
    >standard of a beta product. C# will change and quite a lot in the coming
    >months and years not because M$ doesn't want to violate the so-called
    >standard but because they will have no choice. That's what happens when
    >one rushes to standardize a new, half-baked programming language.


    Again emotive statements. No evidence provided.
    >
    >>
    >> >It isn't an upgrade, it's just different, and not necessarily better.
    >> >For starters, it uses a GC which is the anathema of determinacy. As
    >> >opposed to what most people think, GC introduces many problems (the lack
    >> >of destructors is only a minor example), outstanding memory (Java
    >> >programmers can tell you about that) and so on and so forth. Managed

    C++
    >> >isn't better than C++, it's just different.

    >>
    >> I wasn't suggesting managed C++ is better that C++. I personally think

    it's
    >> there solely for legacy C++ code.

    >
    >Or for those who wouldn't use C# and VB.


    >> >No offense, but it's obvious that you haven't done any serious C++
    >> >programming and your conclusions are based on your own experience with
    >> >VB. That's why you're so easily convinced that C# is the best thing
    >> >since sliced bread. Trust me, it isn't. I do agree with you about one
    >> >thing though: C++ is certainly not for everybody. Quoting Bjarne
    >> >Stroustrup, "it's for serious programmers".


    I certainly don't regard myself as a programmer. I develop software solution
    and am involved an every stage of the software life-cycle. C/C++ programmers
    tend to be pidgeon-holed into specific roles (namely programming). VB programmers
    tend to have a wider skillset.


    >> My conclusions are based on 10 years experience in application development
    >> and IT consultancy. Again I repeat my claim: "For application development,
    >> yes. There are no significant advantages of using C++ over C# (or VB.NET)."
    >>
    >> >Delphi? you gotta be kidding me. It was buried at least twice, ages ago.
    >> >Again, you have to understand that there's more to programming than
    >> >splash screens and dialog boxes.

    >> You give a number of emotive statements like above, yet fail it provide

    any
    >> technical, economic justifications of why C++ is better.

    >
    >I just did that and I'll do it again: performance, portability,

    Not so, as explained previously.

    >stability (I'm talking about the language's specification), ubiquitous

    VB/Delphi are just as stable.

    >availability, general purpose applicability and one thing I didn't
    >mention is the fact that the language isn't subjected to the whims of
    >one company's marketing department or another (I'm not talking about M$
    >in particular, Sun is just as bad in this regard).

    Come on, VC is packed with not standard functionality.

    >Delphi is very much
    >dead, emotional or not. Not that I have anything against it personally,
    >it's just that if we're talking Application Development on Windows, even
    >VB's future seems brighter than Delphi...


    More emotion, no evidence. This is exactly what I meant by die-hard C/C++
    programmers. Application development has and is changing, you are falling
    behind.

    >Danny



  3. #18
    Brian Preston Guest

    Re: Is C# going to take over? Or is MS going to continue their VC++


    "James" <cplus.@127.0.0.1> wrote:
    >


    >I certainly don't regard myself as a programmer. I develop software >solution
    >and am involved an every stage of the software life-cycle. C/C++ > >programmers

    tend to be pidgeon-holed into specific roles (namely > > >programming). VB
    programmers tend to have a wider skillset.

    I have had to churn out VB on occation when required form my employer. This
    is no problem for me or any of the other C++ programmers I know. Ask a VB
    programmer to do C++ and you up **** creek. "VB programmers tend to have
    a wider skillset", maybe in some altenate universe.

    Brian


  4. #19
    Danny Kalev Guest

    Re: Is C# going to take over? Or is MS going to continue their VC++



    Brian Preston wrote:
    >
    > "James" <cplus.@127.0.0.1> wrote:
    > >

    >
    > >I certainly don't regard myself as a programmer. I develop software >solution
    > >and am involved an every stage of the software life-cycle. C/C++ > >programmers

    > tend to be pidgeon-holed into specific roles (namely > > >programming). VB
    > programmers tend to have a wider skillset.
    >
    > I have had to churn out VB on occation when required form my employer. This
    > is no problem for me or any of the other C++ programmers I know. Ask a VB
    > programmer to do C++ and you up **** creek. "VB programmers tend to have
    > a wider skillset", maybe in some altenate universe.


    I only wonder why VB programmers, and other toy-language programmers,
    insist on using pomp terms like "solution provider" or the worst of all:
    "software architect" to define their jobs... Trust me, I know what VB
    exactly is. To me, "wider skillset" means -- among other things -- at
    least some experience in various platforms and application domains other
    than the Windows-message loop-pulldown menu boredom.

    Anyway, since this thread is really sliding off its original topic
    (which has been beaten to death already), I think it would be best to
    conclude it with the usual "let's wait and see". Just as we did with
    Java and the late Visual J++.

    Danny

  5. #20
    ralph Guest

    Re: Is C# going to take over? Or is MS going to continue their VC++


    Danny Kalev <dannykk@inter.net.il> wrote:
    >
    > ... snipped
    >
    >Anyway, since this thread is really sliding off its original topic
    >(which has been beaten to death already), I think it would be best to
    >conclude it with the usual "let's wait and see". Just as we did with
    >Java and the late Visual J++.
    >
    >Danny


    You are right, Danny.

    Besides I have it on very good report, that this is a mute point, as we all
    will be writing in nothing but OPL for Symbian environments in just a few
    years.

    -ralph


  6. #21
    James Guest

    Re: Is C# going to take over? Or is MS going to continue their VC++


    Danny Kalev <dannykk@inter.net.il> wrote:
    >
    >
    >Brian Preston wrote:
    >>
    >> "James" <cplus.@127.0.0.1> wrote:
    >> >

    >>
    >> >I certainly don't regard myself as a programmer. I develop software >solution
    >> >and am involved an every stage of the software life-cycle. C/C++ > >programmers

    >> tend to be pidgeon-holed into specific roles (namely > > >programming).

    VB
    >> programmers tend to have a wider skillset.
    >>
    >> I have had to churn out VB on occation when required form my employer.

    This
    >> is no problem for me or any of the other C++ programmers I know. Ask a

    VB
    >> programmer to do C++ and you up **** creek. "VB programmers tend to have
    >> a wider skillset", maybe in some altenate universe.

    >
    >I only wonder why VB programmers, and other toy-language programmers,
    >insist on using pomp terms like "solution provider" or the worst of all:
    >"software architect" to define their jobs... Trust me, I know what VB
    >exactly is. To me, "wider skillset" means -- among other things -- at
    >least some experience in various platforms and application domains other
    >than the Windows-message loop-pulldown menu boredom.


    Why must your skillset only consist of programming? What about analysis,
    design, team leading, consulting, presentation and training skills, project
    management?

    Again you use terms like 'toy languages' without justification. Why do C++
    programmers find it so difficult to admit that VB has advantges over C++
    (like RAD, prototyping etc.)? It only serves to prove my point about die-hard
    C++ programmers. But you'll be the ones left behind.....

    As for C++ using VB. My experience of such programmers is: poor quality design
    (if any) and programming, failing (or sometimes refusing) to follow any standards,
    little or no documentation, Choosing to use the Win32 API rather that VB's
    own language. In short, they cannot.

    >Anyway, since this thread is really sliding off its original topic
    >(which has been beaten to death already), I think it would be best to
    >conclude it with the usual "let's wait and see". Just as we did with
    >Java and the late Visual J++.


    Yes I agree, my last post.

    >Danny



  7. #22
    James Curran Guest

    Re: Is C# going to take over? Or is MS going to continue their VC++

    "Danny Kalev" <dannykk@inter.net.il> wrote in message
    news:3CA9BED6.376AF47B@inter.net.il...
    >
    > I wonder how all these "benchmarks" always prove that a very carefully
    > crafted obfuscated code that runs under very specific settings appears
    > to be faster than native assembly. Seriously, do you believe C#, which
    > is built on top of C++ can be faster than C++? Let's be realistic. We've
    > heard exactly the same claims from Java buffs for seven years, and still
    > Java is s-l-o-w.



    It no great mystery. The author published the source code. Let see, for
    Object Instantiation, here's the C++ code

    int i, j, iTest = 0;
    clsPerfTest *clsTest;

    tmrStartStop = new Timer();
    for(i = 0; i < 10000; i++)
    {
    for(j = 0; j < 10000; j++)
    {
    clsTest = new clsPerfTest();
    delete(clsTest);
    }

    And here's the C# code (which ran in 1/7th the time)
    int i, j, iTest = 0;

    clsPerfTest clsTest;

    tmrStart = System.DateTime.Now;
    for(i = 0; i < 10000; i++)
    {
    for(j = 0; j < 10000; j++)
    {
    clsTest = new clsPerfTest();
    clsTest = null;
    }
    }

    Pretty much the same right? But appearances may be deceiving.

    First of all, the C++ object is being created on the heap, when it would
    have been just as useful created on the stack -- except it would be much
    faster from the stack. Further, the C++ clsPrefTest has a virtual dtor,
    while the C# version has an implied dtor. The C# compiler to allowed to
    notice that the dtor is empty and elide it, but since the C++ version is
    virtual the C++ compiler is specifically prevented from doing that (if the
    C++ dtor were implied, it could). Further, none of the C++ clsPerfTest
    members are inlined. If we inlined them, they'd be much faster.

    In other words, if you don't use the features in C++ that were put there
    to make it fast, it can be just as slow as any other language.

    --
    Truth,
    James Curran
    www.NJTheater.com (Professional)
    www.NovelTheory.com (Personal)





  8. #23
    Danny Kalev Guest

    Re: Is C# going to take over? Or is MS going to continue their VC++



    James Curran wrote:
    >
    > "Danny Kalev" <dannykk@inter.net.il> wrote in message
    > news:3CA9BED6.376AF47B@inter.net.il...
    > >
    > > I wonder how all these "benchmarks" always prove that a very carefully
    > > crafted obfuscated code that runs under very specific settings appears
    > > to be faster than native assembly. Seriously, do you believe C#, which
    > > is built on top of C++ can be faster than C++? Let's be realistic. We've
    > > heard exactly the same claims from Java buffs for seven years, and still
    > > Java is s-l-o-w.

    >
    > It no great mystery. The author published the source code. Let see, for
    > Object Instantiation, here's the C++ code
    >
    > int i, j, iTest = 0;
    > clsPerfTest *clsTest;
    >
    > tmrStartStop = new Timer();
    > for(i = 0; i < 10000; i++)
    > {
    > for(j = 0; j < 10000; j++)
    > {
    > clsTest = new clsPerfTest();
    > delete(clsTest);
    > }
    >
    > And here's the C# code (which ran in 1/7th the time)
    > int i, j, iTest = 0;
    >
    > clsPerfTest clsTest;
    >
    > tmrStart = System.DateTime.Now;
    > for(i = 0; i < 10000; i++)
    > {
    > for(j = 0; j < 10000; j++)
    > {
    > clsTest = new clsPerfTest();
    > clsTest = null;
    > }
    > }
    >
    > Pretty much the same right? But appearances may be deceiving.
    >
    > First of all, the C++ object is being created on the heap, when it would
    > have been just as useful created on the stack -- except it would be much
    > faster from the stack. Further, the C++ clsPrefTest has a virtual dtor,
    > while the C# version has an implied dtor. The C# compiler to allowed to
    > notice that the dtor is empty and elide it, but since the C++ version is
    > virtual the C++ compiler is specifically prevented from doing that (if the
    > C++ dtor were implied, it could). Further, none of the C++ clsPerfTest
    > members are inlined. If we inlined them, they'd be much faster.
    >
    > In other words, if you don't use the features in C++ that were put there
    > to make it fast, it can be just as slow as any other language.


    Adding to that, the underlying machinery of Managed code ensures slower
    execution time. First of all, it uses JIT compilation of Intermediate
    Language (which isn't very different from Java's bytecode). Unlike in
    Java, the compiled IL code is cached so subsequent calls of the same
    methods don't incur the JITting overhead. Alas, the compiled code is
    transient. Every time you launch the application or reboot the system,
    it must be repeated *for every method* called. Imagine how annoying it
    would be if every morning you'd have to recompile the entire Office
    suite or your Web browser... Although it's possible to pre-JIT and
    entire application and avoid all this nuisance, this nullifies the
    so-called portability of .Net IL code.
    Put differently, C# could be an improvement over Java (which frankly,
    isn't that difficult. Even VB performs better than Java) but it cannot
    compete with properly written C/C++ compiled to native code.

    Danny
    >
    > --
    > Truth,
    > James Curran
    > www.NJTheater.com (Professional)
    > www.NovelTheory.com (Personal)


  9. #24
    ralph Guest

    Re: Is C# going to take over? Or is MS going to continue their VC++


    "James Curran" <JamesCurran@mvps.org> wrote:
    >"Danny Kalev" <dannykk@inter.net.il> wrote in message
    >news:3CA9BED6.376AF47B@inter.net.il...
    >>
    >> I wonder how all these "benchmarks" always prove that a very carefully
    >> crafted obfuscated code that runs under very specific settings appears
    >> to be faster than native assembly. Seriously, do you believe C#, which
    >> is built on top of C++ can be faster than C++? Let's be realistic. We've
    >> heard exactly the same claims from Java buffs for seven years, and still
    >> Java is s-l-o-w.

    >
    >
    > It no great mystery. The author published the source code. Let see,

    for
    >Object Instantiation, here's the C++ code
    >
    > int i, j, iTest = 0;
    > clsPerfTest *clsTest;
    >
    > tmrStartStop = new Timer();
    > for(i = 0; i < 10000; i++)
    > {
    > for(j = 0; j < 10000; j++)
    > {
    > clsTest = new clsPerfTest();
    > delete(clsTest);
    > }
    >
    >And here's the C# code (which ran in 1/7th the time)
    > int i, j, iTest = 0;
    >
    > clsPerfTest clsTest;
    >
    > tmrStart = System.DateTime.Now;
    > for(i = 0; i < 10000; i++)
    > {
    > for(j = 0; j < 10000; j++)
    > {
    > clsTest = new clsPerfTest();
    > clsTest = null;
    > }
    > }
    >
    > Pretty much the same right? But appearances may be deceiving.
    >
    >First of all, the C++ object is being created on the heap, when it would
    >have been just as useful created on the stack -- except it would be much
    >faster from the stack. Further, the C++ clsPrefTest has a virtual dtor,
    >while the C# version has an implied dtor. The C# compiler to allowed to
    >notice that the dtor is empty and elide it, but since the C++ version is
    >virtual the C++ compiler is specifically prevented from doing that (if the
    >C++ dtor were implied, it could). Further, none of the C++ clsPerfTest
    >members are inlined. If we inlined them, they'd be much faster.
    >
    > In other words, if you don't use the features in C++ that were put there
    >to make it fast, it can be just as slow as any other language.
    >
    >--
    >Truth,
    >James Curran
    >www.NJTheater.com (Professional)
    >www.NovelTheory.com (Personal)
    >



    Just as an amplification, the REAL jump in performance is caused by something
    you eluded it, but didn't specifically point out in the C# code.

    In the following it should be noted ...

    clsTest = new clsPerfTest();
    clsTest = null;

    ...that this code doesn't actually do anything except increment and decrement
    a reference count after the first call no matter how many times it is called!

    Because of _GC. (Ghod - trust me - I hate to say anything good about it.
    <g>) The first time through the object is allocated, but the assignment to
    'null' merely decrements the reference count for the OS to destroy the object
    later. But before the OS gets "around to it" - Lo and Behold, you want another
    one, and it just happens to have one laying around!

    C++ is handicapped because when we say "delete" we mean "delete". <g>
    However, as you pointed out no C++ programmer would write such a thing in
    the first place. (Well, uhhh... not a second time anyway. <g>)

    -ralph




  10. #25
    James Guest

    Re: Is C# going to take over? Or is MS going to continue their VC++


    Danny Kalev <dannykk@inter.net.il> wrote:
    >
    >
    >James Curran wrote:
    >>
    >> "Danny Kalev" <dannykk@inter.net.il> wrote in message
    >> news:3CA9BED6.376AF47B@inter.net.il...
    >> >
    >> > I wonder how all these "benchmarks" always prove that a very carefully
    >> > crafted obfuscated code that runs under very specific settings appears
    >> > to be faster than native assembly. Seriously, do you believe C#, which
    >> > is built on top of C++ can be faster than C++? Let's be realistic. We've
    >> > heard exactly the same claims from Java buffs for seven years, and still
    >> > Java is s-l-o-w.

    >>
    >> It no great mystery. The author published the source code. Let see,

    for
    >> Object Instantiation, here's the C++ code
    >>
    >> int i, j, iTest = 0;
    >> clsPerfTest *clsTest;
    >>
    >> tmrStartStop = new Timer();
    >> for(i = 0; i < 10000; i++)
    >> {
    >> for(j = 0; j < 10000; j++)
    >> {
    >> clsTest = new clsPerfTest();
    >> delete(clsTest);
    >> }
    >>
    >> And here's the C# code (which ran in 1/7th the time)
    >> int i, j, iTest = 0;
    >>
    >> clsPerfTest clsTest;
    >>
    >> tmrStart = System.DateTime.Now;
    >> for(i = 0; i < 10000; i++)
    >> {
    >> for(j = 0; j < 10000; j++)
    >> {
    >> clsTest = new clsPerfTest();
    >> clsTest = null;
    >> }
    >> }
    >>
    >> Pretty much the same right? But appearances may be deceiving.
    >>
    >> First of all, the C++ object is being created on the heap, when it would
    >> have been just as useful created on the stack -- except it would be much
    >> faster from the stack.


    Are you suggesting applications should only ever use stack objects? Look
    at the bigger picture and compare like with like.

    >> Further, the C++ clsPrefTest has a virtual dtor,
    >> while the C# version has an implied dtor. The C# compiler to allowed

    to
    >> notice that the dtor is empty and elide it, but since the C++ version

    is
    >> virtual the C++ compiler is specifically prevented from doing that (if

    the
    >> C++ dtor were implied, it could).


    Not a huge impact, if any.


    >> Further, none of the C++ clsPerfTest
    >> members are inlined. If we inlined them, they'd be much faster.


    In this case may be (or may be not) but to what degree i.e. what is ‘much
    faster’? It is also worth noting that ‘inlining’ can actually make code execution
    slower.

    >> In other words, if you don't use the features in C++ that were put

    there
    >> to make it fast, it can be just as slow as any other language.


    No, remember that for like for like tests C# is faster, using the ‘the features
    in C++ that were put there to make it fast’ only serves to bring C++ closer
    to the performance of C#.


    >Adding to that, the underlying machinery of Managed code ensures slower
    >execution time. First of all, it uses JIT compilation of Intermediate
    >Language (which isn't very different from Java's bytecode). Unlike in
    >Java, the compiled IL code is cached so subsequent calls of the same
    >methods don't incur the JITting overhead. Alas, the compiled code is
    >transient. Every time you launch the application or reboot the system,
    >it must be repeated *for every method* called. Imagine how annoying it
    >would be if every morning you'd have to recompile the entire Office
    >suite or your Web browser... Although it's possible to pre-JIT and
    >entire application and avoid all this nuisance, this nullifies the
    >so-called portability of .Net IL code.


    Depends on the application and deployement environment. But such a big issue,
    unlike C, you have a choice in C#. Indeed one suspects that in future it
    will be possible for it to be compiled one only and disk cached.

    >Put differently, C# could be an improvement over Java (which frankly,
    >isn't that difficult. Even VB performs better than Java) but it cannot
    >compete with properly written C/C++ compiled to native code.


    Compete where? In application development it can and will surpass anything
    C++ can offer. Why are C++ programmers so fixated with raw processing speed.
    Why do you always fail to see the bigger picture?

    This is why you are being relagated to system development and specialist
    component building (for the present); thats fine for us VB developers we
    get to do all the exciting development and integration stuff!

    Anyway, I though we agreed no more posts!

    >Danny
    >>
    >> --
    >> Truth,
    >> James Curran
    >> www.NJTheater.com (Professional)
    >> www.NovelTheory.com (Personal)



  11. #26
    Danny Kalev Guest

    Re: Is C# going to take over? Or is MS going to continue their VC++



    ralph wrote:
    > Just as an amplification, the REAL jump in performance is caused by something
    > you eluded it, but didn't specifically point out in the C# code.
    >
    > In the following it should be noted ...
    >
    > clsTest = new clsPerfTest();
    > clsTest = null;


    Duh! How didn't I notice that flagrant fraud? To be fair, certain C++
    implementations use the same trick when you delete an object and
    immediately allocate another object of the same type. The details aren't
    exactly the same because C++ object semantics is still different, but
    the time wasted on searching the heap and finding the first available
    chunk of memory is avoided this way. The problem is that many OS's
    initialize the memory returned from the heap so the time saved by
    eliding a heap search becomes negligible compared to the time wasted on
    in initializing the heap object before even calling the object's ctor.
    That said, one should remember that C++ doesn't require any of these
    operations -- a chunk of heap memory needn't be initialized before an
    object is constructed on it so this benchmark merely shows the
    limitations and inefficiencies of the specific heap manager of the
    platform in question rather than exposing an inherent flaw in C++. As
    James said, a fair comparison would use a dumb struct (or a class that
    doesn't have explicitly defined ctor and dtor member, let a lone a
    virtual dtor) allocated on the stack. Btw, IIRC C# does have a mechanism
    for allocating objects (or perhaps just dumb structs?)on the stack using
    the stackalloc keyword or something like that.

    Finally, it's saddening to see that C# designers were so uninspired,
    copying the verbose and redundant Java syntax of allocating objects
    verbatim:

    clsPerfTest clsTest = new clsPerfTest();

    What's the point in repeating the class's name twice? Even if it's
    allocated on the heap, wouldn't

    new clsPerfTest clsTest;

    Or just plain

    clsPerfTest clsTest;

    Do the trick just as well? The user already knows that the object is
    allocated on the heap so there shouldn't be any confusion regarding the
    storage type of the object.

    >
    > ..that this code doesn't actually do anything except increment and decrement
    > a reference count after the first call no matter how many times it is called!
    >
    > Because of _GC. (Ghod - trust me - I hate to say anything good about it.
    > <g>) The first time through the object is allocated, but the assignment to
    > 'null' merely decrements the reference count for the OS to destroy the object
    > later. But before the OS gets "around to it" - Lo and Behold, you want another
    > one, and it just happens to have one laying around!
    >
    > C++ is handicapped because when we say "delete" we mean "delete". <g>


    And it's just as well. The problem with all GC-based languages is that
    you don't have real destructors. Finalizers execute an indeterminate
    time (when the GC awakens, which can happen weeks after the object was
    discarded) and in Java, there's even no requirement that finalizers ever
    be called!

    Danny

  12. #27
    Danny Kalev Guest

    Re: Is C# going to take over? Or is MS going to continue their VC++



    James wrote:
    >
    > Danny Kalev <dannykk@inter.net.il> wrote:
    > >
    > >
    > >James Curran wrote:
    > >>
    > >> "Danny Kalev" <dannykk@inter.net.il> wrote in message
    > >> news:3CA9BED6.376AF47B@inter.net.il...
    > >> >
    > >> > I wonder how all these "benchmarks" always prove that a very carefully
    > >> > crafted obfuscated code that runs under very specific settings appears
    > >> > to be faster than native assembly. Seriously, do you believe C#, which
    > >> > is built on top of C++ can be faster than C++? Let's be realistic. We've
    > >> > heard exactly the same claims from Java buffs for seven years, and still
    > >> > Java is s-l-o-w.
    > >>
    > >> It no great mystery. The author published the source code. Let see,

    > for
    > >> Object Instantiation, here's the C++ code
    > >>
    > >> int i, j, iTest = 0;
    > >> clsPerfTest *clsTest;
    > >>
    > >> tmrStartStop = new Timer();
    > >> for(i = 0; i < 10000; i++)
    > >> {
    > >> for(j = 0; j < 10000; j++)
    > >> {
    > >> clsTest = new clsPerfTest();
    > >> delete(clsTest);
    > >> }
    > >>
    > >> And here's the C# code (which ran in 1/7th the time)
    > >> int i, j, iTest = 0;
    > >>
    > >> clsPerfTest clsTest;
    > >>
    > >> tmrStart = System.DateTime.Now;
    > >> for(i = 0; i < 10000; i++)
    > >> {
    > >> for(j = 0; j < 10000; j++)
    > >> {
    > >> clsTest = new clsPerfTest();
    > >> clsTest = null;
    > >> }
    > >> }
    > >>
    > >> Pretty much the same right? But appearances may be deceiving.
    > >>
    > >> First of all, the C++ object is being created on the heap, when it would
    > >> have been just as useful created on the stack -- except it would be much
    > >> faster from the stack.

    >
    > Are you suggesting applications should only ever use stack objects? Look
    > at the bigger picture and compare like with like.


    No, if I may speak in James's name, he suggest that that fair benchmarks
    use non-language biased features. Put differently, if the author of this
    test knows (and I bet he or she does) that this loop is a cheat because
    it merely increments and decrements a counter whereas in C++ a real
    object is created and destroyed, he should have had the decency to state
    that or at least use C++ features that a typical experienced and
    knowledgeable programmer would use in this context.

    >
    > >> Further, the C++ clsPrefTest has a virtual dtor,
    > >> while the C# version has an implied dtor. The C# compiler to allowed

    > to
    > >> notice that the dtor is empty and elide it, but since the C++ version

    > is
    > >> virtual the C++ compiler is specifically prevented from doing that (if

    > the
    > >> C++ dtor were implied, it could).

    >
    > Not a huge impact, if any.
    >
    > >> Further, none of the C++ clsPerfTest
    > >> members are inlined. If we inlined them, they'd be much faster.

    >
    > In this case may be (or may be not) but to what degree i.e. what is ‘much
    > faster’? It is also worth noting that ‘inlining’ can actually make code execution
    > slower.


    We're dealing with speed here, so the issue of code size isn't relevant
    here (although in this respect, the excess baggage of the CLR would make
    C# look ridiculously bloated anyway).
    How much faster? It's a good question but there's no point in
    speculating. The original tester should have measured that, unless he
    had a good reason not to do so.


    >
    > >> In other words, if you don't use the features in C++ that were put

    > there
    > >> to make it fast, it can be just as slow as any other language.

    >
    > No, remember that for like for like tests C# is faster, using the ‘the features
    > in C++ that were put there to make it fast’ only serves to bring C++ closer
    > to the performance of C#.


    That's ridiculous. C# borrowed C++ features that weren't in Java for the
    sake of improving the infamous molasses of Java. As I said in one of the
    previous posts, since C# is written in C++, it can't compete with C++,
    period. Whether a specific optimization trick (such as caching JITted
    code on the disk) is used is irrelevant because we're not comparing
    implementations but languages.

    >
    > >Adding to that, the underlying machinery of Managed code ensures slower
    > >execution time. First of all, it uses JIT compilation of Intermediate
    > >Language (which isn't very different from Java's bytecode). Unlike in
    > >Java, the compiled IL code is cached so subsequent calls of the same
    > >methods don't incur the JITting overhead. Alas, the compiled code is
    > >transient. Every time you launch the application or reboot the system,
    > >it must be repeated *for every method* called. Imagine how annoying it
    > >would be if every morning you'd have to recompile the entire Office
    > >suite or your Web browser... Although it's possible to pre-JIT and
    > >entire application and avoid all this nuisance, this nullifies the
    > >so-called portability of .Net IL code.

    >
    > Depends on the application and deployement environment. But such a big issue,
    > unlike C, you have a choice in C#.


    You do have a choice in C++ too. Although dynamic linking isn't a
    standard feature, every platform I know of supports it. DLL's, shared
    Libraries, Sharable Images -- the names may vary but in essence, it's
    the same thing. Perhaps it would be fair to add that C# hasn't invented
    anything new. At most, it borrowed a few concepts from Java (which in
    turn borrowed them from Smalltalk) with new names. Even its security
    model is a Java copycat.

    Indeed one suspects that in future it
    > will be possible for it to be compiled one only and disk cached.


    if you're using disk caching, and thereby lose the alleged portability
    of C# applications, who needs all the overhead of .Net in the first
    place? Distributed applications -- I can understand. Standalone apps
    such as IE or Word don't need this nonsensical features to begin with.

    >
    > >Put differently, C# could be an improvement over Java (which frankly,
    > >isn't that difficult. Even VB performs better than Java) but it cannot
    > >compete with properly written C/C++ compiled to native code.

    >
    > Compete where?


    In performance. We're talking about performance, aren't we?

    > In application development it can and will surpass anything
    > C++ can offer.


    Vacant slogans. Anything that can be done in C# can be done in C++.
    Perhaps not always with the same ease but you have much tighter control
    and freedom. Do you have decent templates in C#? multiple inheritance? a
    standard library of algorithms? or will the wheel be reinvented again
    with preposterous classes like ByteArray?


    >Why are C++ programmers so fixated with raw processing speed.


    Because it matters. At least for C++ programmers. Otherwise, they'd use
    Perl, Python or VB.


    > Why do you always fail to see the bigger picture?


    What's the bigger picture exactly? A more impressive splashscreen?

    >
    > This is why you are being relagated to system development and specialist
    > component building (for the present);


    Most of us do many other things (yes, including GUI stuff, which I find
    the most boring, uninspired and unchallenging task but that's my
    subjective opinion of course), and those who deal with system
    programming find it much more challenging and innovating than editing a
    Wizard's generated boilerplate code. System programming requires real
    innovation and the ability, errm, to see the bigger picture. It's a
    choice, not an obligation, which VB programmers don't even have.

    >
    > Anyway, I though we agreed no more posts!


    You have agreed to that:) Anyway, I'll try to control myself. Take it
    away, Ralph...

    Danny

  13. #28
    ralph Guest

    Re: Is C# going to take over? Or is MS going to continue their VC++


    Danny Kalev <dannykk@inter.net.il> wrote:
    >
    >> ...

    >
    >> Anyway, I though we agreed no more posts!

    >
    >You have agreed to that:) Anyway, I'll try to control myself. Take it
    >away, Ralph...
    >
    >Danny


    Gosh, once again I feel obligated to say something. You know how difficult
    that is for me, being so shy and all. <g>

    My final comment or point is probably the least popular of all and is more
    anecdotal than factual. I have witnessed these "new products" come and go
    for almost 25 years now. Back then it was C vs. The World, now it is C++
    vs. The World. [Note: It is always them against C/C++ - it never seems to
    be them vs. another language...?) It seems like a ton of the "next best thing"
    have come and gone.

    Looking back on the various popular languages one thing stands out - they
    have all been "theme" languages. Meaning they came about to address a particular
    problem, work in a particular environment, or conform to some "ideal" man-machine
    interface. (Pascal was created to teach structual programming, ModuloII <sp?>
    came about to stress encapsulation and subroutines, BASIC for the masses
    of unschooled, Forth the power of the stack, ...

    <Paste Language Name Here> the power of <Paste Theme Here>

    Meanwhile, here was this horrible hybrid - "C" - too raw for a true human
    interface too high for true machine commands. You had to talk to OSs thru
    a translator (the compiler) and just like in real life - both parties are
    often surprised to discover what was actually said compared to what they
    thought they heard. And yet the hybrid "won".

    Along comes C++ and I believe an even uglier hybrid - there are far too many
    gotcha's and shortcuts to call it a true oopl. And it "won" - even bigger.

    The reason for this I think is because C/C++ has no theme. It is just a REAL
    language. You can combine it in any form you want, you can say - ain't if
    necessary, u kan due it th'sa way too, all tho - you best probably wish you
    hadn't done did that.

    I guess what I am trying to say is that other languages (C#, VBClassic, VB.NET,
    Pascal, ...) end up with basic patterns that they can use to solve a specific
    problem, but there are always some pattern that isn't supported well. (Try
    implementing a Go4 factory pattern straight out of the book with VB for example.)
    C++ has no limits (and I am including its ability to 'drop' into C when necessary)
    when it comes to a solution domain.

    That is why the OS is written in it. That is why all the "next best things"
    are written in it. Even the C libray is written in it. That is why it will
    never be "replaced". Its replacement would be so close to c/c++ there wouldn't
    be any reason to use it - since we already have it. <g>

    [Sidenote: People should take a look at K&R sometime. The thin little book
    taught C by writing the "C Standard Library" calls from scratch. You don't
    like strcpy() or printf()? Well then here is how to write your own. Can you
    write the .NET SDK in C#?]

    On the other hand I think we need Theme languages. One thing that often gets
    left out of these discussions is the real need for software and the dramatic
    increase in the number of programmers. Most of whom are using VB and the
    unix-cousin Java. There is NO way there would be the number of working business
    applications as there are if it wasn't for these simplified languages and
    the incrediable tools provided for them by the OS, RDBMS, and IDE's. Just
    as important we need less-skilled code monkeys that can write stuff with
    less effort.

    [You would be surprised (I no longer am) at the number of programmers I interview
    who have contributed usefully to writing million dollar billing systems -
    yet can not give a good definition of a "stack" - except to say it is something
    that seems to fill up if you code an endless loop.]

    I have never said these languages are not interesting or useful. I only get
    annoyed when somebody starts telling me they are going to replace C/C++.
    Somthing will eventually - but it ain't C# or any other theme language. Now
    then, OPL is looking interesting...

  14. #29
    Danny Kalev Guest

    Re: Is C# going to take over? Or is MS going to continue their VC++



    ralph wrote:
    >
    > Danny Kalev <dannykk@inter.net.il> wrote:
    > >
    > >> ...

    > >
    > >> Anyway, I though we agreed no more posts!

    > >
    > >You have agreed to that:) Anyway, I'll try to control myself. Take it
    > >away, Ralph...
    > >
    > >Danny

    >
    > Gosh, once again I feel obligated to say something. You know how difficult
    > that is for me, being so shy and all. <g>


    I can't help myself either...

    >
    > My final comment or point is probably the least popular of all and is more
    > anecdotal than factual. I have witnessed these "new products" come and go
    > for almost 25 years now. Back then it was C vs. The World, now it is C++
    > vs. The World. [Note: It is always them against C/C++ - it never seems to
    > be them vs. another language...?) It seems like a ton of the "next best thing"
    > have come and gone.
    >
    > Looking back on the various popular languages one thing stands out - they
    > have all been "theme" languages. Meaning they came about to address a particular
    > problem, work in a particular environment, or conform to some "ideal" man-machine
    > interface. (Pascal was created to teach structual programming, ModuloII <sp?>
    > came about to stress encapsulation and subroutines, BASIC for the masses
    > of unschooled, Forth the power of the stack, ...


    Put differently, C and C++ are truly general purpose programming
    languages, which mean that you can use them in any application domain.
    The snag is that they aren't optimized (i'm not talking about
    performance but rather ease of writing code) for specific tasks. For
    example, Fortran excels in number crunching bit for writing GUI -- it's
    a disaster. Python is excellent for quick prototyping but in terms of
    performance it's even worse than Java, etc. etc. The main problem with
    these languages is that their creators have tried to push them beyond
    their limits, failing to admit that they can do one particular task very
    nicely but they shouldn't be considered general purpose programming
    languages. Java is an excellent example. Sun has tried for years to show
    that it can be used in embedded systems and real time applications.
    That's a sad joke.

    >
    > <Paste Language Name Here> the power of <Paste Theme Here>
    >
    > Meanwhile, here was this horrible hybrid - "C" - too raw for a true human
    > interface too high for true machine commands. You had to talk to OSs thru
    > a translator (the compiler) and just like in real life - both parties are
    > often surprised to discover what was actually said compared to what they
    > thought they heard. And yet the hybrid "won".


    To be fair, C has lived up to its original promise. The first commercial
    implementation (1973) was Unix. Ken Thompson and Dennis Ritchie wanted
    to create a language for system programming (which until then was done
    in assembly). In this regard, they succeeded very well. No other third
    generation programming language is a better choice for writing OSs.
    >
    > Along comes C++ and I believe an even uglier hybrid - there are far too many
    > gotcha's and shortcuts to call it a true oopl. And it "won" - even bigger.
    >
    > The reason for this I think is because C/C++ has no theme. It is just a REAL
    > language. You can combine it in any form you want, you can say - ain't if
    > necessary, u kan due it th'sa way too, all tho - you best probably wish you
    > hadn't done did that.


    What you're referring to as a "them" is in fact a bias, which nullifies
    a language's ability to become a general purpose programming language.
    What avid users of C/C++ like is that these languages reflect very well
    the under-the-hood operation of a typical computer. For example, they
    use native data types that fit the target CPU's word size (Java's
    creators for example insisted that int be a 32 bit integer, which may or
    may not be the ideal data type of a target machine), you have pointers
    that allow you to access memory directly, low-level I/O interfaces that
    interact with the hardware directly or almost directly, function
    pointers, three or four mechanisms of passing arguments to a function
    (if we include passing arguments through registers as the fourth option)
    etc. etc. That said, the high level abstraction mechanisms of C++ enable
    you to hide the gory details in classes and templates that incur very
    little overhead, if at all. So both kernel hackers and RAD buffs can
    find in it what they need.


    >
    > I guess what I am trying to say is that other languages (C#, VBClassic, VB.NET,
    > Pascal, ...) end up with basic patterns that they can use to solve a specific
    > problem, but there are always some pattern that isn't supported well. (Try
    > implementing a Go4 factory pattern straight out of the book with VB for example.)
    > C++ has no limits (and I am including its ability to 'drop' into C when necessary)
    > when it comes to a solution domain.
    >
    > That is why the OS is written in it. That is why all the "next best things"
    > are written in it. Even the C libray is written in it. That is why it will
    > never be "replaced". Its replacement would be so close to c/c++ there wouldn't
    > be any reason to use it - since we already have it. <g>
    >
    > [Sidenote: People should take a look at K&R sometime. The thin little book
    > taught C by writing the "C Standard Library" calls from scratch. You don't
    > like strcpy() or printf()? Well then here is how to write your own. Can you
    > write the .NET SDK in C#?]


    Indeed, K&R is IMO the best programming book ever written. In less than
    250 pages it teaches all a programmer needs to know about C, and real
    world programming in general.

    >
    > On the other hand I think we need Theme languages. One thing that often gets
    > left out of these discussions is the real need for software and the dramatic
    > increase in the number of programmers. Most of whom are using VB and the
    > unix-cousin Java. There is NO way there would be the number of working business
    > applications as there are if it wasn't for these simplified languages and
    > the incrediable tools provided for them by the OS, RDBMS, and IDE's. Just
    > as important we need less-skilled code monkeys that can write stuff with
    > less effort.


    Sure, there's room for scripting languages (it really doesn't make sense
    to use a C++ program of 200 lines where a Perl script of 12 lines can do
    the job, if speed doesn't matter), quick prototyping languages such as
    Python (btw, Java isn't that impressive in this regard either. You still
    have to write a lot of code, catch silly exceptions that don't mean a
    thing just to make the compiler shut up, use ever-changing APIs and
    finally, resort to JNI calls), in-browser scripting languages such as
    JavaScript or job control languages such as JCL. Yet, as I've said
    several times before, in what language are all these high-level
    languages written? Bingo.

    Danny
    >
    > [You would be surprised (I no longer am) at the number of programmers I interview
    > who have contributed usefully to writing million dollar billing systems -
    > yet can not give a good definition of a "stack" - except to say it is something
    > that seems to fill up if you code an endless loop.]
    >
    > I have never said these languages are not interesting or useful. I only get
    > annoyed when somebody starts telling me they are going to replace C/C++.
    > Somthing will eventually - but it ain't C# or any other theme language. Now
    > then, OPL is looking interesting...


  15. #30
    James Guest

    Re: Is C# going to take over? Or is MS going to continue their VC++


    "ralph" <nt_consulting32@hotmail.com> wrote:
    >
    >Danny Kalev <dannykk@inter.net.il> wrote:
    >>
    >>> ...

    >>
    >>> Anyway, I though we agreed no more posts!

    >>
    >>You have agreed to that:) Anyway, I'll try to control myself. Take it
    >>away, Ralph...
    >>
    >>Danny

    >
    >Gosh, once again I feel obligated to say something. You know how difficult
    >that is for me, being so shy and all. <g>
    >
    >My final comment or point is probably the least popular of all and is more
    >anecdotal than factual. I have witnessed these "new products" come and go
    >for almost 25 years now. Back then it was C vs. The World, now it is C++
    >vs. The World. [Note: It is always them against C/C++ - it never seems to
    >be them vs. another language...?) It seems like a ton of the "next best

    thing"
    >have come and gone.
    >
    >Looking back on the various popular languages one thing stands out - they
    >have all been "theme" languages. Meaning they came about to address a particular
    >problem, work in a particular environment, or conform to some "ideal" man-machine
    >interface. (Pascal was created to teach structual programming, ModuloII

    <sp?>
    >came about to stress encapsulation and subroutines, BASIC for the masses
    >of unschooled, Forth the power of the stack, ...
    >
    ><Paste Language Name Here> the power of <Paste Theme Here>
    >
    >Meanwhile, here was this horrible hybrid - "C" - too raw for a true human
    >interface too high for true machine commands. You had to talk to OSs thru
    >a translator (the compiler) and just like in real life - both parties are
    >often surprised to discover what was actually said compared to what they
    >thought they heard. And yet the hybrid "won".
    >
    >Along comes C++ and I believe an even uglier hybrid - there are far too

    many
    >gotcha's and shortcuts to call it a true oopl. And it "won" - even bigger.
    >
    >The reason for this I think is because C/C++ has no theme. It is just a

    REAL
    >language. You can combine it in any form you want, you can say - ain't if
    >necessary, u kan due it th'sa way too, all tho - you best probably wish

    you
    >hadn't done did that.
    >
    >I guess what I am trying to say is that other languages (C#, VBClassic,

    VB.NET,
    >Pascal, ...) end up with basic patterns that they can use to solve a specific
    >problem, but there are always some pattern that isn't supported well. (Try
    >implementing a Go4 factory pattern straight out of the book with VB for

    example.)
    >C++ has no limits (and I am including its ability to 'drop' into C when

    necessary)
    >when it comes to a solution domain.
    >
    >That is why the OS is written in it. That is why all the "next best things"
    >are written in it. Even the C libray is written in it. That is why it will
    >never be "replaced". Its replacement would be so close to c/c++ there wouldn't
    >be any reason to use it - since we already have it. <g>
    >
    >[Sidenote: People should take a look at K&R sometime. The thin little book
    >taught C by writing the "C Standard Library" calls from scratch. You don't
    >like strcpy() or printf()? Well then here is how to write your own. Can

    you
    >write the .NET SDK in C#?]
    >
    >On the other hand I think we need Theme languages. One thing that often

    gets
    >left out of these discussions is the real need for software and the dramatic
    >increase in the number of programmers. Most of whom are using VB and the
    >unix-cousin Java. There is NO way there would be the number of working business
    >applications as there are if it wasn't for these simplified languages and
    >the incrediable tools provided for them by the OS, RDBMS, and IDE's. Just
    >as important we need less-skilled code monkeys that can write stuff with
    >less effort.
    >
    >[You would be surprised (I no longer am) at the number of programmers I

    interview
    >who have contributed usefully to writing million dollar billing systems

    -
    >yet can not give a good definition of a "stack" - except to say it is something
    >that seems to fill up if you code an endless loop.]
    >
    >I have never said these languages are not interesting or useful. I only

    get
    >annoyed when somebody starts telling me they are going to replace C/C++.
    >Somthing will eventually - but it ain't C# or any other theme language.

    Now
    >then, OPL is looking interesting...


    I never said that C/C++ would be replaced completely. I accept that there
    is a time and place for the language. What I wrote was that C# (and other
    .NET languages) would replace C/C++ for APPLICATION DEVELOPMET.

    Why do I have to keep writing this? Why can't C/C++ comprehend the difference
    be system and application development?

    For new application development on Windows platforms, C/C++ is dead!


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