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

121–130 of 191 posts

Re: Functional programming jargon in plain English

#121

Post by skybrian »

jerf wrote: post #97
ncmncm wrote: post #57

Earlier quoted context omitted.

Saying "it allows for very concise partial function application" does nothing but repeat the definition. It does not, in particular, offer any reason to want that. What is so special about the first argument, that I want to fix it? Why not the third? Why is what I do to fix the third not just as good for the first? Pattern matching is a good example of a language feature included because they could not figure out how…

I'm not trying to dodge your question, but the answer to your question is that until you work with it for a while you're not going to understand it. Any blog-sized, bite-sized snippet isn't impressive. You have to work with it for a while. I speak many computer languages, and one of the ways I measure them is, "what do I miss from X when using Y?" The answers will often surprise you; the thing you'd swear up and down…

That's an example of why Haskell code is often hard to read, and why I'm glad this isn't available in other languages. Why not write out the callback given to map using a let block? Then you can give meaningful names to intermediate values so it's easier to see how the pipeline works.

(Though, functional programmers would probably pass up the opportunity and use one-letter variable names.)

Re: Functional programming jargon in plain English

#122

Post by ratww »

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…

Yes, this is what I mean. IO is contagious for reasons unrelated to it being a Monad.

Re: Functional programming jargon in plain English

#123

Post by labrador »

jacquesm wrote: post #119
labrador wrote: post #100

When I was an assembly programmer, I knew C could help me When I was a C programmer, I knew OOP could help me When I was a JavaScript programmer, I knew TypeScript could help me. I don't know how functional programming can help me, but I'll keep trying to find a reason because people say it can

You can get a lot of mileage out of functional programming as a style without using a functional programming language, and you can do it in (almost) any other language, the big one: avoid side effects to functions as much as possible. That alone can make all the difference between a maintainable, refactorable and testable codebase compared to one that has side effects all over the place. If that's all you get out of…

That's always been good programming practice to me, not functional per se. I learned the term 'spaghetti code' early on and took it to mean not just gotos, but lots of flags, especially globals.

Re: Functional programming jargon in plain English

#124

Post by shikoba »

init0 wrote: post #115
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

Send a PR to fix it!

There are so many things to fix. And they should have use coq as default language.

Re: Functional programming jargon in plain English

#125

Post by samiskin »

pdpi wrote: post #86
urxvtcd wrote: post #73

Earlier quoted context omitted.

While I _think_ I understand monads on some rudimentary level through how join and bind operate, your "just sequencing" doesn't tell me anything. And this is a problem with a lot of these texts. Maybe that's trivial to the writers, but it makes me feel even dumber when I cannot understand a concept I already understand, lol.

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!

Re: Functional programming jargon in plain English

#127

Post by jstanley »

jerf wrote: post #97
ncmncm wrote: post #57

Earlier quoted context omitted.

Saying "it allows for very concise partial function application" does nothing but repeat the definition. It does not, in particular, offer any reason to want that. What is so special about the first argument, that I want to fix it? Why not the third? Why is what I do to fix the third not just as good for the first? Pattern matching is a good example of a language feature included because they could not figure out how…

I'm not trying to dodge your question, but the answer to your question is that until you work with it for a while you're not going to understand it. Any blog-sized, bite-sized snippet isn't impressive. You have to work with it for a while. I speak many computer languages, and one of the ways I measure them is, "what do I miss from X when using Y?" The answers will often surprise you; the thing you'd swear up and down…

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?

Re: Functional programming jargon in plain English

#128

Post by eddyschai »

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.

Re: Functional programming jargon in plain English

#130

Post by dllthomas »

urxvtcd wrote: post #73
mjburgess wrote: post #34

Earlier quoted context omitted.

Currying is one of those cases where the code is the explanation I think in many cases this isnt right, eg., Monads. The reason flatMap() "flattens" is just that "flattening" is really just sequencing, denesting the type using a function requires a sequenced function call: f(g(..)) This applies to many of these "functional design patterns"... theyre just ways of expressing often trivial ideas (such as sequencing) und…

While I _think_ I understand monads on some rudimentary level through how join and bind operate, your "just sequencing" doesn't tell me anything. And this is a problem with a lot of these texts. Maybe that's trivial to the writers, but it makes me feel even dumber when I cannot understand a concept I already understand, lol.

A big problem with "just sequencing" is that there are a lot of ways of sequencing that either don't require the complexity of a monad or for which the monad interface is insufficient.
Post reply on HN