I've found that trying to simplify things is an impossible thing to do in the programming community (cue to "You're missing the point / You're oversimplifying / This is not what a monad is").
It's a problem that stems from being surrounded by millions of people who take disproportionate pride in the belonging to a savant elite.
What I always say to people who ask me to describe programmers: "Programmers are people who like to create metaphors, but who like to correct other people's metaphors even more".
That being said, I feel like I've progressed in my understanding of those concepts by reading the post, so thanks to the author.
No. It's a problem because you, the reader, are missing the point.
Being against cargo cults does not make you elitist. This characterizes a lot of people, and it's not fair or accurate to blindly ascribe them with malicious motivations.
Think about a different area: people who try to "simplify" quantum computing. What do we get? Mass confusion. The fact that so many people think that quantum computers can solve all NP complete problems by trying every possibility is a real problem, not a consequence of "people who take disproportionate pride..."!
And then people go on an try to build things on top of these ideas and end up creating a mess because they started off on shaky foundations. Then that mess gets enshrined in a popular library, it creates lots of problems for everyone. Then programmers either live with those problems or conclude that the whole functional programming "thing" is delusional and useless.
Thing is, you're kind of shooting yourself in the foot here, because a programming language concept should better be very different from something like quantum computing. I know next to nothing about quantum computing, but I do know that currently its significance is mostly theoretical. Concepts like functors and monads (in the context of programming) are literally workman's tools. If explaining to a carpenter how to use a new kind of hammer is as subtle and complex as explaining the standard model, then there is something fundamentally wrong with the hammer. If, in addition, carpenters using the new hammer don't seem to be building things significantly faster (or things that are significantly harder to build) than those using the plain-old hammer, I think it's safe to say that the new hammer kind of sucks.
You're basically telling carpenters, listen, learning to use the new hammer is quite tricky (it's abstract, complicated shit) but it's going to expand your minds, and in the end, after all the hard work, you'll be building things in a completely different way than you do today (although the final result would be rather similar) -- it's totally worth it!
Requiring that a third party "explain it to the carpenter" is a big part of the problem. Our coddled carpenter inevitably shrivels up in bewilderment and frustration when confronted with a new (actually, a century old...) concept, and proclaims the teacher an "elitist," "savant," or "misguided reductionist."
Sometimes the coddled carpenter has trouble grasping a new (actually, a century old...) concept, throws up arms in bewilderment and frustration, and proclaims the concept "too abstract, too complicated" and therefore unsuitable for all. For example, deciding that the value for pi is just too mind-bendy, and deciding on a nice happy value of "22/7" instead.
Computer programming (and theoretical computer science, quantum computing, type theory, etc.) is fundamentally intertwined with the mathematical laws that describe our known universe. There will always be parts of it that seem esoteric to someone, and I bet you that even developers extremely confident in their world of playdough tools would writhe and gnash teeth when reviewing some of the fundamental elements that make their coziness possible. The most obvious example of this might be the parser for their favorite programming language - it is a very complex subject and the algorithms are formidable.
There appears to have been a massive culture shift (rift?) somewhat recently - from individuals who take pride in understanding and growing what we know and what we can do with computers, to individuals who demoralize, coddle, and impede what we can do with them.
> There appears to have been a massive culture shift (rift?) somewhat recently - from individuals who take pride in understanding and growing what we know and what we can do with computers, to individuals who demoralize, coddle, and impede what we can do with them.
Except that none of this applies to pure functional programming. PFP is an idea -- a very interesting one -- about how to program. It neither uncovers the fundamentals of computer science nor grows what we can do with computers. There is absolutely nothing about monads that is fundamental to computation, and understanding monads does not make us understand computation better.
I could say that there appears to be a "culture shift" in which a very interesting abstraction (computation as a function) has shown some promise but has failed to yield significant results (and certainly not a revolution), and so as a marketing effort, begins to present itself as some kind of a necessary "fundamental mathematical" understanding of computer science, while it is nothing of the sort. It is an interesting reformulation where functions and monads replace the familiar concept of the continuation, and that may or may not lead to significant gains. So far, it has not.
Over-hyping research results is often the norm rather than the exception. What may be unique in this case is that rather than believing that in light of recent research, an amazing breakthrough is right around the corner, some PFP advocates seem to claim that the breakthrough is already here, although they find it hard to support their claim with any evidence. I'd say it's a combination of scientific hype and industry-method hype.
It is as worthy of study as any of the other hundreds of research ideas in CS which hold some promise but aren't yet ready for large-scale industry adoption. It is necessary only for those who are interested in exploring computer science's "theory B", and particularly programming language design (which in itself is an important but not an unusually central sub-discipline of the field).
My skepticism of PFP is specific to PFP -- certainly not to studying any of the many under-explored corners of computer-science. I think that PFP's hype/reality ratio is particularly high -- even by CS standards -- and easily rivals that of machine learning (or "AI" as some call those statistical algorithms). It is not skepticism towards study in general but towards PFP in particular, which has so far overpromised and underdelivered.
> Our coddled carpenter inevitably shrivels up in bewilderment
Requiring carpenters to spend a great deal of time to learn how to work in a completely different way, all to achieve a similar level of productivity shows, IMO, a lack of understanding of what carpenters do. It is a mathematician's duty to look at things from different perspectives out of a sense of curiosity or to fund structure. A carpenter should spend time and effort on new methods only if they increase his or her productivity commensurately. I can tell you that algorithms we require programmers to use and/or understand have a much more significant impact relative to their adoption cost.
If we compare techniques and tools to medical drugs, PFP is barely out of the lab and is very early in its human-trials phase. Treating it as a complete success, and requiring that all practitioners spend a great deal of effort learning it at this point in time, is a grievous misrepresentation of the actual achievements of the idea. It is an interesting idea, it shows some promise, and if you have time and interested in this subject, you should give it a look, that's it.
I don't think the issue is with the simplification itself, but with the illusion of complete understanding.
There's nothing wrong with making a concept easier to digest, and to introduce a topic to an otherwise uninformed reader, but you have to do so with the clear disclosure that there is always more to it.
There's nothing wrong with trying to make a topic more accessible to a wider audience, but providing misinformation isn't the right way to do it. If abstractions aren't tangible enough on their own (I know how this feels, since I'm in this situation on a regular basis), provide examples, but never forget to relate the examples to the abstract definition.
You're absolutely right. To be clear, I was not saying that everything can and should be simplified, some things just warrant a certain level of complexity because they're... well... complex and that's absolutely fine (your example of quantum computing is great in that regard, though I supposed it COULD be vulgarized for the masses to some extent, at least more than it currently).
I was addressing the difficulty I've seen in the programming community of trying to make things more accessible when they actually can and should be.
>> Writers use hedges in the vain hope that it will get them off the hook, or at least allow them to plead guilty to a lesser charge, should a critic ever try to prove them wrong. A classic writer, in contrast, counts on the common sense and ordinary charity of his readers, just as in everyday conversation we know when a speaker means in general or all else being equal. If someone tells you that Liz wants to move out of Seattle because it’s a rainy city, you don’t interpret him as claiming that it rains there 24 hours a day, seven days a week, just because he didn’t qualify his statement with relatively rainy or somewhat rainy. Any adversary who is intellectually unscrupulous enough to give the least charitable reading to an unhedged statement will find an opening to attack the writer in a thicket of hedged ones anyway.
> I love this notion of relying on “the common sense and ordinary charity of readers”. What a wonderful, inspiring idea. I realize I’ve begun writing defensively on the web, putting in hedges and clarifications that really aren’t necessary for a charitable reader. I’ve also taken to toning down any rhetorical flourishes that could be interpreted uncharitably in a way that annoys some people. The result: boring writing stripped of a lot of my own personal style.
I think there's a kind of naive reductionism that runs throughout CS.
You can avoid complexity by ignoring it in the proverbial Dunning-Kruger kind of way - where you don't know what you don't know, but you try to turn your toy misunderstanding of some domain into code anyway.
Or you can avoid it by creating over-systematised technologies that try to barricade "impure" unpredictability behind a big wall of abstraction and insider-only jargon.
They're both defensive moves against the messiness of the real world.
There may be other approaches that trade off accessibility with useful results in other ways.
This "naive reductionism" looks to me like the difference between the way that analysts and algebraists work on problems [1]:
"If I have to wave my hands and explain it, I would explain it like this. In algebra there are sequences of operations which have proven to be important and effective in one circumstance. Algebraists try to reuse these operations in different contexts in the hopes that what proved effective in one situation will be effective again. By contrast an analyst is likely to form an idiosyncratic mental model of specific problems. Based on that mental model you have intuitions that let you carry out long chains of calculations that are, in principle, obviously going to lead to the right thing. Typically your intuition is correct to within a constant factor, and you're only interested in some sort of limiting behavior so that is fine."
How else is a person supposed to intelligently explore the solution space of a problem other than through some kind of "naive reductionism"?
I've also run into this myself in publishing my own blog posts. I had this burning need to add caveats and write very defensibly because the fear in the back of my head of being "well, actually..."d.
In the end, I still pushed them out and they made the rounds with positive feedback, but it definitely took way longer to write than I thought. I know that's probably not a very healthy way of going about it, and a big part of it in my opinion has to do with how it's too easy to issue ego-boosting corrections.
I was going to be one of the people who complained about this post's shortcomings, but of course that's because I learned Haskell rather than Swift, and so the implications of monads et al. are a teensy bit different.
This is probably all you need to know in terms of Swift.
If you're talking about the actual mathematical theories, or how other languages see it, this is a gross oversimplification. But since we're talking about just Swift it's fine.
While Type theory in general is fundamental for people who implement languages (and too often we see the result of the lack of knowledge of type theory in the implementation of main stream languages, and no, I'm not talking about PHP here), most developers just want to get an idea of what all that stuff is about. Most developers will never use functors but Monads have interesting applications, like Futures (i.e. Promises).
It's easy to understand with this article that the usual notion of type (int32,char*,...) is just a subset of what types actually are. (T) -> T is also a type. And if most developers can remember that, well, that's a good thing.
I agree, with the caveat that if one is going to mock the Haskell community ("A million words of category theory and Haskell examples to say..."), it would be helpful if you don't summarize it incorrectly ("... Functors contain stuff"). There are plenty of Functors in the Haskell sense that are not immediately obviously containers, such as all functions a -> b, which is actually a very commonly-used one. (Of course one could stretch the definition of "container" to include "function" but, well, would that not constitute engaging in the very academic wankery one is simultaneously trying to mock?) So perhaps it is not so mysterious that it takes a bit longer to explain the Haskell uses of the term.
Haskell is simply more expressive and abstract, and explaining that takes far more time.
Swift lacks that amount of expressiveness. Some people call that level of expressiveness "academic wankery" and some people think it's the best thing ever.
It does sadden me that people think a language is worse or better when it is simply different.
> I feel like I've progressed in my understanding of those concepts by reading the post
You might have progressed but I would guess that you actually haven't, because it was a very poor explanation. How is IO a container? How is State a container? Sure, you can stretch the definition so that container means "Functor" but then you've made a circular definition. Containers are examples of functors. They do not exhaust all possible functors.
Very often, writing a tutorial about monoids, functors, applicatives, or monads ends up improving the understanding of these concepts a lot more for the author of the post than its readers.
At the end of the day, not everyone responds the same way to metaphors, so the more tutorials and metaphors on these concepts, the better. One day, you'll stumble upon that one article that makes all things click for you.
Well said. They won't take any effort to share their knowledge, and they won't let others to share in any possible way as well. As you said, they want to remain a savant elite and don't want anybody else to even start anywhere close.
Just ignore them and their elitist comments, because replying to their comments just invites more elitism, abstractionism, and other insanely high level talk without anything constructive. They will just say its wrong without even explaining why its wrong. If they feel the article is only 90% right, they could very well contribute their 10% back as comments - but no, all they want is to just stop the whole thing.
For good examples, look at comments above and below.
It's a problem that stems from being surrounded by millions of people who take disproportionate pride in the belonging to a savant elite. What I always say to people who ask me to describe programmers: "Programmers are people who like to create metaphors, but who like to correct other people's metaphors even more".
That being said, I feel like I've progressed in my understanding of those concepts by reading the post, so thanks to the author.