
Functional Programming Jargon - adamnemecek
https://github.com/hemanth/functional-programming-jargon
======
erikrothoff
Seriously, what's up with these comments? If the examples are plain wrong,
wouldn't it be more prudent to create an issue in the repo? Also it seems to
be a lot of hate for the use of JavaScript. It's a great thing that they chose
the most widely available language. We get it, you know a purely functional
language. Good for you! I am really disappointed in the general, holier-than-
thou attitude here.

~~~
codemac
And in fact, the learning of new terminology and a new syntax/libraries/etc as
always made it more difficult for me to learn new languages.

I now try to learn new concepts in a language I'm more familiar with, and then
learn the language/syntax.

I find this repo wonderful!

~~~
vsviridov
you might enjoy this then: [https://drboolean.gitbooks.io/mostly-adequate-
guide/](https://drboolean.gitbooks.io/mostly-adequate-guide/)

------
greydius
I took a (mandatory for cs) class in college that introduced these concepts.
For a long time I thought that was a normal part of cs curriculums, but it
seems not.

Also, its very strange to see these concepts illustrated with Javascript. I
imagine thats something like trying to learn Chinese using the roman alphabet.
Not that it can't be done, but a lot of important details are necessarily
missing.

~~~
Waterluvian
JavaScript lends itself really well to functional programming, no?

~~~
wereHamster
Not really, no. Example: partial function application does not feel nearly as
natural as in in Haskell.

~~~
altcognito
The reason they use JavaScript is because it's known by many and the examples
can be tried without downloading/having an additional compiler. There are at
least two dozen concepts on the list there - the value of illustrating new
concepts for some with a known quantity far outweighs the downsides of having
to start with a fresh environment.

I will say though for the exact cases you mention, they probably should be
clear why this isn't _exactly_ the concept as described.

~~~
gaius
Here you go: [http://tryhaskell.org](http://tryhaskell.org)

------
DeadReckoning
Why on earth are people complaining about using Javascript to illustrate
functional programming language concepts? The whole point of this is helping
non FP programmers to wrap their head around these terms. Javascript is by far
the best mainstream language for doing functional programming.

~~~
catnaroek
I'm not so sure. In C++, most certainly a mainstream language, two copies of
the complex number `2 + 3i` are equal to each other. In JavaScript, they're
different. (Assuming you make two objects with fields `realPart` and
`imaginaryPart`.) How can you do functional programming on a foundation where
not even the most basic property of equality holds (every value is equal to
itself)?

Remember that functions are mappings from _values_ from a domain, into
_values_ from a codomain. A language whose treatment of compound values is as
feeble as JavaScript's can't possibly constitute the right foundation for
doing functional programming.

~~~
eru
Just define your own equality operator?

Eg in Haskell, whether things can be compared for equality depends on their
representation. (Eg church encoded datatypes do not lent themselves to the
built-in derivation of the == operator.)

~~~
wereHamster
If you can't use the builtin `==` operator, you can throw away much of the
builtin functionality. The runtime uses `==` in far too many places without
ability to provide your own comparator. You want to use your own types as keys
in a `Map` or `WeakMap`? Yeah, not going to work.

------
white-flame
Defining what things are doesn't describe what they're useful for. Consider
the Monad entry; does this bring any clarity to a beginning functional
programmer who's looking up why people use monads?

~~~
psibi
Also I don't think the definition of Monad itself is accurate there.

~~~
asQuirreL
As far as I can tell, the definition is accurate. The only thing I would say
is that `flatMap` is the name given to the (usual) list monad's bind
operation, and is not used for arbitrary monad's binds.

~~~
eru
Their definition of 'Lift' is interesting. In essence with that definition
they could redefine Applicative Functors as something that's a 'Lift' and a
Pointed Functor.

------
dexwiz
It uses Javascript in the examples, but Javascript has slightly different
definitions for some.

Partial Application and .bind(). Function.bind() in JS is about setting `this`
for when the function is called[1].

Constant, `const`, declaration in JS governs reference reassignment. Is that
the same as referential transparency? Either way the example is wrong. The
following is not an invariant. `five` cannot be changed, but `john.age` can
be. The object reference is constant, but not the object value.

`john.age + five === ({name: 'John', age: 30}).age + (5)`

Lazy evaluation should be called a generator if we are doing JS specific
naming conventions.[2] Seems like the Haskell camp like the term Lazy
Evaluation, but the Pythonthoic yield camp likes the term Generator.

[1] [https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Refe...](https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Reference/Global_Objects/Function/bind) [2]
[https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Refe...](https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Reference/Statements/function*)

~~~
AgentME
>Partial Application and .bind(). Function.bind() in JS is about setting
`this` for when the function is called

Everything after the first parameter to .bind() sets regular parameters.

>Lazy evaluation should be called a generator if we are doing JS specific
naming conventions.

They used a generator as an example of lazy evaluation. Not all generators are
examples of lazy evaluation, and not all lazy evaluation is done with
generators.

Agreed about const. In Javascript, const is purely about the variable binding
being immutable, and not a statement about the value itself.

~~~
jdmichal
> Everything after the first parameter to .bind() sets regular parameters.

And if you consider `this` to be an implicit first parameter, everything makes
perfect sense.

~~~
AgentME
`this` isn't exactly like a parameter to .bind() though: the `this` value
passed to the bound function is completely ignored, instead of being passed as
extra arguments.

------
mavelikara
This could well lead to a GoF-style book to be published. And 15 years later,
cool kids then can point and laugh at "Traversable Semigroup Isomorphism" like
they do for "Abstract Factory Factory" now.

~~~
chii
Except 'Traversable Semigroup Isomorphism' is based on math, and is timeless.

------
openasocket
Some of these are basic, some are more complex, and others I've never ever
seen actually used. Does some one here actually know a practical (or at least
non-toy) example usage of a co-monad?

~~~
platz
lenses, the store comonad, cellular automata, convolution,zippers. "whenever
you see large datastructures pieced together from lots of small but similar
computations there's a good chance that we're dealing with a comonad"

[http://www.haskellforall.com/2013/02/you-could-have-
invented...](http://www.haskellforall.com/2013/02/you-could-have-invented-
comonads.html) (The Builder Pattern, The Iterator Pattern, The Command
Pattern)

------
sdegutis
What's most interesting to me here is that this article uses JavaScript for
all its examples.

Also, this may well be the thing that finally helps me understand what the
crap Monads are.

~~~
jstimpfle
It's not a bad example but lacking generality and more importantly explicit
types.

It's really all about connecting types like LEGO blocks, so the important
thing is to show the type signatures.

"bind" is the function required from Haskell's Monad typeclass, but not a good
choice to explain monads. It's much cleaner to explain monads as functors with
"join" and ("inject" aka return).

    
    
      map :: (a -> b) -> (M a -> M b)
      join :: M (M a) -> M a
      inject :: a -> M a
    

With these guys you can easily compose "dirty" asymmetric operations like
(readFile :: FilePath -> IO Bytes)

------
catnaroek
How come the definitions of “functor”, “applicative functor”, etc. don't
mention the most important part? _The laws._

The definition of equational reasoning is also very weak:

> When an application is composed of expressions and devoid of side effects,
> truths about the system can be derived from the parts.

Truths about _any_ system can be derived from the parts. What equational
reasoning gives you is the ability to study the parts _in isolation from each
other_.

------
TheMagicHorsey
I wish the utility of these concepts was illustrated with some code. Although,
I concede perhaps this is more difficult to do with short code snippets.

------
33degrees
For anyone looking for something more in depth, check out
[https://drboolean.gitbooks.io/mostly-adequate-
guide/content/](https://drboolean.gitbooks.io/mostly-adequate-guide/content/)

~~~
bogomipz
Neat! Thanks for sharing.

------
amelius
Nice idea, but that must be the worst explanation of monads I've seen so far
:)

~~~
sdegutis
Can you recommend a good one? I've read several but still don't get it. And I
hardly have time to write code to learn it like people say is necessary.

~~~
seagreen

      Can you recommend a good one? ... I hardly have time to 
      write code to learn it like people say is necessary.
    

The _easiest_ way to learn monads is through code (in haskell they're just a
tricky typeclass: [http://dev.stephendiehl.com/hask/#eightfold-path-to-monad-
sa...](http://dev.stephendiehl.com/hask/#eightfold-path-to-monad-satori)) If
you don't want to write code you could learn them like a mathematician from
first principles
([https://en.wikipedia.org/wiki/Monad_(category_theory)](https://en.wikipedia.org/wiki/Monad_\(category_theory\))),
but that seems so much harder to me I'm not sure why you would.

~~~
Dr_tldr
Is there a non-haskell resource on monads you could recommend? Anything that
starts with "first, learn haskell" is probably not the _easiest_ way,
assertions from people who already know haskell notwithstanding.

~~~
seagreen
Great point! I found this for python:
[https://www.stephanboyer.com/post/9/monads-
part-1-a-design-p...](https://www.stephanboyer.com/post/9/monads-
part-1-a-design-pattern), but it definitely focuses more on explanation than
practical use. A list of "how to practice with monads in various languages"
would be a neat thing to have.

------
ninjakeyboard
Some feedback for discussion - some of the FP stuff is sort of blurry to me
after a point but here is what I sort of feel scratching this at the surface
as a scala dude. Not trying to be critical - just whatever is off of the top
of my head a la review.

Lazy: I feel like the definition of lazy needs to be demonstrated in contrast
to eager evaluation.

val x = {println("evaluating x"; 5)}

lazy val lazyX = {println("evaluating lazyX"; 5)}

this would print ("evaluating x) to the console. lazyX would not be evaluated
because it is not invoked. Here the eager definition of x demonstrates that it
is evaluated immediately. lazyZ is only evaluated when invoked.

Monads and higher kinded types. The informal vs formal definition of some of
the higher kinded types is worth noting. You're either describing the most
formal definitions (identity/associativity laws) or you're describing the
informal defition (has flatmap, processing things in a series as described in
the wikipedia article
[https://en.wikipedia.org/wiki/Monad_(functional_programming)](https://en.wikipedia.org/wiki/Monad_\(functional_programming\))
) Monad seems to be the informal definition, otherwise associativity laws
should be included maybe? Eg in Scala Try is not a formal monad as the
associativity laws don't hold true.
[https://wiki.haskell.org/Monad_laws](https://wiki.haskell.org/Monad_laws)
Also why is it "of" and "chain" here? Isn't it traditionally flatmap that
indicates a type might be a monad, and then the identity laws the truly
confirm it? Maybe this is js land? If so, should the doc say "this is js" as
flatmap is pretty descriptive of map+flatten. It's hard to talk about - It's
not at all clear to me what people mean when they talk about monads either -
just throwing thoughts around.

I think you should outline how Currying and Partial Application are related
maybe? Eg currying is taking a function with an arg list and making it take
multiple arg lists (the act of making a function take multiple arg lists), and
Partial application is the application of an argument of a curried function
more or less? I think the relationship between these should be highlighted
possibly to sort of draw out what part of the life of a function we're talking
about if trying to illuminate the subject for someone.

~~~
jethrolarson
Thanks for the feedback. I've been trying to direct the definitions to be
informal and understandable but many contributions come in with a different
voice. Some of the definitions are first draft attempts just to get something
in place.

It's been awesome to see the sudden popularity of our humble glossary :)

------
toolslive
what about homographs ? For example, 'functor' means something different
depending on the programming language (Haskell, OCaml)

~~~
eru
Not only that, oop people sometimes use 'functor' to mean an object you can
call like a function.

------
jtchang
Hmm first time I had a semblance of grasping what the heck a monad was. Cool.

------
iandanforth
This is great. Very helpful for understanding / translation.

------
intjk
This is great! Throwing all of these into an anki deck. :)

------
namanyayg
Requesting @dang to change the URL to remove the #list fragment.

~~~
dang
We did. But please send such questions to hn@ycombinator.com, because (a)
they're off-topic and (b) it's the only way to make sure we see it.

