It goes without saying that all 5 SOLID precepts aren't directly applicable to functional programming, but their underlying principles generally do apply. My take on it would be this:
Single responsibility principle: a function should do one thing, and do it well
Open-closed principle: compose small functions, rather than having a single one that does a lot, since the latter will mean that you'll be changing the code too often
Liskov substitution principle: since this is based on design-by-contract, it could be understood as such: when a function's passed as an argument, you should be able to replace it with another function that adheres to the first one's contract within the first one's scope, although it may have extended functionality beyond that scope (say, instead of passing sumTwoIntegerNumber, you pass sumListOfRealNumbers)
Interface segregation principle: for functions, I think this boils down to S, O and L: keep your building blocks small, and rely on contracts
Dependency inversion principle: instead of your function depending directly on some other function (e.g. a specific encryption function), make it take that function as a parameter, based on a certain contract. That way, you aren't hardcoding that aspect into your function.
Let me emphasize again that these aren't the literal SOLID precepts, but they are their underlying principles. There's also a lesson here when we just focus on OOP: SOLID isn't about mindlessly applying those 5 rules, it's about getting benefits from best practices that have been discovered by trail and error. And as with most best practices, having an understanding of the underlying principles helps you to know when to apply the best practice and when not.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
It goes without saying that all 5 SOLID precepts aren't directly applicable to functional programming, but their underlying principles generally do apply. My take on it would be this:
Let me emphasize again that these aren't the literal SOLID precepts, but they are their underlying principles. There's also a lesson here when we just focus on OOP: SOLID isn't about mindlessly applying those 5 rules, it's about getting benefits from best practices that have been discovered by trail and error. And as with most best practices, having an understanding of the underlying principles helps you to know when to apply the best practice and when not.