Skip to content
0:00 / 0:00

#clojure#composition#apidesign

Zach Tellman - Always Be Composing

ClojureTV

111K subscribers • 159 videos on Hallway

YouTube
  • Recommended by 2 people: 1 in engineering communities and 1 curated list.
  • Presented by Zach Tellman
  • An opinion. It argues one side of a question engineers disagree on.

Intermediate. Assumes working knowledge.

23K views11 years ago2 recommendations

Software designProgramming languagesDesign patternsLisp and ClojureFunctional programming

Zach Tellman discusses the constraints and design choices that allow Clojure libraries and code to compose cleanly with one another.

The Clojure ecosystem, we're told, is made up of small, composable libraries. In practice, though, it's all too common to find that two libraries simply will not cleanly compose. This typically will lead to another library that does the same thing, but in a subtly different way. Sometimes this is warranted, but often it's not. This talk will discuss the constraints and affordances that make a piece of code play nicely with other pieces of code. Attendees will learn how to write clean, reusable Clojure, drawing on the speaker's many past failures and few notable successes. The first place I think of, when I try to tell someone about this quality, is a corner of an English country garden, where Zach Tellman grows against a wall. The wall runs east to west; Zach grows flat against its southern side. The sun shines on him and as it warms the bricks behind Zach, the warm bricks themselves warms the peaches on him. It has a slightly dozy quality. Zach, carefully tied to grow flat against the wall; warming the bricks; the peaches growing in the sun; the wild grass growing around Zach's roots, in the angle where the earth and roots and wall all meet.

Why it's here

2 people recommend this

What people say. Recommended as an essential talk on API design, abstraction, and building truly composable software libraries.

u/prosperoin r/Clojure • Recommends

Always Be Composing (Conj 2014 video)

programming-talkscurated list on GitHubRecommends

Under “Clojure”

Always Be Composing 00:35:11 by **Zach Tellman** (2014)

u/nonrecursivein r/Clojure • Mentions

On “Elements of Clojure”

yeah, but they're Zach Tellman's opinions, and he's definitely worth listening to :) Here are some of his talks: * Everything Will Flow * Always Be Composing * Predictably Fast Clojure

u/flokaterin r/Clojure • Mentions

On “Data > Functions > Macros. But why?”

It's all about composability. There is a nice talk from Zach Tellman from the last ClojureConj. Youtube: Always be composing

u/rafalwin r/Clojure • Mentions

On “New Clojurians: Ask Anything”

Well, I don't consider myself as very "proficient", but one of the turning points was realization how easy is to experiment and prototype with Clojure. Realization that not every pieace of code must be some generic abstraction, and using raw data, and data specific functions, during protptype phase is very efficient. Consider watching: [video

u/goodpairosocksin r/ProgrammingLanguages • Mentions

On “Macros good? bad? or necessary?”

Zach Tellman gave a talk discussing this, 10 years ago (link to this video Main point: from most to least 'powerful' you have macro > function > data, but inversely from least to most composable you have macro < function < data.

u/yogthosin r/Clojure • Mentions

On “Data &gt; Functions &gt; Macros. But why?”

I recommend watching the Always Be Composing talk by Zach Tellman where he introduces this idea and goes to make a case for it with code examples. I think Eric should've probably referenced the talk in his post.

u/jamesconroyfinnin r/Clojure • Mentions

On “Is it only possible to call deftest and have it work properly in top level forms - and why?”

`deftest` is itself a macro, and be virtue of being a macro it can defer evaluation of its arguments. In this case the test name symbol. If you don't use a macro your test name (`t` in my example) would have to be quoted to avoid an referring to a var before it's been created. You're definitely thinking the right way with regards to using a function first! Data first, functions second, and macros as a last result is a pretty good rule of thumb (composition and transparency becomes harder as you progress from former to latter). Zach Tellman gave a pretty good talk on this a while back that's worth a watch. Glad to hear `are` solved your problem! I have to admit I find myself using `are`…

u/yogthosin r/Clojure • Mentions

On “Respo: A virtual DOM library in ClojureScript”

For example, I do a lot of that sort of manipulation in reagent-forms, where the user creates a template, then the library walks it and looks for specific tags to replace with Reagent components. Ultimately, it comes down to composability. I recommend watching this talk by Zach Tellman where he makes a very good case for preferring data based APIs whenever possible.

u/yogthosin r/Clojure • Mentions

On “What are Clojurians' critiques of Haskell?”

>As tomejaguar says, polymorphism is key. There a many forms of polymorphism and they can be used to reduce dynamism. Sure, all of these things require additional ceremony and declaration of types up front. It really doesn't change anything I said regarding the fact that you have to express these concerns globally. >Another technique you can use is to start writing your software in terms of behaviours instead of just data. This turns out to A Good Thing, both in the Object Oriented and Functional worlds. My experience is quite the opposite actually. When you start expressing software in terms of behaviors you end up with a lot of domains which are islands of their own and you constantly h…

u/zerg000000in r/Clojure • Mentions

On “Data-Driven Development is a Lie”

…ally like this kind of clickbait article, I could share some hints on this topic. 1. XML is not bad, so don't try to make it an argument 2. DSL doesn't necessarily go to either the bad or good side. 3. Don't create more terms, it did not help on make thing clearer First, let's talk about the benefits, we had a very good talk about it with Zach [video When we can describe our concept using data * last binding, we can change at the very last moment. a.k.a Max Composition * free from different programming concepts like sync/async/stream/reactive/pipeline/multithread/pull/push * queryable/inspectable/explainable * one set of generic tools to rule them all ( Clojure core library ) * the ch…