The goal of functional programming?

[n***@gmail.com]

V=C3=A0o 10:13:11 UTC+7 Th=E1=BB=A9 n=C4=83m, ng=C3=A0y 24 th=C3=A1ng t=C6=
I has always been thinking this, but I need a confirmation: The purpose of =
functional programming is to make written program becomes a mathematical pr=
oof. Once a program is correctly written, it is "proved" and is expected to=
work the same in any environment. This is why in FP, immutable is needed, =
otherwise there's no guarantee for the correctness of the "proof", because =
state changes can introduce unexpected behaviors.
Am I correct on the basis of Functional Programming?

Users of Haskell wouldn't know how to or want to
'formally prove correctness'.

If you read their hand-waiving carefully, you can interpret
it to mean: "because it feels nice".

A massive economy of effort [in maintenance, which is
important] is available from 'piping'.
[functional means 'give input & accept output' = piping]

Eg. if you've got a multi-stage process like:--
output textfile |
translate "US" to "you ess" |
delete <crap> | delete <crap2> |
input to TestToSpeech |
translate *.wav to *.mp3 |
store to playing device

And then there's a new fad/virus of replacing apostrophe with 3 bytes,
so your system says "sea aye en tea" instead of "can't",
without being confused by the details of the multistages,
you can just 'slot in a function' [say just before "input to TestToSpeech"]
which translates the 3-bytes to the single-byte ASCII(singleQuote).

Modularity: the greatest productivity tool; means you only need be
concerned with a small part of the whole system ............

[Ben Bacarisse]

***@gmail.com writes:

You are replying to a post from nearly two years ago. That's not
usually very productive but you never know...

Post by n***@gmail.com

V=C3=A0o 10:13:11 UTC+7 Th=E1=BB=A9 n=C4=83m, ng=C3=A0y 24 th=C3=A1ng t=C6=
I has always been thinking this, but I need a confirmation: The purpose of =
functional programming is to make written program becomes a mathematical pr=
oof. Once a program is correctly written, it is "proved" and is expected to=
work the same in any environment. This is why in FP, immutable is needed, =
otherwise there's no guarantee for the correctness of the "proof", because =
state changes can introduce unexpected behaviors.

It's that the sate make it harder. Nothing about a well-written program
should be "unexpected" but even so the proofs are more complex when
state is being changed at almost every stage.

Post by n***@gmail.com

Am I correct on the basis of Functional Programming?

Users of Haskell wouldn't know how to or want to
'formally prove correctness'.

All of them?

Post by n***@gmail.com
If you read their hand-waiving carefully, you can interpret
it to mean: "because it feels nice".
A massive economy of effort [in maintenance, which is
important] is available from 'piping'.
[functional means 'give input & accept output' = piping]
Eg. if you've got a multi-stage process like:--
output textfile |
translate "US" to "you ess" |
delete <crap> | delete <crap2> |
input to TestToSpeech |
translate *.wav to *.mp3 |
store to playing device

Right. That's why a lot of Haskell programs are written like that.
"Piping" is a natural pattern in lazy function languages.

<snip>