7 ms·

Asynchronous method... interesting. It seems to me that each version they just incorporate a little bit of some hot paradigms into this language that started as

Asynchronous method... interesting. It seems to me that each version they just incorporate a little bit of some hot paradigms into this language that started as a sweeter(or less painful) java. I remember that during the ruby boom they added the "dynamic" feature into it. Together with linq, and lambda, is it me or all these attempts sometimes appear awkward and out of place?

pixie_ 13y ago
I program in a lot languages and C# is heads and shoulders above everything. It doesn't feel hacked together at all. It's like someone with a real vision put a lot of work into making a great language. Too bad project requirements usually dictate the language I have to use.
- kalininalex 13y ago
  One of them is Eric Lippert. If you use C# you'll enjoy his blog, http://ericlippert.com/ http://ericlippert.com/.
hosay123 13y ago
As a (hardened, old) unix dev, it seems to me you've spent little time with the language. C# is one of the most successfully evolved languages of recent times, no feature was added that didn't have a clear & concise story in the context of all other features. No Anders & co didn't just add whatever they felt fashionable, they've designed a language over the course of a decade with (to my knowledge) zero warts, bringing to the table more than 20 years of prior design experience (Turbo Pascal, Delphi). If it weren't for the stigma of being a Microsoft design, C# would be a hugely more popular language.
- frozenport 13y ago
  I felt it compromised C++'s low level compatibility in exchange for increasingly verbose expressions. Perhaps C# has nothing to offer except for Microsoft's ecosystem. Valid in 2005 but not today.
  - marshray 13y ago
    I'm a die-hard C++ guy but years ago I wrote a few 10k's of C# and found it quite productive. Here's what I liked about it: * Garbage collection * Lightning fast compilation * Pointer-safe subset good enough for most common uses. LINQ is also considered a huge win by many, though I suspect it could also be done in C++.
    - pjmlp 13y ago
      Now if they just used the same compiler backend across their C++ and C# toolchains.
      - marshray 13y ago
        Well there is the managed C++ backend, if you're into that sort of thing. I've been known to use it once or twice. :-)
        pjmlp 13y ago
        I did use it a few times, back when .NET was still beta. So I went through Managed C++ and C++/CLI transition. I also find it nice that with C++/CX VC++ is offering what C++ Builder does for years in terms of C++ RAD development. Nowadays most of the consulting projects I work on are in JVM and .NET land. What I really wanted to say it that I would like to see NGEN and .NET JIT offer the same type of optimizations as VC++ does, like SIMD, auto-vectorization and such. When targeting Windows Phone 8, .NET gets compiled to native code with such type of optimizations using a cloud based AOT compiler. Maybe those improvements will eventually be brought into the standard framework.
  - MichaelGG 13y ago
    In C# you need to go pretty far out of your way to implement an exploitable codepath. (It's not _hard_, and I even found one due to the JIT.) But for almost all apps, the better security (and tooling), better turnaround, and, without opening an escape catch, verifiable type safety - that's pretty fantastic.
- Permit 13y ago
  > No Anders & co didn't just add whatever they felt fashionable, they've designed a language over the course of a decade with (to my knowledge) zero warts... There was definitely one that got me (they made a breaking change to fix it in C# 5.0, though). http://blogs.msdn.com/b/ericlippert/archive/2009/11/12/closing-over-the-loop-variable-considered-harmful.aspx http://blogs.msdn.com/b/ericlippert/archive/2009/11/12/closi... I agree completely, though, that it is remarkable how well-designed the language is.
  - danbruc 13y ago
    Array covariance is another one. They added it because Java had it. And now they regret it.
    - elisee 13y ago
      Interesting. Did a Google search which turned up this explanation about why it's considered broken: array covariance means runtime type checks rather than compile-time checks, which are more expensive and could hide bugs that could be caught when compiling. (http://blogs.msdn.com/b/ericlippert/archive/2007/10/17/covariance-and-contravariance-in-c-part-two-array-covariance.aspx http://blogs.msdn.com/b/ericlippert/archive/2007/10/17/covar...)
- millstone 13y ago
  > zero warts C# is a nice language, but oh man, is that asking for it! My pet example of a wart is the set of requirements on the iterated collection in foreach loops. Most C# developers probably think that the collection has to implement IEnumerable, but it is not so! I pasted the requirements from the spec at http://pastebin.com/EfsAmz6f http://pastebin.com/EfsAmz6f This is also a case where the dynamic type does something different than the static type. If you iterate over a statically typed non-IEnumerable collection, it will work fine (assuming it implements the required methods). But if you then change the type to dynamic, I think you get a runtime error. So there's a wart for ya!
  - danbruc 13y ago
    I was aware that something remotely similar is done when rewriting LINQ query expressions but I was not aware of this one. My first thought was that they added it to support dynamic and objects not implementing IEnumerable but as you mentioned exactly this seems to be the case where it would not work. I had a look at the C# 1.0 specification and it's already in there but a lot less verbose. Any idea why they did this? The only thing this seems to achieve is that you can implement IEnumerable and IEnumerator without explicitly stating it. Are there any (common) classes to which this applies?
    - noblethrasher 13y ago
      One big benefit of using structural (rather than nominal) typing in the foreach construct is that value types don't need to be boxed.
      - danbruc 13y ago
        I am not sure about this - why would requiring an interface require boxing?
        noblethrasher 13y ago
        Interfaces are reference types and so if the GetEnumerator method on a struct is called through an interface then it must be boxed.
- gnaritas 13y ago
  No language has zero warts. I use it everyday, and love the language, and it's still sometimes painful to do good OO compared to Smalltalk. No meta classes sucks, static methods are a poor substitute, can't override them, can't call them on passed type references without reflection which is ugly. Multiple equivalent syntaxes for anonymous delegates is a wart, they should have just started with the shorter one. Foreach over a container lets you declare the wrong type and throws a runtime cast exception when it could often know at compile time that it's not valid. Still, great language, love it.
danbruc 13y ago
I personally think they are doing a great job evolving the language. For every version they focus on one or at most a few features and those are really well designed. And I don't think they are following the latest trend - they are adding the things they know how to do [1] and which provide the most value. As far as I know dynamic was added to ease interop with native code - I have never seen it heavily used in regular code. LINQ and lambda expression have been introduced together with the Entity Framework and I am unable to imagine using an O/R mapper without something similar again - it just fits together so nicely. Async was an obvious next choice - we are getting more and more cores and traditional thread-based parallel programming just does not scale because it is so error prone. And after they extended LINQ to PLINQ they had a good part of the necessary infrastructure already in place. [1] For example they would like to add something like Java's checked exceptions but when they considered it they came to the conclusion that there are to many unsolved problems and that it might require a few more years of research to come up with a really good way to do it and so they postponed it for later reconsideration. In general there is a lot of well researched theory behind the things they do. Another example is the Entity Framework. They didn't just implement another O/R mapper but came up with a mathematical theory comparable to the relational algebra and then implemented it based on that results.
Permit 13y ago
C# is an absolute joy to use. The three features you've touched upon in your post are three of my absolute favorites (another being type inference). C# pulls concepts from a variety of other languages and it feels really well structured. I'm sure I'm not the only one who misses these features when they're working in Java.
modarts 13y ago
I'd be hard pressed to find another language that I'd want to use for my server side development work. It's hands down the most expressive c style language in existence. Coupled with Visual Studio, the amount of quality software that can be written in a short amount of time is nothing short of amazing. (This is coming from someone who was a Rails dev in their previous life)
- kailuowang 13y ago
  I am sorry but the amount of time taken to install visual studio is also not short of amazement.
- jfabre 13y ago
  Can you explain what you find more expressive in c# compared to ruby? I've been a c# developer for over 5 years and I have to disagree with almost everything you said. Ruby blew my mind when I learned it.
  - fusiongyro 13y ago
    He did say c style language. I went from Ruby to Java. I have found it very hard to accept the Rails maintenance story since then.
  - deleted 13y ago
    [deleted]
spamizbad 13y ago
As a former C# dev, here's my subjective view: The stuff actually fits in the language pretty well. What has resulted, however, is that there are multiple ways to skin a cat in C#, and there's very limited guidance on what's considered idiomatic. This is complicated by the fact that many .NET/C# shops have coding standards in place that don't go much beyond C# 2.0. The last C# interview I did, at an allegedly "progressive" .NET shop, the interviewer barred me from using null coalesce in a whiteboard example because "That's hobby project code. It's not how we write production code" Great language, terrible culture.
- deleted 13y ago
  [deleted]
  - deleted 13y ago
    [deleted]
- seanmcdirmid 13y ago
  > What has resulted, however, is that there are multiple ways to skin a cat in C#, and there's very limited guidance on what's considered idiomatic. I find C# to be much more idiomatic than C++ or Scala. If you think C# is bad...stay away from those languages.
- MichaelGG 13y ago
  Yes, the whole fights of people confused about "var" and avoiding it shows that a fair amount of MS's target group is simply not interested in proper language research or design. I'll admit that I love the ideas behind the CLR (the VM design is pretty slick, although it's stagnated the past years). I think some parts are really excellent (the generics), but when I approach a vendor and I hear they're using .NET, it is a slightly negative flag. I too had a boss (new owner after acquisition) say "no you're not allowed to use lambdas".
  - pjmlp 13y ago
    If you want to start a flamewar just go to a C++ newsgroup and ask around about using type inference with auto. This is typical enterprise stuff, I bet most typical enterprise already making the switch to Scala and F# also force their developers to type annotate everything.
skwirl 13y ago
I'm just echoing what everyone else here said, but they do a great job at adding these features to the language. I believe that if you learned C# as a first language nothing would feel out of place.
MichaelGG 13y ago
Yeah, C#'s async is a weak version of F#'s workflows, but with a single hard-coded implementation. Research (Haskell) and other languages filter into F# (and team), which filters into C#. F# has had async workflows since 2007. LINQ's another example of a place where the C# team sighted one end advantage (queries) and implemented the minimum to make it work. That's why all the features around the main LINQ part are half-assed (limited expression trees, ambiguous lambda syntax, very limited type inference.) Overall, C#'s a nice enough language for a lot of projects. The tooling really helps sells it, too. It's just rather verbose and limiting, unnecessarily. I just can't think of any place where C# the language is significantly better than F#. But, if you're ranking it against the likes of Java, then yes, C# is close to perfect. Edit: C# implements a lot of stuff right into the compiler, things that'd be useful more generically. For instance, foreach and collection initializers use duck typing that's baked into the C# compiler. That's a generally useful feature, but again, hard coded for a specific scenario. F# has some of that too, but not to the same extent (F# warts arise mainly when you push the edge of F#-C#ish interop).
- pjmlp 13y ago
  Yes, but C# is a better fit for the enterprise world than F#. Currently my F# code is mainly for scripting when doing .NET projects, but only if I am the only user of such scripts, otherwise Powershell. Anyway I really appreciate the work Microsoft puts on F#, Haskell and OCaml via their research arm.
  - Associat0r 13y ago
    Why would C# inherently be a better fit for the enterprise world?
    - pjmlp 13y ago
      Because most Fortune 500 employees by definition are code monkeys that won't touch FP concepts, just doing the typical CRUD applications full of design patterns. Having FP concepts sneak in C# is easier to get them introduced in this world, than forcing this type of developers to use something like F#. This why Erik Meijer decided the best way to bring FP to the enterprise was via Visual Basic. http://research.microsoft.com/en-us/um/people/emeijer/papers/es012-meijer.pdf http://research.microsoft.com/en-us/um/people/emeijer/papers...

pixie_ 13y ago

I program in a lot languages and C# is heads and shoulders above everything. It doesn't feel hacked together at all. It's like someone with a real vision put a lot of work into making a great language. Too bad project requirements usually dictate the language I have to use.

kalininalex 13y ago
One of them is Eric Lippert. If you use C# you'll enjoy his blog, http://ericlippert.com/ http://ericlippert.com/.

hosay123 13y ago

As a (hardened, old) unix dev, it seems to me you've spent little time with the language. C# is one of the most successfully evolved languages of recent times, no feature was added that didn't have a clear & concise story in the context of all other features. No Anders & co didn't just add whatever they felt fashionable, they've designed a language over the course of a decade with (to my knowledge) zero warts, bringing to the table more than 20 years of prior design experience (Turbo Pascal, Delphi). If it weren't for the stigma of being a Microsoft design, C# would be a hugely more popular language.

frozenport 13y ago
I felt it compromised C++'s low level compatibility in exchange for increasingly verbose expressions. Perhaps C# has nothing to offer except for Microsoft's ecosystem. Valid in 2005 but not today.
- marshray 13y ago
  I'm a die-hard C++ guy but years ago I wrote a few 10k's of C# and found it quite productive. Here's what I liked about it: * Garbage collection * Lightning fast compilation * Pointer-safe subset good enough for most common uses. LINQ is also considered a huge win by many, though I suspect it could also be done in C++.
  - pjmlp 13y ago
    Now if they just used the same compiler backend across their C++ and C# toolchains.
    - marshray 13y ago
      Well there is the managed C++ backend, if you're into that sort of thing. I've been known to use it once or twice. :-)
      - pjmlp 13y ago
        I did use it a few times, back when .NET was still beta. So I went through Managed C++ and C++/CLI transition. I also find it nice that with C++/CX VC++ is offering what C++ Builder does for years in terms of C++ RAD development. Nowadays most of the consulting projects I work on are in JVM and .NET land. What I really wanted to say it that I would like to see NGEN and .NET JIT offer the same type of optimizations as VC++ does, like SIMD, auto-vectorization and such. When targeting Windows Phone 8, .NET gets compiled to native code with such type of optimizations using a cloud based AOT compiler. Maybe those improvements will eventually be brought into the standard framework.
- MichaelGG 13y ago
  In C# you need to go pretty far out of your way to implement an exploitable codepath. (It's not _hard_, and I even found one due to the JIT.) But for almost all apps, the better security (and tooling), better turnaround, and, without opening an escape catch, verifiable type safety - that's pretty fantastic.
Permit 13y ago
> No Anders & co didn't just add whatever they felt fashionable, they've designed a language over the course of a decade with (to my knowledge) zero warts... There was definitely one that got me (they made a breaking change to fix it in C# 5.0, though). http://blogs.msdn.com/b/ericlippert/archive/2009/11/12/closing-over-the-loop-variable-considered-harmful.aspx http://blogs.msdn.com/b/ericlippert/archive/2009/11/12/closi... I agree completely, though, that it is remarkable how well-designed the language is.
- danbruc 13y ago
  Array covariance is another one. They added it because Java had it. And now they regret it.
  - elisee 13y ago
    Interesting. Did a Google search which turned up this explanation about why it's considered broken: array covariance means runtime type checks rather than compile-time checks, which are more expensive and could hide bugs that could be caught when compiling. (http://blogs.msdn.com/b/ericlippert/archive/2007/10/17/covariance-and-contravariance-in-c-part-two-array-covariance.aspx http://blogs.msdn.com/b/ericlippert/archive/2007/10/17/covar...)
millstone 13y ago
> zero warts C# is a nice language, but oh man, is that asking for it! My pet example of a wart is the set of requirements on the iterated collection in foreach loops. Most C# developers probably think that the collection has to implement IEnumerable, but it is not so! I pasted the requirements from the spec at http://pastebin.com/EfsAmz6f http://pastebin.com/EfsAmz6f This is also a case where the dynamic type does something different than the static type. If you iterate over a statically typed non-IEnumerable collection, it will work fine (assuming it implements the required methods). But if you then change the type to dynamic, I think you get a runtime error. So there's a wart for ya!
- danbruc 13y ago
  I was aware that something remotely similar is done when rewriting LINQ query expressions but I was not aware of this one. My first thought was that they added it to support dynamic and objects not implementing IEnumerable but as you mentioned exactly this seems to be the case where it would not work. I had a look at the C# 1.0 specification and it's already in there but a lot less verbose. Any idea why they did this? The only thing this seems to achieve is that you can implement IEnumerable and IEnumerator without explicitly stating it. Are there any (common) classes to which this applies?
  - noblethrasher 13y ago
    One big benefit of using structural (rather than nominal) typing in the foreach construct is that value types don't need to be boxed.
    - danbruc 13y ago
      I am not sure about this - why would requiring an interface require boxing?
      - noblethrasher 13y ago
        Interfaces are reference types and so if the GetEnumerator method on a struct is called through an interface then it must be boxed.
gnaritas 13y ago
No language has zero warts. I use it everyday, and love the language, and it's still sometimes painful to do good OO compared to Smalltalk. No meta classes sucks, static methods are a poor substitute, can't override them, can't call them on passed type references without reflection which is ugly. Multiple equivalent syntaxes for anonymous delegates is a wart, they should have just started with the shorter one. Foreach over a container lets you declare the wrong type and throws a runtime cast exception when it could often know at compile time that it's not valid. Still, great language, love it.

danbruc 13y ago

I personally think they are doing a great job evolving the language. For every version they focus on one or at most a few features and those are really well designed. And I don't think they are following the latest trend - they are adding the things they know how to do [1] and which provide the most value. As far as I know dynamic was added to ease interop with native code - I have never seen it heavily used in regular code. LINQ and lambda expression have been introduced together with the Entity Framework and I am unable to imagine using an O/R mapper without something similar again - it just fits together so nicely. Async was an obvious next choice - we are getting more and more cores and traditional thread-based parallel programming just does not scale because it is so error prone. And after they extended LINQ to PLINQ they had a good part of the necessary infrastructure already in place. [1] For example they would like to add something like Java's checked exceptions but when they considered it they came to the conclusion that there are to many unsolved problems and that it might require a few more years of research to come up with a really good way to do it and so they postponed it for later reconsideration. In general there is a lot of well researched theory behind the things they do. Another example is the Entity Framework. They didn't just implement another O/R mapper but came up with a mathematical theory comparable to the relational algebra and then implemented it based on that results.

Permit 13y ago

C# is an absolute joy to use. The three features you've touched upon in your post are three of my absolute favorites (another being type inference). C# pulls concepts from a variety of other languages and it feels really well structured. I'm sure I'm not the only one who misses these features when they're working in Java.

modarts 13y ago

I'd be hard pressed to find another language that I'd want to use for my server side development work. It's hands down the most expressive c style language in existence. Coupled with Visual Studio, the amount of quality software that can be written in a short amount of time is nothing short of amazing. (This is coming from someone who was a Rails dev in their previous life)

kailuowang 13y ago
I am sorry but the amount of time taken to install visual studio is also not short of amazement.
jfabre 13y ago
Can you explain what you find more expressive in c# compared to ruby? I've been a c# developer for over 5 years and I have to disagree with almost everything you said. Ruby blew my mind when I learned it.
- fusiongyro 13y ago
  He did say c style language. I went from Ruby to Java. I have found it very hard to accept the Rails maintenance story since then.
- deleted 13y ago
  [deleted]

spamizbad 13y ago

As a former C# dev, here's my subjective view: The stuff actually fits in the language pretty well. What has resulted, however, is that there are multiple ways to skin a cat in C#, and there's very limited guidance on what's considered idiomatic. This is complicated by the fact that many .NET/C# shops have coding standards in place that don't go much beyond C# 2.0. The last C# interview I did, at an allegedly "progressive" .NET shop, the interviewer barred me from using null coalesce in a whiteboard example because "That's hobby project code. It's not how we write production code" Great language, terrible culture.

deleted 13y ago
[deleted]
- deleted 13y ago
  [deleted]
seanmcdirmid 13y ago
> What has resulted, however, is that there are multiple ways to skin a cat in C#, and there's very limited guidance on what's considered idiomatic. I find C# to be much more idiomatic than C++ or Scala. If you think C# is bad...stay away from those languages.
MichaelGG 13y ago
Yes, the whole fights of people confused about "var" and avoiding it shows that a fair amount of MS's target group is simply not interested in proper language research or design. I'll admit that I love the ideas behind the CLR (the VM design is pretty slick, although it's stagnated the past years). I think some parts are really excellent (the generics), but when I approach a vendor and I hear they're using .NET, it is a slightly negative flag. I too had a boss (new owner after acquisition) say "no you're not allowed to use lambdas".
- pjmlp 13y ago
  If you want to start a flamewar just go to a C++ newsgroup and ask around about using type inference with auto. This is typical enterprise stuff, I bet most typical enterprise already making the switch to Scala and F# also force their developers to type annotate everything.

skwirl 13y ago

I'm just echoing what everyone else here said, but they do a great job at adding these features to the language. I believe that if you learned C# as a first language nothing would feel out of place.

MichaelGG 13y ago

Yeah, C#'s async is a weak version of F#'s workflows, but with a single hard-coded implementation. Research (Haskell) and other languages filter into F# (and team), which filters into C#. F# has had async workflows since 2007. LINQ's another example of a place where the C# team sighted one end advantage (queries) and implemented the minimum to make it work. That's why all the features around the main LINQ part are half-assed (limited expression trees, ambiguous lambda syntax, very limited type inference.) Overall, C#'s a nice enough language for a lot of projects. The tooling really helps sells it, too. It's just rather verbose and limiting, unnecessarily. I just can't think of any place where C# the language is significantly better than F#. But, if you're ranking it against the likes of Java, then yes, C# is close to perfect. Edit: C# implements a lot of stuff right into the compiler, things that'd be useful more generically. For instance, foreach and collection initializers use duck typing that's baked into the C# compiler. That's a generally useful feature, but again, hard coded for a specific scenario. F# has some of that too, but not to the same extent (F# warts arise mainly when you push the edge of F#-C#ish interop).

pjmlp 13y ago
Yes, but C# is a better fit for the enterprise world than F#. Currently my F# code is mainly for scripting when doing .NET projects, but only if I am the only user of such scripts, otherwise Powershell. Anyway I really appreciate the work Microsoft puts on F#, Haskell and OCaml via their research arm.
- Associat0r 13y ago
  Why would C# inherently be a better fit for the enterprise world?
  - pjmlp 13y ago
    Because most Fortune 500 employees by definition are code monkeys that won't touch FP concepts, just doing the typical CRUD applications full of design patterns. Having FP concepts sneak in C# is easier to get them introduced in this world, than forcing this type of developers to use something like F#. This why Erik Meijer decided the best way to bring FP to the enterprise was via Visual Basic. http://research.microsoft.com/en-us/um/people/emeijer/papers/es012-meijer.pdf http://research.microsoft.com/en-us/um/people/emeijer/papers...