Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Functional Programming Lessons Conclusion

jerf.org

Post reply on HN
Print view View original

21–30 of 48 posts

Re: Functional Programming Lessons Conclusion

#21

Post by Tainnor »

ninetyninenine wrote: post #18
Tainnor wrote: post #10

Earlier quoted context omitted.

There must be something wrong in the way FP is taught if the takeaway that people have is that it prevents or is somehow opposed to mutation. On the one hand you have bunch of FP languages that don't care in the least bit about "purity" (i.e. being side-effect free) or are more pragmatic around it, such as various LISPs, OCaml, Scala or even parts of the JS ecosystem. And on the other hand, there's a lot of research…

No you missed the point. I completely get the meaning of segregating IO/mutation away from pure logic. And my point is, what is the purpose of all of this is 90% of what your app does is mutation and side effects? Functional shell, imperative core indeed, but the shell is literally just thin layer of skin. The imperative core is a massive black hole. Functional programming can't save you from black hole.

Obviously the answer to "this doesn't solve my problems" is "don't use it then". If your problem domain literally is nothing but API calls and DB updates, then you may not benefit from this.

OTOH, in my experience a lot of people underestimate how much pure business logic exists (or can be extracted) in many applications. In apps I've worked on I've found a lot of value in isolating these parts more cleanly. The blogbook series by the author of TFA (linked further upthread) goes into some detail about how to do that even without going fully down the "pure functional programming" rabbithole.

Re: Functional Programming Lessons Conclusion

#22

Post by Tainnor »

jerf wrote: post #9
brandonspark wrote: post #5

I was hoping this article would be a little more concrete, but it seems that it largely is talking about the takeaways about functional programming in a philosophical, effort-in vs value-out kind of way. This is valuable, but for people unfamiliar with functional programming I'm not sure that it gives much context for understanding. I agree with the high-level, though. I find that people (with respect to programming…

This is the conclusion of https://jerf.org/iri/blogbooks/functional-programming-lesson... . The concreteness precedes it, this is just the wrap up and summary.

It's a shame that this is not the link that was submitted because that (long) article was a really interesting read that gave me some food for thought and also articulated a bunch of things rather clearly that I've been thinking in a similar form for a while. I'm not sure that I agree with all of it, though (I still prefer maps, folds etc. over explicit loops in many cases, but do agree that this is less important than the overall code architecture).

Re: Functional Programming Lessons Conclusion

#23

Post by meltyness »

ninetyninenine wrote: post #6

web development today is literally just massive massive mutation operations on databases. Functional programming can't stop it, it just sort of puts a fence around it. The fence makes sense if it's just 10% of your program that you want to fence off. But the database is literally the core of our application then it's like putting a fence around 90% of the house and you have 10% of pure functional programming. Most op…

Would you consider TLA+ functional? It sounds like the tension you're describing might be how most distributed consensus protocols are implemented as imperative code, and part of the Raft excursion involved writing a TLA+ proof of the protocol.

https://github.com/ongardie/raft.tla

Re: Functional Programming Lessons Conclusion

#24

Post by aabhay »

d0mine wrote: post #16
BWStearns wrote: post #4

> I consider [having a big benefit at 100% vs an 80/20 rule] a characteristic of type systems in general; a type system that you can rely on is vastly more useful than a type system you can almost rely on, and it doesn’t take much “almost” to greatly diminish the utility of a given type system. This! This is why I don't particularly care for gradual typing in languages like Python. It's a lot of extra overhead but yo…

It may be the exact opposite. You can't express (at least you shouldn't try to avoid Turing tarpit-like issues) all the desired constraints for your problem domain using just the type system (you need a readable general purpose programming language for that). If you think your type system is both readable and powerful then why would you need yet another programming language? (Haskell comes to mind as an example of su…

On the other hand, if you think of a programming language as a specialized tool then you choose the tool for the job and don’t reach for your swiss army knife to chop down a tree.

The problem with gradually typed languages is that there are few such trees that should be chopped by their blunt blades. At least Rust is the best for a number of things instead of mediocre at all of them.

One counterpoint to this is local self exploratory programming. For that a swiss army knife is ideal, but in those cases who cares about functional programming or abstractions?

Re: Functional Programming Lessons Conclusion

#25

Post by kikimora »

I realized I don’t understand idea of pure functions anymore. If a function fetches a web page it is not pure because it modifies some state. But if function modified EAX register it is still pure. How creating a socket or changing a buffer is different from changing a register value considering that in all cases outside observers would never know?

Re: Functional Programming Lessons Conclusion

#26

Post by tines »

kikimora wrote: post #25

I realized I don’t understand idea of pure functions anymore. If a function fetches a web page it is not pure because it modifies some state. But if function modified EAX register it is still pure. How creating a socket or changing a buffer is different from changing a register value considering that in all cases outside observers would never know?

Purity is relative to a given level of abstraction?

Re: Functional Programming Lessons Conclusion

#27

Post by entropicdrifter »

kikimora wrote: post #25

I realized I don’t understand idea of pure functions anymore. If a function fetches a web page it is not pure because it modifies some state. But if function modified EAX register it is still pure. How creating a socket or changing a buffer is different from changing a register value considering that in all cases outside observers would never know?

If a function is pure, it can take in and output 100% unmodifiable values. There will never be any side-effects in a pure function.

In other words, if you need to modify the contents of a variable for a function to run, that's not a pure function. Taking something in and outputting something just like it but with some modifications is allowed, so long as the input is unmodified.

Does that make more sense? You can't modify anything inside a function that originated from outside of the function's scope.

Re: Functional Programming Lessons Conclusion

#28

Post by betenoire »

entropicdrifter wrote: post #27
kikimora wrote: post #25

I realized I don’t understand idea of pure functions anymore. If a function fetches a web page it is not pure because it modifies some state. But if function modified EAX register it is still pure. How creating a socket or changing a buffer is different from changing a register value considering that in all cases outside observers would never know?

If a function is pure, it can take in and output 100% unmodifiable values. There will never be any side-effects in a pure function. In other words, if you need to modify the contents of a variable for a function to run, that's not a pure function. Taking something in and outputting something just like it but with some modifications is allowed, so long as the input is unmodified. Does that make more sense? You can't m…

I think they understand that, and are referring to more nuanced side effects. Logging, for an example, is a side effect, same with even using a date function. Hitting an API endpoint without cache may be functional if the response never changes, but do you want that? Usually we want a cache, which is skirting idempotency. The closer you look, the more side effects you see

Re: Functional Programming Lessons Conclusion

#29

Post by williamdclt »

kikimora wrote: post #25

I realized I don’t understand idea of pure functions anymore. If a function fetches a web page it is not pure because it modifies some state. But if function modified EAX register it is still pure. How creating a socket or changing a buffer is different from changing a register value considering that in all cases outside observers would never know?

Let’s put your uncertainty to rest: at the extreme, any function execution spends both time and energy, both of which are observable side-effects.

So yes, you’re right that there no such thing as an absolutely pure function. “Pure” always assumes that all dependencies are pure themselves. Where it’s a reasonable assumption and whether it’s still useful or not depends on your program: assuming an API call to be pure is certainly not reasonable for many use cases, but it is reasonable enough to be useful for others.

Re: Functional Programming Lessons Conclusion

#30

Post by brandonspark »

jerf wrote: post #9
brandonspark wrote: post #5

I was hoping this article would be a little more concrete, but it seems that it largely is talking about the takeaways about functional programming in a philosophical, effort-in vs value-out kind of way. This is valuable, but for people unfamiliar with functional programming I'm not sure that it gives much context for understanding. I agree with the high-level, though. I find that people (with respect to programming…

This is the conclusion of https://jerf.org/iri/blogbooks/functional-programming-lesson... . The concreteness precedes it, this is just the wrap up and summary.

I see. This is indeed the in-depth breakdown I was looking for, thank you.
Post reply on HN