These definitions don't really give you the idea, rather often just code examples..<p>"The ideas", in my view:<p>Monoid = units that can be joined together<p>Functor = context for running a single-input function<p>Applicative = context for multi-input functions<p>Monad = context for sequence-dependent operations<p>Lifting = converting from one context to another<p>Sum type = something is either A or B or C..<p>Product type = a record = something is both A and B and C<p>Partial application = defaulting an argument to a function<p>Currying = passing some arguments later = rephrasing a function to return a functions of n-1 arguments when given 1, st. the final function will compute the desired result<p>EDIT:
Context = compiler information that changes how the program will be interpreted (, executed, compiled,...)<p>Eg., context = run in the future, run across a list, redirect the i/o, ...
"A homomorphism is just a structure preserving map. In fact, a functor is just a homomorphism between categories as it preserves the original category's structure under the mapping."<p>Oh ok. Plain english.
I didn't really understand FP until I read Functional Light JavaScript by getify/Kyle Simpson. It is so well written and approachable by mere mortal coders. I'm not an FP wizard, but it is the coding paradigm I mostly use now. I've even adapted some aspects (e.g. composability) to the CSS I write using `var()`.<p>You can buy the book or read it on GitHub:<p><a href="http://fljsbook.com/" rel="nofollow">http://fljsbook.com/</a><p><a href="https://github.com/getify/functional-light-js" rel="nofollow">https://github.com/getify/functional-light-js</a>
Lists like this tend to be a bit overwhelming without context, because a definition can often seem to focus on things that don't make sense if you don't understand the use case, even if you understand the words.<p>Even if you've read the definition of functor first<p>> Lifting is when you take a value and put it into an object like a functor. If you lift a function into an Applicative Functor then you can make it work on values that are also in that functor.<p>Is a pretty rough sentence for someone not familiar. I think Elm does a pretty good job of exposing functional features without falling into using these terms for them, and by simplifying it all.<p>It does pay for that in terms of missing a lot of the more powerful functional features in the name of keeping it simple, but I do think it makes it a great entry-point to get the basics, especially with how good the errors are, which is very valuable when you are learning.<p>I know it's a controversial language on HN to some extent (I certainly have my own issues with it <i>shakes fist at CSS custom properties issue</i>), but I genuinely think it's a great inroad to functional programming.
While I appreciate FP using terminology from its math origins - I do think it's a huge barrier for entry, and not really sure languages that cling onto them, will see much real mainstream success.<p>But then again, I don't think the language maintainers et. al. are too concerned with widespread success. Just some observations, but the majority of people I know that actively use FP languages, are academics. I've encountered some companies that have actively gone with a FP language for their main one - but some have reverted, I guess due to the difficulty of hiring.<p>With that said - functional elements are becoming more common in widespread languages, but not all the way.
Pet peeve: The word "just" when used to gloss over something with the author don't know how to explain. Using "just" shift the burden from the author to the reader, since it signals it is the readers fault if they don't understand.<p>> A homomorphism is just a structure preserving map. In fact, a functor is just a homomorphism between categories as it preserves the original category's structure under the mapping.<p>How about removing the "just":<p>> A homomorphism is a structure preserving map. A functor is a homomorphism between categories as it preserves the original category's structure under the mapping.<p>Much clearer. Although most readers would now ask what "structure" and "structure preserving" means, since this is never explained.
Let me present this intuition I've developed.<p>• You have a producer of Cs, then you can turn it into a producer of Ds by post-processing its output with a function g: C → D.<p>• You have a consumer of Bs, then you can turn it into a consumer of As by pre-processing its input with a function f: A → B.<p>• You have something that consumes Bs and produces Cs, then you can turn it into something that consumes As and produces Ds using two functions f: A → B and g: C → D.<p>With pictures: <a href="http://mez.cl/prodcons.png" rel="nofollow">http://mez.cl/prodcons.png</a><p>If you understand that, you understand functors:<p>• producer = (covariant) functor;<p>• consumer = contravariant functor;<p>• producer-consumer = invariant functor;<p>• post-processing = map;<p>• pre-process = contramap;<p>• pre- and post-processing = xmap (in Scala), invmap (in Haskell);<p>• defining how the pre- and post-processing works for a given producer or consumer = declaring a typeclass instance.<p>It doesn't mean that "a functor <i>is</i> a producer", but the mechanics are the same.
When I was an assembly programmer, I knew C could help me<p>When I was a C programmer, I knew OOP could help me<p>When I was a JavaScript programmer, I knew TypeScript could help me.<p>I don't know how functional programming can help me, but I'll keep trying to find a reason because people say it can
It looks like the Partial Application section is missing the most widespread form of partial application, known as "creating an instance".<p><pre><code> class A:
def foo(self, x):
# do something
a = A()
foo(1) # self is already "applied".</code></pre>
This is more helpful than anything I have ever encountered on the topic.<p>Comments:<p>1. It should explain map somewhere before it is used.<p>2. For the more abstruse and abstract concepts, a comment suggesting why anybody should care about this idea at all would be helpful. E.g., "A is just a name for what [familiar things] X, Y, and Z have in common."<p>3. It goes off the rails halfway through. E.g. Lift.
"Category<p>A category in category theory is a collection of objects and morphisms between them. In programming, typically types act as the objects and functions as morphisms."<p>Much clearer now...
Without being very versed in FP and having only read the first two (arity, HFO) this seems super helpful!!<p>Even if imperfect and I need to research further, this glossary provides a way to attach new knowledge to existing one.
I get why they chose to do this in Javascript, but I can't help but feel it's an awkward choice. Many of the examples (e.g. currying) look unnatural in javascript.<p><a href="https://github.com/hemanth/functional-programming-jargon" rel="nofollow">https://github.com/hemanth/functional-programming-jargon</a>
I think the title should have `JS` in it, because for quite few people it just might not make sense. Besides the examples are such that the author seems to have been simultaneously competing in a obscured code brevity competition. Plus, language is definitely not "plain English" wrt jargons.
The absolute state of github projects.<p>This project should be exactly 1 (one) file. The readme.md.<p>LICENSE - There is a license? Why? Someone might steal the text for their own blog post? So what? The license won't stop them.<p>package.json - to install dozens of packages for... eslint. Just install globally. It's just markdown and code examples.
Yarn.lock - ah yeah let's have this SINGLE, NON EXECUTABLE TEXT FILE be opinionated on the javascript package manager I use. Good stuff
We have a .gitignore, just to hide the files eslint needs to execute. wow.
FUNDING folder - wow we have an ecosystem of stating the funding methods?<p>This should have never been a github repo. This is a blog post. It's a single, self contained post.<p>I hate this crap. We have 9 files just to help 1 exist. It's aesthetically offensive.
Can someone clarify something for me? If you build a linked list or a dynamically growing array in a Functional program, am I correct in understanding that the array is never modified, instead a copy is made and the new element is added to the copy of the array?
Looked at first one (arity), saw "argument" when what was actually meant was "parameter", and therefore dismissed the document.<p>If you want to make a glossary, at least try to be precise.
I like it.<p>Could need a bit of clean up. Some points could need more explanation, simpler examples, and every point could follow the same structure.<p>But for a beginner, I think it's a pretty starting point.
I thought this guide is great. Not sure why people are upset with it. It’s not the be all end all definite guide to the topic, but it definitely helps.<p>I especially like the examples given that remove ambiguity in explaining the concepts.
Some helpful explanations in there!<p>Though I think the closure example doesn't actually show capturing context. It's just a partial function application unless you count the literal '5' as a local variable.
<p><pre><code> Constant Functor
Object whose map doesn't transform the contents. See Functor
Constant(1).map(n => n + 1)
</code></pre>
Ummm… how is this constant?
All these niche functional programming languages are an exercise in pseudo intellectualism<p>Give me an object oriented language any day. The world is made of state and processes, (modern niche) functional programming goes too far to derecognise the value of state in our mental models<p>The good thing about functional programming is stressing to avoid side effects in most of the code and keep it localised in certain places…