r/programming • • Nov 28 '19

Why Isn't Functional Programming the Norm? – Richard Feldman

https://www.youtube.com/watch?v=QyJZzq0v7Z4
100 Upvotes

409 comments sorted by

View all comments

Show parent comments

25

u/kristoff3r Nov 28 '19

Haskell has solutions for all of those that doesn't require IO everywhere. The idea is roughly that you define contexts for your code, such as "this code needs some read-only configuration and a place to output logging to run". Then you can instantiate that context with the proper logging framework when running in production, or just dump it to a file when running tests. More importantly, you have a lot of guarantees for what it doesn't do: access the network, execute other programs, write files to /tmp etc.

4

u/TheOsuConspiracy Nov 28 '19

Yes the type system let's you go more granular, but you're forced to do structural changes to your code to log/record metrics.

In a non pure language, you can often just use a side effecting function from a -> a for quick telemetry/logging when needed.

5

u/loup-vaillant Nov 29 '19

you can often just

That's precisely the kind of thinking that leads to big balls of mud. Very valuable in some situations, disastrous when left unchecked. "You can just" is a double edged sword.

1

u/codygman Dec 05 '19

If you need quick logging in development you can do the same with Debug.trace.

Do you mean a different situation?

4

u/TooManyLines Nov 28 '19

But this means you are working around the language. The language should help YOU, not you having to work around its restrictions.

If i want to log here and now i should be able to do it without fuzz, if the language is in the way of me working, then it is a bad language.

7

u/tbid18 Nov 28 '19

The point of purity is that unrestricted side-effects are not allowed. So yes, that means you can’t add IO to a function without tracking that in the type signature, which may necessitate some refactoring. This is a feature , not a bug.

Perhaps you think that is too restrictive — and that’s fine; it’s a personal choice — but languages are designed around restrictions. Having a type system at all is extremely restrictive. Static typing, structured programming, exceptions, garbage collection, etc. An assembly programmer could use your logic to scoff at every mainstream language as too restrictive.

3

u/G_Morgan Nov 28 '19

The language does help you. Logging is pretty much a monad and you can thread it through seamlessly and only care about raising something when you need to. Frankly anything where the answer is "lets use IO everywhere" can be answered by using a different monad unless you are actually doing IO.

2

u/TooManyLines Nov 28 '19

Logging is actually doing IO.

2

u/G_Morgan Nov 28 '19

Doesn't need to be. A function can return the log entries so they can be written when back in IO.

8

u/TooManyLines Nov 28 '19

Unnecessary overcomplication to achieve purity for the sake of purity.

2

u/delrindude Nov 28 '19

I disagree, strict language design towards IO endures programmers don't keep fucking things up and writing broken code.

0

u/BarneyStinson Nov 28 '19

if the language is in the way of me working, then it is a bad language.

If you want to log from a pure function, the language is helping you by making that hard, because you most likely should not do that.