To understand how and why a C compiler works you don't need all that much algebra. If you thoroughly understand assembly, you're basically good to go.

To understand how and why an FP language compiler works you need to grok the lambda calculus (as a bare minimum). I'd call that algebra. To even understand what problems are being solved by closures, I really had to “learn difficult concepts through prolonged mental concentration and effort”. Giving newbies a heads-up that competent use of such a tool requires nontrivial knowledge is only fair.

eh, i dunno. i think anybody with a decent grip on any language can whip up a scheme compiler way faster than a C compiler. [1] is a very readable guide to scheme and its implementation. Will it be the fastest gun in the west? no. Is it a simple workable foundation that, like, anybody who can put together 100 lines of working code, in any language, can build? for sure. Compilation isn't magic.

Lambda calculus won't hurt. Implementing scheme (which imho is pretty darn close to the lambda calculus) really just requires understanding some operational semantics and you're good to go.

[1] (http://agl.cs.unm.edu/~williams/cs491/three-imp.pdf)

Quite. But pretty darn close is still not close enough to support partial application via curried functions out of the box.

Absolutely.

I'd argue, if somebody has written their own interpreter and compiler, leveraging the interpreter at compile time first for constant expression evaluation and then something more sophisticated for partial function evaluation is a lot more intuitive. You can kinda climb a hill of difficulty rather than be teleported to the top and wish them luck.

(To be totally fair i keep trying to open the pdf, but the browser tab locks up. So maybe my observations are meaningless)

_edit_

There is no royal road. but some roads are perhaps longer, but a little easer to travel.

typed pure functional programming is not "functional programming" in the scheme sense.

It's often approached much more formally, using the terms and methods of category theory -- and that is very much the approach of this book.

Is it really that complicated?

A closure is essentially a function pointer with some additional data about what some of the symbols refer to. It happens that you're able to write the function nested inside another function.

In advanced FP languages with sophisticated type systems, etc, there's a little more to it than that.

Why do I need to understand how the compiler works, at that level of detail?

I don't see why understanding closures requires so much mental effort. Just using them a few times should give you a practical understanding of how they work. Closures are not a complicated concept - a bunch data your function has access to outside of its own scope.

They're certainly no harder a concept than pointers in C! They also don't cause crashes that can be very difficult to debug.

> Why do I need to understand how the compiler works

How do you propose to master the language if you don't understand the principal tool that embodies that language? Of course it's always an option to use a language without really understanding it, if that's your thing.

> Closures are not a complicated concept

The first lectures introducing closures after their discovery had CS professors in the audience who didn't understand what they were good for. Functions could access a bunch of data outside their local scope before that.

When I gave this book an attempt, I appreciated the author's honesty about the difficulty of the material. I went with Real World Ocaml instead, intending to reattempt SoFP in the future. Today I suggested an addition to a section in Real World OCaml, and the author pointed out that the section was already so dense that adding the extra content would require more explanation. I now appreciate the difficulty in making such a technical material approachable by a less technical audience, and a heads up is appropriate.

Edit: (in light of another reply that mentioned the lambda calculus). The addition to Real World OCaml that I suggested was to call out the implementation of the Y combinator in the section on Memoization. The explanation used the Y combinator to work up to an implementation of memoization, and it was so intuitive that I felt it should be noted, but that won't easily fit into an already dense chapter.

I don't really agree that the sentence is condescending. It's mostly accurate and the problem is described fairly neutrally.

This is saying "btw this subject isn't for lazy illiterates", presumably unlike other literature the reader is familiar with. What value does that add exactly?

Yeah, this is completely unnecessary. All programming is algebra as algebra is the math logic and instructions.

I tell people who do analysis and planning for work they are doing calculus all day without realizing it as calculus is the math of continuous change. As a result an analyst who has never programmed before may find the concept of lambda calculus far easier to understand in practice without being a math scholar.

Maybe they’re defensive because readers keep complaining about not understanding the math they use?

So the retort is to imply that they didn't understand the math they had in school?

To me it comes off as somewhat douchy.

How is it douchy?

If I write a book about calculus and people say it's too hard, because they don't know what a function is, is it then not more then fair to say to them they should first know some basic math before attempting to understand my book?

That's basically just helping the reader to me and not condescending in any way.

It's a good warning. I would only consider that condescending if I had some insecurity about my abilities.

Who is it targeted at though?

Because I find it hard to imagine somebody "unfamiliar with school-level math" picking it up in the first place.

I never even made it to pre-calc and I suck at Algebra but I'm teaching myself CS and functional programming. The title made me interested and the warning tells me I'm probably not ready for it.

To me, it seems that the "is not suitable" phrase was a bit condescending. Re-word that, and the warning may be fine.

haha, i was going to count and report the number of analogies to beauty, nature, painting, etc. but Chrome gave up on me. (come now Chrome, a PDF inside an HTML page making you crawl like a baby turtle!)

glad to find this comment though. it's the other thing that's a little bothersome with the FP community -- at least for me. to be honest, i don't think they realize they are doing any of this. they just seem like the PHD level mathematicians, so to speak, of the programming community!

FP is basically algebra in some unusual form, therefore ...

Would it be less condescending if it didn't discuss requirements or difficulty?

It would be less condescending if the author just stated what type of math was used and left out the passive aggressive nonsense about people "unwilling to learn difficult concepts through prolonged mental concentration and effort."

And I think that's what the OP is questioning. Most technical writing will spell out what's expected from the reader, but articles about FP also tend to have a "... if you're smart enough" sentiment added in.

How many people "unfamiliar with school-level math" do you know?

Seems like an odd group to target in such a warning.

Many, I would argue. Just a statement of fact, no judgement.

When I took advanced physics classes in 3rd year of undergrad, I was surprised to note that many of my very smart friends who were computer science majors had lost touch with high-school and introductory college math (particularly calculus) because of an immersion in different kinds of stuff for 2-3 years. Similarly, I've sat in on machine learning classes where CS grad students have little knowledge of probabilistic reasoning or linear algebra (both of which I would consider high-school math, or early college level).

It's not surprising that someone who's not written code for a decade will have a tough time jumping in to start programming right away. So, what's so special about math? It just so happens that some texts on functional programming use a different starting point to approach programming, with different pre-requisites. I wouldn't be surprised if people lose touch with these things after a decade of not using/needing them.

Most people I know are unfamiliar with school-level math. They had it one or two decades ago and forget most of it. It's not a skill that is used day-to-day.

There are tons of people that write code that aren't college graduates and aren't very educated in math.

I'm a high school drop out. I'm teaching myself functional programming and I'm slowly relearning HS algebra so I can move on to subjects I've never taken like precalculus, calculus, and undergrad math.

>How many people "unfamiliar with school-level math" do you know?

How many programmers can solve a quadratic equation without knowing the quadratic formula (i.e. how many can do the algebraic manipulations needed to solve it)?

That is school level math.

Working in tech obscures the proportion of how many people truly are stuck when asked to do algebra of any flavor.

Ok, but can you imagine such a person being interested in this book?

Because people do struggle on the topic. It's a fair warning.

>Why do materials on functional programming always have to be at least somewhat condescending towards the reader? Or maybe: why such sentences seems to appear only in them?

Because who else will get to put in such a sentence? A PHP tutorial, or some Javascript one? On what intellectual grounds would they even be able to justify it?

Besides, the accusation is not even true. You can find many C tutorials that are equally "somewhat condescending towards the reader" -- eg. for not understanding pointers, not knowing how the metal works, etc...