Re: In need of .NET advocacy
- From: "Sean Hederman" <email.jpg@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 31 Mar 2005 18:36:37 +0200
"Alex" <response@xxxxxxxxxxxxx> wrote in message
news:3b0mc4F6eboo6U1@xxxxxxxxxxxxxxxxx
> 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
> >product.
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.
>8) Stuff that nobody commented on (yet)
>Reflection, 3rd party tools (NUnit, etc.), ...
>Best regards,
>Alex.
>--
>Please replace myrealbox with alexoren to reply by email.
.
- Follow-Ups:
- Re: In need of .NET advocacy
- From: Alex
- Re: In need of .NET advocacy
- References:
- Re: In need of .NET advocacy
- From: Alex
- Re: In need of .NET advocacy
- Prev by Date: Help me before I take the VB.Net plunge???
- Next by Date: Re: Hello
- Previous by thread: Re: In need of .NET advocacy
- Next by thread: Re: In need of .NET advocacy
- Index(es):
Relevant Pages
|
Loading
