Functional programming jargon in plain English • Hacker News Board

Re: Functional programming jargon in plain English

#161

Post by dllthomas » Mon, Jul 04, 2022, 9:23 PM UTC

lgas wrote: post #158

dllthomas wrote: post #156

Earlier quoted context omitted.

One obvious place to look is things that are almost a monad but can't be lawful and which might nonetheless be useful. An example that comes to mind is trying to use Set as a monad (for nondeterminism like the list monad, but with deduplication), which you can't do for some potentially avoidable technical reasons (it would have to be restricted to things you can Ord) but more importantly Set can't be a monad because…

I thought it was the case that you can't implement the Monad type class using the built in Data.Set implementation of Sets but there's no reason in principle why you couldn't build a Set Monad that works that way, right? Perhaps I am mistaken so I will investigate further.

There is a reason in principle that you can't build a Set Monad that works that way: it violates the functor laws.

In order to be a functor, you need `fmap (f . g) == fmap f . fmap g`.

The problem is that some functions (for instance, Data.Set.showTree) can produce different results for two values that compare equal.

For instance, imagine we have a set containing (only) the lists `[1,2]` and `[2,1]`; let's call it s. How many elements are in `fmap (Data.Set.showTree . Data.Set.fromList) s`? Two, because the result of fromList winds up being order dependent in the structure of the internal tree, even though both Sets represent the same set of values. On the other hand, how many elements in `fmap showTree . fmap fromList`? Just one, because the Set has a chance to "see" the output of fromList and notice that they are equal according to Eq.

Does this violation of the functor laws matter? Maybe; likely not; it depends on your use case.

But mathematically it means that the thing we are working with is not a functor, and so the thing we are working with is also not a monad (as all monads are functors).

Re: Functional programming jargon in plain English

#162

Post by endgame » Mon, Jul 04, 2022, 9:46 PM UTC

garethrowlands wrote: post #96

ratww wrote: post #24

Earlier quoted context omitted.

Monads themselves aren't really contagious, it's the actions that would otherwise have side-effects that are, and also the fact they have to be executed in sequence. This is also true for other things in other paradigms, such as async functions in javascript. This is a good thing, however. In imperative programming, you have invisible temporal coupling. In pure-FP you have the same coupling, but it's exposed.

While I broadly agree with you, I think the post you're responding to has a point. You can't, in general, get a value back out of a monad, so if you call a monadic function, you may well have to return a monad. The obvious example is IO: there's no (safe) way get the `a` from `IO a`, so IO is kinda contagious. Then again, there are lots of monads, such as `Maybe` and `List`, where you can get values out. These aren't…

I think that applicatives and monads feel more contagious than they really are, because at first people tend to write functions that consume values of type `f a` too readily. This is because it takes some time to become comfortable with `fmap` and friends, so the new Haskell programmer often doesn't write as many pure functions.

Re: Functional programming jargon in plain English

#163

Post by pacomerh » Mon, Jul 04, 2022, 10:06 PM UTC

I love these definitions and will bookmark. But there's a point where you can't really explain FP concepts in plain English right?.

Re: Functional programming jargon in plain English

#164

Post by jstanley » Mon, Jul 04, 2022, 10:19 PM UTC

Jtsummers wrote: post #141

jstanley wrote: post #127

Earlier quoted context omitted.

Couldn't I "curry" a function f(x,y) to "partially apply" it on x=3 with just: function(y) { return f(3,y); } ? And then I've "partially applied" f. Is this what currying is? The syntax I posted is ambivalent about which arguments you're partially applying, isn't that superior to only being able to provide the first argument?

Currying is turning a function with arity n into a sequence of unary functions. f(x,y) = ... // arity 2 f = \x -> \y -> ... // sequence of two unary functions f x y = ... // more compact representation of the above Regarding partial application, your JS (?) example is basically what happens under the hood with Haskell, but without the ceremony: f x y = ... fByThree = f 3 fByThree y = f 3 y Those last two are equivale…

Thanks!

Re: Functional programming jargon in plain English

#165

Post by shikoba » Mon, Jul 04, 2022, 10:50 PM UTC

dllthomas wrote: post #161

lgas wrote: post #158

Earlier quoted context omitted.

I thought it was the case that you can't implement the Monad type class using the built in Data.Set implementation of Sets but there's no reason in principle why you couldn't build a Set Monad that works that way, right? Perhaps I am mistaken so I will investigate further.

There is a reason in principle that you can't build a Set Monad that works that way: it violates the functor laws. In order to be a functor, you need `fmap (f . g) == fmap f . fmap g`. The problem is that some functions (for instance, Data.Set.showTree) can produce different results for two values that compare equal. For instance, imagine we have a set containing (only) the lists `[1,2]` and `[2,1]`; let's call it s.…

İ prefer to say that show tree violates the abstraction. You can have s1=s2 but not f(s1)=f(S2). So f (show tree) is not a real function (or = is not a real equal). But showtree is a debug function, it doesn't count. İt's like saying in C that a=13 and b=13 isn't a real equality because &a and &b are not equal. There is the underlying structure and the structure after the equivalence. You have to know of what you're talking.

Re: Functional programming jargon in plain English

#166

Post by shikoba » Mon, Jul 04, 2022, 10:58 PM UTC

stillkicking wrote: post #132

shikoba wrote: post #16

Earlier quoted context omitted.

> 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

This explanation is useless imo because it expects the reader to already understand the weirdest part: "If I have a function A -> B, how could I possibly get something that goes in the direction F B -> F A out of it?" The answer to this is: given e.g. a function that accepts a B, i.e. `B -> ...` you can compose it with `A -> B` on the _input side_, to get a function that accepts an A, i.e. `A -> B` (+) `B -> ...` = `…

Saying without examples is a pedagogical nonsense, I can't argue, because I agree.

But if I provide the two typical examples Hom(A,) and Home(,A) and how they transport the arrows it starts to click.

There is also List which is a covariant functor. The stupid Home(unit,) which is the "identity" functor.

I could also add Hom(Bool,) which is the pair functor, ie Hom(Bool,A) is a tuple in AxA. A->AxA (or A->Him(Bool, A)) is a covariant functor.

Etc. Examples are the keys to understand the idea.

Re: Functional programming jargon in plain English

#167

Post by cratermoon » Tue, Jul 05, 2022, 12:20 AM UTC

b3morales wrote: post #139

cratermoon wrote: post #104

Earlier quoted context omitted.

Assuming that this guide is aimed at people entirely unfamiliar with these concepts, I think it fails to explain the concept. Yes, it is plain English, but it is not simple or common English, and it's mostly code examples. I'm familiar with the concepts, but not fluent, and functional programming jargon I already knew is not clearer to me now than it was before I read it. Good sample code, though. It only required me…

I agree, and not just the English. There is use of particular notation that does not explain anything unless you already know what it means: > f is a morphism from a -> b, and g is a morphism from b -> c; g(f(x)) must be equivalent to (g • f)(x) If I don't already understand (g • f)(x) this is not helpful at all. This other one especially jumped out at me (perhaps because I've personally never seen this "bent equals…

Oh boy. I didn't put on my glasses to read it so I didn't notice that ≍ is not = and that's important.

I think in the context it just means the result is in the range of "function applied to object"

Re: Functional programming jargon in plain English

#168

Post by crossroadsguy » Tue, Jul 05, 2022, 3:31 AM UTC

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.

Re: Functional programming jargon in plain English

#169

Post by shikoba » Tue, Jul 05, 2022, 4:34 AM UTC

62951413 wrote: post #137

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…

I can relate to your sentiment but calling it " pseudo intellectualism" is a step too far in my opinion. The math behind FP is legit. Like Programming Language Theory it can teach you interesting abstractions. And useful basic things like how most collections you use are monoids, map/flatMap, etc. On the other hand, the original Design Patterns book was published in 1994. I'm still waiting for its FP equivalent.

Design patterns are just a repetition of the golden rule "don't repeat yourself" (when they're not they're antipattern). Maybe the functional developers don't need a book to teach them how to walk...

Re: Functional programming jargon in plain English

#170

Post by Akronymus » Tue, Jul 05, 2022, 6:49 AM UTC

saithound wrote: post #54

goto11 wrote: post #36

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. > 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. How a…

Mathematicians use "just" with a specific meaning: it is not used to gloss over something that the author doesn't know how to explain. It has a purpose, useful for mathematically trained readers. For suc a reader, "a homomorphism is just a structure preserving map" makes it clear that "homomorphism" and "structure-preserving map" can be used interchangably, and that by understanding one of the concepts, you'll immedi…

I think for the layperson "equivalent to" would work better than "just".