> IME is a bigger foot gun than

Pretty much true for any functional feature. Great in the classroom, less practical in the real world.

Trying to be as functional as possible I think has great benefits in the "real world". Functions are very easy to unit test, for one.

Pure functional is difficult, but breaking out the parts of the program which can be pure functional is generally a smart thing to do

If I had drive and ability the to make a programming language from scratch, it would be hybrid imperative/functional, and "pure" functions (no side effects, EXCEPT possibly debug logging) would be clearly marked as such.

▲

alternatex 4 days ago | parent [-]

Pure functional isn't too difficult once you understand how to put everything that causes side effects on the side. You can write a domain layer in a purely functional manner and feed it data from non-pure sources. It's definitely a shift in thinking for people used to something like OOP, but once you make it, writing software functionally is not difficult. There's really not many ways to approach it, unlike OOP for which there are hundreds of books and approaches.

▲

William_BB 4 days ago | parent [-]

I studied FP in college. I currently work on a large low latency C++ codebase. I honestly have no idea how I'd use pure functional concepts everywhere in this context. I'm also probably doing it wrong.

	▲	alternatex 4 days ago \| parent [-]
		I wouldn't be able to say without knowing the project, but just following the simple rule of not calling impure functions from pure functions will force your codebase in a state where all impure functions bubble up to the top layer of calling code. For web apps that's simple, it's just the entry point of an HTTP request. For desktop apps it might mean the event handlers for user actions. Then you realize you are sort of forced to handle all exceptions from impure code at the top level, and after that all that remains is validated data running through pure functions that are easily testable. At the top layer, your code will dip in and out of pure and impure functions. All possible exceptions coming from bad data and I/O issues are visible at that layer since those cannot reasonably occur in the pure code. I admit it will be an odd sight at first, but the feeling of working with a domain safe from bad data makes it worth it.