Re: .NET myths debunked.

From: Michael Swindell \(Borland\) (mswindell_at_dontspam.borland.com.ih8spam.org)
Date: 12/30/03 

Date: Mon, 29 Dec 2003 23:54:35 -0800

Respectfully, I don't agree with the counterpoints, but it's a great
discussion nonetheless.

> - The advantage of being 2 to 100 times slower

Currently some operations are faster, some are slower - overall application
speed is good to very good. Our most significant speed "challenges" had to
do with lots of managed to unmanaged jumps (since we are still using quite a
bit of unmanaged code in the IDE) rather than .NET operations. Rest assured
that operations where speed is not up to unmanaged equivalents, will improve
in the future.

> - The advantage of having a huge memory consumption

The runtime memory requirements in managed code apps are higher, but
reasonable - I would hesitate to use classify it as "huge" but it's a matter
of opinion, perspective, and purpose. Anything halfway modern with a quarter
gig of RAM or more, memory isn't an issue. I'm not putting .NET on my dusty
128mb 300mhz Thinkpad, although I think it meets the minimum requirements of
32mb min 96mb recommended. Regardless, having the memory managed results in
more reliable and more secure applications. Small price to pay for a little
more RAM. It took me years to come to terms with this trend. I recently
moved into a new house and in the move I ran across an old Apple II 5.25
floppy that had a dozen or so old Apple Pascal apps I'd written more than 20
years ago, and I was thinking about working within 48k back then. It really
seemed like a lot of space compared to 4k and 16k z80's we were playing with
before that. In so many ways this discussion would have been unthinkable
back then.

> - The advantage of having a massive deploy

In fact the opposite is true. The runtime framework is considered part of
the Windows platform, is also included in Windows update, and is part of all
shipping Windows OSes from Win2003 and on. Deployment size is not going to
be an issue except on older OSes without Internet connectivity. The point is
moot anyhow, if you want to run future Microsoft applications, you're going
to have to have an OS with the runtime present. The .NET runtime *is*
Windows moving forward. Considering that the .NET runtime is part of the
Windows platform, application deployment requirements will actually be much
*smaller* than today's deployments.

> - The advantage of countless bugs due to the immaturity of .net

Coming from a development group who has spent the past year eyeballs deep in
.NET and weaving thru the innards of CLR, immaturity and bugs in the
platform isn't going to be an issue for you. The platform is ready and good
quality.

> - The advantage of not being able to use pointers and other useful things

<shrug> You can use pointers and other useful things. Of course using
pointers is unsafe and you lose managed code benefits. But, you have the
choice.

> - The advantage of getting your application broken when MS puts out a new
.net
> runtime (DLL hell all over again)

Interestingly, we developed the first Galileo IDE with .NET v1.0, and
switched more or less over to v1.1 one day. Very little, if anything at all,
was broken. In fact, I ran the first version of our .NET v1.1 IDE on v1.0
for several days. It's not a magic bullet, but Microsoft has done a lot to
make things resilient between .NET releases...

> - The advantage of being locked in to the MS platform

It's very much a Microsoft platform, that's for sure. But it's Windows. If
you're not interested in Windows development then .NET's not really for you.
As Windows developers we've always been locked into Windows. Sure there is
Mono, but it's yet to be seen whether Mono will be able to keep up with the
volume of APIs and framework components as .NET more and more becomes
"Windows" - It's going to be fun and interesting to follow.

> - The advantage that your app can do nothing w/o MS's permission

If you're referring to signed code... thats up to you. If you're referring
to running within a protected runtime, it's about safety. .NET is taking the
idea of user level code security seriously. Today's viruses rely on the fact
that the majority of user level code has free reign to do as it pleases with
your PC. Code security is long past overdue. Not to do with directly with
security, but managed code also plugs most of the holes by which viruses get
in the door in the first place.

But forget viruses. I dont' know about you, but in the old days I used to
download utilities and apps freely. Anymore, I'm weary of running anything
on my PC that's not signed and trusted. Theres spyware, malware, adware,
whoknowsware, etc... myself, I welcome a structured way to trust and grant
what an app can or can't do on my PC.

> - The advantage that the user needs to be a guru in order to run your app
(the
> horror of security settings etc.)

<shrug> xcopy deployment doesn't require a guru IMO... and I think setting
security for apps will soon be commonplace and a welcomed feature. I never
would have imagined that nearly every pc would have a personal firewall but
somehow mom and dad seem to be able to manage them. Application level
security is overdue.

> - The advantage that anyone can reverse-engineer your code and see the
source

No one can see your compiled source code. You *can* see the IL, which is
surprisingly understandable - and which I sometimes find useful. But that's
what obfuscators are for. Granted nothing is foolproof. If someone wants to
reverse engineer even the best obfuscated code, it's certainly possible. But
it's also very possible to reverse engineer compiled C code or assembly.
Nothing is completely irreversible.

I'm really not trying to be a .NET cheerleader, but it's just our
responsibility at Borland to pave the way for the type of development our
customers, in this case Windows developers, are going. To put great tools in
developers hands that will be relevant and timely so that they can build the
kinds of applications customers/end users will need on the platforms that
they will be using. We're in a platform shift today from Win32 to .NET that
is comparable to the shift from Win16 to Win32 in 1994. There will most
certainly be new Win32 development for years, but successful Windows
developers will be building on the .NET platform. No one has to choose to
make the jump to .NET, but if you want to develop real Windows apps in the
future and fully, or at least best, take advantage of all that will be
Windows, I'd recommend it. And I've yet to meet a developer who has made the
.NET jump that hasn't been happy and satisfied that they did so. Is it
perfect? What is? But it offers a heck of a lot, solves many issues that are
currently thorns in the sides of Windows developers, it works REALLY well,
and it's clearly where Microsoft is taking the OS - not to mention my
favorite: It feels like Delphi :o).

-michael

Relevant Pages

  • RE: just general questions about fbsd
    ... Im writing an article about FreeBSD and want to ask some few question: ... Do the FBSD developers work for free? ... If it was a Windows platform, I would certainly inform my MS sales rep ... and that the normal security mechanisms do not apply to. ...
    (freebsd-questions)
  • Re: Unix vs. Windows Security
    ... There are those who would argue that the act of installing Windows ... - The numerous security problems associated with IE, ... looking at what flexibility of skills the average system administrator ... To be trained to be a security expert for the platform? ...
    (comp.security.misc)
  • Re: Apple is Impatient
    ... >>> Also ignoring the FACT that a lot of people run Windows because ... > to *developers*, and whatever platform developers target, that is ... card-carrying MSDN subscriber. ...
    (comp.sys.mac.advocacy)
  • Re: Fed up with Apple platform upgrades
    ... There are major issues with Windows security and all of them can be easily ... It allows many software developers including ... Steve W ...
    (comp.publish.prepress)
  • Re: Hats off to long-time Mac OS developers...
    ... documentation for Windows and the API itself diverged so often that ... Really, for any given platform, the worst experiences I had came from ... Apple, in 1989, decided to treat its developers as a revenue source. ... Drove large numbers of developers away just as Windows was becoming a ...
    (comp.sys.mac.programmer.misc)