http://bitemyapp.com/posts/2014-03-25-when-nested-io-actions...

It seems that 'this' here must not refer to the parent post (https://news.ycombinator.com/item?id=7538461):

> Also, if you don't want to make the full leap into "PURE EVERYTHING MUST STAY CLEAN DONT BREAK THE RULES" style code, try Haskell. Imperative programming in Haskell is great! The language evaluation rules may be purely function, but your code doesn't need to be.

with which you seem to be agreeing. Perhaps it refers to the grandparent post (https://news.ycombinator.com/item?id=7537877), specifically to its implicit claim that Haskell programming involves "PURE EVERYTHING MUST STAY CLEAN DONT BREAK THE RULES"?

I really like Standard ML in that sense. Unfortunately, seems to be fading away in sense of popularity.

F# is a .NET language.

http://fsharp.org/use/mac/ http://fsharp.org/use/linux/

The language can compile into CIL, javascript, and a handful of other build targets.

I don't believe this is true, at least not easily.

Anyway, I needed to do a small .NET work two years ago. I choose to try F#. It was the first and only time I got highly please by another language features. Actually, I've to admit that I was pissed of : F# may well be a better language than Haskell.

It seems like the primary purpose of using a typed provider is so that the types (classes) can dynamically change during runtime (for example, you get different table objects for the different connection strings you pass in). But how do you program a client against an API that can change at will? Is your client code just basically doing runtime reflection on the data the type provider returns?

It seems like a useful feature but far from the power of having full macros.

http://channel9.msdn.com/Series/C9-Lectures-Dr-Don-Syme-Intr...

http://channel9.msdn.com/Series/C9-Lectures-Erik-Meijer-Func...