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

31–40 of 191 posts

Re: Functional programming jargon in plain English

#31

Post by goto11 »

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 are used pervasively in Haskell, less so in other functional languages.

In Haskell, you can't write a "Hello world" program without using monads, so you cant really avoid learning about them.

IMHO monads are only really useful in Haskell because it has specific built-in syntax sugar to support them. Without this syntax sugar, they would be very cumbersome to use. So it's not really the monad type per se which is interesting, it is the code style which the syntax sugar enables.

Re: Functional programming jargon in plain English

#34

Post by mjburgess »

stingraycharles wrote: post #13
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…

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) under some constraints.

Re: Functional programming jargon in plain English

#35

Post by ncmncm »

This is more helpful than anything I have ever encountered on the topic.

Comments:

1. It should explain map somewhere before it is used.

2. For the more abstruse and abstract concepts, a comment suggesting why anybody should care about this idea at all would be helpful. E.g., "A is just a name for what [familiar things] X, Y, and Z have in common."

3. It goes off the rails halfway through. E.g. Lift.

Re: Functional programming jargon in plain English

#36

Post by goto11 »

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 about removing the "just":

> A homomorphism is a structure preserving map. A functor is a homomorphism between categories as it preserves the original category's structure under the mapping.

Much clearer. Although most readers would now ask what "structure" and "structure preserving" means, since this is never explained.

Re: Functional programming jargon in plain English

#39

Post by fhars »

ogogmad wrote: post #18
endgame wrote: post #9

Earlier quoted context omitted.

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…

But then monads are a way to think about computations sequentially. If I write highly sequential code in a C-like language, in many cases most of the code is just boilerplate made necessary by the absence of native support for monads:

    int ret = doStepOne();
    if (ret == RESULT_OK) {
        ret = doStepTwo();
    }
    if (ret == RESULT_OK) {
        ret = doStepThree();
    }
    return ret;
would just be

    doStepOne() >>= doStepTwo() >>= doStepThree()
in a language with support for monads.

Re: Functional programming jargon in plain English

#40

Post by ncmncm »

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…

Every anything-oriented language amounts to wankage.

The world is a complicated place with complicated problems. Complicated problems are always solved by splitting them into different sub-problems, each routinely of radically different character than the outer problem, other sub-problems, or its own sub-sub-problems.

So, a language "oriented" for any one of those is a terrible choice for others. To solve any whole problem, your language should support all the styles that might be useful. Often, a sub-problem falls to a style combining a little of this style and a little of that. Styles should not be straitjackets.

Generally, it is better if the language is powerful and expressive enough that support for a style is not built in, but can be provided by a library. Any fancy built-in feature is always an admission that the core language wasn't strong enough to express it in a library.

That is why weak languages so often have fancy core features (e.g. dictionary): without, you would be left with no support. This should make us suspicious of a "match" feature.

A more powerful language lets you pick from variations on the fancy feature in a library or libraries. And, the library might define a new style useful for the sort of problems the library is designed for.

Post reply on HN