Constraints Liberate, Liberties Constrain — Runar Bjarnason

Scala World · 44K views · 2016 · 51:40

Open on YouTube

Functional programmingSoftware architecture & designtalk

Why Hacker News recommends it

HN recommends it as a talk that changes how you think about system design, and links it whenever constraints, abstraction or least power come up.

What it is

Runar Bjarnason's Scala World talk argues that restraint and precision in components beat power and flexibility. Constraints on parts make them easier to compose into systems.

Recommended by 5 HN commenters across 5 different months, 2016 to 2025.

What Hacker News said

Strong rec cinnamonheart · 2018-04 · on “Ask HN: What is your favourite tech talk?”

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.

Recommends harveywi · 2016-06 · on “Programming Languages as Constraints”

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

Recommends clhodapp · 2019-07 · on “Why Continuations Are Coming to Java”

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]

Recommends MaxBarraclough · 2024-04 · on “Htmx and the Rule of Least Power”

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]

Recommends MaxBarraclough · 2024-04 · on “No Abstractions: our API design principle”

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)

Recommends solidninja · 2024-06 · on “Compromised Visions Are Superior”

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.

Cites bjz_ · 2016-07 · on “Habits of highly mathematical people”

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...

Cites jackcviers3 · 2019-11 · on “We do not use foreign keys (2016)”

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 avera