I do not work in a functional language, but these ideas have helped me a lot anyway. The only idea here that I find less directly applicable outside purely functional languages is the "Errors as values [instead of exceptions]" one.
On the surface, it makes complete sense, the non-locality of exceptions make them hard to reason about for the same reasons that GOTO is hard to reason about, and representing failure modes by values completely eliminates this non-locality. And in purely functional languages, that's the end of the story. But in imperative languages, we can do something like this:
def my_effectful_function():
if the_thing_is_bad:
# do the failure thing
raise Exception
# or
return Failure()
return Success()
and a client of this function might do something like this:
and completely ignore the failure case. Now, ignoring the failure is possible with both the exception and the failure value, but in the case of the failure value, it's much more likely to go unnoticed. The exception version is much more in line with the "let it crash" philosophy of Erlang and Elixir, and I'm not sure if the benefits of locality outweigh those of the "let it crash" philosophy.
Have any imperative folks here successfully used the "errors as values" idea?
Rust does "errors as values" pretty well, see [1]. You can manually handle them if you want, or just apply the '?' operator to auto-propagate them out of the function. In both cases, it is obvious that there was an error handling needed.
These are great ideas and patterns even if you’re not doing functional programming.
FP-first/only languages tend to push you in these directions because it makes programming with them easier.
In languages where FP is optional, it takes discipline and sometimes charisma to follow these affirmations/patterns/principles.. but they’re worth it IMO.
> How can you do "Errors as values" at a large scale without do-notation / monads?
You don't need monads for this. You just need the ability to encode your error in some term like `Either e a` and ability to eliminate those terms. In Rust for example that is the `Result` type and you use pattern matching to eliminate those terms.
Genuinely curious for all these follow up questions:
Is immutability exclusive to functional programming?
Is the ability to use data/values exclusive to functional programming?
Are monads exclusive to functional programming?
For discussions like this, how do we separate "it was done first in functional programming but can also be done in procedural programming" with "it cannot be followed outside of functional programming"?
One way to achieve "Make illegal states unrepresentable" is by using "refined" types, a.k.a. highly constrained types. There is a "refined" library in both Haskell and Scala and the "iron" library for Scala 3.
> This is fine but it's just a rehash of old well-knowned stuff.
A significant share of the current dev community wasn't there when these principles were first described. Sometimes, bringing up old topics once again helps seeing that many people had never heard of them yet.
Do you have an example of the many books and established blogs that you can share? A newcomer might not be familiar with where to start when attempting to learn more about functional programming.
~~I can't tell if you're being sarcastic, but that's exactly what TFA does. But just to pull it out explicitly:~~
Edit: I think I misunderstood your point. You were asking for a similar kind of list as TFA from the other commenter which may not necessarily be the *same* 5 ideas
I do not work in a functional language, but these ideas have helped me a lot anyway. The only idea here that I find less directly applicable outside purely functional languages is the "Errors as values [instead of exceptions]" one.
On the surface, it makes complete sense, the non-locality of exceptions make them hard to reason about for the same reasons that GOTO is hard to reason about, and representing failure modes by values completely eliminates this non-locality. And in purely functional languages, that's the end of the story. But in imperative languages, we can do something like this:
and a client of this function might do something like this: and completely ignore the failure case. Now, ignoring the failure is possible with both the exception and the failure value, but in the case of the failure value, it's much more likely to go unnoticed. The exception version is much more in line with the "let it crash" philosophy of Erlang and Elixir, and I'm not sure if the benefits of locality outweigh those of the "let it crash" philosophy.Have any imperative folks here successfully used the "errors as values" idea?
Rust does "errors as values" pretty well, see [1]. You can manually handle them if you want, or just apply the '?' operator to auto-propagate them out of the function. In both cases, it is obvious that there was an error handling needed.
[1] https://doc.rust-lang.org/book/ch09-02-recoverable-errors-wi...
These are great ideas and patterns even if you’re not doing functional programming.
FP-first/only languages tend to push you in these directions because it makes programming with them easier.
In languages where FP is optional, it takes discipline and sometimes charisma to follow these affirmations/patterns/principles.. but they’re worth it IMO.
I'm not convinced that you can follow all of these outside of Functional Programming.
How can you "Make illegal states unrepresentable" with mutable state and sequences of mutations that cannot be enforced with the type system?
How can you do "Errors as values" at a large scale without do-notation / monads?
How can you do "Functional core, imperative shell" without the ability to create mini DSLs and interpreters in your language?
> How can you do "Errors as values" at a large scale without do-notation / monads?
You don't need monads for this. You just need the ability to encode your error in some term like `Either e a` and ability to eliminate those terms. In Rust for example that is the `Result` type and you use pattern matching to eliminate those terms.
Genuinely curious for all these follow up questions:
Is immutability exclusive to functional programming?
Is the ability to use data/values exclusive to functional programming?
Are monads exclusive to functional programming?
For discussions like this, how do we separate "it was done first in functional programming but can also be done in procedural programming" with "it cannot be followed outside of functional programming"?
Completely agree with these.
One way to achieve "Make illegal states unrepresentable" is by using "refined" types, a.k.a. highly constrained types. There is a "refined" library in both Haskell and Scala and the "iron" library for Scala 3.
I'm very disappointed. I was really hoping for something like the SRE affirmations - https://youtu.be/ia8Q51ouA_s
A class is just a function in the category of Javascript.
This is fine but it's just a rehash of old well-knowned stuff.
I don't see the value of learning this stuff one random blog post at a time.
There are many books and established blogs with long series of material to give you an education.
> This is fine but it's just a rehash of old well-knowned stuff.
A significant share of the current dev community wasn't there when these principles were first described. Sometimes, bringing up old topics once again helps seeing that many people had never heard of them yet.
Known by you, maybe.
None of these "affirmations" are common in any code base I work with, unfortunately.
Do you have an example of the many books and established blogs that you can share? A newcomer might not be familiar with where to start when attempting to learn more about functional programming.
I'm a big fan of Haskell Programming from First Principles. That's where more advanced ideas like Monads started clicking.
https://haskellbook.com/
It's a pretty good collection and summary of ideas I've only seen scattered around, before.
Could you list the top 5 ideas, with a short summary and a link to a well-regarded blog post that goes into more detail for each?
~~I can't tell if you're being sarcastic, but that's exactly what TFA does. But just to pull it out explicitly:~~
Edit: I think I misunderstood your point. You were asking for a similar kind of list as TFA from the other commenter which may not necessarily be the *same* 5 ideas
Leaving the rest here in case it helps someone:
1. Parse, don’t validate
https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...
2. Make illegal states unrepresentable
https://fsharpforfunandprofit.com/posts/designing-with-types...
3. Errors as values
https://jessewarden.com/2021/04/errors-as-values.html
4. Functional core, imperative shell
https://www.javiercasas.com/articles/functional-programming-...
5. Smart constructor
https://wiki.haskell.org/index.php?title=Smart_constructors
Let's keep repeating it until it gets more adoption.