Why C# Is Not My Favorite Programming Language

http://www.curly-brace.com/favorite.html

by pankratiev • 15 years ago

18 20 15 years ago

jhack2• 15 years ago

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.

pankratiev• 15 years ago

And what language do you prefer?

jhack2• 15 years ago

I do mostly web development work, so lots of Javascript and PHP. I ported a project to Google App Engine a few months ago and I had a lot of fun working with Python, too. I enjoyed Python so much that I even made a couple of personal projects with it, including a command-line Twitter client.

With C#, I feel forced into strict OOP and it just doesn't give me that same level of enjoyment.

latch• 15 years ago

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.

frou_dh2• 15 years ago

Most of these boil down to "It's different from C++. I'm used to C++".

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>.

rottyguy2• 15 years ago

Just goes to show that anyone can write a book. The first two reasons:

1. Default Object Lifetime Is Non-Deterministic 2. Object Lifetime is Not Determined by Scope

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.

zeugma• 15 years ago

Maybe that what's the author wanted to pointed out: if you have garbage collection (at least the way it's implemented in C#/Java) you have to give away scope lifetime of object. This is annoying because you want determinism for some kind of resources (file, lock, ...) and then you have to manually clean them, which is what you wanted to avoid in the first place with garbage collection.

In C++, if you declare the object on the stack, the destructor will be called when the scope is closed. Which is very handy for e.g. lock.

The thing is, garbage collection could be use together with scope lifetime (aka RAII) just let the programmer choose which is best/more convenient for him given his resources.

zwieback• 15 years ago

I agree. I think the author does understand the difference between scope, object lifetime and manual/GC object management.

The article is clearly written for pogrammers coming from C++ to C#, which there are a lot of, including myself. I like both C++ and C# a lot but have to admit that managing object lifetime in C# is one of the things I really dislike. There's the suggestion that RAII is reasonable in C# but for me always ends up being a headache.

kkowalczyk• 15 years 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).

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• 15 years ago

Still, the example in p.1 with purportedly forgotten file closing feels wrong.

mullr• 15 years ago

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.

cdesmar• 15 years ago

So he brought up sealed classes and didn't think that was a point in itself?

Only problem I typically have is libraries that overuse sealed and final keywords.

peteri• 15 years ago

The locking bit on events is wrong certainly for C#v4 (see http://blogs.msdn.com/b/cburrows/archive/2010/03/30/events-g... and the other entries in the series) for why.

Also I've nearly always done the first pattern on Chris Burrows page, although Jon Skeet recommends differently on his multi-threading event page http://www.yoda.arachsys.com/csharp/threads/lockchoice.shtml which (I think but I must ask him) is really more about avoiding the lock(this).

tmitchel2• 15 years ago

How on earth did you find someone to publish your work.

Deestan2• 15 years ago

Skip past points 1. and 2. They are just embarrasing to read.

The rest of the points are valid for discussion.

nrkn• 15 years ago

Plenty of flaws and mistaken assumptions in the other points too.

Deestan2• 15 years ago

Yes, there are mistakes in the details, but the actual points are valid. Default comparison behaviour is error-prone, operator overloading is badly designed, and the subscriber-less events exceptions are a kludge.

tzs• 15 years ago

   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)

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.

frou_dh2• 15 years ago

The term 'destructor' alone feeds in to the C++ conflation. In C#, this syntax is more specifically sugar for a 'finalizer' if I'm not mistaken.

Why C# Is Not My Favorite Programming Language

Related Stories