What is the point of functional programming?

Stateless programming. No side-effects.

What about black hat haskell

>No side-effects.
>what is a monad

I don't think you understand monads user

1) Reasonability.
2) Static Analysis
3) Correctness
4) Maintainability
5) Expressiveness

These are the 5 main benefits I generally express when trying to explain to people.

sorry sempai forgot () from Semigroup, () from Alternative, and oh wait there's a fuckton more...

en.wikipedia.org/wiki/Monad_(functional_programming)#The_I/O_monad

wreck yourself at your own leisure

The fact that Haskell uses a monad to abstract IO does not mean that monads create side effects.

I'm someone else...

Realtalk, would you like a more detailed explanation of what we mean by "no side effects", and monads in general?

If you're genuinely interested I'd be happy to help explain. I ask so I don't waste effort if this is just a dick-waving thing though.

are you autistic?

sure, I'd be very grateful.

you can use ruby or js as a reference if you want

There's no point, that's why they call it “point-free notation.”

Okay, lets start with monads then. A monad is simply an architectural pattern. A "design pattern" if you will. More specifically though, the FP world has a tendency to use "patterns" that are inspired from the realm of category theory. This means that to implement the pattern is to obey certain laws.

The one that comes in handy for explaining monads specifically is that there is a law that they must have a function called "bind" defined for them.

This function will take a monad of some type, and a function from that type to a monad of another type, and apply it such that the result is a monad of the second type.

Think of this somewhat like the javascript Promise .then, which I believe can return a promise or a simple value, but the result is still just a promise. They are flattened.

Bind is also often called FlatMap in this context.

There are other monad laws (traits of the design pattern), but this is sort of the most commonly needed to understand trait for beginners.

As to the idea of "no side effects", what we mean is that invoking a function will always have exactly the same result for the same inputs.

That is to say, even if you call a function that represents, say, printing to a screen... What you get is a VALUE that represents printing to the screen. You will always get that same representational value no matter how many times you call the function.

And because these things are lazy evaluated and it is up to the "runtime" environment to "act on" these effectful values, the only thing that matters is the composition returned to the environment.

That is to say, I can call the function to delete things from the database 1000000 times if I want, but if I filter those values out of the end result before main evaluates, it doesn't happen. It doesn't matter that those functions were called and that the functions evaluated, only their value results matter for the runtime. Filter them out, and no effect happens.

Sort of a poorly worded start :3

best reasons so far, not even jokin

I think the correct question is "what is the function of functional programming"

the important question is, can you make a website with it? can you make it profitable?

>can you make a website with it? can you make it profitable?
Yes to both.

ask kikebook: github.com/facebook/Haxl

>Filter them out, and no effect happens.

So you're saying, if I understand this correctly, the side effects can be unpredictable? Isn't that even worse?

I mean it seems convenient when you build a simple calculator app or something, but inconvenient if it's anything beyond.

I don't really get it, and I probably won't get it until I do it myself. The only reason why I haven't is because I haven't found a use for haskell yet (I've tried)

maybe one day.

>, if I understand this correctly, the side effects can be unpredictable? Isn't that even worse?

I am saying they are completely predictable based on the composition of the value of main.

I work in the functional world professionally. It is WAY easier to work in large codebases that are purely functional that others.

You don't need to work about state mutation or mentally tracking a lot of shit. It's really a lot cleaner.

They are unpredictable because of laziness, so if you want "predictable" side effects you use a state/IO monad because they guarantee they'll compute when you call them, that enables you to have for example x

It's IO that's unpredictable. Accessing a file is unpredictable.

I was reading some interview with one guy that works in google sec team + google zero etc. and he said that to be functional programming wizard you have to be genius tier.

>worry about state mutation

pure functions would indeed be nice. they're probably coming to js at some point.

Assume I'm writing a complicated data structure (just in memory), with all the related functionalities. Would haskell be the best choice for that? Should I try using it for that?

anyway thanks for your time.

Try to code that in your non FP language:
let create_file file f =
let oc = open_out file in
let r =
try
let r = f oc in
flush oc;
r
with
| x ->
close_out oc;
begin try Sys.remove file with _ -> () end;
raise x in
close_out oc;
r

>tfw you know why FP is the future and the only way to produce reliable code.

I'ts predictable in the sense that every call will be executed, I'm not talking about it's result

could you be more specific, please? i can't seem to find the article.

Attached: 4kggytkgrqwz.png (1179x659, 1.01M)

It would take a genius to predict behavior of a concurrent program written in imperative/pOOP code.

>tfw you know Caml is shit

Regardless, Scheme did it better than Haskell.

Attached: oh-please-do-tell-me-more-via-9gag-com-14040283.png (500x532, 142K)

lol, scheme's type system is garbage.

>needing types
hahhahahahaha

real functional programmers only need lambda and let

so go write assembly or forth then fuckwad.

no thanks, Lisps work fine without needing a strong type system.

>Works at Google.
What would an advertiser know about functional programming?

It's pretty simple, just two rules:

1. Don't mutate variables.
2. Use only pure functions.

Of course, things get a little weird when you need to [spoiler]mutate state and use impure functions[/spoiler]

fpbp

Oddly enough, it's not functionality.

this perfectly sums it up

FUNctional programming is FUN.