

Arguments in favor of pure functional programming - Confusion
http://apocalisp.wordpress.com/2009/04/27/a-critique-of-impure-reason/

======
bdfh42
I am deeply suspicious of any attempt to define the next "one true way".

Perhaps it is because I have lived (and worked) through Structured
Programming, Object Oriented Programming and now see Functional Programming
promoting a (valid) bid to make a contribution to the general improvement in
the standard of written programs - this time by attempting to eliminate the
side effects of "state".

Each of the previous "one true ways" has made a welcome contribution but only
a contribution.

We must remember that all such programming techniques are intended to help us,
the poor imperfect programmer, write code with fewer bugs. The final code is
always translated into a sequence of simple procedural instructions for the
processor to execute - procedural programming is the foundation upon which all
other edifices are constructed.

~~~
Confusion
I don't think the article promotes functional programming in favor of
structured programming or object oriented programming. Rather it explains why
_pure_ functional programming should be favored over 'impure' functional
programming.

I think your point about 'us poor imperfect programmers' is well supported by
the article, because it argues that purely functional programs are easier to
understand. To quote the article:

 _This is why you have bugs, why programs are hard to debug, and software is
difficult to extend. It’s because programs are difficult to comprehend to the
extent that they are impure. And the reason for that is that they are not
sufficiently abstract. A writer of impure code is not operating on the level
of abstraction of programming. He’s operating at the level of abstraction of
the machine._

~~~
anamax
> [Quoting the article.] It’s because programs are difficult to comprehend to
> the extent that they are impure.

That's wrong.

> And the reason for that is that they are not sufficiently abstract.

Abstraction has nothing to do with functional purity.

> A writer of impure code is not operating on the level of abstraction of
> programming.

Nonsense.

> He’s operating at the level of abstraction of the machine.

The real world has mutable state and all abstractions leak.

I write functional when I can and single-assignment (mechanically
translateable into pure functional, but is often cleaner in procedural
languages) almost all of the rest of the time, so I live on the functional
Kool-Aid(TM).

The above is the sort of crap that makes it harder to get people to write
functional.

~~~
Raphael_Amiard
Argumenting your "That's wrong" "Nonsense" and such interjections would help
me understand the usefulness of your post

~~~
anamax
Functional purity is mostly unrelated to comprehensibility - comprehensible
programs can be pure, or not, and the same goes for incomprehensible
probgrams. The relevant background knowledge is some experience with programs.

If someone knows what both functional purity and abstraction are, they don't
need to be told that they're different and one can have either one without the
other.

"the abstraction of programming" is on the edge of bather and the part that
isn't blather has nothing to do with impure programming.

And, if you don't understand that abstractions leak and that the real world
(and machines) are stateful/not functional, you're in for it.

What part of that is hard to understand?

~~~
ekiru
Pure functions are easier to think about than impure functions. It is easier
to think about simpler things. Pure functions are simpler than impure
functions because their result depends only on their parameters(complexity
being correlated with the number of things on which a thing depends).

If purely functional programs in some language to accomplish some goal are
harder to understand than stateful implementions, the appropriate response is
not to criticize functional programming, but instead to try to find ways to
make that language more understandable or more suitable for accomplishing that
goal.

"And, if you don't understand that abstractions leak and that the real world
(and machines) are stateful/not functional, you're in for it."

I think there are actually conceptual advantages to thinking of the universe
functionally(as a tail-recursive function with all the "state" contained in
the parameters), in case a method for time travel is ever developed. It seems
as though it would be easier to reason about than it would be if the universe
is treated as stateful.

~~~
anamax
> Pure functions are easier to think about than impure functions.

Many pure functions are easier to think about than their impure equivalents,
but it's certaintly not the case the all pure functions are easier to think
about than their impure equivalents.

> Pure functions are simpler than impure functions because their result
> depends only on their parameters.

And, because pure functions have no state, many pure functions have to drag
along state through their parameters that they don't need/use but that their
callees need/use.

> (complexity being correlated with the number of things on which a thing
> depends).

The complexity of the things matters a lot as well.

> If purely functional programs in some language to accomplish some goal are
> harder to understand than stateful implementions, the appropriate response
> is not to criticize functional programming, but instead to try to find ways
> to make that language more understandable or more suitable for accomplishing
> that goal.

"the appropriate response"? Sorry, I have work to do, work that doesn't
include making advocates of functional programming happy, let alone spending
time on things that they haven't been able to do. (Some of the developers of
functional programming systems are quite brilliant so the fact that they
haven't solved certain issues is significant.)

> I think there are actually conceptual advantages to thinking of the universe
> functionally(as a tail-recursive function with all the "state" contained in
> the parameters), in case a method for time travel is ever developed.

Talk about premature optimization, not to mention the bogus assumption that a
universe with time travel can't be stateful.

~~~
ekiru
> Many pure functions are easier to think about than their impure equivalents,
> but it's certaintly not the case the all pure functions are easier to think
> about than their impure equivalents.

I disagree. Most cases of the pure function being harder to think about than
the impure equivalent are a result of either demanding impure semantics from a
pure function(pure functions aren't always the best choice for implementation)
or bad programming. I think that even programs that are best implemented
statefully such as databases are easier to think about if they are defined
conceptually in a pure way(as functions taking an additional parameter to
represent the database state when it is called) regardless of how they are
actually impelmented.

> And, because pure functions have no state, many pure functions have to drag
> along state through their parameters that they don't need/use but that their
> callees need/use.

I don't understand this argument. Calling another function on data from their
parameters is the way functions need/use their parameters.

> "the appropriate response"? Sorry, I have work to do, work that doesn't
> include making advocates of functional programming happy, let alone spending
> time on things that they haven't been able to do.

I'm not saying that you have some sort of obligation to make it possible to
more understandably solve some problem purely. However, as I am one of those
functional programming advocates, I think that you would be helping yourself
by solving problems purely when impure semantics are not a necessary
requirement of the problem(I would also expect that fewer problems than you
might think require impurity). What I meant by what you quoted is not that you
specifically should make a better functional language, but that flaws in the
existing languages are not necessarily a condemnation of the concept of pure
functions.

> (Some of the developers of functional programming systems are quite
> brilliant so the fact that they haven't solved certain issues is
> significant.)

Significant, but hardly an indication that those issues are unsolvable. C was
developed by quite brilliant people, but there were many issues they did not
solve.

~~~
anamax
> Most cases of the pure function being harder to think about than the impure
> equivalent are a result of either demanding impure semantics from a pure
> function(pure functions aren't always the best choice for implementation)

So much for the claim that purity is always easier to understand....

>> And, because pure functions have no state, many pure functions have to drag
along state through their parameters that they don't need/use but that their
callees need/use.

> I don't understand this argument. Calling another function on data from
> their parameters is the way functions need/use their parameters.

Callees provide a service. I don't care how they provide said service, but if
they're "stateful", functional programming exposes that.

> However, as I am one of those functional programming advocates, I think that
> you would be helping yourself by solving problems purely when impure
> semantics are not a necessary requirement of the problem(I would also expect
> that fewer problems than you might think require impurity).

Read up the thread. I'm a believer, and I'm telling you that the way that fp
folk advocate is counter-productive. (Telling people that they shouldn't
reject fp because some future language might be useful for their problem is
especially dumb.)

> C was developed by quite brilliant people, but there were many issues they
> did not solve.

C wasn't developed by folks who were trying to introduce a new type of
programming language. C was, in some sense, an afterthought for them because
their argument was about systems building, not programming languages. Also, it
was a different world then - C didn't really have competitors.

While FP can be a fantastic way of programming, FP advocates are
mindbogglingly ignorant of people and programming in the real. (Perhaps the
ability to write small programs for some non-trivial problems is an obstacle
to understanding.)

But, feel free to ignore me.

~~~
Raphael_Amiard
>FP advocates are mindbogglingly ignorant of people and programming in the
real

I think i agree with you on some points, but this just sounds like mindless
generalisation.

Not all fp advocates are like this, if it were so, we wouldn't see so much
real world solutions to the use of fp in non academical languages

~~~
anamax
> Not all fp advocates are like this, if it were so, we wouldn't see so much
> real world solutions to the use of fp in non academical languages

There is the possibility that FP gets wins despite the actions of FP
advocates.

------
ilitirit
As long as IT services business, the most cost-effective solution will always
be considered best.

