In need of .NET advocacy

[Alex]

Hello people,

The following is not a troll but a serious request.

I found myself in a position where I have to present a Pro/Con list to management and architects in our company with regard to developing new products (specifically - desktop products) in C#/.NET instead of the usual C++/COM that we do.

Since I am not an experienced .NET developer by any definition, I don't have a good grip on the "Pro" part.

The argument that I hear most extols the virtues of the garbage collection in .NET.
Frankly, I am not really convinced by it myself because I started since consistently using smart pointers and RAII, I did not have to worry about deallocations. I also feel that the lack of deterministic destructors is a big drawback that makes managing non-memory resources cumbersome.

Therefore I ask the community to provide me with reasons that could persuade me, and the people I will present them to, that switching would be beneficial to the company (they would be mostly interested in lowering risks, increasing productivity and saving money).

Both links and prose are welcome.


Best regards,
Alex.

 

[Sylvain Lafontaine]

Microsoft is in the process of killing the C++/COM stuff. The easiest way
of doing COM components was with VB6 but they don't sell it anymore and they
will soon (next month) stop unpaid support for it; the only exception beeing
things about security. In two years, even the security support for VB6 will
cease to be free. With VB6 out of the picture, the demand for COM
components will be falling rapidly.

On the C++/MFC/ATL side, you can be pretty sure that there will be no new
further development - excerpt of course for the integration of managed
code - and MS will only offer support for maintenance releases.

For Windows, it is fair to say that in the future, any new development will
be based on the .NET Framework; so you can tell that C++/COM is a thing of
the past and of the present but not of the future.

S. L.

Hello people,

The following is not a troll but a serious request.

I found myself in a position where I have to present a Pro/Con list to
management and architects in our company with regard to developing new
products (specifically - desktop products) in C#/.NET instead of the usual
C++/COM that we do.

Since I am not an experienced .NET developer by any definition, I don't have
a good grip on the "Pro" part.

The argument that I hear most extols the virtues of the garbage collection
in .NET.
Frankly, I am not really convinced by it myself because I started since
consistently using smart pointers and RAII, I did not have to worry about
deallocations. I also feel that the lack of deterministic destructors is a
big drawback that makes managing non-memory resources cumbersome.

Therefore I ask the community to provide me with reasons that could persuade
me, and the people I will present them to, that switching would be
beneficial to the company (they would be mostly interested in lowering
risks, increasing productivity and saving money).

Both links and prose are welcome.


Best regards,
Alex.

 

[Sean Hederman]

Hello people,

The following is not a troll but a serious request.

I found myself in a position where I have to present a Pro/Con list to
management and architects in our company with regard to developing new
products
(specifically - desktop products) in C#/.NET instead of the usual C++/COM
that we do.

Since I am not an experienced .NET developer by any definition, I don't
have a good grip on the "Pro" part.

Here we go:
- Productivity, productivity, productivity. Within 3 months of switching to
..NET we found a 20-50% productivity boost over VB6. The boost over C++ was
several times.
- Interoperability. A lot of work has gone into making sure that your .NET
code will work seamlessly with your COM components, preserving your existing
investment. Similarly IJW protects your existing non-COM C++ code.
- Security. CAS allows you to be very specific about code permissions,
allowing you to ship safer code and administrators to protect their systems
better.
- Some platform independence. With Mono you get the ability to write for
Windows and Linux in one code base.
- Future. COM does have a future, but will not receive much work. Most new
components and libraries on Windows will be .NET.
- Massive unified libraries. Their unified nature makes them easier to learn
(ONE string class!). Their capabilities are awesome.
- RAD features. Visual designers, edit & continue (soon back) and suchlike
make it very easy for even beginners to pump out good components.

The argument that I hear most extols the virtues of the garbage collection
in .NET.

That's perhaps because of how important a feature it is.

Frankly, I am not really convinced by it myself because I started since
consistently using smart pointers and RAII, I did not have to worry about
deallocations.

Good for you! But now imagine you were working in a system where it not only
guaranteed RAII for, but for all code you used. You could put that newbie to
work without having to scan their code for naked pointers and invalid
resouce usage semantics, because it would be taken care of for you.

I also feel that the lack of deterministic destructors is a big drawback
that makes managing non-memory resources cumbersome.

There is a pattern called IDisposable that allows you your deterministic
clean-up. Also note that the new C++/CLI allows for deterministic
finalisation.

 

[Olaf Baeyens]

- Productivity, productivity, productivity. Within 3 months of switching
to

.NET we found a 20-50% productivity boost over VB6. The boost over C++ was
several times.

I do not know about VB but when I use managed C++ then I speed up about 3
times compared to unmanaged C++ because especially in user interface design.
And a second aspect because of the assemblies, that reduces compile and
linker time a lot.

If I create a program purely in C# then I even speed up with 7 times
compared to unmanaged C++.
Mainly because of the lightning faster compile times than C++, and also the
auto-completion is much faster, and the languages is designed from scratch
to use the .NET so much simpler to extend and very readable compared to the
C++ where I need tons of macro's to make it .NET compatibe.

Right now I create C# projects for prototyping and test my program, en then
port it to conventional C++ and still have time left.

The good things about the .NET is that you can write parts in managed C++
code, so you still have the raw processing speed while you have the very
nice User interface featuers of the .NET.

Oddly enough, I create the programs in the same time frame when I program in
..NET or conventionally. The only difference is that I can add more
functionality and make it far more user friendly in the case of the .NET
program.

- Security. CAS allows you to be very specific about code permissions,
allowing you to ship safer code and administrators to protect their systems
better.

This is true, the security of the code is buit into the application by
default.
In my opinion, now in the world of so many virusses and worms, this is the
best thing they ever implemented.
E.g. if you create a small program lets say a calculator, then it cannot be
infected by a virus/worm and taken over to connect the Internet. Compared to
a conventional executable, it could take over your complete computer. I
don't clame that a .NET program cannot be infected, but it slows down the
propagation dramatically.

- Some platform independence. With Mono you get the ability to write for
Windows and Linux in one code base.

And don't forget, with the Visual Studio 2005 coming out in the summer in
combination with the .NET framework 2.0 you can compile a program in such a
way that it stays neutral of the 32/64 bit code.
This means that a program that is compile with this flag, then when
installed on a 32 bit Windows XP it will compile as 32 bit program, and when
run on a 64 bit Windows XP it will compile and run as pure 64 bit!!!!! And
the 64 bit Windows XP is out to be soon? This month I believe?

- Future. COM does have a future, but will not receive much work. Most new
components and libraries on Windows will be .NET.
- Massive unified libraries. Their unified nature makes them easier to learn
(ONE string class!). Their capabilities are awesome.

In the near future we will have .NET framework v2.0 combined with Visual
studio 2005, this summer.
But then the name changes to WinFX (equivalent of .NET framework 3.0) to be
included into the next version of WIndows codenamed Longhorn (2006).
The good news is that I hear rumors that this WinFX will also be available
for Windows XP and maybe W2K(?)

Since porting code from unmanaged code to managed code takes time, it would
be nice to start doing it now. Or at least start to learn the .NET way it
does have a pretty steep learning curve regarding to the security stuff. And
you have to think in OOP which to my suprise a huge bunch of programmers
still do not understand because they have to unlearn the none-OOP way.

The biggest negative side of the .NET applications is that there is a big
resistance towards installing the .NET framework.
I get very silly responses when I ask people why they do not want to install
it. Most of the responses are psychological orientated, which translates to
fear of the unknown.
But it appears that when you buy a recent version of Windows XP then the
..NET framework framework is automatically included.

Another psychological thing is that .NET programs appears to be slow,
because they load much slower. But tests here by running the program, I do
not see any noticible slowdown. Except for the additional user interface
functionality that you implement of course. You tend to implement more
active user interface stuff.

 

[Olaf Baeyens]

The argument that I hear most extols the virtues of the garbage collection

in .NET.
Frankly, I am not really convinced by it myself because I started since
consistently using smart pointers and RAII, I did not have to worry about
deallocations. I also feel that the lack of deterministic destructors is a
big drawback that makes managing non-memory resources cumbersome.

The GC is fantastic!
The only scary thing is that if you look at your taks manager, your memory
consumption gets up and up and up an when it reaches out of memory
situations it suddely drops dramatcially. This means that the GC got into
action freeeing up memory. It does this by alanyzing you assigned code and
if it discovers that some memory blocks are not assigned anymore anywhere
then it frees up memory. Smart pointers cannot do that in my opinion, not in
that extend way.

The very good thing about this is that I do to have to keep track of who
allocated the memory, if you assign it to multiple pointers.
The other good thing is that the memory does not get disposed untill every
pointer to it have been changed to another location. This reduces the risk
of access violations dramatically since all pointers point to a valid memory
block. Your code gets simplified dramatically. Especially when you create
code for OpenGL, to built a dynamic scene.

There is one negative impact of the GC.
When you implement code that have file access, that locks a file, and you
would close the file in the destructor, then the file gets close in a
unpredictable time frame. So in this case you should not close the file in
the destructor, but use the "dipose" function for that. This is similar like
calling the delete function but it happens when you decide it, not depending
on the GC.

I have to admit that in the beginning I did not trust that GC, I was afraid
that it would not work very reliantly, but tests have shown that it is very
reliant, so now I trust it more than the time that I used the delete way of
doing.

 

[Cor Ligthert]

Sean,

Very nice post. I find this one of the best on this ever asked question.with
the exception from that not expliciet question to respond to your mail
address, let us all benefit from this kind of discussions. (Although in my
opinion there is not much to ask anymore when we see your message).



Cor

 

[Olaf Baeyens]

Another reason to move to .NET is the fact that VB programmers that upgrade
to VB.NET somehow gets forced to use the .NET.
Since there are far more VB programmers than C++ programmers, I believe that
the .NET framework will be forced to be installed by everybody that wants to
use that latest program created by the VB programmer.

Also I noted that ATI video card drivers expect the .NET installed for their
user interface to configure the card. (CATALYSTT for Windows XP) ATI is also
a big player in the market so expect .NET to be installed on many computers
that have the newest ATI video cards.

In my opinion, investing in none-NET technology except if you need raw
performance power, is a waste of time and resources if you create a program
that have a year development cycle.

 

[Nick Malik [Microsoft]]

I have to throw in my two bits here...

I have to present a Pro/Con list to management and architects in our
company with regard to developing new products (specifically - desktop
products) in C#/.NET instead of the usual C++/COM that we do.<

(they would be mostly interested in lowering risks, increasing productivity
and saving money).<

The framework library alone is worth the switch. For years, folks have been
complaining that MFC and the classes built on top of it ignored most of the
most productive design patterns. It was difficult to really use many of the
most powerful patterns without creating yet another layer of code on top of
the MFC classes to create the relationships that you needed, and even then,
C++ was structurally limited from answering a few of the most difficult
problems.

No more.

You get a class library that was redesigned from the ground up. It makes
EXTENSIVE use of the modern design pattern principles, one of the key
reasons that folks had been switching to Java, but are now switching back.
As a result, the code is smaller, easier to plug in, and easier to maintain.
I'll be honest, I'm able to do things in C# that would not have occurred to
me in C++ because the library has fostered a better approach to solving
problems.

The neat thing about this is: the explosion of open source C# code. I guess
it was hard to tell that one of the biggest reasons why C++ never really
took off in the open source community was the lack of patterns in the MFC,
but now that we have the framework, it is not only easy to get high quality,
open source, components written in C#, but Microsoft itself has released
fairly sizable chunks of code into open source.

In fact, many of the "productivity" applications that were popping up in the
Java world for years have now started appearing as ported code in .Net,
including (my favorites) NUnit, NAnt, and ports for many popular AOP
frameworks.

Also, with C# and .NET, we have no more DLL Hell, like we did with COM.
That was an expensive problem and one of the best things that MS fixed. In
order to share your library with other apps, you MUST sign it and provide a
version number. The system will check the version (unless you tell it not
to) to make sure that you are getting the library you debugged with.

What does all this give you:
Lowered risk
--- code can be reused, shared, and leveraged more easily because of the
extensive use of patterns in the framework
--- less code is required, therefore less likelihood of defects, therefore
less risk in the integration phases
--- more readily available code for profiling, unit testing, automated
build, and others
--- by using the newer framework, finding skilled resources is easier than
finding C++ folks
--- Absense of DLL hell reduces support costs

Increased productivity
--- No need to write expensive "layers" on top of MFC to get it to do the
things that OO developers expect
--- Support for a wide variety of needs, including internet protocols, XML,
and Web Services, built in to the tools. Zero code to use these new
features.
--- C# language is simpler to write in, and simpler to train folks in,
dramatically increasing the productivity of average developers
--- Elegant event model built in to languages allows for more powerful
application architectures with less code to maintain.

Lowered costs
--- First off: lowering risk and increasing productivity... no need to
repeat myself
--- availability of low cost or no cost options for components and tools,
even a few from Microsoft.
--- Training costs are lowered due to the approachability of the system
--- More people are available in the contingent staffing world who know C#
now, lowering their billable rates


--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--

 

[Patrick A]

Except when M$ drops support for .Net, like they are doing with VB6,
you'll be screwed, just like the millions of people/companies that have
invested billions in building VB apps. You'll have to either migrate
your code to the next great M$ platform or else just try to plod on
with no support or upgrades from M$. At least if you build something
with C++, you know that you'll always be able to compile it and always
be able to find support.

 

[Cor Ligthert]

Patrick,

At least if you build something
with C++, you know that you'll always be able to compile it and always
be able to find support.

In a kind of same way is this said in past from the universal language Algol
as well.

Beside Cobol are there not much program languages with a longer lifetime
than 30 years.

Cor

 

[Sean Hederman]

Cor,

Whew! Thanks, I really appreciate the compliment.

BTW, my email address can be found here:
http://www.codingsanity.com/email.jpg.

Sean

 

[Sylvain Lafontaine]

And what about Fortran? According to the following references, Fortran was
born well before Algol:
http://www.math.grin.edu/~rebelsky/Courses/CS302/98S/Outlines/outline.02.html
http://www.scriptol.org/dates.htm

S. L.

 

[Sean Hederman]

Except when M$ drops support for .Net, like they are doing with VB6,
you'll be screwed, just like the millions of people/companies that have
invested billions in building VB apps.

And who didn't bother using the great Upgrade Wizard provided with .NET.
Also, note that when VB6 support ends, you'll still be able to write VB6
apps and sell them, and they'll work. MS just won't be providing free tech
support on it.

You'll have to either migrate
your code to the next great M$ platform or else just try to plod on
with no support or upgrades from M$. At least if you build something
with C++, you know that you'll always be able to compile it and always
be able to find support.

By this logic we shouldn't buy anything. Where do you think I can get free
support for my Nokia 2110? Or my parents Datsun 1200 (1980's model)? How
about getting support for my Betamax video player, or my LP record player?
The fact is that you can still get support for those things, it'll just cost
you more. VB6 is the same.

Keep in mind that VB6 was about providing RAD to developers, and .NET
continues that tradition. I'll say that I believe I'd spend less time
writing an app in VB6, and then rewriting it in VB.NET from the ground up
than I would writing it in C++ once. So, a longer term language but at the
cost of productivity and profits. I'm not in that sector of the industry
where solutions have to last 10+years, so for me, C++ makes no sense.

 

[Olaf Baeyens]

Except when M$ drops support for .Net, like they are doing with VB6,

you'll be screwed, just like the millions of people/companies that have
invested billions in building VB apps. You'll have to either migrate
your code to the next great M$ platform or else just try to plod on
with no support or upgrades from M$. At least if you build something
with C++, you know that you'll always be able to compile it and always
be able to find support.

If you think like that, then we would probably still be stuck with Windows
3.1 now and no Internet.
Programming languages must evolve since the programs they must create
becomes more and more complex.
Using managed C++ using .NET framework I gain a 3 fold speed of development,
while creating more secure code an far more user friendly.

I realize that the VB6 people have a hard time since it is a step backwards
in functionality, but the Visual studio 2005 coming out in de summer, will
have a much better solution and ease of use for VB programmers. You will
still have a transition, but it will become much easier.

Regarding support and experience, since .NET programs look alike in any
programming language except for small syntax differencs, you will gain a lot
more experience from other developers that program in different languages.
The only limiting factor would be the none-case sensitivity, but if C# and
C++ programmers write .NET assemblies (dll's similar like OCX) you simply
can use them if you want. So your search for usefull components increases
treefold with the components designed for the managed C++ and C# + your
normal VB.NET components .

See many advantages over VB 6, it is really worth the transition!

 

[Nick Malik [Microsoft]]

no one is stopping you from sticking with VB6. Support is still there...
it's just not free. There's a BIG difference.

Those C++ language compilers you are comparing with... will you be paying
for support there too?

I was once a Luddite too, but no more. Sometimes progress really is better.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.

 

[Alex]

Thank you very much for your replies, they (especially Sean's Olaf's and Nick's) were very informative!

First, a minor nit picking:

Sean Hederman> There is a pattern called IDisposable that allows you your deterministic clean-up.

Not really, as it depends on the user of the object to manually call Dispose() at the appropriate time.
I had this problem with Java and it is the same in C#.
I hope that C++/CLI would solve it in an elegant way (i.e., allowing destructors in managed objects).


Now, to the bulk of the answers.

The comments mentioned several advantages:

1) Productivity increase.

Is it possible to get some "official" data from a company?
It is one thing to say "Joe Sixpack claimed on m.p.d.g that he experienced a productivity increase of 64.7% since switching to .NET" and quite a different thing to point people to the site of a commercial (preferably well known) company stating the same.

Also, it would be interesting to break down the productivity increase.
Did the savings come from an easier transformation of the design to code? Faster coding? Less bugs to fix? More efficient tracking of the said bugs? More understandable code? Something else? Did all activities (analysis/design, coding, QA, refactoring, support) benefit equally?

2) Security.

Again, real-world examples will be appreciated.

3) Portability and interoperability.

I don't see any advantage over using C++ with platform-independent library (like Qt, ACE, WxWidgets, etc.)

4) "Future".

Not really an issue in this particular case because future platforms will still support COM and native execution.
As somebody mentioned, the availability of newer Maximas did not cause older Datsuns to stop working.

5) Framework.

Can anyone comment what parts of the framework proved to be "lifesavers" compare to the "old way"?

6) RAD features.

MFC had them, no?

7) Programmer availability.

I guess that if a lot of VB6 coders are "forced" to switch to VB.NET then the market of .NET developers will get a big boost.
However, no offence intended but VB6 did little to promote good programming practices and a good number of VB6 coders should not be let anywhere near a product.

My own (admittedly biased) perception is that top developers would achieve better results given the power and flexibility of C++ but the average developer will do better with managed code.

8) Stuff that nobody commented on (yet)

Reflection, 3rd party tools (NUnit, etc.), ...


Best regards,
Alex.

 

[Cor Ligthert]

Alex,

With all those good answers in this threads, which answers that are in my
opinion more than you could expect from a newsgroup. I can only get this
opinion. This starting message in your question is false.

The following is not a troll but a serious request.

Just my thought,

Cor

 

[Olaf Baeyens]

Now, to the bulk of the answers.Very tough questions now, you want proof. ;-)
I can only give you the programers point of view.

1) Productivity increase.

I cannot give real data, but look at it this way:
Currently I am still forced to use unmanaged C++ because users have still
the big scare to install the .NET framework.
But I can speed up the unmanaged C++ cycle by creating prototype C# programs
to test out ideas and functionality because the C# compiler is lightning
fast.
This way I know the pitfalls that I will encounter, I can use NUnit for
tesing stuff and then I port that C# code to C++ and still have more time
left than I would have created the program in unmanaged C++ directly. I had
to find a good way to emulate delegates/events and use properties in
unmanaged C++, but now the C++ programs are equivalent of the .NET way of
doing. Also the C++ programs are actually a stripped down version of the C#
programs that have far more functionality otherwise I would never reach a
delivery date. But at least the C++ programs are ready to be extended for
the future.

2) Security.
Again, real-world examples will be appreciated.

If you go to http://www.securityfocus.com/bid/keyword/
Here you fins all known bugs of almost anything software related.
APS.NET uses the .NET frameowrd, ASP uses the old ways.

Use keyword "asp.net" (.NET way) and I get 5 bug reports:

16-02-2005: Microsoft ASP.NET Unicode Character Conversion Multiple
Cross-Site Scripting Vulnerabilities
06-10-2004: Microsoft ASP.NET URI Canonicalization Unauthorized Web Access
Vulnerability
06-05-2004: Microsoft ASP.NET Malformed HTTP Request Information Disclosure
Vulnerability
08-09-2003: Microsoft ASP.NET Request Validation Null Byte Filter Bypass
Vulnerability
06-06-2002: Microsoft ASP.NET StateServer Cookie Handling Buffer Overflow
Vulnerability

Use the keyword "ASP" (none .NET way) and you get a zillion of bugs.

6) RAD features.

MFC had them, no?

Not really, it was a first trial to make it RAD, but they failed miserably
because the MFC classes are created in the none-Object way of thinking.
It was nothing more that a set of classes that acts as wrapper around
windows functions. You had a very hard time to extend and reuse the objects.
The framework was built in the wrong way.

Another thing about MFC is that every class behaves differently. So many
execptions in how to use dialog box controls that are in a lot of cases not
compatible with each other.
Which is perfectly normal because since MFC is a set of class wrappers
around Windows and Windows have been extended with all different new
technologies.

Creating a user interface is an adventure on it's own.
Look at the differences in using menu items and popup menu's. Completely
different ways of implementing.

At the same time, Delphi came out with the pure Object oriented way of
thinking. This was in 1995 or something like that.
Every component have almost the same properties with predictable names. If
you understand one control, then you probably understood the other control
too.

Maybe it is of no suprise but the guy that developed the Delphi framework,
happens to be the same guy that was in the design phase of the .NET.
I don't know the details about this, but it is striking how close Delphi and
..NET are related.

Look I don't say that MFC is really that bad, it was a good idea in those
times to implement it like that, but the Delphi/.NET way appears to be the
better choice since it is designed from scratch in such a way that is can be
extended. It looks like that MFC is designed to have the highest performance
in speed while the .NET way is to the easiest way of extending and creating
programs.

7) Programmer availability.

I guess that if a lot of VB6 coders are "forced" to switch to VB.NET then

the market of .NET developers will get a big boost.

However, no offence intended but VB6 did little to promote good programming practices and a good number
of VB6 coders should not be let anywhere near a product.

This is a something that I do not wish to discuss. ;-)
But the hord of VB.NET programmers will somehow make the users install the
..NET framework which is very good news.

My own (admittedly biased) perception is that top developers would achieve better results given the power
and flexibility of C++ but the average developer will do better with managed code.

I have to agree on that. But to programmers are expensive and in short
supply.
And what do you do when they leave the company or maybe get sick? Who is
able to take over that code?
Top programmers tend to create unreadable code for other developers. Mostly
because they use techniques that the common people have no clue of what they
are doing.

8) Stuff that nobody commented on (yet)

Reflection, 3rd party tools (NUnit, etc.), ...

I love NUnit!!
Testing code have never been so easy when you starts to have a huge library
and you must change something in that library you can test very fast if it
breaks something else.

Another issuse, if you program in C# and have a syntax error, then your
incorrect code gets underlined, so you can find the problems faster. Also
you maybe get a few errors while C++ tends zo give you a kazilion errors all
trying to point you in the wrong direction.


In my opinion choosing for the .NET or not is like a action of faith. Only
history will tell if it was a good choice or not.
But right now I personally would gamble on .NET.

 

[Nick Malik [Microsoft]]

Hi Alex,
Glad to be of help

Developers have been arguing about how to measure developer productivity for
years. If you notice from my signature, I am a CFPS. That is a Certified
Function Point Specialist. In other words, I am trained and certified
measure developer productivitiy. Most of my data is private and
proprietary. I can tell you this: when translating from function points to
estimates, we use "normalized" numbers to determine the expected
productivity of a developer against a particular feature set. We are very
happy with the productivity of C#. C++ is considered one of the "average"
languages. These are not guesses. They are measurements. (And no, I
cannot share the numbers). You can get public numbers from
http://www.spr.com

The reasons "why" vary from person to person, mostly because each person
finds a different reason for the productivity gains of .Net. Besides, why
do you care? If its more productive, its more productive. It's a little
like asking "Why does Broccoli taste better than Asparagus?" You'll get an
argument and no answers. Note that 2.0 (Whidbey) adds a LOT of useful
features, including a unit testing framework very similar to NUnit.

2) Security.

There have only been a handful of security issues reported against .NET, and
all have been fixed in current service packs. Not so for COM over the
years. . (Public info was provided by another poster).

3) Portability and interoperability.

I never raised this as an advantage of .Net. I simply stated the error of
using this as a cost factor over .Net because it is not cheaper to use a
different compiler (with paid support or no support).

4) "Future".

I thought you were pulling this stuff together for managers and executives.
Now I'm beginning to wonder. Is Cor right?

"Future of the language" affects the availability of developers. These
issues are CLOSELY tied together.

If your company is doing custom software development, even just for internal
apps, this matters a LOT. Ask all those organizations stuck with miles of
Powerbuilder code and no developers around to maintain it, and no way to add
the new features that the business wants, or change the business rules to
keep up with changes in law, policy, or business practices. This is an
EXPENSIVE place to be.

I know of a government agency with a mission critical app written in
SmallTalk, and no way to extend it. It's a nice app, but they needed
integration features, and SmallTalk doesn't give you anything "out of the
box" like .Net (and even VB6) does. Their last remaining SmallTalk
developer doesn't understand integration.

This story is repeated in thousands of companies and agencies, with systems
written in dozens of languages. With the aging of the COBOL population,
this fate will soon befall the estimated billions of lines of COBOL code. I
used to support an app in Simula. Talk about "hard to fix!" Simula is a
wonderful language that no one remembers. I even added one to the pile:
many years ago, I wrote a very useful app for Linguistics research... in
SNOBOL. I dare you to find a professional SNOBOL programmer, for any price.

Availability of developers matters. Over time, it will matter to C++. The
trend has already started, and historically, this trend is a freight train
that cannot be stopped.

5) Framework.

All of it. The structure of the framework is totally different than a set
of wrapper classes around a set of wrapper classes around an API. (COM on
MFC on Win32). You can do things in 20 lines of code in C# that would
require hundreds in C++, and that story is repeated many times.

Are you familiar with Design Patterns? If not, read this to get you
started: http://blogs.msdn.com/nickmalik/archive/2004/12/21/328727.aspx

6) RAD features.You are kidding, right?


7) Programmer availability.
Now, you are being prejudiced. I know many excellent programmers in the VB
ranks, and some pretty lousy ones in the C++ ranks.

Your statement is naieve. *All* developers will achieve better results
using C# over unmanaged code because you can focus on the business problem
and not the details of the technology. Also, _your_ projects will have
average developers on them, if not now, then later during maintenance. This
is a fact of life. Average developers outnumber top developers about 20 to
1 in my experience.

No one creates an IDE for top developers, or a language, or a framework.
These tools are there for average developers to increase their productivity
because a 1% increase in productivity applied to 95% of the workforce is far
better for overall cost savings than a 25% increase applied to 5% of the
workforce. Company executives get this, and if you want to be able to speak
with them with a coherent message, you need to learn it too.

I commented on third party tools and open source platforms in my previous
post.

I've seen many postings from Java users who were impressed with the
Reflection capabilities of .Net. Personally, I think that reflection is
probably a tad bit over-discussed because it is a 'cool' feature, but for
those applications where it is the right answer (quite a few, actually), it
is absolutely mission-critical, and this capability simply wasn't available
in C++.


--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.

 

[Sean Hederman]

Thank you very much for your replies, they (especially Sean's Olaf's and
Nick's) were very informative!

First, a minor nit picking:

Sean Hederman> There is a pattern called IDisposable that allows you your
deterministic clean-up.

Not really, as it depends on the user of the object to manually call
Dispose() at the appropriate time.
I had this problem with Java and it is the same in C#.

Whether it's manually called or not does not impact it's determinism. A
naked pointer in C++ has deterministic clean-up, but you have to call delete
to get it. If you want smart pointer equivalence, wrap the reference in a
using block.

I hope that C++/CLI would solve it in an elegant way (i.e., allowing
destructors in managed objects).

It does. C++/CLI supports deterministic cleanup via ~ClassName.

Now, to the bulk of the answers.

The comments mentioned several advantages:

1) Productivity increase.

Is it possible to get some "official" data from a company?
It is one thing to say "Joe Sixpack claimed on m.p.d.g that he experienced
a productivity increase of 64.7% since switching to .NET" and quite a
different thing to point people to the site of a commercial (preferably
well known) company stating the same.

Does Microsoft count? ;-)

Also, it would be interesting to break down the productivity increase.
Did the savings come from an easier transformation of the design to code?

Yes, much easier.

Faster coding?

The tools help you with coding if that's what you mean. Also C++ to C# meant
a cleaner syntax with less gotchas and ambiguities.

Less bugs to fix?

Yep. No swallowed error conditions via unchecked HRESULT's. No dangling
pointers, no buffer overruns, no memory leaks.

More efficient tracking of the said bugs?

Nope. Generally one uses third-party tools for that.

More understandable code?

Yes, C# is much easier to read than C++.

Something else?

One coherent set of libraries.

Did all activities (analysis/design, coding, QA, refactoring, support)
benefit equally?

No, Id say coding was helped the most by the tool, and the Framework also
assisted A&D, coding and QA a bit.

2) Security.
Again, real-world examples will be appreciated.

Code Access Security and no buffer overruns are the biggies here.

3) Portability and interoperability.
I don't see any advantage over using C++ with platform-independent library
(like Qt, ACE, WxWidgets, etc.)

Read the posts. Sure, you can do it in C++, but C++ is a pain to develop for
in comparison.

4) "Future".

Not really an issue in this particular case because future platforms will
still support COM and native execution.
As somebody mentioned, the availability of newer Maximas did not cause
older Datsuns to stop working.

No, but do you really *want* to drive an old Datsun?

5) Framework.
Can anyone comment what parts of the framework proved to be "lifesavers"
compare to the "old way"?

Reflection, unified type system, single string class (happiness), Remoting.

6) RAD features.
MFC had them, no?

No. I suggest you write a simple MFC windows app, and then do the same in
Windows Forms. Chalk and cheese.

7) Programmer availability.
I guess that if a lot of VB6 coders are "forced" to switch to VB.NET then
the market of .NET developers will get a big boost.
However, no offence intended but VB6 did little to promote good programming
practices and a good number of VB6 coders should not be let anywhere near a

Agreed, but then I also believe that large numbers of C++ coders should be
similarly constrained. Also, you seem to be suffering from a fairly common
misapprehension that .NET is basically C# & VB.NET. You can also code .NET
using
C++, either ANSI C++ (using Managed C++ Extensions), or the much easier to
read C++/CLI.

My own (admittedly biased) perception is that top developers would achieve
better results given the power and flexibility of C++ but the average
developer will >do better with managed code.

Disagree completely:
http://codingsanity.blogspot.com/2005/01/return-of-whiny-gripes-about-net.html. I
love this attitude by dyed-in-the-wool C++ devs that C++ is somehow "better"
than other languages. It's not. It's just a language. It does some things
better, and some things worse than other languages. I don't understand how
you can come up with the idea that top developers won't achieve better
results by using better tools. For writing most applications today, .NET is
a far better tool than most C++ implementations. In the few areas where it's
not, fine use C++. Premature optimization is a mistake no matter what the
context, and developing 100% in C++ because of the 1% (or less) where you
really need it is a clear case of premature optimization.

Alex, I'm struggling to understand something. You asked for pro/cons to
persuade others and then flat out admitted that you're biased against what
you're supposedly championing. Your statements appear designed to assert
that C++ is better than .NET/C#. I'm struggling to reconcile this with your
assertion that you're not a troll, and it seems I'm not alone.