News for hackers. Stuff that matters.
Re:Thinking About Recursion by brianberns on Wednesday March 08, 2017 @06:57PM (#13825196)
Man, this article really shows why imperative programming is so much harder to reason about than functional programming.

Difference between "variables" in math vs. functional programming? None. The value of a variable can't change.

Difference between "function" in math vs. functional programming? None. It's just a map from one set to another.

Re:Thinking About Recursion by eikenberry on Wednesday March 08, 2017 @10:43PM (#13826782)
What evidence is there that math is easier to reason about than imperative programming?
Re:Thinking About Recursion by brianberns on Wednesday March 08, 2017 @11:57PM (#13827093)
Here's an article that explains it pretty well: http://fsharpforfunandprofit.com/posts/is-your-language-unre...
Re:Thinking About Recursion by dualogy on Thursday March 09, 2017 @05:51AM (#13828446)
Incomplete assessment.

Functional programming much better supports equational reasoning.

Imperative programming much better supports operational reasoning.

Or you could contrast "data flow" vs "control flow".

I'd have thought we won't need operational reasoning in 2017 but currently I conclude it may always be a part of computer programming..

Re:Thinking About Recursion by khedoros1 on Wednesday March 08, 2017 @08:39PM (#13826011)
You've described the reason that I doubt I'll ever do much with functional programming. Using it to solve a non-trivial problem reminds me unpleasantly of math, rather than lists of instructions.
Re:Thinking About Recursion by dreamcompiler on Thursday March 09, 2017 @12:47AM (#13827279)
This is what I like about FP. As in math, you're expressing ideas about relationships that must always hold true, regardless of time. You think less about how state changes over time and more about what the fundamental "truths" of your program have to be. For me -- and for many problems but certainly not all -- this is an easier way to think.
Re:Thinking About Recursion by dualogy on Thursday March 09, 2017 @05:53AM (#13828453)
yeah "regardless of time and space", as one observes in the resulting time and space usage. By the time the purely functional program has been tweaked for better (time and space) performance, said readability has greatly suffered ;D and I say that as an enthusiastic FPer
Re:Thinking About Recursion by komali2 on Wednesday March 08, 2017 @07:22PM (#13825374)
I don't really know much about functional programming. How can a variable not change?
Re:Thinking About Recursion by crimsonalucard on Wednesday March 08, 2017 @07:29PM (#13825439)
In functional programming the entire program is literally a single expression. This is essentially what functional programming is. A variable in a single expression cannot be modified.
Re:Thinking About Recursion by clusmore on Wednesday March 08, 2017 @07:30PM (#13825452)
In mathematics, variables don't change inside expressions -- they define a family of expressions, each with a different value. For example, in the function

  f(x) = x^2 + x + 1
the value of x in the right-hand-side expression doesn't change in the same sense that variables in imperative languages change. But it allows the single expression "x^2 + x + 1" to have a value which varies by the value of x. For example, f(2) yields the value 7 while f(3) yields the value 13.
Re:Thinking About Recursion by dualogy on Thursday March 09, 2017 @05:57AM (#13828465)
Construct a whole program of functions only with say `readonly` (in c#) or `const` (in EcmaScript) or only `:=` (in Go) "variable" "assignment-declarations", never mutating them after initial declaration. It's possible and it's one of the core tenets of purely FP.