What are the bad features of C#?
-
What are, in your opinion, the bad features of C#?
The quick red ProgramFOX jumps right over the
Lazy<Dog>. -
What are, in your opinion, the bad features of C#?
The quick red ProgramFOX jumps right over the
Lazy<Dog>.C# or .NET in general? If it was .NET, one thing I'd pick up on is the fact that generics are compile time constraints - I'd love to be able to have them as runtime constraints (a-la C++ templates). Given that there's support for dynamic in the language, I'd have thought they'd be able to extend to this as well.
I was brought up to respect my elders. I don't respect many people nowadays.
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier -
What are, in your opinion, the bad features of C#?
The quick red ProgramFOX jumps right over the
Lazy<Dog>. -
C# or .NET in general? If it was .NET, one thing I'd pick up on is the fact that generics are compile time constraints - I'd love to be able to have them as runtime constraints (a-la C++ templates). Given that there's support for dynamic in the language, I'd have thought they'd be able to extend to this as well.
I was brought up to respect my elders. I don't respect many people nowadays.
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easierPete O'Hanlon wrote:
C# or .NET in general?
C# (the discussion above my discussion is about the annoying aspects of .NET development, so if you've an annoying aspect of .NET, then you can reply to the discussion above my discussion).
The quick red ProgramFOX jumps right over the
Lazy<Dog>. -
What are, in your opinion, the bad features of C#?
The quick red ProgramFOX jumps right over the
Lazy<Dog>.Small, but annoying: public constructors in abstract classes. The creation of abstract class is forbidden, why do they allow public keyword for the constructor of abstract class? It confuses the developer who reads. I`d require
protected/privatekeyword only. -
Pete O'Hanlon wrote:
C# or .NET in general?
C# (the discussion above my discussion is about the annoying aspects of .NET development, so if you've an annoying aspect of .NET, then you can reply to the discussion above my discussion).
The quick red ProgramFOX jumps right over the
Lazy<Dog>.Sorry to hijack your thread, but I couldn't resist. :) Good question though. Really makes you think about how much you've been indoctrinated. It's kind of like asking a person, "what's wrong with your government?" :thumbsup:
-
C# or .NET in general? If it was .NET, one thing I'd pick up on is the fact that generics are compile time constraints - I'd love to be able to have them as runtime constraints (a-la C++ templates). Given that there's support for dynamic in the language, I'd have thought they'd be able to extend to this as well.
I was brought up to respect my elders. I don't respect many people nowadays.
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easierI'm not sure you mean 'runtime' here, if you're comparing with C++. What C++ does is check, at compile time, that the methods (or system functions e.g. +) you're trying to call are defined on the class in question. That's very similar to the where constraints in C#, except it applies to operations not to interfaces. I agree that an extension to check that (for simple operations at least; I don't like the 'method signature is interface' aspect of doing it on function calls) would be good, but it could be done at compile time when you use the generic method.
-
What are, in your opinion, the bad features of C#?
The quick red ProgramFOX jumps right over the
Lazy<Dog>.It's a scalar language, like the rest of the C family, so it's really ugly writing code that is trying to operate on array data. For example, let's say you have two lists of numbers, and you want to add them up. Why not:
int[] a = { 1, 4, 6, 8, 21}, b = {2, 1, -3, 5, 9};
int[] c = a + b;That really shouldn't require a loop construct and explicit serial array walking in 2013! Similarly, there should be some construct for
List<object> myList = (something);
List<string> textReps = myList.¨ToString();(I've used the APL 'each' symbol there but the actual syntax isn't important. In pure ASCII you could do e.g. myList[].ToString() instead) The ForEach IEnumerable extension almost does this, but you should be able to call it on arrays too, and it should be a language feature. Both of these would also provide really easy hooks for the CLR to perform parallelisation when it sees that it's appropriate.
-
I'm not sure you mean 'runtime' here, if you're comparing with C++. What C++ does is check, at compile time, that the methods (or system functions e.g. +) you're trying to call are defined on the class in question. That's very similar to the where constraints in C#, except it applies to operations not to interfaces. I agree that an extension to check that (for simple operations at least; I don't like the 'method signature is interface' aspect of doing it on function calls) would be good, but it could be done at compile time when you use the generic method.
I've deliberately been loose with my terminology here to show that there is a difference in the behaviour between templates and generics. What I would like to see is the ability to have generics specialisation put in place.
I was brought up to respect my elders. I don't respect many people nowadays.
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier -
Small, but annoying: public constructors in abstract classes. The creation of abstract class is forbidden, why do they allow public keyword for the constructor of abstract class? It confuses the developer who reads. I`d require
protected/privatekeyword only.Reharper picks that up
-
It's a scalar language, like the rest of the C family, so it's really ugly writing code that is trying to operate on array data. For example, let's say you have two lists of numbers, and you want to add them up. Why not:
int[] a = { 1, 4, 6, 8, 21}, b = {2, 1, -3, 5, 9};
int[] c = a + b;That really shouldn't require a loop construct and explicit serial array walking in 2013! Similarly, there should be some construct for
List<object> myList = (something);
List<string> textReps = myList.¨ToString();(I've used the APL 'each' symbol there but the actual syntax isn't important. In pure ASCII you could do e.g. myList[].ToString() instead) The ForEach IEnumerable extension almost does this, but you should be able to call it on arrays too, and it should be a language feature. Both of these would also provide really easy hooks for the CLR to perform parallelisation when it sees that it's appropriate.
For the first, C# now supports initializer lists. EDIT: I misunderstood your first item. However, LINQ should allow this to be pretty minimal. For the second, you can use LINQ to perform mapping with minimal code.
-
It's a scalar language, like the rest of the C family, so it's really ugly writing code that is trying to operate on array data. For example, let's say you have two lists of numbers, and you want to add them up. Why not:
int[] a = { 1, 4, 6, 8, 21}, b = {2, 1, -3, 5, 9};
int[] c = a + b;That really shouldn't require a loop construct and explicit serial array walking in 2013! Similarly, there should be some construct for
List<object> myList = (something);
List<string> textReps = myList.¨ToString();(I've used the APL 'each' symbol there but the actual syntax isn't important. In pure ASCII you could do e.g. myList[].ToString() instead) The ForEach IEnumerable extension almost does this, but you should be able to call it on arrays too, and it should be a language feature. Both of these would also provide really easy hooks for the CLR to perform parallelisation when it sees that it's appropriate.
How about these:
int[] a = { 1, 2, 3 }, b = { 4, 5, 6 };
int[] c = a.Select((x, index) => x + b[index]).ToArray();List<object> myList = new List<object>() { 1, "dragon", new Object() };
List<string> textReps = myList.Select((x) => x.ToString()).ToList(); -
What are, in your opinion, the bad features of C#?
The quick red ProgramFOX jumps right over the
Lazy<Dog>.1. Unnecessary loss of control. I'm a control freak like most good programmers. Garabage Collection is fine but I must be able to make it happen when I require it and prevent it happening when I require 100% of the available performance. 2. Loss of the compilation unit concept. Removing the separation between header and implementation files is often seen as a good thing but it has non obvious negative effects. I'm no longer able to specify a pure interface for the purposes of export or interop (within the language) which has an implementation but the declaration of which can be used without access to or depenedency on the implementation. The separation of .h and .cpp files was not a mistake, oversight, shortcut or side effect of some other inadequacy. It was a deliberate and sensible idea that certain people at Microsoft never really understood. 3. Loss of dependency control. Removing the #include concept, also related to the loss of compilation units, means I'll never really know precisely what the compiler does and doesn't reference when compiling a class in exact files access terms. Like many such things this is OK if it's right but a nightmare if I have 7 versions of Runtime library headers installed and I can't tell which one it is getting its definitions from. 4. The additional learning requirement of endless extra badly specified and poorly documented 'secondary' languages. Most of the mitigation Microsoft have put in for items 2 and 3 has lead to the addition of yet more different formats of files to a project. App configs, manifests, non compiled resources &c. Every one of these new files is in what is effectively a new language although it is seldom recognised as such. Each and every one requires additional tools and or more knowledge to use it properly. Anything which increases the number of languages, formats, conventions or rules I need to know in order to do my job makes it harder not easier. Every time I have to edit or otherwise interact with one of these kludges I have to to stop thinking in C++ and switch to something else, usually some hacked subset of XML. The switching cost in time, concentration and quality of perception is high and completely unaccounted for by those who promote more and more such sub-domain specific languages. 5. Forcing me to use a JIT compiler when Native compilation should and could be available is another unacceptable loss of control. 6. Not strictly a C# issue, however providing a class library (the CLR) but forcing me to learn and use a new language
-
What are, in your opinion, the bad features of C#?
The quick red ProgramFOX jumps right over the
Lazy<Dog>.Lack of support for C++ style 'const' (but this is a .NET limitation) and the inability to create generics for maths, i.e. class Matrix { } you can't make a matrix template for ints/floats/complex numbers because you cannot say in a template definition something like: class Matrix where T : *,+,-,/ So mathematical templates are darn near impossible to make. But other than that C# is pretty darn good. also 'dynamic' types are a nice time saver syntactically, but not very sensible in a static language.
My Blog: www.dwmkerr.com My Charity: Children's Homes Nepal
-
What are, in your opinion, the bad features of C#?
The quick red ProgramFOX jumps right over the
Lazy<Dog>. -
How about these:
int[] a = { 1, 2, 3 }, b = { 4, 5, 6 };
int[] c = a.Select((x, index) => x + b[index]).ToArray();List<object> myList = new List<object>() { 1, "dragon", new Object() };
List<string> textReps = myList.Select((x) => x.ToString()).ToList(); -
What are, in your opinion, the bad features of C#?
The quick red ProgramFOX jumps right over the
Lazy<Dog>.Not being able to convert an old project in order to recompile against later frameworks, if you didn't get the version of VS that did the conversion. VS2003 will convert 2001 projects. VS2005 won't. It's a similar situation converting Visual C/C++ 6 projects. in VS2005 it can't be done unless you happen to have VS2003 lying around to do an intermediate conversion. I suppose the fear factor will keep the money rolling in for Microsoft when developers get wind of these issues. A syntax shortcoming recently discussed on CP.
break <label>;
"It's true that hard work never killed anyone. But I figure, why take the chance." - Ronald Reagan That's what machines are for. Got a problem? Sleep on it.
-
They are nice (I love Linq extension methods), but still not as nice as if the language did it natively.
BobJanova wrote:
not as nice as if the language did it natively
That's the second time somebody has said that recently. I don't understand why it matters if the language does it natively. The language supports LINQ, and LINQ does it, so what's the problem with that? If you really wanted, you could even extend LINQ (e.g.,
myList.AllToString()), overload the plus operator (e.g.,new MyArray(a) + new MyArray(b)), or create an extension method and overloaded operator (e.g.,a.Extras() + b.Extras()). -
What are, in your opinion, the bad features of C#?
The quick red ProgramFOX jumps right over the
Lazy<Dog>. -
It's a scalar language, like the rest of the C family, so it's really ugly writing code that is trying to operate on array data. For example, let's say you have two lists of numbers, and you want to add them up. Why not:
int[] a = { 1, 4, 6, 8, 21}, b = {2, 1, -3, 5, 9};
int[] c = a + b;That really shouldn't require a loop construct and explicit serial array walking in 2013! Similarly, there should be some construct for
List<object> myList = (something);
List<string> textReps = myList.¨ToString();(I've used the APL 'each' symbol there but the actual syntax isn't important. In pure ASCII you could do e.g. myList[].ToString() instead) The ForEach IEnumerable extension almost does this, but you should be able to call it on arrays too, and it should be a language feature. Both of these would also provide really easy hooks for the CLR to perform parallelisation when it sees that it's appropriate.
In your first example, it's not immediately obvious what you're expecting to happen. Should the output be:
{ 1, 4, 6, 8, 21, 2, 1, -3, 5, 9 }
Or:
{ 3, 5, 3, 13, 30 }
If it's the second option, what should happen if the operands have different lengths? Different types? Different ranks? Your solution has a much higher cognitive overhead than simply:
int[] c = a.Zip(b, (x, y) => x + y).ToArray();
For your second example, you could use:
List<string> textReps = myList.ConvertAll(Convert.ToString);
It even works with arrays:
string[] testReps = Array.ConvertAll(myArray, Convert.ToString);
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
