|
Meh. I've seen worse languages than C#, but there is really nothing exciting about it. Good enough for developing boring enterprise applications, I guess.
|
|
|
|
|
... but that is 95% of what we do, even if you work for a 'clever stuff' company.
|
|
|
|
|
The thing I dislike most about C# are the users who are like Apple fan-boys. C# is amazing, perfect even, much better than anything else and especially much better than VB!
Guess what, C# has its flaws. VB has its good points. As most languages have their strong and weak points.
I like VB, I like C# a bit less, but in the end it comes down to picking the right language for the right solution.
It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
}
|
|
|
|
|
Needs a coffeescript version to loose all the irritanting redundant brackets! Otherwise OK
|
|
|
|
|
I worked with C++ for almost 6 years. I was in love with C++. I was reading all Stroustrup to Herb Sutter stuff religiously and was planning to start with James Coplien's book. Bu then suddenly things changed. I got a chance to work with C#.
My First experience was "Wow, its reminds me of the syntax of java only million times better, It carry forward the C++ good stuff too. and on top of all the vast framework and awesome IDE makes working so cool."
Now after working in C# for 2 years, I think. C# is awesome. there is no thing like C#. C# makes it possible to be more productive. It makes me keep my work life balance(I am getting emotional now). and the constant improvement in language (C# 4.5) makes me feel like never going back.
SO for me there are only two languages: un-managed world of beautiful C++ and managed world of awesome and powerful C#. rest all are like #@#@#@# (find a suitable 4 letter word)
|
|
|
|
|
The last time I did any programming for money, it was developing database applications in Paradox Application Language and Pascal. When that ended, I tried in vain for years to learn C++ and MFC; I could never get past a conceptual framework for any app, and couldn't make the transition from procedural programming to event-driven programs hosted on modern platforms. C# is the first sensible thing Microsoft has done, for me, at least. I'm still just a hobbyist, but with the C# language, and the .Net Framework, I finally have tools that are understandable and usable. I completely understand your enthusiasm, though I envy your skill in C++.
Will Rogers never met me.
|
|
|
|
|
I'd like to split that in two parts... I love C# and I love .NET Framework.
- I love C# because it is terse yet elegant, like C, and - in contrast with C++ - has very little syntactic weirdness going on to support object-orientation. I especially like recent additions such as generics and lambda expressions, that while introducing some syntactic weirdness does so in a very careful and minimalistic way.
- I love the .NET Framework for all the stuff I don't have to do. My first project in C# was an industrial control system using multi-threading, serial ports and TCP services. I was quite shocked when I realized I didn't have to implement any of that stuff myself. When I was about to implement an event queue to pass machine events between threads, I found the Queue class and just had to laugh...
As for the VB:ers commenting here... you have the .NET Framework as well, and what you write will be compiled into the same MSIL or machine code. And what is beautiful in a language is purely a matter of taste. So I wouldn't even think of looking down on you. After all, I've spent over 10 years in earlier versions of VB, and although I come from C and prefer strong typing, it isn't THAT bad (the old versions, that is - I have spent very little time in VB.NET, but from what I understand, it is nowadays as strongly typed as you want it to be - making it better, in my opinion).
And... I'm VERY jealous of one thing. Using C# in ASP.NET (or Razor), you're in a method body, and can't write other methods or functions. I know, views should be lightweight, but I prefer writing a four-line method over repeating the code ten times, and sometimes the task is too trivial and implementation-dependent that it doesn't belong in the controller. In VB, you can do that...
If ony I could stand the syntax... but again, that's a matter of taste...
Peter the small turnip
(1) It Has To Work. --RFC 1925[^]
|
|
|
|
|
There are a few ways to get around Razor methods - partials, @helper sections, static helper classes, or extension methods - depending on what exactly you're trying to do.
One thing I strongly dislike about Razor is the lack of documentation. MSDN works great navigating the C# class library, but the Razor reference just isn't there yet. I have to find method and syntax docs on offsite personal blogs.
There are other things about Razor that cause me daily pain, but I don't want to get too far off topic here. 
|
|
|
|
|
I'm totally with you on all that...
Peter the small turnip
(1) It Has To Work. --RFC 1925[^]
|
|
|
|
|
C# is okay, the framework makes a large number of things quite easy but it does have it's flaws like most other things. Outside of work I don't tend to use it, instead preferring things like C++, Go, Python and I'm quite getting into Node.js now. I have done some C# in my own time using Mono though.
|
|
|
|
|
To answer the original question:
Love:
- Clean, very readable and minimalistic syntax - C with object orientation the way it should have been done in C++ (backwards compatibility made C++ extremely ugly and cluttered in my opinion).
- The type system in general. Admittedly a .NET feature, but integrates nicely with C#.
- Reflection, generics, namespaces, lambdas and a lot of other stuff.
- The ability to perform like C++ using "unsafe" and "unchecked" blocks, and possibly ngen when needed (almost never happens, but nice to know its there).
Hate:
- Inability to write methods in methods. The original docs say "we don't compile code onto the stack", which is ridiculous. It's a matter of scope and visibility, not where it gets compiled (of course not the stack). I don't want to clutter class namespace with small helpers only used in one method - presumably using local variables.
- Inability to declare variables outside of getter and setter blocks in properties. I don't want shadow members in class namespace - too easy to inadvertently use the shadow member instead of the property. Those variables would work exactly like class members but would be invisible to the rest of the class. Maybe with a special keyword to make it clear that they aren't on the stack, but persist with the instance (or forever, if the property is static).
Peter the small turnip
(1) It Has To Work. --RFC 1925[^]
|
|
|
|
|
PeterTheSwede wrote: - Inability to write methods in methods. The original docs say "we don't compile code onto the stack", which is ridiculous. It's a matter of scope and visibility, not where it gets compiled (of course not the stack). I don't want to clutter class namespace with small helpers only used in one method - presumably using local variables.
Lambdas might be useful here?
|
|
|
|
|
Indeed - it's my favourite workaround...
Peter the small turnip
(1) It Has To Work. --RFC 1925[^]
|
|
|
|
|
Man, I love LINQ!
In VB its ugly, but in C# its beautiful! 
|
|
|
|
|
Ridiculous C# still has no virtual static methods. Even .NET has no such capability, what's suxx.
C# cannot return multiple values from method.
C# has very limited metaprogramming, it's a trend of the next decade.
C#'s interfaces cannot be partly implemented inside themselves, even if method access no any fields.
C# has no slices, killer feature of the D language.
C# has no 'with' operator which reduces insignificant code.
C# has ugly type cast syntax, which you have to use everywhere.
In C# function cannot be overriden unless it's marked as virtual.
LINQ syntax is also ugly.
'Switch' operator is the same primitive like you write on C in 70th! Seems, MS monkeys are happy with it.
This list is a way far from completion, so sometime I think to leave this ridiculous student homework like ".NET" and use something more modern like 'D'.
|
|
|
|
|
Thornik wrote: Ridiculous C# still has no virtual static methods. Even .NET has no such
capability, what's suxx.
I'm positive that I wouldn't call that "ridiculous". I'm not even sure I'd call it a shortcoming. I'll admit though, that I can't think of any problem I've ever had for which this would have been a solution.
Thornik wrote: C# cannot return multiple values from method.
Having worked with Perl, I don't see this as a particular disadvantage, either. Retrun a struct; you'll get roughly the same effect.
Thornik wrote: C# has very limited metaprogramming, it's a trend of the next decade.
Another "shortcoming" that has never affected my ability to do whatever I want in the language. However, I'm unlikely to be programming when the next decade rolls around in 2021, so I guess I somewhat non-chalant about this one...
Thornik wrote: C#'s interfaces cannot be partly implemented inside themselves, even if method access no any fields.
That is rather the point, isn't it? It's an interface, not an implmentation. If you want a partial implementation, use an abstract class.
Thornik wrote: C# has no slices, killer feature of the D language. C# has no 'with' operator which reduces insignificant code. OK, I'll give you those.
Thornik wrote: C# has ugly type cast syntax, which you have to use everywhere.
No uglier than any other language I've ever worked with, though, and quite a bit simpler and obvious than some. Try it in Ada sometime.
Thornik wrote: In C# function cannot be overriden unless it's marked as virtual.
Not quite true. The "new" keyword will accomplish much the same task, albeit in a manner not quite identical.
Thornik wrote: LINQ syntax is also ugly.
Beauty is in the eye of the beholder. I love the LINQ syntax.
Thornik wrote: 'Switch' operator is the same primitive like you write on C in 70th! Seems, MS monkeys are happy with it.
I have to admit, I don't have much of a problem with it, either, other than the required "break" statement. Never could figure that one out.
Thornik wrote: This list is a way far from completion, so sometime I think to leave this ridiculous student homework like ".NET" and use something more modern like 'D'. Well, I never could understand this type of attitude. If you don't want to use a language, don't. If you're constrained to do so by someone else, try to change their mind. If you can't change their mind, either accept it, or move on.
Currently reading: "The Prince", by Nicolo Machiavelli
|
|
|
|
|
What do programming languages and breakfast cereals have in common?
Answer: The amount of sugar is inversely proportional to how well informed the consumer is.
|
|
|
|
|
The only thing I'd change would be to make objects and strings not nullable.
int i1 = 5;
int i2? = null;
String s1 = '';
String s1? = null;
Button b1 = new Button();
Button? b1 = null;
|
|
|
|
|
I'll never regret changing our default language from VB to C#!
Love the syntax.
Minor grudge: When looking at a pile of '}' having to add an 'else' it's difficult to navigate to the right one.
Really hate: It's Case Sensitive! Which might be usefull for computer generated code, but makes no sense at all when man made.
However, todays IDE's compensate retty well for that evil...
|
|
|
|
|
Put your cursor on the }, press ctrl ] and it will take you to the matching one.
|
|
|
|
|
The designers of C# have irritated me in a number of ways:
1. I don't like the fact that they eliminated drop-through on case statements. It is irritating to have to code work-arounds for situations where one or more case statements can execute the same code.
2. The fact that they did not provide the ability to create static libraries that could be included at compile time and thus eliminate the need for having to ship umpteen dlls with your code.
3. This is more about .NET rather than C#, but I think it applies:
With every version of .NET they take something away. In .Net V4 they removed the ability to catch memory exceptions...!!!##@^!
4. This is more about .NET rather than C#, but I think it applies:
LINQ is not part of the framework! It is a binary lump that you can't step through in the debugger. Stop pretending it is part of the framework and part of C#
|
|
|
|
|
1. Methods anyone?
2. System.CodeDom.Compiler, System.Reflection.Assembly, etc
3. Maybe, but what can you really do with that in a managed language? If you're out of memory, you're out of memory.
4. Don't debug the framework, it defeats the purpose. Assume the framework works, report bugs you find, work around ones they don't fix. If you *really* need to debug it, decompile, proxy, rinse, repeat.
|
|
|
|
|
The nature of the programming I've done almost my whole career requires the power and control of C++ (actually, many things I've worked on would benefit from assembly, but the time/cost benefit isn't there.)
That said, I do some work in .NET and find that I like it all they up until it turns on me and I can't get that one last thing to work right without jumping through hoops. As with any language/framework, it isn't how well it helps you start a project, but how well it helps you finish it. When you hit the wall in .NET, you hit the wall and getting around it can be very painful, time consuming and unstable.
Then there's .NET Compact Framework.
|
|
|
|
|
I have used Basic and Visual Basic, since Basic , VB6 and .net. The best of VB is that uses English words, and C#, and when developing for Desktop is easier and faster than c#, I'm developing in C# but just 'cause is a requisite here, 'cause a lot of programmers learns Jave in MExican schools. I have used more than 500 lines of code than in VB.
And intellisense support is better in VB.
But finally the 2 languages can make the same, they are compiled in CLR.
|
|
|
|
|
The topic is why C# is awesome, not why you like VB better.
|
|
|
|
|