Author of Advanced Functional Programming with Elixir
I think we’re talking past each other a bit on terminology. My use of “declarative” isn’t meant to imply self-healing or recoverable behavior. The examples here fail fast by design. By “declarative” I only mean that the code is describing intent and constraints, not prescribing control flow.
I did not invent this meaning; if you check the three articles I linked you will see it is actually in common use (one is literally the official React blog).
FWIW my favorite term to describe how React works is that you write “rewindable” code, but nobody will recognize that if I use it.
Healing and recovery are nice but they imply errors. This is true of OTP crashes but is not true of the general technique. You want to rebuild state not only in the case of a crash but in the case of any state change. Crashing is actually a special case.
If you have spare time and you like databases study FoundationDB and this will become very clear. The whole idea is that they use the same recovery path for state changes and crashes (and they do call it Recovery, and it is a bit of a misnomer for this reason). Also Hobbes uses the same design btw
Another related use of “declarative” is in the context of SQL, where declarative code is useful for a very specific reason (data independence) which is not commonly understood by most devs unless you’re into databases. Incidentally the declarative-ness of SQL has nothing to do with query optimization, which is what most people seem to think. That article is also a fun treatment of the concept of “declarative”. It really is a bit of a rorschach term lol.
Author of Advanced Functional Programming with Elixir
Optics are a generic concept. I’m using a common pain point in the examples as a concrete way to show how they work, not as a claim that our only choice in solving this problem is between pattern matching in the function head and the solution I’m showing.
The cause of the confusion (and this long confused me as well) is that in simple cases imperative code looks an awful lot like code which describes intent.
def validate_length(string, length), do: String.length(string) < length
def validate_not_empty(string), do: string != ""
def validate(string) do
validate_length(string) and validate_not_empty(string)
end
Like, this code describes its intent pretty well. Is it declarative?
There are actually cases that accentuate the difference well, but they are generally centered around complex state transitions.
No, my reply was to @garrison who is using the terminology differently. I don’t really understand either use.
OK, definition has expanded a bit, but nothing I haven’t already heard. What I haven’t heard is how/why this tooling in particular does those things more than other validation patterns.
Yes, sorry, I should have been clear that I understand the concept of lenses and traversals and they seem like an interesting pattern but my question is more directed that the (implicitly positive) rhetorical use of “declarative.” It doesn’t really help me understand why I should consider this pattern over ones that are simply more familiar to me. Again, not specifically a problem in your presentation, I have never found uses of this term very compelling.
Author of Advanced Functional Programming with Elixir
Oh, you’re saying you don’t like my use of “declarative” as something implicitly positive.
That’s a fair point. By its nature, declarative code, as I’m using the term, adds at least one level of abstraction, and that indirection has real costs.
Also, under my definition, It’s probably safe to say that only SQL is truly declarative. The rest of us are on a sliding scale.
There were many different implementations of optics in Elixir, namely Lens, Focus and now Funx. I’ve made my own some time ago, called Pathex
The main problem with all other optics solutions is performance, especially with Funx/Witchcraft approaches, where results are wrapped into structures, introducing runtime overhead. In *ML family of languages (and similar languages like Rust) these things are optimized at compile-time into branching, while in elixir every such operation introduces a dispatch on the returned structure and initialization of the new structure.
At the same time Pathex always compiles into almost the most efficient code it can, inlining everything it can, concatenating paths, etc.
Yes, part of my problem with the term is that it’s often used to simply mean “good” so I appreciate you acknowledging that, since it always involves abstraction, it always has costs as well as benefits.
The other part is I’m still not sure what it means beyond “abstraction.” Certainly, a good abstraction can do all the things that people seem to mean when they use the term “declarative”–it can improve expressiveness, it can encapsulate constraints, etc, indeed, those are precisely the hallmarks of a good abstraction, i.e. good software design. But obviously it needs to signify something more than that in order to be a helpful term and it sounds like you think it does mean something more specific but it’s still unclear to me.
I’ve seen SQL cited as the paradigmatic example of “declarative” especially when stressing the contrast to “imperative” and I think it actually proves my point. Yes, SQL can be defined as a set of abstractions around searching and retrieving (“querying”) data but it’s “goodness” remains highly dubious, likewise its specific similarity to a web FE framework like React. If I write my own DSL for routing web requests to controllers, the whole point is for the user to avoid telling the computer how to do that themselves (“imperatively”) but I wouldn’t say my DSL in particular is “declarative” due to that.
All that said, I guess something similar could be said about other jargon like “DRY,” where it’s really just a decision to abstract mostly connected to the goal of avoiding duplicating logic, as opposed to making it more “intentful” and I should just get over it. But I find something about declarative particular frustrating. Sorry to hijack your thread! My intention was really to see if there’s something about this pattern in particular that would illuminate the issue for me.
