>In F#, all variables, functions, types and files can only depend on variables, functions, types and files defined earlier. The benefits of this are the fact that a circular dependency is not possible by default and extra clarity with “what depends on what”, which helps during code analysis and PR reviews
Ehm. So it's like C... with no forward declarations?
No it's not the same thing as in C. What they try to explain but quite badly phrase is that F# (or OCaml, on which it is based) is lexically scoped, values of non local variables are captured in definitions (so they must exist at that time, but also and more importantly they cannot be changed later because of the immutability by default).
In C you can have a function using a global variable, and change to this global variable will affect the function behavior.
Why are algebraic data types called "discriminated unions" here? Is there a subtle difference between the two or is it just that F# calls the same feature differently than OCaml?
Rust doesn't apply. You need a functional language for the kind of robustness we are talking about. Rust got some influences from there but it's not one.
- Discriminated unions with exhaustive check. Check
- No nulls by default. Check
- No exceptions in the business logic. Check
- Strict dependency order. Rust doesn't have this
- Warnings on unused expression results. Check
- Typed primitives. The level of ergonomics this is implemented with in F# I'll say Rust doesn't have this
- Explicit conversions. Check
- Functional approach to concurrency. I think Rust's compile time safety against data races gives this a check. I've used channels for concurrent server processes, it's nice. Check
- Explicit dependency injection. I've never understood what this means
> - Explicit dependency injection. I've never understood what this means
The article seems to mean what's described in this other article as "dependency parameterization" where the dependency is explicitly passed to the function (and every function it calls that also needs that same dependency). This is as opposed to, in OO languages, setting the dependency (typically) during construction (however the object is constructed). Or it's otherwise set in some larger scope than the functions which make use of it (global, module, object instance, whatever is appropriate to the language and task).
Most of these points are related to strict type system. If that was the case, then Lisp wouldn't be functional programming language.
IMO the first and foremost principle of Functional Programming languages is that they are optimised around building programs in terms of function composition. And anyone who had to work with borrow checker and closures for 5sec knows, that this is not the case for Rust.
I think you've taken it backwards. The comment you were replying to is listing features that lead to robustness (many of which appear in strongly-typed functional languages in the ML family), not essential aspects of functional programming languages.
>Strict dependency order
>In F#, all variables, functions, types and files can only depend on variables, functions, types and files defined earlier. The benefits of this are the fact that a circular dependency is not possible by default and extra clarity with “what depends on what”, which helps during code analysis and PR reviews
Ehm. So it's like C... with no forward declarations?
No it's not the same thing as in C. What they try to explain but quite badly phrase is that F# (or OCaml, on which it is based) is lexically scoped, values of non local variables are captured in definitions (so they must exist at that time, but also and more importantly they cannot be changed later because of the immutability by default).
In C you can have a function using a global variable, and change to this global variable will affect the function behavior.
Also because Microsoft spends relatively little on it and so it’s not changing at a fast pace.
The short answer - F# and similar languages provide confidence in correctness due to being strongly typed.
The long answer - https://bartoszmilewski.com/2014/10/28/category-theory-for-p...
Immutability by default contributes just as much if not more
I feel that shortened it too much.
Why are algebraic data types called "discriminated unions" here? Is there a subtle difference between the two or is it just that F# calls the same feature differently than OCaml?
Microsoft explained why we love Rust so much ;)
Haskell, Ocaml, scala
anything else?
Rust, ReasonML
Rust doesn't apply. You need a functional language for the kind of robustness we are talking about. Rust got some influences from there but it's not one.
What are "we" talking about?
- Immutability by default. Check
- Discriminated unions with exhaustive check. Check
- No nulls by default. Check
- No exceptions in the business logic. Check
- Strict dependency order. Rust doesn't have this
- Warnings on unused expression results. Check
- Typed primitives. The level of ergonomics this is implemented with in F# I'll say Rust doesn't have this
- Explicit conversions. Check
- Functional approach to concurrency. I think Rust's compile time safety against data races gives this a check. I've used channels for concurrent server processes, it's nice. Check
- Explicit dependency injection. I've never understood what this means
7/10
> - Explicit dependency injection. I've never understood what this means
The article seems to mean what's described in this other article as "dependency parameterization" where the dependency is explicitly passed to the function (and every function it calls that also needs that same dependency). This is as opposed to, in OO languages, setting the dependency (typically) during construction (however the object is constructed). Or it's otherwise set in some larger scope than the functions which make use of it (global, module, object instance, whatever is appropriate to the language and task).
https://fsharpforfunandprofit.com/posts/dependencies/
https://fsharpforfunandprofit.com/posts/dependencies-2/
Most of these points are related to strict type system. If that was the case, then Lisp wouldn't be functional programming language.
IMO the first and foremost principle of Functional Programming languages is that they are optimised around building programs in terms of function composition. And anyone who had to work with borrow checker and closures for 5sec knows, that this is not the case for Rust.
I think you've taken it backwards. The comment you were replying to is listing features that lead to robustness (many of which appear in strongly-typed functional languages in the ML family), not essential aspects of functional programming languages.
Erlang, Elixir.