Skip to content
0:00 / 0:00

#scala#abstraction#composition

Constraints Liberate, Liberties Constrain — Runar Bjarnason

Scala World

5.9K subscribers • 8 videos on Hallway

YouTube
  • Recommended by 6 people: 5 on Hacker News and 1 on Lobsters.
  • A classic. People kept recommending it from 2016 to 2024.
  • Presented by Runar Bjarnason
  • An opinion. It argues one side of a question engineers disagree on.

Intermediate. Assumes working knowledge.

44K views10 years ago6 recommendations

Software designProgramming languagesSoftware architectureDesign patternsFunctional programming

Runar Bjarnason argues that imposing constraints and precision on software components makes them easier to compose into larger systems.

As programmers, we tend to think of expressive power of a language or library as an unmitigated good. In this talk I want to show the contrary; that restraint and precision are usually better than power and flexibility. A constraint on component design leads to freedom and power when putting those components together into systems. What’s more, this feature is built into the very nature of language and reasoning.

Why it's here

6 people recommend this

What people say. Highly recommended by engineers for its insightful perspective on how constraints and abstractions improve system design and modularity.

cinnamonhearton Hacker News • Recommends

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': link to 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.

harveywion Hacker News • Recommends

On “Programming Languages as Constraints”

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

clhodappon Hacker News • Recommends

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 link to this video

MaxBarracloughon Hacker News • Recommends

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 link to this video

MaxBarracloughon Hacker News • Recommends

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 link to this video (this takes you right to the Dijkstra quote)

solidninjaon Hacker News • Recommends

On “Compromised Visions Are Superior”

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

dbremneron Lobsters • Recommends

Constraints Liberate, Liberties Constrain (2015)

u/isovectorin r/haskell • Mentions

On “Is using granular effects an anti-pattern ?”

Are effects really needed? No. But then again, the bare lambda calculus is sufficient for computation. It depends on how much you value compositionality and reusability. Of course you can always just do everything in `IO`, but you pay a cost for doing so. > The main benefit of granular effects seems to be for mocking purpose This is an unfortunate narrative about effects. Yes, granular effects help for mocking, but they more fundamentally allow for _reconfiguration of meaning_. They allow you to ignore implementation details, and perform easy performance-optimization passes later. They allow you to push tiny diffs in order to keep up with rapidly changing specifications. They allow you t…

u/twitchardin r/haskell • Mentions

What are your favorite Haskelly aphorisms? What are your favorite Haskelly aphorisms? e.g. "Make Invalid States Unrepresentable" (which I guess is from an OCaml talk ) "Liberties Constain, Constraints Liberate" (which I guess is from a Scala talk) "Turn business logic bugs into type errors" (which is from a Haskeller ) Context: I'm scheduled to give a short talk to two dozen or so devs at my company, "All of us should be programming in Haskell: Not Really but Kind Of" that I'm planning to organize around catchy phrases, since I think those will stick harder and be better received than language feature overviews or demonstrations

u/Laseringin r/scala • Mentions

Looking for keynotes with very good insights and/or explaining some key fundamental ideas Like the title says. Let me give you some examples: - Constraints Liberate, Liberties Constrain - Runar Bjarnason - Simple Made Easy - Rich Hickey - How do Fibers Work? A Peek Under the Hood - Fabio Labella - Introduction to ScalaCheck - Noel Markham - High Wizardry in the Land of Scala - Daniel Spiewak - Roll Your Own Shapeless - Daniel Spiewak - Type Members vs Type Parameters - Jon Pretty - Doing Batshit Crazy Algebra with Scala Types! - Jon Pretty

u/ephrionin r/haskell • Mentions

On “OOP averse culture at the company. How to manage?”

From an OOP/Ruby perspective, Functional Core Imperative Shell is a good start. (Really, all of Gary Bernhardt's videos are great) Then, realize that functional programming is inherently *more limiting* than object oriented programming - and Constraints Liberate, Liberties Constrain talks about why that's a *good* thing. Parse, don't validate is a fantastic way of seeing how we can use types to make our programs better.

u/rampionin r/haskell • Mentions

On “RAII is better than the bracket pattern (follow up from ResourceT discussion)”

> Instead of adding Nothing to a function’s codomain, why not simply restrict the function’s domain to the set of valid inputs? Another riff on the same idea from a recent post by Matt Parsons: > ### Constraints Liberate > > Runar Bjarnason has a wonderful talk titled Constraints Liberate, Liberties Constrain. The big idea of the talk, as I see it, is this: > > > When we restrict what we can do, it’s easier to understand what we can do. > > I feel there is a deep connection between this idea and Rich Hickey’s talk Simple Made Easy. In both cases, we are focusing on simplicity – on cutting away the inessential and striving for more elegant ways to express our problems. > > Pushing the s…

u/isovectorin r/functionalprogramming • Mentions

On “New FP Book: Algebra-Driven Design”

It's hard to give an answer in general here, but ADD works best in an environment you control that doesn't have predecided implementation details. Just because a field is based on sloppy thinking doesn't mean our software needs to be; my suspicion is to just give an observation of your algebra that throws away the abstraction, and let practitioners do as much reasoning as possible inside the algebra before eventually producing the answer they expect. Constraints Liberate, Liberties Constrain is an _excellent_ talk on this topic. My book touches on this in its image example; with the exception of vector graphics, the industry has decided that pixels are the one true way of representing im…

u/sagittarius_ackin r/functionalprogramming • Mentions

On “Where to learn”

Regarding the \`liberties vs constraints\` debate, the talk "Constraints Liberate, Liberties Constrain" by Runar Bjarnason is quite interesting: [video

bjz_on Hacker News • Mentions

On “Habits of highly mathematical people”

Came across this Dijkstra quote via link to 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...

jackcviers3on Hacker News • Mentions

On “We do not use foreign keys (2016)”

…ble 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. link to this video 2. link…