Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Functional programming jargon in plain English

github.com

Post reply on HN
Print view View original

11–20 of 191 posts

Re: Functional programming jargon in plain English

#11

Post by frogulis »

jstx1 wrote: post #5
ijidak wrote: post #3

This is great. Finally understand monads a little better. Definitely saving this for later.

Why do monads come up so often when people talk about FP? Is it a meme or are they really an important and difficult to understand concept?

Many important "effects" (e.g. non-determinism, IO, asynchrony, environmental context, state... etc) are modelled as monads in Haskell.

You _can_ write Haskell code without understanding what a monad is, but composing and creating these things is going to be a little painful without that understanding.

Additionally, it seems to be a harder concept to grasp than e.g. functors or monoids.

I think this can be partly attributed to many Haskell programmers first being introduced to monads that are less than ideal for understanding the concept.

Shameful plug, I've written some thoughts on this here: https://frogulis.net/writing/async-monad

Re: Functional programming jargon in plain English

#12

Post by alpaca128 »

jstx1 wrote: post #5
ijidak wrote: post #3

This is great. Finally understand monads a little better. Definitely saving this for later.

Why do monads come up so often when people talk about FP? Is it a meme or are they really an important and difficult to understand concept?

I'd say both.

For me the difficulty comes from the formal explanations/definitions, those always manage to confuse me. Result & Option types seem to have something to do with it so I may already have some understanding of the concept. But many explanations containing the word Monad also contain various other abstract mathematical terms. Trying to explain the concept to someone without mathematical background can be tricky.

Re: Functional programming jargon in plain English

#13

Post by stingraycharles »

mjburgess wrote: post #4

These definitions don't really give you the idea, rather often just code examples.. "The ideas", in my view: Monoid = units that can be joined together Functor = context for running a single-input function Applicative = context for multi-input functions Monad = context for sequence-dependent operations Lifting = converting from one context to another Sum type = something is either A or B or C.. Product type = a recor…

I completely understand what you’re saying, but assuming that this guide is aimed at people entirely unfamiliar with these concepts, I’m not sure whether these “ideas” provide any meaningful explanation to them.

Demonstrating by example what e.g. currying actually looks like is much more powerful, at least from my point of view. In that regard, I’m actually pleasantly surprised this guide does a very good job at that.

Re: Functional programming jargon in plain English

#14

Post by rswail »

singaporecode wrote: post #10

All these niche functional programming languages are an exercise in pseudo intellectualism 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 The good thing about functional programming is stressing to avoid side effects in most of the code and keep it localised in certain plac…

Functional programming is actually mathematics based on lambda calculus.

Imperative programming isn't.

OOP is a failed metaphor, unless you use composition, not inheritance, even then, the actual basis for OOP was about the messages between objects, not the internals.

> The world is made of state and processes

No, the world is made of objects that have state and messages (events) between them.

Re: Functional programming jargon in plain English

#15

Post by jmgimeno »

mjburgess wrote: post #4

These definitions don't really give you the idea, rather often just code examples.. "The ideas", in my view: Monoid = units that can be joined together Functor = context for running a single-input function Applicative = context for multi-input functions Monad = context for sequence-dependent operations Lifting = converting from one context to another Sum type = something is either A or B or C.. Product type = a recor…

Yes, but you're relying on the undefined concept of context. How do you define context?

Re: Functional programming jargon in plain English

#16

Post by shikoba »

mjburgess wrote: post #4

These definitions don't really give you the idea, rather often just code examples.. "The ideas", in my view: Monoid = units that can be joined together Functor = context for running a single-input function Applicative = context for multi-input functions Monad = context for sequence-dependent operations Lifting = converting from one context to another Sum type = something is either A or B or C.. Product type = a recor…

> Functor = context for running a single-input function

No a functor is a "function" over types that can transport the arrows:

(A -> B) -> (F A -> F B) for a covariant functor

(A -> B) -> (F B -> F A) for a contravariant functor

With the sum and product there is also the exponential:

B^A = functions from A to B

Re: Functional programming jargon in plain English

#17

Post by lopatin »

jstx1 wrote: post #5
ijidak wrote: post #3

This is great. Finally understand monads a little better. Definitely saving this for later.

Why do monads come up so often when people talk about FP? Is it a meme or are they really an important and difficult to understand concept?

They come up because people who don't understand them think they are important and people who do understand them want other people to know.

Also, speaking of memes: https://www.youtube.com/watch?v=ADqLBc1vFwI

Re: Functional programming jargon in plain English

#18

Post by ogogmad »

endgame wrote: post #9
xigoi wrote: post #6

Earlier quoted context omitted.

Haskell uses monads as an escape hatch for performing side effects, so they come up often there.

Not as an "escape hatch" (that would be something more like `unsafePerformIO :: IO a -> a`), but as a principled way to compose (among other things) IO actions. A Haskell program executes the IO action at `Main.main`, which must have type `IO ()`. `putStrLn :: String -> IO ()` is a pure function - if you give it the same input, it always the same IO action as a result.

Monads are (for better or worse) contagious. So when one function calls a monad, then it needs to be included in the monad as well. It makes introducing memoisation to a file, randomisation, and memoisation not-to-a-file (without using lazy evaluation to express it) difficult. I don't know whether the alternatives (effect systems for instance) help with this.

I personally don't use functional languages because I find them too difficult given the needs and interests I have. I think about computations sequentially most of the time.

Re: Functional programming jargon in plain English

#19

Post by ratww »

singaporecode wrote: post #10

All these niche functional programming languages are an exercise in pseudo intellectualism 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 The good thing about functional programming is stressing to avoid side effects in most of the code and keep it localised in certain plac…

It's kinda funny, because you could say exactly the same about object-oriented programming as a discipline.

In functional programming the jargon might be foreign, but they correspond with the math they came from. You also have clear rules and clear situations where you can apply all those things.

In object orientation, however, we have mostly made-up jargon (from patterns and from SOLID), the "rules" for the application of those are completely fuzzy, arbitrary and broken most of the time, and even the categorisation of those is mostly made-up. It's pseudoscientific-mumbo-jumbo compared to Monads and other FP silly-named stuff.

Re: Functional programming jargon in plain English

#20

Post by HelloNurse »

mjburgess wrote: post #4

These definitions don't really give you the idea, rather often just code examples.. "The ideas", in my view: Monoid = units that can be joined together Functor = context for running a single-input function Applicative = context for multi-input functions Monad = context for sequence-dependent operations Lifting = converting from one context to another Sum type = something is either A or B or C.. Product type = a recor…

A product type, named after Cartesian product, contains other objects of various types, but it is none of A, B or C itself.

If types A, B and C have respectively a, b and c distinct values, their sum type has a+b+c values (each value of each type is allowed) and their product type has abc values (the part of the value that belongs to each type can be chosen independently).

Post reply on HN