
Even pure functions have side-effects - ColinWright
http://www.johndcook.com/blog/2010/05/18/pure-functions-have-side-effects/
======
cscheid
Wow. The argument in the original post that is linked to about scalability and
functional programming is almost exactly backwards. Resource usage here is a
silly red herring.

Keeping code free of side effects means you _can_ scale it. Try scaling out to
multiple machines when you have a fundamental bottleneck like serialized state
in your code.

All data-parallel programming techniques, dating back from at least 1985 with
the connection machine lisp, and whose modern friends include MapReduce, come
from unshackling ourselves from too much state.

These benefits come from making software _more_ functional, not _less_
functional.

------
bnegreve
A (pure) function is a mathematical concept. Saying a pure function can have
side effects is like saying a line has a thickness because no one can draw a
line with no thickness.

------
lallysingh
TL:DR; Pure functions still use memory and CPU.

Very insightful. I forgot code ran.

~~~
jerf
Mock him if you like, but he puts his finger on a real problem. When I
encounter a library or language that makes a big deal about being
"declarative", I now consider that a black mark against it, not a feature,
because what that translates to is usually "You still have to tell it how to
get the thing you want, but since we thought we could abstract away all such
performance issues, we've made it impossible to introspect or fix any
performance issues you may encounter, and the language will require bizarre
contortions to get acceptable performance."

Example the first and one of the biggest: SQL. Sure, it's a declarative
language... after you learn how databases work, after you learn how indexes
work, after you profile your biggest hitting queries and work out how to
rewrite them into semantically equivalent queries that perform orders of
magnitude faster, after you learn how to deal with sharding, after you learn
when to denormalize and when not to, after you learn the necessary performance
hacks that trick the indexer into doing what you need instead of what it
thinks is correct, and after a few more things I could go on about, it's a
declarative language where you don't have to worry about performance any more.
Yup, totally declarative.

I like Haskell, but only because I can _mostly_ (although not entirely) see
through it.

 _"The major difference between a thing that might go wrong and a thing that
cannot possibly go wrong is that when a thing that cannot possibly go wrong
goes wrong, it usually turns out to be impossible to get at and repair."_ \-
Douglas Adams

Anything that claims to be declarative is lying. All declarations in some
given environment entail some process that will be used to obtain your
results, you will not be able to get good performance if you don't know that
process, and actively obscuring those processes only makes it harder.

You can't afford to ignore the side effects of "pure" functions.

~~~
polymatter
In the same vane, is the classic article [Evolution of a Haskell
programmer](<http://www.willamette.edu/~fruehr/haskell/evolution.html>). Its
just the factorial function written in different styles in Haskell, each with
very different performance implications.

------
crenshaw
What does the literature say about a pure function that throws an exception?
For example, what of an asynchronous exception like out-of-memory or stack?

~~~
ars
I don't think pure functions are supposed to throw exceptions, instead they
should return error values.

~~~
T_S_
The Maybe and Either type classes are typically used to model exceptions in
Haskell.

~~~
mdwrigh2
There's actually some discussion about how to handle errors in Haskell. See:
[http://blog.ezyang.com/2011/08/8-ways-to-report-errors-in-
ha...](http://blog.ezyang.com/2011/08/8-ways-to-report-errors-in-haskell-
revisited/)

------
T_S_
The main thing a statically typed pure functional language tries to do is
force you to "mark" the side effect in your code with type annotations.
Various effects can be modeled with different types. Many of these types still
support some form of composability, which promotes modularity--a major goal of
functional programming.

Whether every effect can and should be modeled in this way seems to be an open
question that depends on the semantics you wish to apply to your programming
language.

------
mdwrigh2
Anybody know what presentation software the guy in the PyCon talk was using?
That looked pretty slick.

~~~
architech
Looks like Prezi <http://prezi.com/>

