> I think this point has probably been argued to death by now, but I still can't see this as a good idea. 'Side effects' are really just a reality of software d

> I think this point has probably been argued to death by now, but I still can't see this as a good idea. 'Side effects' are really just a reality of software development. For example if I want to fade in a GUI element on a page, I don't want to create a new element for every transition change. Theres nothing wrong with mutable state, but it is nice to have immutability for some use cases. In this case c# has valuetypes, and the const/readonly modifiers. Mutability is one side effect. OCaml is not Haskell and doesn't have a type system baked in. Sure, sometimes you need to cheat, but mutability as the general rule is crazyland. Immutability gives you a compile-time assurance that your data structures are consistent and valid, as long as the tests in your constructor function are correct. > Yep C# has had this since the beginning. And you can even use 'dynamic' if you really want which moves all type checking to runtime. Well, it has strong static type checking... within the bounds of what its type system supports. Which is fairly limited. > I feel like these are more buzz words than actual substance. Others have responded to that, but in short, your impression is wrong. > Again C# has these abilities with 'var a = 0' for example. It won't infer method return types, not because it couldn't, but because it's just generally clearer to have the explicit return type written there in the code for the reader. C#'s "type inference" is cute, but you can't seriously compare it with OCaml's.