Hacker News Reader

Comment by peaton | Hacker News Reader

> 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?)

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."

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.

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.

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.

That's a little vague, I think. Pure functional programming has no side effects. Isn't that as succinct & thorough as it gets?

"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?

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

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.

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)

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.

Well (a -> Void) "morally" ensures it'll never be run... kind of.

I'll show myself out.

How about: no side effects within the defined semantics of the language.

I doubt that CPU temperatures are part of many language specs.

I think I'm comfortable with that. Then you push the "that we care about" question down to considering correctness and optimization of implementations.

Reply on news.ycombinator.com