A practical introduction to functional programming

http://maryrosecook.com/blog/post/a-practical-introduction-to-functional-programming

by danso • 11 years ago

240 62 11 years ago

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?

jacquesm5• 11 years ago

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.

bufordsharkley3• 11 years ago

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.

girvo• 11 years ago

Interestingly, at least at the places I've worked at recently, that functional "style" or kernel of truth is being picked up by more and more PHP programmers. It's great, makes it far easier to test code.

jgable2• 11 years ago

I am. I know python quite well, but I did not understand functional programming before I read this article. Oh sure, I'd looked it up on wikipedia, and read a few blog posts, and perused a Haskell tutorial, but none of that made it click. Too many new concepts at once. Using python as the instructive language is great simply because many people know python, and for those who don't, the syntax is easy to follow.

This article was perfect for me. The "guide rope" paragraph instantly clarified and put into context all the other disjoint pieces of information that I had picked up.

I can now see how to apply these concepts in almost any language. Right away, I can see how to refactor my side-effect-riddled C++ to make it more suitable for unit tests.

I came across this piece after following a previous story on HN, and was very tempted to post it at the time, because it really helped me.

bufordsharkley3• 11 years ago

It really is an excellent introduction to FP, but:

I know python quite well, but I did not understand functional programming before I read this article

Sounds like someone who would have benefitted from practical uses of FP in python, such as comprehensions.

...It's a really neat article, but I think it would have been considerably improved with asides for "And here's an even cleaner way to write this, if you're using python"

zmmmmm• 11 years ago

I thought leaving out list comprehensions was an excellent idea - it is a construct that few programmers from other languages would understand, and would have caused parts of the article to turn into a python tutorial. As it is, the python is close enough to universal pseudo-code.

If I was going to claim it was perverse I would say it is a little perverse to teach FP concepts in a language that doesn't support tail call optimisation. Eventually someone who tries to apply this rigorously is going to get an unpleasant surprise in Python. But since it is more about explaining principles than language details I would give it a pass on that anyway.

agumonkey2• 11 years ago

Because the purpose is to demonstrate the use of functions. * comprehensions are syntactic sugar above them and would hide their true nature.

csandreasen• 11 years ago

I can see the value in not using Python's comprehensions because although they provide an easy way to write map and filter, there's no clean, consistent way of expressing fold (or reduce or whatever you want to call it) - at least, not without altering state, which flies in the face of what this tutorial is trying to teach. Since those are the big three, I can see the value of writing everything with lambdas in the tutorial just to keep things consistent.

That said, I agree that it would have been helpful to at least give a mention to list/generator comprehensions.

warkid• 11 years ago

This would show that with proper language support FP could be much more pleasant. Who would want to try and apply ideas from this worderful article to, say, her everyday C++ coding? After seeing something like squares=[x*x for x in range(10)] she would write exactly WHAT in C++?

woah• 11 years ago

JS would probably have been a better language for a few reasons:

- braces denote function bodies, even if you don't code it's pretty obvious.

- no strange difference between lambda and def, a function is a function

rsp1984• 11 years ago

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.

angersock5• 11 years ago

Eh, I think that leaving out first-class functions is unforgivable. The complete spirit of functional programming can be neatly summed up as:

"Functional programming is the creation of useful programs using only functions mapping input arguments (perhaps themselves functions!) to outputs (also perhaps functions!) without external state."

You can't leave out the function part of functional programming.

gracenotes• 11 years ago

I would agree with GP that emergent code organization principles that come from eliminating side effects are the crux of FP, as far as being the bottom line of what makes it effective and worth internalizing.

Higher-order functions are a simple and powerful form of abstraction, but not much else. I could imagine something which has the software engineering benefits of an FP language without HOF, although maybe it wouldn't culturally be one.

I think getting enthusiastic about higher-order functions and trying to use them in OO languages can range from good to neutral to bad. On the plus side, code is usually shorter. On the negative side, it's not necessarily more readable, and types still usually expose the same amount of information about their inputs/outputs, which is "call me, anything can happen" (plus plenty of opportunity for lazy side effects, the most confusing kind).

SeanDav• 11 years ago

I am probably making a similar point to "gracenotes" here, but as I see it the functions in functional programming are simply a tool that can be used in order to achieve side effect free programming. They are not what really defines functional programming as a concept, even though they share the root name "function".

stonemetal• 11 years ago

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.

coolsunglasses2• 11 years ago

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.

rtpg• 11 years ago

An FP language doesn't preclude non-FP code, just like OOP doesn't preclude ... procedural code? I'm not sure what the opposite would be but it exists (think Matlab code).

I would argue that the lisps are not very functional languages (both in the importance of effects and the style of code I've seen written in lisps), but Scala provides for a lot of FP assurances (val over var, good FP-y libs), and people in the community value effectlessness. So I'm comfortable calling Scala a FP language.

agumonkey2• 11 years ago

Would concatenative languages apply ?

nbevans3• 11 years ago

Yep. It always amazes me when die-hard OOP'ers get it all wrong and think FP is at war with their beloved OO. Well no. Plenty of FP languages exist that combine FP and OO together. Scala.. F#.. OCaml.. etc.

seanmcdirmid5• 11 years ago

It always amazes me when die-hard FP'ers get it all wrong and think OOP is at war with their beloved FP. Well no, plenty of OOP languages exist that combine FP and OO together. Scala.. C#.. Clojure.. etc.

ww5202• 11 years ago

You've got it wrong. OOP'ers have no problem using FP. It is die-hard FP'ers who would disparage OOP whenever given the chance.

tel5• 11 years ago

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• 11 years ago

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

coolsunglasses2• 11 years ago

Yes, but you can uncouple the API talking about and generating IO actions from the performance of those IO actions if you have a pure, lazy language.

tel5• 11 years ago

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

esaym• 11 years ago

I found Higher Order Perl as a good tutor as well: http://tinyurl.com/orwm2ed

bmn_• 11 years ago

http://amazon.com/dp/1558607013

huehue• 11 years ago

http://www.plover.com/amazon.html

Tycho• 11 years ago

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• 11 years ago

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

lateguy• 11 years ago

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

avinassh• 11 years ago

Yes, since the author works at Hacker School.

scarylettuce• 11 years ago

So clearly written. Thank you.

A practical introduction to functional programming

Related Stories