Comments by "" (@jboss1073) on "Is Functional Programming DEAD Already?" video.
-
4
-
3
-
3
-
2
-
2
-
2
-
2
-
@SeeingBackward "I'm not getting what you're going for here with either of those..."
Allow me to explain
"With the first, I could see the point of the original comment being that there is an analogy between Cartesian and Polar coordinates in Classical Mathematics and Procedural and Functional programming within computer science."
But there isn't.
"In both instances, each are able to describe solutions covering (generally) the same problem-spaces, and the solution descriptions are (generally) translatable between the systems (maybe with a few special cases described idiomatically) but often one translation of a given solution is much more compact than the other."
But this happens between any two mathematical ways to do one thing, and "cartesian versus polar coordinates" does not capture anything more than that generality.
"Which is not to say that Set Theory vs Type Theory could not be a more perfect analogy, but it also seems that you didn't describe how that is so."
It should be obvious how Set Theory vs Type Theory is a more apt comparison of Procedural vs Functional programming, namely because Procedural programming is based on Set Theory and Functional programming is based on Type Theory.
"With the second comment, it seems like the commenter you were replying to was pointing out that computer architecture, as it exists today, is only the stateful manipulation of memory according to a stream of instructions to the processor which carries out those state changes, and that compilers translate the stateless algorithmic descriptions of FP into equivalent stateful steps that referentially transparently produce the same result described by the FP 'lambda calculus equation'."
No. He said:
"The underlying components in a CPU have state and side effects ... So..."
Which I interpreted as:
"Since the CPU is stateful, it's pointless to use a stateless language, because it's like avoiding the unavoidable"
To which you said:
"I'm not sure what your reply has to do with that,"
Simple: I am saying "what is actually pointless, is to point out that we shouldn't be using functional stateless programming just because the CPU is procedural, because if you think that there is a huge semantic gap between functional and procedural, I'd like to remind you Algebraic Effects have proven that functional programming with all side-effects type-checked is equivalent to procedural programming".
For example, the exact same code below:
v1 = new_variable
v2 = new_variable
put(v1, 9)
put(v2, "hello")
print(get(v1))
put(v1, 10)
print(get(v1))
print(get(v2))
is both valid Procedural code unmodified as-is and pure, stateless functional programming code unmodified as-is (using Algebraic Effects, with all side-effects type-checked), but can never be valid OOP code unmodified as-is.
Therefore the point I am making is "the notion that it is pointless to code functionally statelessly just because we're targeting stateful CPU necessarily assumes that Procedural and Functional are oh-so-far-away from each other, which is the opposite of the truth; OOP is the odd paradigm out of the three Procedural, FP and OOP. FP proved it is equivalent to Procedural and that it can type-check all side-effects of unmodified Procedural code. Meanwhile OOP remains impenetrable to type-checking or to anyone interested or who cares about this at all for OOP.
"especially as type-checking has always been what compilers do in any 'strongly-typed' language"
No, "strongly-typed languages" do tag checking, which is not the same as algebraic type checking using Hindley-Milner algebra.
"and procedural code by definition works by manipulating the side-effects of state changes of memory..."
And only FP can type-check all side-effects of Procedural code unmodified as-is, which proves that both FP and Procedural are equivalent, and hence, since FP and Procedural are equivalent, it's quite silly to say "you shouldn't code in FP because the CPU is Procedural, derp!" since once again and for the last time FP and Procedural are equivalent and so we code in FP to get the benefits of type-checking side-effects that haven;'t migrated over to "strong-typed languages" yet because their "type-checker" are not real "algebraic type-checkers" buts rather "tag-checkers", checking the tags of argument "types" (tags) against the tags of parameter "types" (tags), while a proper "algebraic type-checker" like that of Rust, SML, OCaml, Haskell, knows much more than to check argument type against parameter type and can actually reason equationally holistically throughout the program and check if all program interactions are valid type-wise. This is a much more powerful type-checking ability than the mere tag-checking of C/C++/Java/C#/etc.
2
-
2
-
2
-
2
-
2
-
2
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1
-
1