The Artima Developer Community
Sponsored Link

Weblogs Forum
What Are Your C# Pain Points, Really?

29 replies on 2 pages. Most recent reply: Dec 26, 2007 1:22 AM by Peter Kellner

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 29 replies on 2 pages [ 1 2 | » ]
Bill Venners

Posts: 2249
Nickname: bv
Registered: Jan, 2002

What Are Your C# Pain Points, Really? (View in Weblogs)
Posted: Mar 3, 2007 12:29 AM
Reply to this message Reply
Summary
For those of you who are programming in C#, what would you say are the biggest sources of pain, or at least discomfort, when using C#.
Advertisement
Each Friday for the past three weeks I've asked about the pain points of a particular programming language. So far I've asked about Java, Ruby, and Python. Today, I'd like to ask about C#. C# is in many ways similar to Java in design, but by no means the same language or environment. Since C# came after Java, its designer had the opportunity to learn from Java's problem areas. If you've been programming in C#, what would you say are your most significant pain points with the C# language and .NET environment?


Horia Coman

Posts: 1
Nickname: horia314
Registered: Mar, 2007

Re: What Are Your C# Pain Points, Really? Posted: Mar 3, 2007 3:24 AM
Reply to this message Reply
I always saw C# as a better language than C/C++ or Java for large projects. It had a lot of nice features coming from both of them (interfaces, operator overloading etc. just to name a few) while adding some interesting ones of it's own (properties, delegations). So my biggest pain wouldn't probably be with the language itself, but with the fact that it isn't open-sourced, GPLed or anything of that sort - it's tied to Microsoft.

adrian milliner

Posts: 13
Nickname: goron
Registered: Feb, 2007

Re: What Are Your C# Pain Points, Really? Posted: Mar 3, 2007 3:37 AM
Reply to this message Reply
Coming from Java, a few things bug me about C#:

* The convention of leading upper case letters for method names.

* Properties - I like to know from reading the code whether setting a property will have a side effect.... eg, hiding a.B=3 with public int B { set { b=value*2; }}
In Java it would be a.setB(3) so you know it's a method.

* Visual Studio...*shudder* Even with Resharper, it's only just bearable.

* No instance-inner classes - sometimes you want more than a single method (anon delegate).

* stack vs heap allocation of structs - useful feature, but the way it's implemented makes it hard to see what's going on just by looking at the code.

* Async IO uses threads.. surely one of the main reasons for async IO is to avoid using lots of threads for scalability reasons? Java was really hampered until NIO came along in 1.4. Maybe I'm missing something, but .NET doesn't seem to have the equivalent.

* Looks like enums have to be integer types - I like the way Java enums are property types and implement interfaces.

* no equiv of java.util.Set

* lots of misc other things, but nothing major.

adrian milliner

Posts: 13
Nickname: goron
Registered: Feb, 2007

Re: What Are Your C# Pain Points, Really? Posted: Mar 3, 2007 3:40 AM
Reply to this message Reply
> <snip> So my biggest pain
> wouldn't probably be with the language itself, but with
> the fact that it isn't open-sourced, GPLed or anything of
> that sort - it's tied to Microsoft.

C# is open, and Novel have an implementation with Mono.

Although I know what you mean. Microsoft's implementation is closed.

Michael Campbell

Posts: 5
Nickname: mcampbell
Registered: Sep, 2006

Re: What Are Your C# Pain Points, Really? Posted: Mar 3, 2007 12:14 PM
Reply to this message Reply
Much of what Adrian noted, above, but for me...

* Visual Studio. Did MS learn nothing from leading IDEs in other arenas?

* Leading upper case names

* Properties - good idea, but in practice they just feel odd and make me uncomfortable

* A style pain:
The
{
preponderance
}
of
{
whitespace
}
around
{
braces
}

Come on, 48 lines of text, and only 14 of code?



Ok, so not much of that is the language as such and I could use what I want and not have these irritations. But, if you're working in a .NET environment, you go with the community's standards.

Jay Wren

Posts: 2
Nickname: evarlast
Registered: Feb, 2006

Re: What Are Your C# Pain Points, Really? Posted: Mar 4, 2007 12:01 PM
Reply to this message Reply
I love the C# language.

My gripes are mostly about the BCL. While I do think the BCL as a whole is wonderfully coherent, certain things here and there do bother me.

List, IList, ICollection, Collection etc... these don't align with their more traditional definitions. It would be nicer if they corresponded to the collection classes in java a little bit more obviously.

Lack of a Hash, but 3.5 (orcas) is fixing this.

Already mentioned, but maybe in a slightly different angle is that of "microsoft owns it" vs. GPL. I am more concerned that MS keeps stomping over very excellent .NET open source projects. Half of LINQ really should be NHibernate. NDoc died and microsoft failed to replace it. NUnit should have just been adopted by MS, but instead there is MSTest garbage from Team Suite. And the Enterprise Application Library stuff is really just second rate garbage compared to Castle Project.

lewis zhou

Posts: 1
Nickname: lewisou
Registered: Feb, 2007

Re: What Are Your C# Pain Points, Really? Posted: Mar 4, 2007 10:03 PM
Reply to this message Reply
o~~~

Jeff Foster

Posts: 6
Nickname: jefffoster
Registered: Nov, 2004

Re: What Are Your C# Pain Points, Really? Posted: Mar 5, 2007 2:39 AM
Reply to this message Reply
> NDoc died and microsoft failed to replace it

What about http://blogs.msdn.com/sandcastle/ ?

chris donnan

Posts: 1
Nickname: chrisdrop
Registered: Mar, 2007

Re: What Are Your C# Pain Points, Really? Posted: Mar 5, 2007 12:20 PM
Reply to this message Reply
* Async IO uses threads.. surely one of the main reasons for async IO is to avoid using lots of threads for scalability reasons? Java was really hampered until NIO came along in 1.4. Maybe I'm missing something, but .NET doesn't seem to have the equivalent.

This is not true. In c# when you do things like BeginRead off of a stream, it uses async io 'completion ports'. The theadpool has some # of 'threads' for CPU bound operations - and many many many more for IO bound operations. There are certainly differences. It is more 'baked in' than the NIO stuff. NIO was an afterthought - albeit a good one. The async io was baked in from day 1 into .net.

-Chris

adrian milliner

Posts: 13
Nickname: goron
Registered: Feb, 2007

Re: What Are Your C# Pain Points, Really? Posted: Mar 5, 2007 1:39 PM
Reply to this message Reply
Yes, but the AsyncCallback still gets scheduled on a different thread to the one doing the BeginRead (or whatever), so if there's any shared data involved, you need do some kind of synchronisation between the threads.

With NIO, you don't; it stays in the same thread and it's up to you to use a thread pool (or whatever) to service the data.

Jeff Ratcliff

Posts: 242
Nickname: jr1
Registered: Feb, 2006

Re: What Are Your C# Pain Points, Really? Posted: Mar 5, 2007 6:35 PM
Reply to this message Reply
> Yes, but the AsyncCallback still gets scheduled on a
> different thread to the one doing the BeginRead (or
> whatever), so if there's any shared data involved, you
> need do some kind of synchronisation between the threads.
>
> With NIO, you don't; it stays in the same thread and it's
> up to you to use a thread pool (or whatever) to service
> the data.

I don't know much about NIO, but your description sounds like the original thread can't service the data. Is that right?

In the case of .NET's Asynchronous Programming Model there are three options for rendezvous:

1) Wait-Until-Done which blocks the calling thread until the I/O operation is complete when EndRead is called. This is only useful if you have work that can be done between BeginRead and EndRead calls. Your code uses only 1 thread.

2) Polling, where you check for completion on periodic basis. Probably the only advantage to this method is its simplicity since no explicit synchronization is required to check for completion. As in #1, your code uses only 1 thread.

3) Method callback. This is the most flexible option. Typically you'd perform whatever processing is required in the callback method, but since the callback method is called by a different thread you'd have to use sync techniques if the main thread needed to manipulate the data as well.

What technique(s) does NIO use?

Matt Gerrans

Posts: 1153
Nickname: matt
Registered: Feb, 2002

Re: What Are Your C# Pain Points, Really? Posted: Mar 5, 2007 7:16 PM
Reply to this message Reply
What in the world are you talking about? None of these have anything to do with the C# language. They are mostly about lack of aesthetic sensibilities arising from Java coding style indoctrination.

I like leading uppercase names just fine and was always annoyed by Java's inconsistency on that.

Properties rock. They are the one thing I loved most about Delphi and even Borland C++ Builder (despite the pain of creating compiler-specific code).

Python solves the curly problem correctly, but if a language must have them (to avoid scaring all the programming languages neo-luddites with something too revolutionary), then lined-up curlies are the way to go. It is much easier to read and readability is what's important. I do dislike use of curlies where they aren't needed (as well as the inane justifications for the same).

The convention of putting "I" in front of interfaces is pretty annoying, though.

adrian milliner

Posts: 13
Nickname: goron
Registered: Feb, 2007

Re: What Are Your C# Pain Points, Really? Posted: Mar 6, 2007 2:34 AM
Reply to this message Reply
On the style point and readability:

With Java (standard style), you know by looking at it whether an identifier is a package path, type (interface, class), a method call, property accessor/setter or variable name.

I like the consistency.

With C# (standard style), things are a bit mixed up. Namespaces, types, methods and properties tend to all start with an upper case letter. Accessors/getters may be hidden by a property. Interfaces start with an I, which does help identify-ability.

Of course, a good IDE will show you all these in different styles and colours too, but VS2005 (shudder) doesn't. Maybe the new VS, but I haven't tried it.

P H

Posts: 1
Nickname: peterchen
Registered: Mar, 2007

Re: What Are Your C# Pain Points, Really? Posted: Mar 6, 2007 11:40 AM
Reply to this message Reply
My gripes:

Rapidly evolving language - currently, you can't see where it will stop.
I am all for the new C# features (lambda, Linq), but if your hire can't deal with it, s/he can't maintain the code.

When interop with Win32 / COM isn't main-road-paved, it's ugly and complex.

Implementing Disposable pattern is a pain.

Restrictions on Generics parameters are to rough.

The enum name in front of the enum value :)

Searching for memory leaks in a garbage collected environment :X

Other than that, C# rocks!

Properties:
Adrian, noone stops you in any language from writing

setB(int b) { this.c = 12; }

meaning: It is the job of the programmer defining the interface whether or not the interface actually does what the name suggests. Properties should be used only where the access behaves like a property (from top of my head an O(0) operation that has only the 'obvious' side effect on public state). Everything that doesn't behave like a property should be implemented as a method.
The possibility to calculate values on the fly or create them on demand (for getters), to validate input fire change notifiations, cache invalidation etc. while still keeping the public appearance of a property works very very smooth.

I understand that you lose a visual cue (or rather, the meaning of the cue has changed subtly), and getting used to that is hard. But it allows proper encapsulation of fields while keeping the simplicity of access of sloppy public members.

On Visual Studio: give it another version and a service pack...

Mumtaz Shah

Posts: 10
Nickname: mumtaz
Registered: Feb, 2006

Re: What Are Your C# Pain Points, Really? Posted: Mar 6, 2007 4:46 PM
Reply to this message Reply
Growing, rather than Sliding, the spectrum of abstraction ( as put by Heilsberg ) seems to be working well. It is systematically and consciously removing major pain points WITHOUT introducing new ones.

C# is a darling....MMMMMOOOOOOAAAAAAAHHHH...;)

Flat View: This topic has 29 replies on 2 pages [ 1  2 | » ]
Topic: What Are Your C# Pain Points, Really? Previous Topic   Next Topic Topic: Extension Methods and Chained Invocations


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us