Skip to content
0:00 / 0:00

#scala#abstraction#composition

Constraints Liberate, Liberties Constrain — Runar Bjarnason

Scala World

5.9K subscribers • 13 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/woztzyin r/scala • Mentions

On “Ask HN: What are the best resources to properly learn Scala?”

Here's some stuff I found useful, mostly specific to Scala: Worth reading to get started, at your leisure * Programming in Scala (Martin Odersky) * Functional Programming in Scala (Paul Chiusano, Runar Bjarnason) * Ammonite docs (/u/lihaoyi) * Principle of Least Power (/u/lihaoyi) Worth reading afterward, whenever they start to sound interesting * Learning Scalaz (eugene yokota) * Futures and Promises * Scalaz Task - the missing documentation (Tim Perrett) * Intro to Functional Streams for Scala (FS2) (/u/mpilquist) * Scalaz-stream example (/u/paultypes) * Previous example implemented with a Free monad (comment by /u/Milyardo) * Free Monads are Simple (Noel Welsh) * Free Mon…

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/luismilanooliveirain r/scala • Mentions

On “Must watch talks ?”

I like Constraints Liberate, Liberties Constrain, from Runar Bjarnason (one of the authors of FP in Scala).

u/woztzyin r/scala • Mentions

On “"Ask Slashdot: Should I Move From Java To Scala?"”

> There is value in the category theory, and using arcane libraries like cats or shapeless, but 99% of the time, you don't need to: Just like back in the 90s you had to stop people from overusing OO design patterns, or their code will end up looking like Spring, Scala shops have to remind people to do the same when it comes to higher kinded types, hlists and concepts out of category theory. You really don't need any of that to use Scala successfully. I used to nod along with these kinds of arguments before I understood the value of "Haskell-style" programming, which I now prefer, because it makes a lot more sense: functional programming takes "programming with only pure functions" to its lo…

u/paultypesin r/scala • Mentions

On “Question about Free Monad in production”

We (Verizon Labs) use it. I can't claim we're representative, or even that the slice of developers I interact with most are representative—we employ probably half the committers to scalaz and Cats, and these are the colleagues I tend to interact with most. So keeping selection bias in mind, it seems to me that: * Many developers are tired of being bitten by third-party API hysteresis. * The big leap is wrapping such APIs in monads at all. * It's (too) easy to just toss everything in `Task` and call it a day. (I'm super guilty of this myself.) * Another big leap is thinking of an API you want to develop as an algebra in the first place. * How to combine N small monads (monad transformers? Mo…