4 ms·

To make it perfectly clear , "async void" should be replaced with "async Task" The async stuff is interesting in that akin to generics it has an almost cancero

by mhomde 11y ago

To make it perfectly clear , "async void" should be replaced with "async Task" The async stuff is interesting in that akin to generics it has an almost cancerous effect on your code. When you start using them they tends to spread to large parts of your code base if you're not careful. It's awesome that C# now has such good support for parallelism and asynchronicity... but I remain in the opinion that a lot of this stuff is grafted on to the language and at some point we need to start over from scratch. Already more and more of the code is taken up by crud that should be abstracted away.

Ciantic 11y ago
and you add this mess the immutables, which are making inroads for example in the Roslyn compiler. This is of course mitigated a bit by the new pluggable analyzer feature, but it does feel like a hack.
saosebastiao 11y ago
I've been pleasantly surprised by the async workflows in F#. Behind the scenes it is one big ass monadic construct that has been grafted onto the language, but it doesn't feel that way at all when you use it...it is incredibly elegant and easy to read/write and understand exactly what is happening in terms of control flow. I think it is perfectly possible for C# to improve it without starting over from scratch, simply for the fact that F# has already done it. EDIT: See this link for more info on how F# has solved this problem, as well as others. http://tomasp.net/blog/csharp-async-gotchas.aspx/ http://tomasp.net/blog/csharp-async-gotchas.aspx/
- mhomde 11y ago
  Yeah, but the problem with C# is not that it isn't working, and it is pretty legible and easy to understand. The problem is the syntax and lack of some abstractions. F# syntax is probably more suited for a certain style of programming. You could try to rework C# without concern for breaking current behavior and making it more cohesive and consistent... but at that point it won't be C# I think. What I'd really like though is a switch from an explicit parallelism/multi-thread/asynchronous model to an implicit declarative model with optional explicitness. Let me explain what I mean. In many cases how code is executed should follow from the constraints of the computer/the types/side effects etc. If a programming language was structured so it was more about annotating those constraints then explicitly saying what to do, then the compiler and runtime should be able to optimize for us. Less risk of bugs and greater potential for advanced optimization. Also a software program might need to run different on a computer with many cores and a single core, or one with a RAM drive rather than a HD, or whatever hardware constraints we'll have in the future. Implicitness in that way is much more agile. Software built like this could even adapt and learn on it's own. Imagine you have a loop or something that performs an operation on a number of items. That loop could be parallelized, but should it? Right now that's a tricky question, it depends on the number of items and how demanding the operation. How much should it be parallelized? 2 operations simultanenously? 4? 24? Another tricky question. A smart program could profile itself continuously, see what typical input is and adapt itself accordingly. I know many are afraid of a "black box" a 'la ORM's but I think at some point we have to let go to a certain extent and move to a higher level of abstraction, in the same way we went from assembler to c. Controlling specific cases explicitly when needed should be possible of course
  - solarexplorer 11y ago
    What you describe really sounds like functional programming.
    - mhomde 11y ago
      Yes, it's probably closer to functional programming than OOP, but I feel that strict functional programming doesn't adapt well to some use-cases, and there really needs to be a modular model involved as well. I think a new mainstream language would be best to be a hybrid of some sort.
      - deleted 11y ago
        [deleted]
  - HanyouHottie 11y ago
    You pretty much just described data parallel Haskell to a T: https://wiki.haskell.org/GHC/Data_Parallel_Haskell https://wiki.haskell.org/GHC/Data_Parallel_Haskell
DougBTX 11y ago
Here's a nice article to describe that transitive effect. http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y... Also applies to IDisposable etc.

by mhomde 11y ago

Ciantic 11y ago

and you add this mess the immutables, which are making inroads for example in the Roslyn compiler. This is of course mitigated a bit by the new pluggable analyzer feature, but it does feel like a hack.

saosebastiao 11y ago

I've been pleasantly surprised by the async workflows in F#. Behind the scenes it is one big ass monadic construct that has been grafted onto the language, but it doesn't feel that way at all when you use it...it is incredibly elegant and easy to read/write and understand exactly what is happening in terms of control flow. I think it is perfectly possible for C# to improve it without starting over from scratch, simply for the fact that F# has already done it. EDIT: See this link for more info on how F# has solved this problem, as well as others. http://tomasp.net/blog/csharp-async-gotchas.aspx/ http://tomasp.net/blog/csharp-async-gotchas.aspx/

mhomde 11y ago
Yeah, but the problem with C# is not that it isn't working, and it is pretty legible and easy to understand. The problem is the syntax and lack of some abstractions. F# syntax is probably more suited for a certain style of programming. You could try to rework C# without concern for breaking current behavior and making it more cohesive and consistent... but at that point it won't be C# I think. What I'd really like though is a switch from an explicit parallelism/multi-thread/asynchronous model to an implicit declarative model with optional explicitness. Let me explain what I mean. In many cases how code is executed should follow from the constraints of the computer/the types/side effects etc. If a programming language was structured so it was more about annotating those constraints then explicitly saying what to do, then the compiler and runtime should be able to optimize for us. Less risk of bugs and greater potential for advanced optimization. Also a software program might need to run different on a computer with many cores and a single core, or one with a RAM drive rather than a HD, or whatever hardware constraints we'll have in the future. Implicitness in that way is much more agile. Software built like this could even adapt and learn on it's own. Imagine you have a loop or something that performs an operation on a number of items. That loop could be parallelized, but should it? Right now that's a tricky question, it depends on the number of items and how demanding the operation. How much should it be parallelized? 2 operations simultanenously? 4? 24? Another tricky question. A smart program could profile itself continuously, see what typical input is and adapt itself accordingly. I know many are afraid of a "black box" a 'la ORM's but I think at some point we have to let go to a certain extent and move to a higher level of abstraction, in the same way we went from assembler to c. Controlling specific cases explicitly when needed should be possible of course
- solarexplorer 11y ago
  What you describe really sounds like functional programming.
  - mhomde 11y ago
    Yes, it's probably closer to functional programming than OOP, but I feel that strict functional programming doesn't adapt well to some use-cases, and there really needs to be a modular model involved as well. I think a new mainstream language would be best to be a hybrid of some sort.
    - deleted 11y ago
      [deleted]
- HanyouHottie 11y ago
  You pretty much just described data parallel Haskell to a T: https://wiki.haskell.org/GHC/Data_Parallel_Haskell https://wiki.haskell.org/GHC/Data_Parallel_Haskell

DougBTX 11y ago

Here's a nice article to describe that transitive effect. http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y... Also applies to IDisposable etc.