4 ms·
The first 2 points shows such fundamental misunderstanding of garbage collection that it's hard to take this article seriously. Every garbage-collected languag
by kkowalczyk 15y ago
The first 2 points shows such fundamental misunderstanding of garbage collection that it's hard to take this article seriously.
Every 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).
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#.
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.
The rest is just a bunch of "I know better" opinions.
C# was actually designed but some of the best, thoughtful language designers (like Anders Hejlsberg http://en.wikipedia.org/wiki/Anders_Hejlsberg http://en.wikipedia.org/wiki/Anders_Hejlsberg).
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.
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.
- drdaeman 15y agoStill, the example in p.1 with purportedly forgotten file closing feels wrong.