The first 2 points shows such fundamental misunderstanding of garbage collection that it's hard to take this article seriously.<p><i></i>Every<i></i> garbage-collected language has this "problem". The "problem" (objects are reclaimed an unspecified time after they have been determined as unreachable by GC) is a fundamental property of garbage collection (at least the most frequently used, non-ref-counted GC).<p>It's also well accepted that when it comes to releasing resources other than memory, programmers should be doing it more explicitly and not rely on GC and that's why C# has using statement and IDispose interface. It's no worse than in non-GC languages where you have to do such manual management for everything and it applies to all GCed languages, not just C#.<p>He's complaining about C# crashing on broken code (where program used an unsafe operation to get at raw memory of the object without telling GC that the object cannot be reclaimed). C#, of course, is to blame, not the programmer who wrote broken code.<p>The rest is just a bunch of "I know better" opinions.<p>C# was actually designed but some of the best, thoughtful language designers (like Anders Hejlsberg <a href="http://en.wikipedia.org/wiki/Anders_Hejlsberg" rel="nofollow">http://en.wikipedia.org/wiki/Anders_Hejlsberg</a>).<p>I'm sure if they had a chance, they would fix a thing or two but it's exceedingly easy to spend a few minutes thinking about an issue, decide it's broken and broadcast one's beliefs in a blog post.<p>The hard part is thinking about trade offs in alternative designs, unintended consequences etc. I'm pretty sure C# designers had good reasons for most of the things a guy who blames language for crashing on broken code criticizes.
Most of these boil down to "It's different from C++. I'm used to C++".<p>Though I do agree that you shouldn't have to check whether an event has any subscribers before raising it. It's possible to DRY that out with an extension method on EventHandler/EventHandler<T>.
Just goes to show that anyone can write a book. The first two reasons:<p>1. Default Object Lifetime Is Non-Deterministic
2. Object Lifetime is Not Determined by Scope<p>For a GC based language? Seriously? Sorry, but this article should not be voted up. One wonders if it was done so to peddle the Author's book.
Some very valid criticisms and interesting observations. I personally think C# is too complicated for it’s own good and takes OOP to an unnecessary extreme, which is why I don't use it (or any .NET-based language, really) for anything other than rapid and simple GUI projects.
The locking bit on events is wrong certainly for C#v4 (see <a href="http://blogs.msdn.com/b/cburrows/archive/2010/03/30/events-get-a-little-overhaul-in-c-4-afterward-effective-events.aspx" rel="nofollow">http://blogs.msdn.com/b/cburrows/archive/2010/03/30/events-g...</a> and the other entries in the series) for why.<p>Also I've nearly always done the first pattern on Chris Burrows page, although Jon Skeet recommends differently on his multi-threading event page <a href="http://www.yoda.arachsys.com/csharp/threads/lockchoice.shtml" rel="nofollow">http://www.yoda.arachsys.com/csharp/threads/lockchoice.shtml</a> which (I think but I must ask him) is really more about avoiding the lock(this).
<p><pre><code> In most object-oriented languages, there is a
very specific time when an object constructor is
called (namely, when an object is instantiated) and
when its destructor is called (namely, when it falls
out of scope)
</code></pre>
Is that actually correct? From what I recall and from what I see after a bit of Googling, it would appear that most object oriented languages either don't even have destructors, or if they have they are called when the object is garbage collected, not when it goes out of scope.
So he brought up sealed classes and didn't think that was a point in itself?<p>Only problem I typically have is libraries that overuse sealed and final keywords.
The only really valid criticism is the one about event handlers, and that kind of makes sense if you consider symmetry with regular nullable references. "Languages shouldn't allow null references" is a more valid and interesting topic, but hat ground has been well covered.
I don't like it because I spend 25% more times making my code 25% harder to read and 25% harder to maintain, in order to make it testable and have it "properly" designed.