6 ms·

Well, I don't know if "boring" is the word I'd use, but I like _transparent_ stacks: if I make a mistake, it tells me where I made a mistake in a way that I can

Well, I don't know if "boring" is the word I'd use, but I like _transparent_ stacks: if I make a mistake, it tells me where I made a mistake in a way that I can interpret. All of the "boring" stacks have this property.

jimbokun 10y ago
I think this is the biggest selling point for Functional Programming. You know given these inputs, you will always get the same output. Even if not using a Functional Programming language, it is good practice to write your code to follow this principle whenever possible. I think this is what mocks and unit tests try to achieve, creating a scenario where given certain inputs, you know what the output will be.
- nikanj 10y ago
  From what I've seen, functional programming doesn't really excel at error messages
  - edgyswingset 10y ago
    Sure it can - here's an example of an error message added to F# which suggests valid names for Record labels when you've typed an incorrect one: https://github.com/Microsoft/visualfsharp/pull/1102 https://github.com/Microsoft/visualfsharp/pull/1102 Don't confuse correlation (some functional programming languages out there don't have good error messages) with causation (functional programming languages don't excel at good error messages).
    - reitanqild 10y ago
      Elm is also said to be a good example. Haven't gotten around to really test it after hello world though but what I read was somewhat convincing.
      - 616c 10y ago
        I think Evan is really winning people over with his interest and focus on that, as I alluded to in my other comment. http://elm-lang.org/blog/compilers-as-assistants http://elm-lang.org/blog/compilers-as-assistants
        arvinsim 10y ago
        Elm has the best error messages I have seen by far in any language.
  - 616c 10y ago
    But I think there is a point worth noting that nikanj has alluded to. I think the FP languages of increasing popularity (not necessarily simply because they happen to be FP) care about developer interaction with the tool. FP is supposed to be a better tool (not because I want to flame, but from the perspective of its developer), so why are we bragging about all this type info and not using it to convey more relevant info to the developer with less cryptic and much more precise error messaging. I listent to programmer interviews a lot, and this obviously comes up with Rust a lot, and the original dev of Elm to a very siginficant amount. He is most proud of that. I agree: the languages that are winning hearts and minds are those requiring less and less mind to use, thus growing heart. I mean if this crowd will allow very cheesy imagery.
  - bbcbasic 10y ago
    I reckon you are looking at Haskell here, and the ghc compiler in particular. I agree but it's not a property if ever FP language and it doesn't have to be.
    - kccqzy 10y ago
      I might be the odd one here but I think ghc has great error messages, but it's written in an academic style that takes more mental effort to parse and understand.
  - baddox 10y ago
    Empirically, that's probably true, but probably only because functional programming is usually more popular with fiddlers and academics than with get-shit-done developers, so there's simply less time spent on improving developer experience. I can't think of any inherent reason why functional languages would have worse error messages. Elm prides itself in its (compiler) error messages, for instance: http://elm-lang.org/blog/compilers-as-assistants http://elm-lang.org/blog/compilers-as-assistants
- tbrownaw 10y ago
  I don't care about known inputs. I care about correct output (including lack of crashes) on new inputs. Behavior on known inputs is only good for refactoring, not debugging.
  - edgyswingset 10y ago
    Here are two scenarios: 1. Calling a function with the same input sometimes gives you a different output. 2. Calling a function with the same input will always give you the same output. Which do you think will more reliably give you correct outputs? > I care about correct output That's why we unit test. Well, and to protect the requirements of the system from the engineers who change the codebase. Referential Transparency (the concept described above) is a boon to this.
bartread 10y ago
^^^He/she speaketh the truth. I'm having flashbacks about Angular 1.x error stack traces, and their overall complete uselessness, as I write this. Imprecise, inaccurate, or downright misleading errors are the bane of my life. Please: tell me what went wrong and exactly where it went wrong. (As an aside, this is why I'm no lover of the Arrange-Act-Assert test pattern, or of BDD using specflow: both great for telling you that something is wrong, not so clever at giving you a clue what that might be or where it happened. Gurning time vampires the pair of them.)
- mehh 10y ago
  I'd argue the code you have written should help with identifying errors, its not something that comes for free.

jimbokun 10y ago

I think this is the biggest selling point for Functional Programming. You know given these inputs, you will always get the same output. Even if not using a Functional Programming language, it is good practice to write your code to follow this principle whenever possible. I think this is what mocks and unit tests try to achieve, creating a scenario where given certain inputs, you know what the output will be.

nikanj 10y ago
From what I've seen, functional programming doesn't really excel at error messages
- edgyswingset 10y ago
  Sure it can - here's an example of an error message added to F# which suggests valid names for Record labels when you've typed an incorrect one: https://github.com/Microsoft/visualfsharp/pull/1102 https://github.com/Microsoft/visualfsharp/pull/1102 Don't confuse correlation (some functional programming languages out there don't have good error messages) with causation (functional programming languages don't excel at good error messages).
  - reitanqild 10y ago
    Elm is also said to be a good example. Haven't gotten around to really test it after hello world though but what I read was somewhat convincing.
    - 616c 10y ago
      I think Evan is really winning people over with his interest and focus on that, as I alluded to in my other comment. http://elm-lang.org/blog/compilers-as-assistants http://elm-lang.org/blog/compilers-as-assistants
      - arvinsim 10y ago
        Elm has the best error messages I have seen by far in any language.
- 616c 10y ago
  But I think there is a point worth noting that nikanj has alluded to. I think the FP languages of increasing popularity (not necessarily simply because they happen to be FP) care about developer interaction with the tool. FP is supposed to be a better tool (not because I want to flame, but from the perspective of its developer), so why are we bragging about all this type info and not using it to convey more relevant info to the developer with less cryptic and much more precise error messaging. I listent to programmer interviews a lot, and this obviously comes up with Rust a lot, and the original dev of Elm to a very siginficant amount. He is most proud of that. I agree: the languages that are winning hearts and minds are those requiring less and less mind to use, thus growing heart. I mean if this crowd will allow very cheesy imagery.
- bbcbasic 10y ago
  I reckon you are looking at Haskell here, and the ghc compiler in particular. I agree but it's not a property if ever FP language and it doesn't have to be.
  - kccqzy 10y ago
    I might be the odd one here but I think ghc has great error messages, but it's written in an academic style that takes more mental effort to parse and understand.
- baddox 10y ago
  Empirically, that's probably true, but probably only because functional programming is usually more popular with fiddlers and academics than with get-shit-done developers, so there's simply less time spent on improving developer experience. I can't think of any inherent reason why functional languages would have worse error messages. Elm prides itself in its (compiler) error messages, for instance: http://elm-lang.org/blog/compilers-as-assistants http://elm-lang.org/blog/compilers-as-assistants
tbrownaw 10y ago
I don't care about known inputs. I care about correct output (including lack of crashes) on new inputs. Behavior on known inputs is only good for refactoring, not debugging.
- edgyswingset 10y ago
  Here are two scenarios: 1. Calling a function with the same input sometimes gives you a different output. 2. Calling a function with the same input will always give you the same output. Which do you think will more reliably give you correct outputs? > I care about correct output That's why we unit test. Well, and to protect the requirements of the system from the engineers who change the codebase. Referential Transparency (the concept described above) is a boon to this.

bartread 10y ago

^^^He/she speaketh the truth. I'm having flashbacks about Angular 1.x error stack traces, and their overall complete uselessness, as I write this. Imprecise, inaccurate, or downright misleading errors are the bane of my life. Please: tell me what went wrong and exactly where it went wrong. (As an aside, this is why I'm no lover of the Arrange-Act-Assert test pattern, or of BDD using specflow: both great for telling you that something is wrong, not so clever at giving you a clue what that might be or where it happened. Gurning time vampires the pair of them.)

mehh 10y ago
I'd argue the code you have written should help with identifying errors, its not something that comes for free.