Thanks for this link. I've been using jj for 2 years now. Whenever people ask me why, it's hard to explain. I'll have to keep this in my pocket for the future.
Exactly! A very nice explanation of what is and what is not a proof by contradiction is given by R. Harper in "Proofs by contradiction, versus contradiction proofs" [1]
It is always a pleasure to read Daniel Jackson [1].
In this paper, Daniel revisits the ideas developed in his book, "The essence of software" [2].
placing them in their historical context and opening a future for more modular software implementations.
He presents a convincing argumentation on how and why an object-oriented approach does not really contribute to reducing coupling.
And his proposal is truly appealing: building an application as a set of external synchronization rules governing the interactions between modules (so called concepts). Each module comes with its own view on the entities of the application domain and provides the actions featuring the concept. Only the synchronization rules of the application relate the entities and actions of these modules.
That said, I'm left wanting more and I will need to take the time to put these ideas in code.
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.
