A proper doc definitely has to provide the details. However starting with an example or two is a nice way to a give the users a quick overview. Even better when this example is interactive as for redis where you even have an example use case. See https://redis.io/docs/latest/commands/incr/
A nice model solving a quite recurring problem. However this sounds a bit as over-engineering here, as two traits have exactly the same type signature.
I really enjoyed reading this well-written paper that introduces the Rel query language implemented at RelationalAI [1].
One main goal of Rel is to give users the ability to grow the language using libraries [2],
say for linear algebra or graph processing. And I'm really impressed by the result.
With ability to defines (possibly recursive) relations over relation variables and arbitrary-length tuples,
Rel is a nice successor of Datalog.
I also like the oppiniated approach which is to enforce strong data modeling constraints on all relations
(6th normal form and identifier uniqueness across entity types).
This removes the need for nulls and beyond helps to remove complicated corner cases.
Great to hear Alistair speaking about hexagonal architecture!
Since long, I love Alistair's books which are extraordinary insightful. As an example, [1] has drastically changed my way of writing specs and even thinking about user-software interactions.
Now, it's good to discover that Alistair is also a great speaker highlighting the key points that will help to understand his point.
Actually, this document is direct to the point with the broad questions agile teams should address to repeatedly deliver the software their users are expecting.
I'm just a bit surprised that this post says nothing about Heaviside who rewrote Maxwell's equations in the form commonly used today.
According to wikipedia [1], Heaviside significantly shaped the way Maxwell's equations are understood and applied in the decades following Maxwell's death.
The integral equations of Maxwell, which few know today, are much more generally applicable and actually easier to understand.
The differential equations of Heaviside are valid only when certain restrictions about continuity are true. Moreover, the meanings of curl and divergence are hard to understand otherwise than by deriving them from the integrals over curves and surfaces used in the original equations of Maxwell, which are also necessary to determine how to handle discontinuities.
The differential form of the equations looks prettier on paper due to a simpler notation, but it is less helpful for understanding and for solving practical problems than the integral form.
In my opinion, it is a serious mistake that almost all manuals show the equations of Maxwell in the Heaviside form, instead of showing them in their original form. This is one of the main reasons why they are hard to understand for many.
IEEE floating point is far more practical for computation than axiomatic arithmetic, but the fundamental axioms are a more intuitively enlightening description of what arithmetic is. Same with Maxwell and Heaviside.
Understanding how it all fits together in fewer words makes the rules make sense. Heaviside gives meaning to Maxwells equations.
A really appealing menu on interactive programming systems.