
A practical introduction to functional programming - danso
http://maryrosecook.com/blog/post/a-practical-introduction-to-functional-programming
======
rsp1984
> Ignore all that. Functional code is characterised by one thing: the absence
> of side effects. It doesn’t rely on data outside the current function, and
> it doesn’t change data that exists outside the current function. Every other
> “functional” thing can be derived from this property.

This. So much this. I'd go even further and say functional programming is just
like imperative programming but without variables (except for those passed in
as arguments). This has always struck me as the key difference between the
two. The rest (first class / higher order functions, mapping, reducing,
pipelining, recursing, currying etc) in my opinion is just making things more
convenient in functional languages, dealing with this absence of variables.

The key achievement of functional programming in my opinion is then the
provision of special tools (see above) that help programmers solve particular
problems in particular efficient ways, that programmers would have solved by
using variables in a possibly less efficient way in an imperative language. In
short functional programming forces the user to pick the right tool for the
task.

~~~
stonemetal
How many functional programming languages do you cross of the list of
functional programming languages if you make that claim? At the very least
anything Lisp related, all the ML languages as well. You are pretty much left
with Miranda, Haskell, and a few related languages.

~~~
coolsunglasses
>You are pretty much left with Miranda, Haskell, and a few related languages.

Agda and Idris as well.

The bar for what constitutes "FP" has been changing since the 50s. Doesn't
sound unreasonable to me.

~~~
seanmcdirmid
Functional programming used to mean programming with first class functions and
closures; they even put it in the name "functional"al programming (just like
OOP meant program with objects, whether this involved classes or not).

So that is Lisp, the first FP in the 60s, and then the MLs of the 70s/80s.
They knew about purity, and even preferred it (for things like list
comprehensions, it is very useful), but were never very dogmatic about it.

------
esaym
I found Higher Order Perl as a good tutor as well:
[http://tinyurl.com/orwm2ed](http://tinyurl.com/orwm2ed)

~~~
bmn_
[http://amazon.com/dp/1558607013](http://amazon.com/dp/1558607013)

~~~
huehue
[http://www.plover.com/amazon.html](http://www.plover.com/amazon.html)

~~~
ldng
[http://en.m.wikipedia.org/w/index.php?title=Special%3ABookSo...](http://en.m.wikipedia.org/w/index.php?title=Special%3ABookSources&isbn=978-1558607019)

------
tel
It's worth noting that things like print and random are just as much side
effects as mutability. To eliminate random is easy: realize that random
generation is a function from a hidden random generator state to a "random"
value and a new random generator state. Now use state-minimization techniques.

To eliminate print is much harder.

~~~
rubiquity
print is IO so of course it is hard to eliminate side effects.

~~~
tel
IO monads aren't the only way. If all you want is print it's even quite easy.

~~~
sanderjd
Please do tell or link to more, if you're willing!

~~~
tel
Print alone is easy as you can just have functions output both their normal
output and a listing of whatever they printed. These listings then get
concatenated together (this is technically "the writer monad", but you don't
need to know as much).

IO was originally handled in Haskell as `main :: [String] -> [String]`. More
generally, we might think `main :: [Input] -> [Command]`. This is obviously a
pure function. If the types Input and Command are a bit like

    
    
        Input   = SawChar Char   | Tick UTCTime | FileRecv String
        Command = PrintChar Char | RequestTime  | RequestFile FilePath
    

you can imagine how a more general effects framework could be done purely.

In practice, monads are a lot simpler than this. In particular, it can be easy
to get desynchronized from your Commands and Inputs.

Other language have more explicit effect typing as well. Conor McBride's
`Frank` comes to mind, but it's fairly complex.

------
Tycho
The lambda syntax seems like a major shortcoming in Python's readability. It
uses the comma in its declaration and then the comma is used again a separator
for the arguments being passed into the outer function (reduce in this case).
I feel their should be better visual indication for when you are out of the
lambda part.

~~~
hueving
Isn't the colon an adequate indicator that you have left the anonymous
function declaration?

------
bufordsharkley
Seems somewhat perverse to do this in python, and never once mention
list/generator comprehensions.

I get that this isn't a guide for using functional programming in python, but
rather a guide for using functional programming in non-python languages, shown
with examples in python. But practically, who's the audience for that?

~~~
jacquesm
> But practically, who's the audience for that?

Anybody that would benefit from re-using some of the lessons from functional
programming such as side-effect free programming, splitting pure and stateful
code and so on (though some of the examples could do this better than they do
now it is a step in the right direction).

Python, PHP, Java, Ruby and C programmers could learn quite a bit from this.

~~~
bufordsharkley
It's a well-written and nice article, but just kinda weird in spots, saying
that the code is more self-evident and readable, whereas I think it's
sometimes making a language do something it only does with considerable
strain.

Insofar as python is essentially pseudocode, I can get the appeal of writing
non-pythonic python, but ... it strains it a bit to do this for such extensive
use of lambda, the most awkward bit of syntax in python, one that almost
always has more readable alternatives.

~~~
ferrari8608
Any time I see a use for lambda (typically only with the functional builtins),
I just write a function instead. Two extra lines are worth it for the
readability alone. You can also reuse a function, which makes more sense to me
than potentially writing the same lambda multiple times.

I do like that the author used Python, even if it was only for the purpose of
pseudocode. Python is, after all, "executable pseudocode". It's also the only
language I really know in-depth.

------
lateguy
I think the same article was on hacker school website also?

~~~
avinassh
Yes, since the author works at Hacker School.

------
scarylettuce
So clearly written. Thank you.

