Constraints Liberate, Liberties Constrain — Runar Bjarnason

I find Runar Bjarnason's talks to be interesting; one of my favourites is 'Constraints Liberate, Liberties Constrain': ▶ this video The essence of it is that constraints actually allow for easier composition and more modularity. It had a real impact on the way I think about the design of systems.

This reminds me of the excellent talk "Constraints Liberate, Liberties Constrain" ▶ this video that is more about doing the programming rather than planning it as in the article, but with a similar approach.

This reminds me of a great talk, Constraints Liberate, Liberties Constrain , by Runar Bjarnason. [0] Useful abstractions necessarily impose restrictions compared to a free-form 'all powerful' approach, but abstractions make it easier to perform/compose meaningful operations. A compiler can reason about an AST far more easily than it can reason about a machine-code sequence, for instance. A compiler typically converts from AST to machine-code pretty late in the game, as you want to take advantage of the utility of the abstraction, not the unlimited power of directly working with instructions. [0] ▶ this video

That's a great quote. This topic turned up a couple of weeks ago in another thread. [0] The excellent talk Constraints Liberate, Liberties Constrain , by Runar Bjarnason, gets at the same point, and even uses this same Dijkstra quote. [1] [0] link [1] ▶ this video (this takes you right to the Dijkstra quote)

Constraints on the user free the platform. Freedoms for the user constrain the platform. If you are interested in someone pontificating about this at length, see ▶ this video

> Constraints provide freedom. For a great video on this, see Runar Bjarnason's talk "Constraints Liberate, Liberties Constrain" ( ▶ this video ).

> I might have a different take. I think microservices should each be independent such that it really doesn't matter how they end up being connected. The connections you allow or disallow are basically the main interesting thing about microservices. Arbitrarily connected services become mudpits, in my experience. > Think more actors/processes in a distributed actor/csp concurrent setup. A lot of actor systems are explicitly designed as trees, especially with regard to lifecycle management and who can call who. E.g. A1 is not considered started until its children A2 and A3 (which are independent of each other and have no knowledge of each other) are also started. > Also for many system designs, you would explicitly want a different topology, so you really shouldn't restrict yourself mentally with this advice. Sometimes restrictions like these are useful, as they lead to shared common understanding. I'd bet an architecture that designed with a restricted topology like this has a better chance of composing with newly introduced functionality over time than an architecture that allows any service to call any other[1]. Especially so if this tree-shaped architecture has some notion of "interface" services that hide all of the subservices in that branch of the tree, only exposing the public interface through one service. Reusing my previous example, this would mean that some hypothetical B branch of the tree has no knowledge of A2 and A3, and would have to access their functionality

> Your second line is a silly slogan which presumably means constraints make the job of picking one choice from a set easier due to less thought needed That is absolutely not what it means, and it is not a silly slogan — it is a basic law of reality. As an example, if your build system is monadic (build nodes can add new nodes dynamically) then the number of nodes in it is not known upfront. If the build system is not monadic, the number of nodes is determined at the start of the build process. As another example, the constraints that Rust sets around & and &mut mean that the compiler can do really aggressive noalias optimizations that no one would even dream about doing in C or C++. See ▶ this video for more examples. > It is applicable to inexperienced developers but certainly not to experienced ones who need all the flexibility that a language can give. I'm quite an experienced developer, and I've tended to use more constrained languages over time. I love the fact that Rust constrains me by not having uncoordinated shared mutable state. > This discussion reminded me of "The Blub Paradox" by Paul Graham ( link ) which i think most Rust evangelicals suffer from At Oxide we use Rust and would never have been able to achieve this level of rigor in C++. Hell, try writing anything like my tool link in C++ (be sure to get the signal handling exactly right). Rust tooling is at a completely different quality level from earlier-generation languages.

That post is excellent and is now in my bookmarks. I'm glad I asked for clarification because when you mentioned licensing, I first thought that you meant things like software licenses. Now, I know you mean things like engineer licenses. Up to this point, I personally would like licensing, but only for the most critical projects, such as avionics, nuclear power plants, crytography, and perhaps even foundational projects like compilers. But only those things. So I am glad you made me aware that people who want licensing tend to go overboard with it. That means I will need to reconsider my position. I wonder how the engineering world has solved that problem, or if they even have. > I think that "supply chain" dependencies (like standard SDKs and libraries that are used as a "baseline") are juicy hack targets (think SolarWinds). Yeah, this is one reason I wiped all outside code from the repo where I am building my software. [1] [2] [3] [4] [5] > Software needs to be flexible. It's very, very difficult to have flexibility and Quality shacking up together. In the company I worked for, the hardware people insisted that flexible software was automatically "bad quality," so we were forced to apply rigid hardware development methodologies to software development; with ghastly results. I think that this can be done with good design, which is the reason why my Design phase part of process is so long. I have many reasons to think so, but a good intro to my thoughts is "Constraints Libera

Thanks for that synopsis, when put that way it seems similar to one of the takeaway messages from the talk "Constraints Liberate, Liberties Constrain", especially the early example in the talk of making a description language for printer commands being better than just doing the commands directly. ( ▶ this video )

I thought foreign keys were necessary for the consistency part of ACID compliance. Once you remove the integrity constraint, the database cannot guarantee consistency, even with isolation and atomicity. Sure, removing the constraint will get you a huge burst in performance, but now you are in charge of guaranteeing consistency outside of transactions in a distributed system involving at least one client and one server. That's a tall order. As Runar Bjarnson put it: "Constraints liberate, liberties constrain,"[1]. If you give something the freedom to be inconsistent at any extreme scale, Murphy's law requires that anything that can go wrong, will go wrong. It is hubris to think that the average developer who hasn't spent years becoming a consistency expert is going to be able to guarantee that data won't become corrupted better than the engineers that build and maintain and acacademics that study rdbms systems full-time.Even experts get this wrong all the time [2]. To all junior devs out there, until you know you need to abandon a guarantee available to you in a given system, exhaust every other possible option. 1. ▶ this video 2. link

Came across this Dijkstra quote via ▶ this video > The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise By taking away all the non-essential things and leaving only on what you need, it allows you to truly understand the structures that you are studying. Definitely rings true when I work in ML/Haskell-style type systems. Easier said than done convincing the students though...