5 ms·

I am a back-end developer, and I don't know front-end. I also know very little of functional programming. Elm is the only language that I like writing, and wh

• al2o3cr 7y ago
  our job is basically to be in a constant state of half broken code In my experience, Elm code is only ever in a state of "horribly broken, won't compile" or "works". Whether that's a bug or a feature depends on what I'm trying to do...
  • 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
• eckza 7y ago
  This has been my experience, 100%.