Fog Creek Software
Discussion Board




My views on .NET

Hello.

I disagree with Joel's comments protraying .NET as "one of the most brilliant and productive development environments ever created", designed by the "world's best language designer".

For me, C# is not a creative imitation of Java that fixes its gripes. Instead, it inherits the most important of them.

Like Java, C# assumes that the most expensive resource is memory, and thus provides you with a conservative garbage collector. Their bytecodes make it difficult to implement it in other way. There are two consequences. One is memory comsumption. For conservative garbage collection to work
optimally, a large heap is needed. It is for this reason why
Java and C# programs take so much memory.

More important, one never knows when an object is going to be destroyed. This is important for objects that hold resources such as file handles or database conexions. Thus in Java and C#, many objects provide methods Close() and Dispose() that
release system resources. It is not so useful that memory
is managed automatically but other resources must be
managed by hand. And it is IHMO a regression from C++
where with the help of smart pointers all resources can be
mantained by hand.

Prior art, such as the DIS virtual machine of Inferno were IHMO
better designed.

That said, C# has a well designed API (like Java), with a user interface consistent with the system (unlike Java).

I must agree with Rob Pike that we are having too much hype with very little real innovation (see the paper "Systems Software Research is Irrelevant", http://cm.bell-labs.com/who/rob/utah2000.pdf )

Ramón García Fernández
Friday, April 19, 2002

Most people will find the productivity gains from .NET not only come from not having to track down memory leaks (perhaps the most pervasive and annoying bugs), but also because the API is consistent and well designed (well, mostly... don't get me started on ADO.net), and because the development environment is very helpful. C# is just a bit player in the whole thing, and you can reap these benefits without ever touching C#.

Brad Wilson
Friday, April 19, 2002

Hmmm... I'd be inclined to disagree with you on the importance of memory requirements. Sure, Java / .NET is a bit of a hog in relation to hand crafter C++ code, but what about the gains in productivity, ease of coding etc? Joels arguments on bloatware and disk space could easily be adapted to memory requirements.

One thing I love about the VM approach is the managed code aspect. How many conventional programs crash out all over the place (hello Netscape 4)  or leak memory? Taking that responsiblity of the programmer is a good thing imo. Certainly when you take into account the amount of buffer-oriented attacks on the Microsoft platform.

I love the C# / Java approach and certainly wouldn't like to go back to the malloc () days...

Derek
Friday, April 19, 2002

Please, not another dissertation on the merits deterministic finalization.  Please go read the 18 month long thread on this topic over at at the DOTNET list hosted at http://discuss.develop.com.

This debate is over, and managed runtime environments with GC functionality have won out over the system resource and optimization related arguments.  Java, C#, or other high level modern languages are not designed with system resource utilization and optimization as their primary objectives, therefore these designs should not be considered to be flawed.  The reason that many people emphasize the "flaws" is that the perceived benefits of code portability across platforms has yet to be truly realized.  With the Mono project and a number of aggressive .NET projects taking place on other platforms, I suspect that we're going to see some real results in the near future.  Java has made some traction here as well, but the results have consistently fallen short of industry/community expectations.

Also, I agree with Brad's assessment on the benefits of the base system classes provided with the .NET Framework.  Therein lies the real value for enhancing the productivity of developers.

Randy Holloway
Friday, April 19, 2002

In my opinion, C++ is sufficient to fix (hide and care for automatically) all of your usual memory-related problems ... using not only smart pointers, but also for example std::string (no more buffer overflows) ... so Java and C# may be better than C, but better than C++? I don't see how non-deterministic (garbage-collected) memory management isn't a problem for server-side processes, even for soft real-time ones. Admittedly, Microsoft's C++ GUI framework takes some getting used to.

Christopher Wells
Friday, April 19, 2002

Not too long ago, I spent about three weeks tracking down a reference-counting bug in some C++ code we were working on.

That's THREE WEEKS of doing nothing but chasing a single memory management bug.

And yes, we used smart pointers everywhere. We did everything you're supposed to do. And still we had the bug.

The reason - just because you know what you're doing, doesn't mean your library vendor does. Code doesn't exist in a vacuum anymore. Anything that makes it easier for everyone to do the right thing is good.

Bring on the GC! PLEASE!

Chris Tavares
Friday, April 19, 2002

Some clarifications.

Even if taking a lot of disk space is irrelevant with modern hard drives, memory requirements are not so irrelevant (rembember OS/2?) and start up time is very relevant.

Ramón García Fernández
Friday, April 19, 2002

> Anything that makes it easier for everyone to do the right thing is good.

Then again, with C++ we can write (have written) our own little smart pointer class (because std::auto_ptr doesn't do quite what we want). We have a choice of STL vendor; you can even buy a 3rd-party heap manager ... *and* we have more deterministic (non-GC) memory management. And still we have problems. Yet, our having more control may make it possible (let alone easier) to 'do the right thing'. At least MS have instrumented (perfmon) the CLR, but how much good does that do you if you can't change the CLR?

Christopher Wells
Friday, April 19, 2002

Randy Holloway,

> The reason that many people emphasize the "flaws" is that  > the perceived benefits of code portability across platforms
> has yet to be truly realized.

You can have both.

The DIS virtual machine, part of Inferno operating system,
(developed by Rob Pike, one of the smartest system designers) implements garbage collection by reference counting and thus provides deterministic finalization.

If you tell me that portability might outweigh other benefits, that is sensible, as a reason for we using Java or .NET. However, there is not excuse for multibillion companies
such as Microsoft or Sun doing the wrong thing.

Ramon

Ramón García Fernández
Friday, April 19, 2002

I admit a lack of knowledge, but I have a question: why can't C# and Java let me manage my own memory? Seriously, sure I may screw up once in a while, but that's why there's the garbage collection there. But if Java had destructors on objects and a delete keyword, I could make it use less memory by destroying things myself when it's not needed. If necessary, the delete keyword could do a check to ensure that it wasn't referenced anywhere. What's the big deal about this?

Mike Swieton
Friday, April 19, 2002

Impossible debate.  I had just dealt last week with some former C++ programmers who had all sorts of dubious, strange schemes to deal with a Java memleak. 

No matter how safe you make a language, there will always be gotchas.  You can never remove all the dead ends predicted by computational theory.  People with good coding styles, who have dealt with constantly thinking of memory, will find GC a wonderful freedom.  Novices will shoot their legs off, and have no idea of the simple ways to deal with their problems.

Always, you will program in some subset of the power of a language.

kaskian
Friday, April 19, 2002

Ladies and gentleman, if GC solves most of your time consuming bugs, then you are either not doing anything interesting, or using the wrong tools.

Memory GC is only half the story, and Java (and I believe C# as well) doesn't let you GC on any other resource in any reasonable way. Don't know about C#, but Java had to introduce weak references exactly for this reason, and ... guess what? They're about as painful to use as managing everything yourself.

The right tool - Purify, BoundChecker, ElectricFence, Valgrind (soon), MemPatrol, gcc -finstrument-functions/memory etc. can more or less solve all of these problems well within the C/C++/Fortran/{$favourite_old_style_language} domain. Plus, there IS a conservative GC (Boehm) that works well for C, and it's a lot more configurable than any language mandated one (allows calling on C++ destructors in most cases, for example, or "C" destructors if you implemented the vtbl yourself).

This argument is mostly religious - good GC has only been available since 1959, together with metaprogramming, consistent system interfaces, etc. Yes, that's 1959 - the original Lisp implementation. Together with Lisp s-expressions which, although simpler to parse are nearly compatible with XML and offer signficiantly more power. There is little innovation (if at all) in modern environments. Yet, whenever another aspect of LISP is added to any other language it recieves the glorified treatment of innovation.

There are non religious arguments which can be summarized more or less by (origin of quote unknown):
"C programmers know memory management is too important to leave it at the hand of the language; LISP programmers know memory management is too important to leave it at the hand of the individual programmer". Both, of course are right in their respective circumstances.

Ori Berger
Friday, April 19, 2002

W.r.t. GC in DIS, when I looked at this several
years ago there was little information because
of a patent pending on the cycle breaker.
Were the details ever published?
I can't find them.

Tom Cargill
Saturday, April 20, 2002

Ramon,

<quote>
You can have both.

The DIS virtual machine, part of Inferno operating system,
(developed by Rob Pike, one of the smartest system designers) implements garbage collection by reference counting and thus provides deterministic finalization.

</quote>

<quote>

However, there is not excuse for multibillion companies
such as Microsoft or Sun doing the wrong thing.

</quote>

Your explanation of Inferno doesn't sound that different to how COM works. Describing the .NET model as 'the wrong thing' may be a little harsh - have you even read any of the discussions about why it was designed that way (I mean, MS obviously understands deterministic finalisation based on their COM design)? Might be worthwhile checking out: http://discuss.develop.com ...

Seeya
Matthew

Matthew John Wills
Sunday, April 21, 2002

*  Recent Topics

*  Fog Creek Home