* Lack of names Can't you just use records and named user defined types? * Hard to track mutations I feel he's mixing imperative and OOP. Its not even every

* Lack of names Can't you just use records and named user defined types? * Hard to track mutations I feel he's mixing imperative and OOP. Its not even every OOP languages that have the self referential this keyword. Basically, I struggle just as much with this in imperative and OOP languages. The fix in FP is that you don't design things to be mutated in the first place, so you don't need to track it. * Partial evaluation Strange name, I think he meant partial application. Anyways, I actually think OCaml is curried, which is different to partial in that its implicit. I agree with him a little here, don't abuse this, but the feature does come in very handy once in a while. I think that just comes to learning good practice like in all languages, you still need discipline. * High order function I really don't understand this one. Just look at the doc-string or the function signature if you're confused what arguments the higher order function takes. * Passing values around I find reduce way better. How weird is it that sum is mutated outside the loop? I've seen plenty of imperative code where the mutated accumulator isn't declared near the loop, or its reused from one loop to another. * Lack of methods I think he's confused with namespacing? Also, methods are an OOP concept, not imperative, an FP/OOP lang could easily have them. Anyways, I find methods are one of the worst thing in mainstream OOP. That's why all modern OOP langs are adding traits. Methods are closed, so a type can't be extended to support more of them. Also they get abused as namespaces, where really the methods should only operate on the class fields. * Lists Well, not all FP languages are built of the same datastructures. So that might be OCaml specific. I'm sure there's libraries to fill the void. * Lack of early returns Minor gripe, I don't particularly miss it.