4 ms·
I get the feeling the author's total knowledge of functional programming comes from reading -1 comments on Slashdot. > It's theoretically possible that the '
by jmillikin 16y ago
I get the feeling the author's total knowledge of functional programming comes from reading -1 comments on Slashdot.
> It's theoretically possible that the 'f()' or 'x' might
> change between the lazy evaluation of step one and the
> lazy evaluation of step three million. Trying to prevent
> that is what we programmers call a 'hard' problem.
I don't know of any functional language that allows values to change during evaluation.
> Trying to run functional logic in two or more
> simultaneous threads can raise serious problems, for
> instance.
The whole point of using functional programming in multithreaded applications is that it doesn't raise such problems. The data are immutable; one thread doesn't affect the other, unless the programmer explicitly uses stateful constructs like pointers.
> Myth #2 - Functional programming is 'different from' imperative programming.
> [...]
> On the other hand, 'imperative' is also used as a
> contrast to 'functional', on the basis of really poorly
> defined terms. The most common version runs something
> like, "imperative languages use assignment, functional
> languages don't".. a concept I'll jump up and down
> upon later.
I've never heard this definition. Ever. It simply doesn't make any sense; of course functional languages use assignment.
> No, functional programming is not some kind of magic
> pixie dust you can sprinkle on a computer and banish
> all problems associated with the business of
> programming. It's a mindset-altering philosophy and/or
> worldview, not a completely novel theory of
> computation. Accept that. Be happy about it. At least
> friggin' COPE.
This paragraph is completely ridiculous. Functional programming:
1. Is not magic problem-solving pixie dust (obviously).
2. Is not a philosophy, mindset-altering or otherwise.
3. Is a novel theory of computation.
Whether a Turing machine and the lambda calculus are equivalent in power is irrelevant; they are, undeniably, different. Otherwise, there would be no point in using one over the other.
> Myth #3 - Functional programming is referentially transparent
This entire section deals with Perl, which is not a functional language (as it is not based on the lambda calculus). I don't know enough about Perl to state whether the authors assertions are correct, but regardless, they have nothing to do with functional programming.
The second half of section #3 claims referential transparency is impossible because it requires two values with some external equivalent meaning, such as "three" and "3", to be considered equivalent by the program. At this point I'm wondering whether the entire article is some elaborate prank.
> Myth #4 - Functional programming doesn't support variable assignment
> [...]
> According to Church's thesis, all programming languages
> are computationally equivalent. They all do the same
> things, and only the syntactic sugar is different.
Section #4 is already off to a bad start...in fact, reading further, it's just more of the same. Abject confusion, combined with a belief that Perl can be used to demonstrate functional concepts, yielding incomprehensible conclusions.
- hsmyers 16y agoI'd like to propose a new rule similar to Goodwin's--- any response/reply that begins with a personal attack should be ignored from that point forward--- except I'm not sure how I avoid being self referential...
- polynomial 16y agoTo a certain extent sound thinking people already follow this rule, though I don't think it's yet been named as such.
- tptacek 16y agoI'm decently sure "functional programming has been called programming without assignments" comes from Ravi Sethi's programming languages book.
- jmillikin 16y agoIn that case, I'd be very interested to know what Dr. Sethi meant by it. Even the simplest Haskell program requires one assignment (to `main`), so the idea of programming without them seems like an exercise in futility.
- jmreardon 16y agoThe "=" in the declaration of Haskell functions isn't considered an assignment, but a binding of a name to a definition. Usually when you have assignments, you are permitting a name to be rebound to a different value than it had originally. In Haskell you cannot rebind a name. Essentially "=" in Haskell is more like the operator's use in defining mathematical functions. Due to how scoping and how do-comprehensions actually work, you can do some things that look like assignment, but are really creating a new binding in a nested scope. But if you try to bind a name twice in the same scope, the program fails to compile.
- jmillikin 16y agoWhat definition does "assignment" have other than "a binding of a name to a definition"? Keep in mind that there are at least three popular definitions of the = operator: 1. In C or C++, = handles assignment and mutation (no re-assignment): int x = 1; /* assignment */ x = 2; /* mutation */ 2. In Python, = handles assignment and re-assignment (no mutation): x = [1] # assignment x = [2] # re-assignment 3. In Haskell, = handles assignment (no re-assignment or mutation) let x = 1 in Just because Haskell's = operator does not behave like C's = operator is no reason to claim Haskell does not support assignment. In fact, that is the only thing Haskell's = operator supports.