Hacker News new | comments | show | ask | jobs | submit login
Functional Programming Jargon (github.com)
339 points by adamnemecek on July 24, 2016 | hide | past | web | favorite | 103 comments



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.


We know Haskell variants or maybe scalaz. I don't get why these now represent pure functional programming. Scala isn't even close to pure. This is just jargon for languages that can represent very abstract mathematical concepts.

I am happy to see these ideas work their way into any language. I just question the utility here. So there are potentially abstract things going on in my code? Great. So what? I can maybe notice it and get back to work.

Haskell gives me more. It says I can define some of the abstractions and write code against them. More realistically, it allows someone smarter than me to define the abstractions which I can then code against. For better or worse, this is expected now of even beginner Haskell programmers, where "monad" rears its head as an inbuilt type class, in inbuilt functions and some of the earliest type errors.

In Haskell, a monad isn't just an abstract concept that you can see if you squint hard enough at your code. A monad is code. It has an implementation as a typeclass, in Ocaml as a module type. How is it implemented in JS?

I am also sceptical that these abstractions are useful outside statically typed languages. Haskellers habitually ride towers of these constructs and I for one couldn't do it without a type inferencer. I already find scalaz too painful for me personally.


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!



I think it would be even better if the repo had the javascript examples alongside another language which is more widely accepted as a functional language for example Haskell, Scala or Clojure.

Seeing examples together to me is an even stronger way of illustrating the concepts and differences between implementations.


A more serious objection is that many structures used in functional programming have associated equational laws, which JavaScript provides a very poor medium to formulate - never mind actually prove. The ability to query the physical identity of every object makes the equational theory of JavaScript objects completely trivial: every object is equal to itself (physically in memory) and nothing else.


People want to feel like they're smarter than everyone else, basically.


Perhaps its a good thing to go through the newbie guidelines once in a while: https://news.ycombinator.com/newsguidelines.html

https://news.ycombinator.com/newswelcome.html


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.


Your mistake is in thinking that most developers have gone through CS, I do like to wager that we have more developers today without a CS background than those with a CS background. Therefore, things like these are new to them. I actually think that Javascript is a great way to teach these concepts because those developers without CS backgrounds are less likely to be writing lisp or haskell code, and more likely to know Javascript.


I think that touches on one of the problems with hiring in tech. People tend to think things they learned earlier chronologically are simpler or more fundamental and necessary building blocks in order to be competent at the things they learned later. So we have programmers with CS backgrounds rejecting programmers without who would be perfectly capable of doing a particular programming job because they get tripped up on some algorithm or data-structure quiz that has no relation to what they'd actually be doing on the job (and could be quickly learned if and when it did).


> People tend to think things they learned earlier chronologically are simpler or more fundamental and necessary building blocks in order to be competent at the things they learned later.

That would explain why C is still so prevalent, as opposed to being 'yet another language from the 70s' ;)


I guess it depends on the country.

On my own, if you don't come from CS or EE background you hardly will get through HR.


Curious, could I ask the country? I've lived in both the US & UK and would say that the vast majority of companies I've been involved with (via employment or simply interviewing) haven't cared about my degrees, but instead care about what I've worked on in the past and what they perceive I could learn/add to the company.

NB I don't have a CS or EE background.


Portugal.

Without a degree very few companies will bother.

In France, Germany and Switzerland one should at very least have a technical experience level and written references from past jobs.


It's good we (still) have free-ish movement of labour within the EU. (And closer to the ideal of free in IT than in almost any other sector.)


Well, kind of.

There is also the language barrier.

Not many accept working in English, and we had some customers from well known multinationals that only upper management was willing to use it.

Besides the degree, knowing multiple languages and soft skills really helps.


>I imagine thats something like trying to learn Chinese using the roman alphabet.

So basically, completely normal and reasonable? (see http://languagelog.ldc.upenn.edu/nll/?p=10554)


I also found that comment incredibly ironic :P


> 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.

I think you're being sincere in expressing a common attitude within the Lisp/FP community, but it's an unfortunately limiting attitude. It would appear strange to an ancient Sumerian to see the Epic of Gilgamesh translated into English, but the translation is far more accessible and thus far more influential than the original.

I'm a front-end dev and I got into Clojure and Elm because of some books/libraries for functional programming in Javascript. It's doubtful I would've ever had enough interest to learn if no one in those communities made an effort to translate some of their concepts into a language that I already use.


>I'm a front-end dev and I got into Clojure and Elm because of some books/libraries for functional programming in Javascript. It's doubtful I would've ever had enough interest to learn if no one in those communities made an effort to translate some of their concepts into a language that I already use.

That's the way most front-end devs learn new things. People talk about FP attitude here, but it is no-www attitude actually.


> It would appear strange to an ancient Sumerian to see the Epic of Gilgamesh translated into English, but the translation is far more accessible and thus far more influential than the original.

well said!

(i'd have found es5 more accessible still.)


> I imagine thats something like trying to learn Chinese using the roman alphabet.

Chinese kids learn chinese characters by learning the roman alphabet first. Primary-school kids in China learn pinyin, which then helps them to learn chinese characters.


JavaScript lends itself really well to functional programming, no?


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


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.


Here you go: http://tryhaskell.org


It's definitely no Haskell. But if you wanted to do FP in JavaScript, it wouldn't be a painful ordeal, no? Well, ES6 and newer at least.


Functional programming puts the static structure of a program at the forefront: types, invariants, equations relating inputs and outputs of processes, etc. JavaScript doesn't do this very well. In fact, even C++ does it better than JavaScript. Nobody would in their reasonable mind call C++ a functional language, right?


In Javascript functions are first class objects, there are closures, and higher order functions. Having a garbage collector makes it easier to implement persistent data structures. I've always thought that despite it's weird corners it's actually a powerful and flexible language. You can see that in the article, because in just a handful of lines of code it is able to express all of these ideas in an accessible way. I'd be interested to see a C++ version of this.


> functions are first class objects

Programming languages have procedures, not functions. (Yes, even Haskell. Consider the possibility of divergence.) Functional programming is a style that:

(0) Emphasizes values over physical object identities.

(1) Emphasizes procedures that compute functions - mappings from values from a domain, into values from a codomain.

(2) Discourages distinguishing between procedures that compute the same function.

Functional languages are languages that facilitate and encourage functional programming. Does JavaScript? IMO, it doesn't even do (0) very well, which is a precondition for discussing whether it does (1) or (2) well.

> garbage collector, persistent data structures

Don't conflate “purely functional” with “persistent”. Purely functional programming can deal with ephemeral data structures just fine - using substructural types. In the other direction, there exist persistent data structures whose implementation internally uses imperative assignment.

> powerful and flexible

Those are desirable qualities in a language, but they are orthogonal to whether the language supports functional programming.

> express all of these ideas in an accessible way

JavaScript doesn't even make it easy to talk about structurally equal values. Since everything is mutable, the only notion of equality that the language will actually respect is equality of physical object identities.

Without the ability to talk (soundly) about structural value equality, you can't formulate algebraic laws (e.g., the monoid or group laws), which is the basis for equational reasoning - one of the key benefits of programming in a functional style!


You can have weakly/dynamically typed functional languages (most lisps for example) just like you can have strongly/statically typed procedural or OO languages, like Fortran or C++.

Haskell the language also knows nothing at all about invariants, and the language will happily let you make something a Monad even if it doesn't obey the right laws. The culture and libraries of course take invariants quite seriously, but some aspects of the Javascript culture also take invariants quite seriously, like Promises for example.


> You can have weakly/dynamically typed functional languages (most lisps for example)

I would call Racket a functional language. Common Lisp? Nope.

> Haskell the language also knows nothing at all about invariants

I'm aware. But I'm not talking about mechanically enforcing equational laws. I'm talking about the ability to state them in the first place. For this, you need a sufficiently rich value language, where, for example, the list [1,2,3] is always the list [1,2,3] regardless of where it resides in memory.

In JavaScript, [1,2,3] isn't a list. It's an expression that, when evaluated, constructs an object whose initial value is one particular list, but its value at another point in time might be a different list. Furthermore, if you evaluate [1,2,3] twice, you get completely different objects. Although the objects are first-class, the list values aren't, so you can't (soundly) formulate any equational laws about lists. And object identities have an equational theory so weak (“everything is equal to itself and nothing else”) that it's completely useless.


I think in any cases you will have to define your notion of equality in the mathematical language you use. Indeed, even in Haskell, the equality operator returns a Haskell boolean but not a proposition, and cannot cope with equality on functions (I guess).


> I think in any cases you will have to define your notion of equality in the mathematical language you use.

The point is that I can reason about equality of ML and Haskell expressions in ML and Haskell themselves, with a few minor extensions (e.g., the usual laws of arithmetic, applied to pure `int` expressions), whereas reasoning about equivalence of JavaScript programs requires carrying out the entire reasoning process in a separate metalanguage. The latter is obviously far more tedious, which is why programmers have largely given up on actually reasoning about JavaScript programs, preferring testing as an alternative.

> Indeed, even in Haskell, the equality operator returns a Haskell boolean but not a proposition,

Equality testing (a runtime operation, only valid for types with decidable equality) is different from propositional equality (a type constructor on its own, which can be used on any type). See https://existentialtype.wordpress.com/2011/03/15/boolean-bli... for details. Haskell doesn't have a propositional equality type constructor.

> and cannot cope with equality on functions (I guess).

Indeed, and, in any higher-order language, this is a feature, not a bug.


> whereas reasoning about equivalence of JavaScript programs requires carrying out the entire reasoning process in a separate metalanguage

I do not see how you can reason about Haskell in Haskell either, as this is a programming language and not a proof language (maybe I am missing something?).

> Haskell doesn't have a propositional equality type constructor.

This is what I meant. Since with both Haskell and JavaScript you will need to define a propositional equality, in my experience this does not help that much to have a better decidable equality.


> I do not see how you can reason about Haskell in Haskell either, as this is a programming language and not a proof language (maybe I am missing something?).

http://www.haskellforall.com/2013/12/equational-reasoning.ht...

http://www.haskellforall.com/2014/07/equational-reasoning-at...

The reasoning is entirely carried out by replacing Haskell expressions with contextually equivalent ones.

> Since with both Haskell and JavaScript you will need to define a propositional equality

No, you need much more than a propositional equality to be able to reason about JavaScript programs. If you try to use Haskell-style equational reasoning on JavaScript objects, you can only pick between your reasoning being trivial (because every object reference is only equal to references to physically the same object) or unsound! So if you want a more useful notion of program equivalence, you'll have to use a separate logic (e.g. Hoare logic) or axiomatic system (e.g. Dijkstra's predicate transformer semantics) for reasoning about imperative programs.


It is by far the best mainstream language for functional programming.


yes, I think it does, it's not a pure functional language so you can break out of functional programming easily ( and accidentally ). But nothing really stops you from doing FP or playing with FP concepts. There's some nice core FP libraries like Ramda for JS. Also we are seeing more and more application libraries that are taking a more functional approach. Could they have used a specific functional programming language? sure... But, I think that might of missed the target audience. Most haskell / lisp / Ocaml / etc etc programmer would be comfortable with these terms already.


Once you get far enough with template metaprogramming, C++ start to look like a slow version of Haskell with horrible syntax and cryptic error messages...


> For a long time I thought that was a normal part of cs curriculums, but it seems not.

Alas, not all CS programs are created equal. Many skip entirely over FP because it isn't 'what the industry does'.


Pinyin is a thing that exists tho?


Pinyin's existence is as a stepping stone, and misses out on a lot of interplay between words. Pinyin negates how you can separate Chinese characters into different symbols, such as the Chinese character '鮮' ('xiān' in pinyin), is the combination of '魚' ('yú') and '羊' ('yáng'). It's certainly not impossible to learn Chinese through pinyin, but it would be an odd choice.


It's not an odd choice. I've never heard of anyone learning Chinese as a second language who doesn't use pinyin at least for the first few years.


I'm not convinced that there are enough hanzi that decompose nicely like that to make up for all the other issues.


Pinyin doesn't negate Chinese characters. It's just tackling another issue - sounds and tones.


> Also, its very strange to see these concepts illustrated with Javascript.

Indeed.

And I don't like it at all. It seems as if everybody is afraid that web developers won't understand the concepts if they are expressed with mathematical symbols instead of JavaScript functions.


Honestly I want both. The mathematical expressions, and an implementation in any language. I never took math in university and am woefully deficient. But the past few years proved to me that I'm 100% capable of learning the concepts.

I just really sorely need examples in a syntax I understand.


Syntax is easy to learn if you know the mathematical concepts. The other way around... not so much.


all those symbols in haskell aren't really helping, even if the syntax is easy to learn...


Most of the funky symbols in Haskell are library defined operators. You can define your own in a single line of code. They behave just like functions, just with an infix syntax by default, instead of prefix.

You can use Hoogle (eg https://www.stackage.org/lts-6.9/hoogle?q=%3E%3E%3D) to look them up.

It's a bit daunting at first. But most code actually only uses operators from at most a few libraries. Once you understand Monoid, Applicatives and Monads and their operators, you'll be doing OK.

There are alphabetic names for their operators. But they are not used much---working programmers prefer the symbols. Alas, learning wouldn't be much easier with them either, because most of the work is in understanding the concepts. People would complain just as much about the cryptic names as about the cryptic symbols.

(The only mainstream library that really goes crazy with the symbols is 'lens'.)


hm maybe you're right.

I saw one of the problems was, that I had higher math in German and some translations aren't straight forward (monoid -> halbgruppe) so I often thought things I knew were entirely new concepts.


Oh, if you had some higher math you are already ahead of the game. (I did the same, but I got lucky and had heard of Monoide even in German.)

Yes, it's a bit of a shame that some things are so abstract that we can really give it good names. For example, the operation in the monoid is just any old operation that's associative. What name do you want to call that? I don't see anything that improves on the little Kringel that we make on the black-board, or the <> that Haskell uses.


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.


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.


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.)


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.


> Just define your own equality operator?

Have fun doing that in JavaScript. Have fun making objects/hashtables use your custom equality operator when comparing field names. Have fun making sure that every single part of your program respects the notion of equality defined by your custom equality operator.

> Eg in Haskell, whether things can be compared for equality depends on their representation.

In any higher-order langauge, that's a feature, not a bug.


Not knowing anything about this, is the end effect the same?


The effect is that, if you want to reason about JavaScript programs, you can't carry out your reasoning in JavaScript itself, but rather have to use an external metalanguage - ideally something like Hoare logic, but, realistically, usually an informal, insufficiently understood, even insufficiently defined language, like English.

OTOH, a Haskeller can reason about Haskell programs by just evaluating Haskell expressions.


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?


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


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.


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.


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... [2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...


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

The two are actually orthogonal -- generators are a control-flow structure where control keeps re-entering an existing function context and returning from it (basically, a coroutine), whereas lazy evaluation is a language-semantics choice where every value starts out as a thunk (bit of code) with enough information to compute the value, until resolved to the result.

Generators in the Python or JavaScript sense aren't really doing "lazy evaluation" in the Haskell sense, IMHO, though I can see how one sees the parallels (infinite sequences, etc). You can have the same "infinite sequence" by just defining an iterator implementation that always returns a next value, without the use of generators/coroutines.

Likewise, there are other uses for lazy evaluation than generator-like infinite sequences. For example, lazy evaluation lets you build a (finite) table of values in a memoized dynamic-programming problem, where each value is an expression that refers to some of the other values, and the lazy evaluation semantics ensure that (i) only the needed values are computed and (ii) once a value is computed, it's memoized (the thunk resolves to its result). You get demand-based computation and memoization "for free" from the language runtime.


>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.


> 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.


`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.


Generator is a specific algorithm that emulates a kind of lazy evaluation in strict languages.


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.


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


One can only hope.


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?


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... (The Builder Pattern, The Iterator Pattern, The Command Pattern)


Some of the words defined like comonad were added merely because they're defined in the fantasy-land spec. It's all still a WIP so contributions or corrections are welcome.


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.


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)


It's hard to capture monad in a paragraph and a couple examples. The utility of chain/flatmap doesn't get too interesting until you apply it to the Option Type or Promises but I didn't want to require readers to come with knowledge of them. Maybe a promise-based example isn't asking too much though


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.


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.


For anyone looking for something more in depth, check out https://drboolean.gitbooks.io/mostly-adequate-guide/content/


Neat! Thanks for sharing.


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


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.


I think most people would need to write some code to really grok it, I would anyway. It's a simple enough idea in context, but there's no royal road to understanding.

The explanations I know of (all from the Haskell community) are either

1) formal, referring to ideas from category theory,

2) metaphorical, conveying the ideas by intuitions you may already have about burritos or whatever, or

3) pragmatic, focused on how and why you use them in code.

I think this last category, pioneered by byorgey's wonderful TypeClassopedia [1], is by far the most useful in teaching people about monads but it depends on observing them yourself. (Ditching the metaphors actually seemed quite radical to me at the time -- I presumed they were necessary because everyone else did.) It builds up from understanding what a Functor is, then the next abstraction up, and so on until Monads seem like an obvious idea. The same approach is used in Learn You a Haskell for Great Good [2] but you need to doing the exercises to follow the book. sigfpe's classic explanation [3] is also by example and goes into a bit more depth. It still contains exercises for the reader though :)

[1] https://wiki.haskell.org/Typeclassopedia

[2] http://learnyouahaskell.com/functors-applicative-functors-an...

[3] http://blog.sigfpe.com/2006/08/you-could-have-invented-monad...


I like how mpj explains it. Monad - FunFunFunction #21 https://www.youtube.com/watch?v=9QveBbn7t_c

Furthermore, the creator of Elm has a fun explanation too. Evan Czaplicki - Let's be mainstream! User focused design in Elm - Curry On https://youtu.be/oYk8CKH7OhE?t=1454

More serious computer scientist explains monads in the following. Erik Meijer: Functional Programming https://www.youtube.com/watch?v=z0N1aZ6SnBk&feature=youtu.be... and here too https://www.infoq.com/interviews/meijer-monads


  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...) 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)), but that seems so much harder to me I'm not sure why you would.


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.


Great point! I found this for python: https://www.stephanboyer.com/post/9/monads-part-1-a-design-p..., 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.


Precious few mathematicians ever learn what monads are...


If you use JS, if you get how Promises work your probably 90% of the way there; abstracting that pattern out to use in other contexts will probably get you the rest of the way.


Here's one from LYAH: http://www.learnyouahaskell.com/a-fistful-of-monads

There are a couple of other links here [0] including "Don't fear the Monad" by Brian Beckman.

[0] https://github.com/0xmohit/talks


My favorite:

You could have invented monads (and maybe you already have) [1]

[1] https://news.ycombinator.com/item?id=958789


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) ) 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 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.


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 :)


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


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


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


This is great. Very helpful for understanding / translation.


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


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


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.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: