Discussion on: Do you consider learning Elm?

[Pragmatic Maciej]

The thing is that it is. Do notation looks like imperative code and when you don't get what is happening behind the curtain it looks familiar and you think you see what is that. When you understand Haskell concepts and Monad Typeclasses, do notation is crazy confusing to catch.

It's like somebody wanted to emulate imperative code in pure language.

Of course after a while this feeling go away. but I don't see do notation as must have.

[Matei Adriel]

Whoa whoa whoa, since when does do-notation look like imperative code, it's just syntactic sugar for working with monads

I also brought up computational expression, take async/await, a lot of languages have it now (c#, js, rust, py etc) but it came from the async workflow f# had to offer

[Pragmatic Maciej]

It looks like it or at least simulates motion of simple effectfull step by step instructions. In the same way async/await looks like synchronous code. There is a reason for both - it's just more handy and readable. It's syntactic sugar exactly that is why it's not just have.

[Matei Adriel]

Do-notation isnt effectful code only, it can work with any monad, the same way you can call .bind on an Io/Eff by hand

[Pragmatic Maciej]

I didn't say it is related only to IO. But for such it looks like one. I am not against do notation I am also not stating it's wrong, I am just saying it's not must to have and being only suger can be added to Elm in any moment.

[Matei Adriel]

How can sintactic sugar for monads be addable to elm when elm doesnt even support typeclasses?

[Pragmatic Maciej]

That would be a problem. But we could be having some do notation for specific Monads, like async await is for continuations.

[Matei Adriel]

But then we would need something like computstional expressions to use user defined notations