That’s interesting because F#’s OOP, as someone who knows neither C# nor Java, makes it more intimidating to me than OCaml.
Also interesting that when FP is mentioned, Hindley-Milner is implicitly understood to be part of FP too even though it doesn’t have to be. Clojure emphasizes immutability and FP but with dynamic typing and everything that comes with that.
OCaml classes and objects are (ironically) rarely used and generally discouraged. There are some cases where they’re practically required, such as GUI and FFI (js_of_ocaml). But otherwise, most code does encapsulation and abstraction using modules and functor modules (which are more like Haskell and Rust typeclasses than traditional OOP classes).
I don’t know much about F#, but last time I used it most of its standard library was in C# and .NET, so F# code would interact with objects and classes a lot. AFAIK F# also doesn’t have functor modules, so even without the dependence on C# code, you still can’t avoid classes and objects like you can with OCaml (e.g. you can’t write a generic collection module like `List` or `Set` without functors, it would have to be a collection of a specific type or a class).
I think you misread their claim - they said that generic list/set would have to be classes, not modules (generic modules are a specific thing in OCaml and aren't the same as a module of generic classes).
Alright. Humor me, what is the issue with F# generics as compared to other languages with generics? Which implementation (that is productively useful) is a "true" one?
This seems like a meaningless criticism when it comes to immutability in Clojure. You can have mutability in Haskell too. That doesn’t make it as unsafe as memory management in C++.
> What safeguards around mutability does Clojure have?
Very nearly the entire language and standard library operate on immutable values only. Immutable values are the default, and you will use them for the vast majority of logic. You must do so, unless you very specifically opt to use dedicated reference types, at which point you’ll still need to produce intermediate immutable values to interact with that vast majority of the standard library.
And…
> is there any kind of contract, notation ... anything which could suggest whether it mutates or not?
Functions which mutate state are almost always suffixed !. They will typically fail if you pass them immutable values; they only operate on reference types, which have to be dereferenced (typically with the prefix @) to access their state.
> C++ explicitly supports memory-safe programming. You can choose whether you want to mess around with raw pointer arithmetic.
I don't think you know what you're talking about. Managing object ownership through systems like smart pointers is not memory safety. Applications that use smart pointers still suffer from memory issues, and it's possible to adopt object ownership systems that still use raw pointers, such as It's object ownership system.
The world is much less black and white than you’d like to see it.
Functions in Haskell including Prelude can throw exceptions which is not reflected in the type signature of the function. That is an effect that makes seemingly pure functions impure.
You can’t judge a language from a list of buzzwords. You need to look at how it is used in practice.
> Functions in Haskell including Prelude can throw exceptions which is not reflected in the type signature of the function. That is an effect that makes seemingly pure functions impure.
No, bottom, or _|_, is an inhabitant of every lifted type. An exception is bottom. So the / function is still pure even though it can throw a divide-by-zero exception.
Also interesting that when FP is mentioned, Hindley-Milner is implicitly understood to be part of FP too even though it doesn’t have to be. Clojure emphasizes immutability and FP but with dynamic typing and everything that comes with that.