Re: Future of MFC?

In article news:<1190483614.331757.323600@xxxxxxxxxxxxxxxxxxxxxxxxxxx>,
Ajay Kalra wrote:
[I wrote]
Ajay Kalra wrote:
For regular development, unless you have legacy code, there is no
reason to not use .Net.

You could say that ... but, then again, there is no reason *TO* use
NET.

Actually there are several. Productivity alone is sufficient. Finding
labor is another. Complexity, software pattern implementation, tool
integration in IDE etc are many more.

OK, I deserved that ... I made a glib answer in the same tone that I
perceived in your comment and paid for my glibness.

What I should have said is this:

I accept that, taken overall, .NET does provide better tools and those
tools they can provide a productivity gain that may tempt you towards
NET development. This is all due to the tools, not to any inherent
advantage of the platform, the APIs, or the languages.

It doesn't have to be that way. It is possible to provide good tools
for native code development, and with tools that were as good as those
for .NET it would be just as easy to develop native applications as
NET applications, and the native applications would typically perform
better.

Says who? You are making it between Java and .Net. I dont care about
Java. We were talking about MFC and .Net.

I'm not "making it" anywhere. I said that the advantages of .NET as a
platform (rather than as a development environment) were that it
allowed a single binary application to run unchanged on disparate
hardware platforms, and that it afforded the security of a sandboxed
runtime. If those things matter to you you won't be interested in MFC,
you will be looking mostly a .NET or Java.

My point was that the JVM is nigh-on ubiquitous, while the CLI is
pretty-much a rarity on non-Windows platforms (and can't be guaranteed
on Windows). If you want to be reasonably confident that a user can run
your application you write it for the JVM not the CLI. This is not a
choice based on ease of development, but one based on commonnness of
the target platforms concerned.

If you're not writing that kind of app then you're probably right not
to care.

Comparing the two environments, I see .Net as by far the most
productive. Things which MFC developer worries about are not even a
thought. You jump straight to business logic. It costs far less to
have the same functionality in .Net than MFC. Even cheaper to
maintain it.

... but this is STILL down to tools. It's not because .NET apps are
better than native apps (they're not) it's because .NET has the best
tools. All I'm arguing for here is that native code developers should
get tools that are just as good.

Cheers,
Daniel.


.

Relevant Pages

  • Re: SharedCLibrary version
    ... The guard could be there for a very good reason. ... any RMEnsures. ... If however a programmer, for whatever reason, decides not to use ... platforms he wants to support. ...
    (comp.sys.acorn.programmer)
  • Re: Fast / Slow Line Layout
    ... That it has happened over time is part of the reason, ... at flat junctions a train may have to cross all other lines to make ... more easily by just putting the platforms on the outside. ... Interchange between trains in the same direction can easily be ...
    (uk.railway)
  • Re: [PATCH 1/2] OLPC: Add support for calling into Open Firmware
    ... tree, etc. ... There's potentially no reason why other platforms couldn't use this, ... currently OLPC is the main user of it. ...
    (Linux-Kernel)
  • Re: File exist
    ... and never give a reason on some implementations. ... will give the reason on those platforms that tell you why. ... Windows GetLastError() call. ... that I've seen set errno for you.) ...
    (comp.lang.c)
  • Re: Delphi Product Manager questioned
    ... native code development are not poor, ... The only reason for Delphi IMHO... ...
    (borland.public.delphi.non-technical)