7 ms·

This is some pretty great stuff. Optimizing the null checking pattern will help a lot. It's a language feature that seems obvious after seeing the if let x = so

by Glide 12y ago

This is some pretty great stuff. Optimizing the null checking pattern will help a lot. It's a language feature that seems obvious after seeing the if let x = something as? SomeType in Swift. I've only been a year away from C# and I was writing 3.5 code at that time. It's kind of amazing seeing how quickly C# has moved from year to year compared to it's closest competitors. I had the same experience when I was looking at web development after a couple years of not really touching it. It's really nice to just take a step back and realize how quickly these things are progressing.

manojlds 12y ago
Sorry to say, but writing 3.5 (I hope you mean 3.0) code a year ago mean't you were far behind. I myself feel that C# has not changed a lot in the last 2 years or more. C# 5.0 was released almost exactly 2 years ago, and even that didn't bring a lot of changes ( The biggest was of course async-await and the other one the callerinfo attributes, and that's about it.)
- moron4hire 12y ago
  async-await was huge, though. I don't think we've come anywhere near seeing the full consequences of it. And honestly, I'm okay with C#'s release schedule. Fix bugs rapidly and frequently, by all means, but it takes time to learn how to take the best advantage of new semantics. I could really use not having those semantics change immediately after figuring that stuff out.
  - zamalek 12y ago
    > I don't think we've come anywhere near seeing the full consequences of it. If you dig into how it works and really grok it, you can do some outright crazy stuff with it. For example: http://blogs.msdn.com/b/pfxteam/archive/2011/01/13/10115642.aspx http://blogs.msdn.com/b/pfxteam/archive/2011/01/13/10115642....
- algorithmsRcool 12y ago
  I recall Anders giving a talk (at JAOO maybe?) saying that the big jumps in between C# 1.0 -> 2.0 and especially 2.0 -> 3.0 caused some push back. People complained that they were changing the language too fast and it was causing knowledge churn. So 4.0 was more 'targeted' in scope as a result of this feedback. I know dynamic was a 'big' feature, but it was mostly in it's own corner and had little application to most daily code. .NET 4 introduced Task<T> and the TPL which was very important but it didn't see any assitance from C# itself. As to C# 5.0, I am assuming that the managed languages team at MS was well into designing and implementing roslyn and probably didn't see great value is contributing massive features to the old compliler, but Async/Await couldn't, well uhh, wait for roslyn to be finished.
- Locke1689 12y ago
  Async didn't change anything for you? It seems pretty big to us.
  - manojlds 12y ago
    My main thrust was that the last release was 2 years ago, and relatively, the changes in 5.0 were minimal. (async-await is nothing compared to changes in 3.0 and 4.0)
  - S_A_P 12y ago
    I think Async was not very big for big legacy code bases. I have used it a handful of times, but it had nowhere near the same impact as Linq and lambdas had on my daily activities. In fact I would say that has had the single greatest impact on my coding style and habits...
  - ryanjshaw 12y ago
    I used async for a WPF application. That worked out well. I also experimented with a scraper using async. I dug myself into holes very quickly (memory usage ballooned, difficult to debug and reason about application state despite the code being very easy to read, threads were being created all over the place which annoyed me even though I understood why). I rewrote the scraper to use BlockingCollections and Take(), with async being used solely with the HttpClient (which really needs to learn how to play nicer with async in the face of network errors!). The code was more decoupled, and while slightly more difficult to follow because of this, far easier to test and debug because the working set of my application was explicit rather than hidden in tasks. This had the added benefit of making it easy to persist and restore state. For me, the concurrent collections introduced in .NET 4 have been the big winner (no more custom thread pools!). Use of async needs to be matched carefully with the problem domain, especially in backend development.
- virtue3 12y ago
  I really seriously can't fathom how you can say that async-await isn't absolutely huge... I remember having my brain sufficiently blown when I realized just what it was doing and how powerful of a feature this was.
  - hvidgaard 12y ago
    async is nice in the proper domain, where you need asynchronous behaviour or callbacks. But outside of that it's not really that much of use. Compare that to a feature like LINQ, which changed the way programmer can write code pretty in pretty much any program.

by Glide 12y ago

manojlds 12y ago

Sorry to say, but writing 3.5 (I hope you mean 3.0) code a year ago mean't you were far behind. I myself feel that C# has not changed a lot in the last 2 years or more. C# 5.0 was released almost exactly 2 years ago, and even that didn't bring a lot of changes ( The biggest was of course async-await and the other one the callerinfo attributes, and that's about it.)

moron4hire 12y ago
async-await was huge, though. I don't think we've come anywhere near seeing the full consequences of it. And honestly, I'm okay with C#'s release schedule. Fix bugs rapidly and frequently, by all means, but it takes time to learn how to take the best advantage of new semantics. I could really use not having those semantics change immediately after figuring that stuff out.
- zamalek 12y ago
  > I don't think we've come anywhere near seeing the full consequences of it. If you dig into how it works and really grok it, you can do some outright crazy stuff with it. For example: http://blogs.msdn.com/b/pfxteam/archive/2011/01/13/10115642.aspx http://blogs.msdn.com/b/pfxteam/archive/2011/01/13/10115642....
algorithmsRcool 12y ago
I recall Anders giving a talk (at JAOO maybe?) saying that the big jumps in between C# 1.0 -> 2.0 and especially 2.0 -> 3.0 caused some push back. People complained that they were changing the language too fast and it was causing knowledge churn. So 4.0 was more 'targeted' in scope as a result of this feedback. I know dynamic was a 'big' feature, but it was mostly in it's own corner and had little application to most daily code. .NET 4 introduced Task<T> and the TPL which was very important but it didn't see any assitance from C# itself. As to C# 5.0, I am assuming that the managed languages team at MS was well into designing and implementing roslyn and probably didn't see great value is contributing massive features to the old compliler, but Async/Await couldn't, well uhh, wait for roslyn to be finished.
Locke1689 12y ago
Async didn't change anything for you? It seems pretty big to us.
- manojlds 12y ago
  My main thrust was that the last release was 2 years ago, and relatively, the changes in 5.0 were minimal. (async-await is nothing compared to changes in 3.0 and 4.0)
- S_A_P 12y ago
  I think Async was not very big for big legacy code bases. I have used it a handful of times, but it had nowhere near the same impact as Linq and lambdas had on my daily activities. In fact I would say that has had the single greatest impact on my coding style and habits...
- ryanjshaw 12y ago
  I used async for a WPF application. That worked out well. I also experimented with a scraper using async. I dug myself into holes very quickly (memory usage ballooned, difficult to debug and reason about application state despite the code being very easy to read, threads were being created all over the place which annoyed me even though I understood why). I rewrote the scraper to use BlockingCollections and Take(), with async being used solely with the HttpClient (which really needs to learn how to play nicer with async in the face of network errors!). The code was more decoupled, and while slightly more difficult to follow because of this, far easier to test and debug because the working set of my application was explicit rather than hidden in tasks. This had the added benefit of making it easy to persist and restore state. For me, the concurrent collections introduced in .NET 4 have been the big winner (no more custom thread pools!). Use of async needs to be matched carefully with the problem domain, especially in backend development.
virtue3 12y ago
I really seriously can't fathom how you can say that async-await isn't absolutely huge... I remember having my brain sufficiently blown when I realized just what it was doing and how powerful of a feature this was.
- hvidgaard 12y ago
  async is nice in the proper domain, where you need asynchronous behaviour or callbacks. But outside of that it's not really that much of use. Compare that to a feature like LINQ, which changed the way programmer can write code pretty in pretty much any program.