Re: In need of .NET advocacy
- From: "Olaf Baeyens" <olaf.baeyens@xxxxxxxxxx>
- Date: Thu, 31 Mar 2005 09:50:34 +0200
>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.
--
http://www.skyscan.be
.
- 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: Sporadic errors when calling DLLs
- Next by Date: Re: bug on .net framework or...
- Previous by thread: Re: In need of .NET advocacy
- Next by thread: Re: In need of .NET advocacy
- Index(es):
Relevant Pages
|
Loading
