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?
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.
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.
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.
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.
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.
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.
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.
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 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.
To me it comes off as somewhat 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.
Because I find it hard to imagine somebody "unfamiliar with school-level math" picking it up in the first place.
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!
Seems like an odd group to target in such a warning.
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.
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.
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.
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.
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...