5 ms·

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,

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.
  - millstone 13y ago
    Can you please elaborate on the exploitable codepath you found that was due to the JIT? That sounds interesting!
    - MichaelGG 13y ago
      This was in a early version of .NET, over a decade ago. Basically, certain calls in the CLR are marked in a special way so they can be done by internal CLR code instead of running managed code like any other function. I think Array.Copy is one example. If you created a delegate (function pointer) to such a special function that hadn't been called yet, it'd point to the wrong place and let you do things that shouldn't be possible. The neat thing is that the code was valid and verifiable (so it'd run in low-trust), but you'd still end up owning a function call to the wrong point of memory due to a runtime bug. Like practically every CLR vuln, it's the loading platform that is affected, not the applications. I think it's only important when relying on the complicated sandboxing restrictions (CAS). I'd like to publish a working example, but haven't had the time to figure out which old OS allows the specific old .NET version to replicate the behaviour. I only found it by accident and was more concerned about finding a workaround to not crash.
      - marshray 13y ago
        Did you report it and did it get fixed?
        MichaelGG 13y ago
        Yeah I had some friends and did an internal report. It's long fixed :)
- Moto7451 13y ago
  I disagree with the "Microsoft platform" bit. The Mono/Xamarin guys have been coming up with a very nice competing/complementary platform. I've built personal and production projects running on Linux using Mono. While I haven't used, the Xamarin iOS/Android development platforms look quite interesting. I suppose it has the stigma of a somewhat pricy per seat license but its likely worth it if you want to go with a shared codebase for iOS/Android/WP/Win8. There's also MonoGame[1] which targets developers of MS's former XNA game dev kit. [1]http://www.monogame.net/about http://www.monogame.net/about
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.

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.
- millstone 13y ago
  Can you please elaborate on the exploitable codepath you found that was due to the JIT? That sounds interesting!
  - MichaelGG 13y ago
    This was in a early version of .NET, over a decade ago. Basically, certain calls in the CLR are marked in a special way so they can be done by internal CLR code instead of running managed code like any other function. I think Array.Copy is one example. If you created a delegate (function pointer) to such a special function that hadn't been called yet, it'd point to the wrong place and let you do things that shouldn't be possible. The neat thing is that the code was valid and verifiable (so it'd run in low-trust), but you'd still end up owning a function call to the wrong point of memory due to a runtime bug. Like practically every CLR vuln, it's the loading platform that is affected, not the applications. I think it's only important when relying on the complicated sandboxing restrictions (CAS). I'd like to publish a working example, but haven't had the time to figure out which old OS allows the specific old .NET version to replicate the behaviour. I only found it by accident and was more concerned about finding a workaround to not crash.
    - marshray 13y ago
      Did you report it and did it get fixed?
      - MichaelGG 13y ago
        Yeah I had some friends and did an internal report. It's long fixed :)
Moto7451 13y ago
I disagree with the "Microsoft platform" bit. The Mono/Xamarin guys have been coming up with a very nice competing/complementary platform. I've built personal and production projects running on Linux using Mono. While I haven't used, the Xamarin iOS/Android development platforms look quite interesting. I suppose it has the stigma of a somewhat pricy per seat license but its likely worth it if you want to go with a shared codebase for iOS/Android/WP/Win8. There's also MonoGame[1] which targets developers of MS's former XNA game dev kit. [1]http://www.monogame.net/about http://www.monogame.net/about

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.