# why are all the functional programming tutorials so mathy?

I've been trying to learn functional programming and most tutorials I have found use math as examples for the more complicated constructs (even the simple ones in some cases). Why is this? I would imagine something easier could be used. Its making it difficult to learn.

Background Info: I have been writing software for 12 years. I understand some of the concepts such as closures, functions as first class citizens, and generics. I may be having problems with higher-order functions at some advanced level, but I would like to believe I have a basic grasp. Monads are biting me in the butt, and at this point I haven't gotten past that (I'm sure I will eventually, because I'm persistent).

-
only a little, i haven't tried the other 3 languages you suggested – Charles Lambert Aug 26 '11 at 4:01
F# is easiest thing to start if you know C#. Doesn't request big mathematics knowledge. – Heather Aug 26 '11 at 6:29
Try SICP - it does not go too much beyond the high school math. – SK-logic Aug 26 '11 at 8:09
@Charles Lambert - Go watch OfficeSpace and you'll get the second part of Job's comment. – Jetti Aug 26 '11 at 15:08
@Charles Lambert: Learn You a Haskell for Great Good is not too mathy :D – Matthieu M. Aug 26 '11 at 17:03

They use math because Functional Programming is very good at modelling mathematical constructs and is very tied into mathematical concepts, particularly Lambda Calculus. Also since I/O is typically a fairly thorny and advanced subject in a lot of languages of the functional paradigm mathematics via the REPLs of the various languages becomes a good way of teaching the language at first.

Because Functional Programming treats Functions as first class constructs within the programming language, function generation becomes very important. Therefore higher math becomes fairly important particularly graph theory.

Imperative Languages are just as mathy but it's all arithmetical at base since they are closer to the machine which can only add anyway. Functional languages with their higher abstraction tend more toward mathematics. The general use in academia doesn't help either as they get used and thus taught by people who know a lot of math and are teaching people who are expect to learn a lot of math. So it's possible to "dumb it down" so to speak but it is unlikely given these factors.

http://learnyouahaskell.com/ - Is probably one of the gentlest introductions to Functional Programming, I double checked and there's nothing beyond basic algebra and graph theory in there.

-
+1 for the point about avoiding I/O – Peter Taylor Aug 26 '11 at 8:26
learnyousomeerlang.com is also an option if you want something else besides Haskell. – Travis Aug 26 '11 at 15:40

There are numerous reasons, and they are all kind of related:

• Most functional programming languages were developed in an academic context, where CS is closely linked with Mathematics, so the people who designed them have a strong Math background (and tend to assume the same about their audience)
• Functional programming is a paradigm especially suited to solve math-heavy problems
• The theory behind FP, lambda calculus (basically, an abstract theory of functions), is a branch of Mathematics, and FP languages tend to use the concepts and terminology from lambda calculus

Also, FP isn't any more mathy really than other paradigms, but the key concepts (functions as real first-class citizens, higher-order functions, closures, and purity) require a certain mindset. At some point, your mind should go "click"; if you understand these 4 core ideas, the rest is likely to be just as easy as any other paradigm.

-
+1 for developed in academia: people creating functional languages base it on mathematical properties, so it leaks... – Matthieu M. Aug 26 '11 at 17:04
@Matthieu M: Basing a programming language on mathematical properties helps to write correct software and reduce development time. For example, I definitely spend less time debugging my Haskell code than my C++ code. Reducing development time (and costs) is a huge practical advantage which can justify the effort of learning some maths. As tdammers pointed out, there are a few extra concepts that need to be learnt but after you have understood a few core ideas FP is as intuitive as imperative programming. – Giorgio May 9 '13 at 9:15
I also agree with tdammers that also imperative languages can be described using mathematical concepts. In fact, a mathematical description of an imperative program is normally much more complex than a mathematical description of a functional program. IMO this explains why imperative languages are more likely to contain bugs: it is more difficult to fully understand imperative code. At least, this is my personal experience with a few year of functional programming and many more years of imperative programming. – Giorgio May 9 '13 at 9:20
@Giorgio: there is a difference between "leaking into the language" (somehow) and "leaking into the tutorial". I am pretty sure you could write functional programming tutorial without so much math in them. Of course whether they would be better or not is up to debate and probably subjective. – Matthieu M. May 9 '13 at 11:32
@MatthieuM.: Thanks a lot for clarifying what you meant by leaking (leaking into the tutorial): your comment makes much more sense to me now. I agree with you that a tutorial on FP should contain as little math as possible. I had somehow misinterpreted your comment: Having worked both in the industry and in academia I am a bit oversensitive to "in academia they do a lot of maths that's useless in the real-world" kind of comments. +1 for both your comment and tdammer's answer. – Giorgio May 9 '13 at 12:05

It's because fundamentally, computer programming is mathematics. Functional languages were designed with this in mind and this is why much of the tutorials are focused on the mathematics.

It's only difficult to learn if you aren't used to thinking of computer programming as having a mathematical foundation.

-
Fundamentally computing is a combination of logic and arithmetic. This is not mathematics. You cannot express a branch instruction in a mathematical formula - so it cannot be based in math. The functional programming crowd would like it to be based in math so they develop program languages which behave as if branch instructions did not exist. – James Anderson Aug 26 '11 at 8:13
@James Anderson, are you saying that logic and arithmetic aren't mathematics? And I've seen tonnes of mathematical formulae which contain branch instructions (usually expressed in a switch-like formalism). – Peter Taylor Aug 26 '11 at 8:27
Arithmetic a subset of math that deals with simple calculation. Logic is a superset of math that is the basis of all rational thought. Incidentally functional programming is a very good idea to solve problems that can be expressed mathematically; its not so hot when you are trying to follow an illogical mess of arbitrary rules like GAP (Generally Accepted Accounting practices) – James Anderson Aug 26 '11 at 8:34
@ian31, how would you define the word "fundamentally"? You know, civil engineering is also based on physics and mathematics, whereas practically it is all about building stuff for people to use and enjoy. And, any way, before even starting thinking about programming a solution to some real-world problem, you must translate that problem into some mathematical formalism. It just won't work the other way. Programming is all about formalisms. – SK-logic Aug 26 '11 at 10:52
@ian31, programming languages are formalisms. Their behaviour is strictly defined and predictable. Thus, coding any particular model (even if it is vague) is turning it into a formalism of a sort. Math scales well onto this vague area, despite the general perception of it being confined to the shiny cristal-clear world of well-defined strict models. – SK-logic Aug 26 '11 at 12:21

I think "The Little Schemer" is an awesome introduction to functional programming and is not at all mathy. It doesn't get into Monads, so it might be too basic for your tastes, but does do a derivation of the Y-combinator towards the end.

I recently went through it after not doing any functional programming since college 12 years ago, and it was a great refresher, I definitely feel ready to tackle more advanced stuff after working most of the problems in the book using Racket.

-