I’m using “declarative” in contrast to imperative or procedural control flow, not as a synonym for “pure FP.” What I mean is that declarative code describes intent, while procedural code proscribes execution.

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.

Check it out: Pathex v2.6.1 — Documentation

I’ve read the blog post and it is very funny.
Quote

So our minimum requirements for interesting program transformations include:

1. Static typing (so that we know what values look like).
2. Static dispatch (so that we know which functions will be called).
3. Some way to reason about the properties of functions (eg that a == b implies hash(a) == hash(b) or that addition is commutative).
4. Some way to reason about which values are finite and which functions terminate.
5. Some way to reason about the time and space cost of functions (so that we can predict if a given transformation is worthwhile).
6. Some way to reason about the effects caused by calling functions (eg by only allowing pure functions, or by tracking effects and aliasing in the type system).

While I can say that most of these points are not true (for example functions can sometimes be speculated and made pure by postponing effects, etc.), but it generally describes a qualities of declarative programming language, not the imperative one.

To put my 2 cents into the overall discussion, I think that declarativeness and imperativeness are not two separate opposites and not even a spectrum, but are just qualities of information description or code.

Here’s a table to demonstrate the idea, where languages in boxes are the most extreme examples I can think of.

For example, Prolog is neither declarative, nor imperative, because it is logical. You dont state the instructions and you dont explain the expected result, you just define rules and then ask questions.

Markdown is declarative, because it describes the end result: a text document. Different editors and viewers decide how to render it.

Assembly is imperative, because all you have is a set of instructions. You don’t describe the end result in any way, you just write down a bunch of instructions which bring to the end result.

And SVG is both declarative and imperative, because it defines an image as a set of curves and shapes and then it lets user apply some changes and actions (some transforms) to these curves, in any order. So it contains both a description of an image and some very detailed instruction on how to change the image. I think CSS also belongs to the same category.

Most general purpose Turing-complete programming languages (like C, Haskell, Elixir or Python) are somewhere in-between, some are leaning more to one thing or another, or some leaning more towards both (like Scala or C++, for example).

This information is fun to know, but for me personally, it is completely useless