5 ms·

That's interesting. How does Elm statically know if the logic of your app is correct? Since I don't know Elm I'll use some pseudocode: if condition pour

by Touche 7y ago

That's interesting. How does Elm statically know if the logic of your app is correct? Since I don't know Elm I'll use some pseudocode: if condition pourCoffee() else pourTea() Is Elm able to determine that this condition is flipped the wrong way?

jlengrand 7y ago
Yes, because in elm everything is pure. At least in the code you write. Elm will force you to declare all possible cases that can happen, all branches in every function you write. That leaves literally nothing to break. Not saying you can't break an elm program. But you won't run into runtime exceptions in elm, by design:)
jweir 7y ago
Elm makes no claims to correct your logic. Logical errors are not caught by the compiler. You might still decode a JSON field to the wrong field on a Record (if the fields are the same type), you might invert a BOOL and use True were you meant False, you might incorrectly calculate some value, etc. But, state errors are caught – your application can not get into an impossible state and therefore should never have any runtime errors. Getting back to logical errors – Elm can provide some additional safeguards. For example you could have a record ``` type alias Point = { x: Int, y: Int } ``` and then decode it with ``` decode.map2 Point (field "y" int) (field "x" int) ``` Whoops you got the wrong order. So you could make X and Y explicit types: ``` type alias Point = { x: PointX, y: PointY } type PointX = PointX Int type PointY = PointY Int decode.map2 Point (field "x" decodeX) (field "y" decodeY) ``` Now your decoder won't compile unless the types line up correctly. But this adds a bit of extra overhead in unwrapping the values, but not much.
jasim 7y ago
Neither Elm, nor any language in the Typed FP family, can do that. What it can do is to prevent us from making clerical mistakes. That's the surprising thing I learned programming in Typed FP: we very rarely make logical mistakes. Our programs are all broken, make no mistake, but they are broken not because we accidentally swapped a conditional (logical mistake), but rather because we passed in data of the wrong shape (clerical mistake). A common clerical mistake which Elm, Reason etc. prevents, is when we grab something from a list and pass it to another function. What if in a rare case it is possible that the element doesn't exist? A function deeper in the stack might crash, or if defensively built, substitute it with an empty value. Both could be wrong. By providing more information about our data and our functions to the compiler, the compiler can ensure our code always follow those constraints. These constraints are often in our head when using dynamically typed languages, or even statically typed OO languages. Typed FP helps us make them explicit in code so the compiler can track it instead of we tiring ourselves mentally and making a mess of it.
- santoriv 7y ago
  Just want to give props. This is the clearest explanation of the value of typed FP I've ever seen.
  - jasim 7y ago
    :)
- not_smart 7y ago
  > These constraints are often in our head when using dynamically typed languages, or even statically typed OO languages. I’m curious about this comment on statically typed OO languages. I work mainly with C# and don’t have much FP experience. Are you referring to exhaustive matching? Edit: To clarify, I understand that C# compiler won’t prevent you from trying to access an element in an empty collection. What prevents you, in a typed FP language, from accessing head of an empty list?
  - jasim 7y ago
    Yes I was thinking of a couple of things, but most importantly the existence of null in the language. So functions either receive exactly the type they were looking for (which is better than dynamically typed), or a null (which never happens in a Typed FP language). In OCaml, (List.hd []) throws an exception, which is not a desirably behaviour, so we mostly use a safer version of List.hd which would return an option type. This could be either "None" or "Some(value)". To operate on option types, we have to pattern match and handle both cases where the value could be either None or Some) Exhaustive pattern matching is useful here, so is the very notion of variants. Without variants (or sum type / union type) we tend to leave domain concepts implicit in the codebase. While we can simulate variants with classes, it is too unwieldy to be used except for core domain concepts.
    - not_smart 7y ago
      Got it, thanks!
- 7y ago

by Touche 7y ago

jlengrand 7y ago

Yes, because in elm everything is pure. At least in the code you write. Elm will force you to declare all possible cases that can happen, all branches in every function you write. That leaves literally nothing to break. Not saying you can't break an elm program. But you won't run into runtime exceptions in elm, by design:)

jweir 7y ago

Elm makes no claims to correct your logic. Logical errors are not caught by the compiler. You might still decode a JSON field to the wrong field on a Record (if the fields are the same type), you might invert a BOOL and use True were you meant False, you might incorrectly calculate some value, etc. But, state errors are caught – your application can not get into an impossible state and therefore should never have any runtime errors. Getting back to logical errors – Elm can provide some additional safeguards. For example you could have a record ``` type alias Point = { x: Int, y: Int } ``` and then decode it with ``` decode.map2 Point (field "y" int) (field "x" int) ``` Whoops you got the wrong order. So you could make X and Y explicit types: ``` type alias Point = { x: PointX, y: PointY } type PointX = PointX Int type PointY = PointY Int decode.map2 Point (field "x" decodeX) (field "y" decodeY) ``` Now your decoder won't compile unless the types line up correctly. But this adds a bit of extra overhead in unwrapping the values, but not much.

jasim 7y ago

Neither Elm, nor any language in the Typed FP family, can do that. What it can do is to prevent us from making clerical mistakes. That's the surprising thing I learned programming in Typed FP: we very rarely make logical mistakes. Our programs are all broken, make no mistake, but they are broken not because we accidentally swapped a conditional (logical mistake), but rather because we passed in data of the wrong shape (clerical mistake). A common clerical mistake which Elm, Reason etc. prevents, is when we grab something from a list and pass it to another function. What if in a rare case it is possible that the element doesn't exist? A function deeper in the stack might crash, or if defensively built, substitute it with an empty value. Both could be wrong. By providing more information about our data and our functions to the compiler, the compiler can ensure our code always follow those constraints. These constraints are often in our head when using dynamically typed languages, or even statically typed OO languages. Typed FP helps us make them explicit in code so the compiler can track it instead of we tiring ourselves mentally and making a mess of it.

santoriv 7y ago
Just want to give props. This is the clearest explanation of the value of typed FP I've ever seen.
- jasim 7y ago
  :)
not_smart 7y ago
> These constraints are often in our head when using dynamically typed languages, or even statically typed OO languages. I’m curious about this comment on statically typed OO languages. I work mainly with C# and don’t have much FP experience. Are you referring to exhaustive matching? Edit: To clarify, I understand that C# compiler won’t prevent you from trying to access an element in an empty collection. What prevents you, in a typed FP language, from accessing head of an empty list?
- jasim 7y ago
  Yes I was thinking of a couple of things, but most importantly the existence of null in the language. So functions either receive exactly the type they were looking for (which is better than dynamically typed), or a null (which never happens in a Typed FP language). In OCaml, (List.hd []) throws an exception, which is not a desirably behaviour, so we mostly use a safer version of List.hd which would return an option type. This could be either "None" or "Some(value)". To operate on option types, we have to pattern match and handle both cases where the value could be either None or Some) Exhaustive pattern matching is useful here, so is the very notion of variants. Without variants (or sum type / union type) we tend to leave domain concepts implicit in the codebase. While we can simulate variants with classes, it is too unwieldy to be used except for core domain concepts.
  - not_smart 7y ago
    Got it, thanks!
7y ago