While some of the complaints in the article are reasonable, the author seems to miss that F# began as essentially "OCaml for .NET". It's syntax is ML derived and the .NETisms came later, which is why there's sometimes two ways to do the same thing.
In early versions of F# you had to stick `#light` at the top of a file to use lightweight syntax, which is now the default. The verbose syntax, which is closer to ML was originally the default.
> 1. You have to manually order your files in F# projects in order they must be processed by the compiler.
This is one of my favourite features of F# because it forces you to design your code in a way that minimizes mutually recursive types, since all mutually recursive types must live in the same code file. You end up with cleaner code which is easier to test, maintain and reason about.
> 2. No break and continue for loops. 3. No do-while loops.
I've never seen as a problem because I rarely write loops. It's so rare that I use them I end up having to double-check the syntax. I always reach to .map, .fold, .filter, etc first, and I can't remember a time I couldn't express what I wanted using these.
> 6. Awful type constructor syntax
The primary constructor syntax makes sure all other constructors must call it. Prevents you from not instantiating a class incorrectly and is a better fit for immutable-first types. Perhaps could have some improvements but the common case becomes more terse to write.
> 7a. a) array type can be declared as “int[]” or “int array”; same for list and seq; moreover, it’s the same for any other generic type with one type argument.
Comes from ML, where multi-parameter generics are also written `(x * y) type`. I think it was a good idea to make F# closer to .NET and use `Type<X, Y>`, but they should have done the same for single-parameter generics too to make it consistent. I never use `X array` syntax and prefer `array<x>`, though I would prefer if they also made these case consistent and I could write `Array<x>`, but Array is a module. Not sure how to fix this.
> 8. “fun x y z -> …” syntax for lambda expressions
Again from ML. I imagine there are syntactic ambiguities if you drop the `fun`, as `->` is also used in pattern matching and other places.
I dislike the idea of spaces being significant, and there are already gotchas in F# where this is the case. `x().y` and `x ().y` are not always the same thing.
> 12. “<-” for assignment. Another personal thing, maybe, but “:=” seems easier to type.
`:=` was used for ref cell assignment, but is now deprecated.
In early versions of F# you had to stick `#light` at the top of a file to use lightweight syntax, which is now the default. The verbose syntax, which is closer to ML was originally the default.
> 1. You have to manually order your files in F# projects in order they must be processed by the compiler.
This is one of my favourite features of F# because it forces you to design your code in a way that minimizes mutually recursive types, since all mutually recursive types must live in the same code file. You end up with cleaner code which is easier to test, maintain and reason about.
> 2. No break and continue for loops. 3. No do-while loops.
I've never seen as a problem because I rarely write loops. It's so rare that I use them I end up having to double-check the syntax. I always reach to .map, .fold, .filter, etc first, and I can't remember a time I couldn't express what I wanted using these.
> 6. Awful type constructor syntax
The primary constructor syntax makes sure all other constructors must call it. Prevents you from not instantiating a class incorrectly and is a better fit for immutable-first types. Perhaps could have some improvements but the common case becomes more terse to write.
> 7a. a) array type can be declared as “int[]” or “int array”; same for list and seq; moreover, it’s the same for any other generic type with one type argument.
Comes from ML, where multi-parameter generics are also written `(x * y) type`. I think it was a good idea to make F# closer to .NET and use `Type<X, Y>`, but they should have done the same for single-parameter generics too to make it consistent. I never use `X array` syntax and prefer `array<x>`, though I would prefer if they also made these case consistent and I could write `Array<x>`, but Array is a module. Not sure how to fix this.
> 8. “fun x y z -> …” syntax for lambda expressions
Again from ML. I imagine there are syntactic ambiguities if you drop the `fun`, as `->` is also used in pattern matching and other places.
> 9. a) <expression>[<expression>] = <indexingExpression> ... Please, please implement this.
I dislike the idea of spaces being significant, and there are already gotchas in F# where this is the case. `x().y` and `x ().y` are not always the same thing.
> 12. “<-” for assignment. Another personal thing, maybe, but “:=” seems easier to type.
`:=` was used for ref cell assignment, but is now deprecated.