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

131–140 of 191 posts

Re: Functional programming jargon in plain English

#131

Post by pdpi »

samiskin wrote: post #125
pdpi wrote: post #86

Earlier quoted context omitted.

This is one of those things where looking at the type signature hard enough eventually gives the game away, but most writing on it sucks: bind :: m a -> (a -> m b) -> m b Because that function in the middle takes an `a`, your implementation of `bind` needs to be able to take an `m a` and pull an `a` out of it, which means it also has to evaluate however much of `m` is needed to actually get to that `a`. Because that…

This makes a lot more sense than anything I've read about this in the past, thanks for the explanation!

Thanks, that's reassuring. I've long been frustrated by just how bad monad posts are in general, and been meaning to write something up about it that makes it clearer. It's good to know that I'm at least going in the right direction :)

Re: Functional programming jargon in plain English

#132

Post by stillkicking »

shikoba wrote: post #16
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

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

Once you've managed to get that across, you can start talking about contravariant functors. But expecting people to just intuit that from the condensed type signature is pedagogical nonsense.

Re: Functional programming jargon in plain English

#133

Post by mypalmike »

eddyschai wrote: post #128
naillo wrote: post #33

"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." Oh ok. Plain english.

Maybe if I explain what a Monad is in Plain English it'll help you understand functors? A monad is just a monoid in the category of endofunctors.

I think you need to explain endofunctors.

An endofunctor is the category containing monoids such as the monad.*

*This is probably wrong. Please don't explain.

Re: Functional programming jargon in plain English

#134

Post by the_only_law »

eddyschai wrote: post #128
naillo wrote: post #33

"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." Oh ok. Plain english.

Maybe if I explain what a Monad is in Plain English it'll help you understand functors? A monad is just a monoid in the category of endofunctors.

The closest I've come to understanding Monads was funny enough, the Wikipedia page (ok so there's at least two pages on Wikipedia for Monads, one in a category theory context, and one in a more general programming context, the latter I could actually begin to grasp). It wasn't overly full of vocabulary from category theory, nor did it try to compare it to taco bell menu items.

Re: Functional programming jargon in plain English

#135

Post by IncRnd »

eddyschai wrote: post #128
naillo wrote: post #33

"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." Oh ok. Plain english.

Maybe if I explain what a Monad is in Plain English it'll help you understand functors? A monad is just a monoid in the category of endofunctors.

If I may also quote!

A monad is a special kind of a functor. A functor F takes each type T and maps it to a new type FT. A burrito is like a functor: it takes a type, like meat or beans, and turns it into a new type, like beef burrito or bean burrito.

Re: Functional programming jargon in plain English

#137

Post by 62951413 »

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.

Re: Functional programming jargon in plain English

#138

Post by dboreham »

ebingdom wrote: post #106
jimbob45 wrote: post #84

Earlier quoted context omitted.

The lambda calculus is an entirely arbitrary way to organize things in math. It’s not based on nature or truth at all. The real problem, though, is that FP doesn’t do anything well. It’s never the fastest method of programming, which means that it needs to excel in some other way for its proponents to be right about it. Is it the most maintainable? Maybe if you have zero side effects but then any paradigm would be in…

> The lambda calculus is an entirely arbitrary way to organize things in math. It’s not based on nature or truth at all. Lambda calculus, category theory, and logic are essentially 3 sides of the same coin (the Curry-Howard-Lambek correspondence). The rules of lambda calculus match those of natural deduction. It runs quite a bit deeper than you're suggesting here. It's not just some arbitrary formalism.

Glad to see these comments because the parent's "it's math therefore from a deity, and much more correct than your grubby computer stuff" is so often trotted out. It turns out that there's no directionality to the relationship between mathematics and computers -- they're the same thing and one can be transformed into the other. e.g. Lambda Calculus is just a kind of VM someone came up with that can be used to model certain structures. Same for Category Theory, and same for Logic. So you might as well say that Lambda Calculus is derived from IBM 360 assembler language than the other way around.

Re: Functional programming jargon in plain English

#139

Post by b3morales »

cratermoon wrote: post #104
stingraycharles wrote: post #13

Earlier quoted context omitted.

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…

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 sign" ≍ before):

> A functor must adhere to two rules:

> Preserves identity

> object.map(x => x) ≍ object

What does that sign ≍ mean? If I don't know, I am no closer to understanding functors. And the sign is not explained anywhere in the document.

Re: Functional programming jargon in plain English

#140

Post by Rumudiez »

labrador wrote: post #108
aeonik wrote: post #103

Earlier quoted context omitted.

The biggest benefit I see is lack of side-effects. With a functional program you can be sure that your can safely call any function without having to worry about the current state of your app. A proper functional program can start to do very cool things safely: like hot reloading of code. When I'm debugging a Clojurescript app I can have a live running game, and update the physics without even reloading the page. It'…

I should probably add that I program mostly C# so I'm getting Functional benefits like Map and Filter because Eric Meijer added LINQ. He made it his life's work for a few years to bring functional programming to the masses. But I was minimizing state long before that because state makes any program much harder to understand. Confessions of a Used Programming Language Salesman: Getting the Masses Hooked on Haskell htt…

C# might not be the best language to try FP in. F# is a popular alternative that might feel more familiar than e.g. Haskell. Since JS was one of my first languages, I learned a lot just from using the library RamdaJS which helped soften the learning curve for me
Post reply on HN