Hacker News Reader

Comment by BoppreH | Hacker News Reader

I think that's a bit harsh. It's frustrating to translate an imperative task to an FP language, but it's also frustrating to translate a Bash command into Python, or Prolog semantics into Go, or any program full of mutations and global state into (safe) Rust.

I think a lot of the friction you mentioned comes from learning imperative programming first. Our vocabulary, tools, and even requirements come with an implicit imperative assumption.

PS: I didn't downvote you, though your tone is harsher than I prefer for HN.

View on HN

I would argue that command sequences that mutate global state are far more intuitive to humans (food recipes, furniture assembly manuals, the steps to take to fix a flat tire on your bike, etc.) than functions. So it’s not just what we learn first in a pedagogic sense. We’re already wired for imperative programming. “Thread the state of the world through the food recipe instructions” is a ridiculous concept to a normal person.

I think it is very dependent on the problem at hand.

Some traditional CS algorithm? Mutable it is. But a compiler with different passes is a great fit for the FP paradigm.

But even if we go to pure math, you will have constructive proofs beside traditional ones.

> “Thread the state of the world through the food recipe instructions”

Oh, that's how it works? That actually makes sense. Thanks!

I agree in principle. However, if you work imperatively, you'll use _much_ more (global) state than if you worked with a pragmatic functional language like Clojure. Which in turn leads to normal people not understanding what's going on, since humans are built to keep, say, 10 things (atoms) in mind, not 100.

I strongly disagree, it is definitely the teachers and advocates of FP which are lacking.

There are plenty of programs and libraries written in "imperative" languages like Python with lots of functional style applied. That should be the starting point, not sermonizing about whether a monad can even be defined with English words.

Of course you can use English words. To quote:

"A monad is just a monoid in the category of endofunctors, what's the problem?"

Haskell is particularly, egregiously bad for this.

None of the concepts are particularly complex. They're unfamiliar, sort of, but they're not insanely obscure.

But then there's the labelling. If an ordinary for-loop was called a yarborough and a function call a demicurry it really wouldn't help with the learning.

I realise the concepts are supposed to map[1] to category theory, but category theory stole words like monad from elsewhere anyway.

[1] Ha.

This comment only makes sense in the monolingual USA, where learning a new language is an arduous task and not something people do all the time.

German, Polish, and Chinese programmer all learn what "for" means.

And anyway, Java calls functions "methods", yet somehow we survived.

That is somewhat true, but in practice, not really so.

Imagine you're a Chinese programmer. Obviously a lot of open source documentation is in English, so you have to learn basic English anyways (I'm bilingual from an early age, but most people struggle if they start the process even in their teens).

Then you see English-speaking programmers talking about yarborough and demicurry as if they were English words. Now you're majorly confused. Worse, an encyclopedia of philosphy tells you that it means something (see eg. https://plato.stanford.edu/entries/leibniz/#MonWorPhe ) What's the actual connection? When you ask, people casually tell you to read up on category theory, which is apparently something they teach to advanced Math majors. Remember we're struggling to learn basic English here!!!

Tangent: what I like about (the) Haskell (ecosystem) is that most often you'll find the exact right tool for a job.

Eg: in Python you get `dict` ... In Haskell you get very specialized versions of you need them. Do you have integers as keys? `IntMap` is your friend. Hash able keys? `HashMap`! Don't know anything about your keys except for it a key is different from another? You still functions that tread a list of tuples as a map.

> I think a lot of the friction you mentioned comes from learning imperative programming first. Our vocabulary, tools, and even requirements come with an implicit imperative assumption.

Yes that's exactly my point and why no one cares about how great a monad is when trying to learn FP.

How is that a problem of functional programming? When you learn a language you don’t start with “Well in English we say…” you learn language with its idioms and quirks.

It's not. It's a problem with people trying to sell FP to non FP programmers. A non FP programmer doesn't care about monads. They care about making what they already do simpler and clearer.

Fair enough. I guess it's the same as when you're trying to teach imperative programming starting from classes and OOP.

> When you learn a language you don’t start with “Well in English we say…” you learn language with its idioms and quirks.

Idioms and quirks come after rote memorization of basic vocabulary and sentence structure, which are then used to learn the idioms and quirks. I think Bongo is saying FP-ers are skipping the basic vocabulary part and jumping straight to the idioms and quirks.

It was interesting in 2015/2016 to see co-workers learn some of that basic vocabulary of functional programming without realizing they were touching on it, using map/fold/etc when learning React.

s = 1; s = 2;

is same as

unit(1).chain(add(1))

That's the beauty of immutable data.

You have to admit it’s not a great example, though, and it comes off as verbose for no reason.

1. it's not

2. the beauty of immutable data isn't in hiding meaning behind meaningless piles of functional abstractions

Reply on news.ycombinator.com