3 ms·

> In a functional language, you describe the problem to the computer, and it solves it for you. Isn't this the definition of a declarative programming paradigm

by peaton 12y ago

> In a functional language, you describe the problem to the computer, and it solves it for you. Isn't this the definition of a declarative programming paradigm? (I.e. SQL?)

munro 12y ago
I had the same thought, seemed off. What I think of "functional programming", and how it seems to be used, is that a function has to be pure.
- peaton 12y ago
  That's a little vague, I think. Pure functional programming has no side effects. Isn't that as succinct & thorough as it gets?
  - dllthomas 12y ago
    "Pure functional programming has no side effects." Well... every program has side effects when you run it - I don't yet know a language with a type system that reifies CPU temperature. I think it might be correct to say that idealized pure functional programming doesn't rely on side effects for correctness?
    - munro 12y ago
      It makes more sense if you think of your program as schematics for building a machine. Following that metaphor, the type system can help you find flaws in your design. When you build your schematics, you're still constrained by the real world, unfortunately. CPU temperature would just be an IO request, which leaves your program, the runtime collects the information, then feeds it back into your program. I personally like to think of my machine running in a lab, with IO being scientists running around taking data out, doing work, then feeding it back into the machine. :D
      - dllthomas 12y ago
        You missed my point. I'm not talking about reading CPU temperature from the program - that is easily represented as you say. I'm talking about the generation of heat from the very act of running the program. I don't think there is any reasonable thing to label that but a "side effect". It's an unavoidable effect of running the program, it is not in any sense why you run the program, it doesn't show up anywhere in the types, the language gives you no guarantees about it, &c, &c.
        munro 12y ago
        You're conflating the term "side effect", in functional programming it only describes purity. That is all. [1] [1] http://en.wikipedia.org/wiki/Side_effect_(computer_science) http://en.wikipedia.org/wiki/Side_effect_(computer_science)
        dllthomas 12y ago
        You are going to have to point at something more specific than the article as a whole. At a skim, it seems to support my interpretation perfectly fine. It starts off: "In computer science, a function or expression is said to have a side effect if, in addition to returning a value, it also modifies some state or has an observable interaction with calling functions or the outside world." The increase in CPU temperature certainly an "observable interaction with [...] the outside world". Given that you are given no kinds of guarantees about the semantics of this interaction in any language I'm aware of, it would be poor engineering to rely on it, but that doesn't mean it doesn't happen or that it is not a side effect.
        tel 12y ago
        Well (a -> Void) "morally" ensures it'll never be run... kind of. I'll show myself out.
    - Dewie 12y ago
      How about: no side effects within the defined semantics of the language. I doubt that CPU temperatures are part of many language specs.
      - deleted 12y ago
        [deleted]
      - dllthomas 12y ago
        I think I'm comfortable with that. Then you push the "that we care about" question down to considering correctness and optimization of implementations.
UberMouse 12y ago
According to Wikipedia Functional Programming fits under the Declarative Programming paradigm. I'm not sure how accurate that is, but it seems to hold some truth. "Functional programming, and in particular purely functional programming, attempts to minimize or eliminate side effects, and is therefore considered declarative." "While functional languages typically do appear to specify "how", a compiler for a purely functional programming language is free to extensively rewrite the operational behavior of a function, so long as the same result is returned for the same inputs."
- peaton 12y ago
  Ah, I see. That last bit is especially interesting. I would argue that there are many languages (and no reason they couldn't) act otherwise with regard to that second quote. However, the line between pure functional and not starts to become fuzzy as well.
tel 12y ago
Meh. "Declarative" and "functional" are such weak technical terms that it's tough to say whether or not that's true. Or whether or not seeking the truth of such a statement is itself even meaningful.

by peaton 12y ago

> In a functional language, you describe the problem to the computer, and it solves it for you. Isn't this the definition of a declarative programming paradigm? (I.e. SQL?)

munro 12y ago

I had the same thought, seemed off. What I think of "functional programming", and how it seems to be used, is that a function has to be pure.

peaton 12y ago
That's a little vague, I think. Pure functional programming has no side effects. Isn't that as succinct & thorough as it gets?
- dllthomas 12y ago
  "Pure functional programming has no side effects." Well... every program has side effects when you run it - I don't yet know a language with a type system that reifies CPU temperature. I think it might be correct to say that idealized pure functional programming doesn't rely on side effects for correctness?
  - munro 12y ago
    It makes more sense if you think of your program as schematics for building a machine. Following that metaphor, the type system can help you find flaws in your design. When you build your schematics, you're still constrained by the real world, unfortunately. CPU temperature would just be an IO request, which leaves your program, the runtime collects the information, then feeds it back into your program. I personally like to think of my machine running in a lab, with IO being scientists running around taking data out, doing work, then feeding it back into the machine. :D
    - dllthomas 12y ago
      You missed my point. I'm not talking about reading CPU temperature from the program - that is easily represented as you say. I'm talking about the generation of heat from the very act of running the program. I don't think there is any reasonable thing to label that but a "side effect". It's an unavoidable effect of running the program, it is not in any sense why you run the program, it doesn't show up anywhere in the types, the language gives you no guarantees about it, &c, &c.
      - munro 12y ago
        You're conflating the term "side effect", in functional programming it only describes purity. That is all. [1] [1] http://en.wikipedia.org/wiki/Side_effect_(computer_science) http://en.wikipedia.org/wiki/Side_effect_(computer_science)
        dllthomas 12y ago
        You are going to have to point at something more specific than the article as a whole. At a skim, it seems to support my interpretation perfectly fine. It starts off: "In computer science, a function or expression is said to have a side effect if, in addition to returning a value, it also modifies some state or has an observable interaction with calling functions or the outside world." The increase in CPU temperature certainly an "observable interaction with [...] the outside world". Given that you are given no kinds of guarantees about the semantics of this interaction in any language I'm aware of, it would be poor engineering to rely on it, but that doesn't mean it doesn't happen or that it is not a side effect.
      - tel 12y ago
        Well (a -> Void) "morally" ensures it'll never be run... kind of. I'll show myself out.
  - Dewie 12y ago
    How about: no side effects within the defined semantics of the language. I doubt that CPU temperatures are part of many language specs.
    - deleted 12y ago
      [deleted]
    - dllthomas 12y ago
      I think I'm comfortable with that. Then you push the "that we care about" question down to considering correctness and optimization of implementations.

UberMouse 12y ago

According to Wikipedia Functional Programming fits under the Declarative Programming paradigm. I'm not sure how accurate that is, but it seems to hold some truth. "Functional programming, and in particular purely functional programming, attempts to minimize or eliminate side effects, and is therefore considered declarative." "While functional languages typically do appear to specify "how", a compiler for a purely functional programming language is free to extensively rewrite the operational behavior of a function, so long as the same result is returned for the same inputs."

peaton 12y ago
Ah, I see. That last bit is especially interesting. I would argue that there are many languages (and no reason they couldn't) act otherwise with regard to that second quote. However, the line between pure functional and not starts to become fuzzy as well.

tel 12y ago

Meh. "Declarative" and "functional" are such weak technical terms that it's tough to say whether or not that's true. Or whether or not seeking the truth of such a statement is itself even meaningful.