Functional Design in Clojure

Latest Episodes:

Ep 099: REPL Your World Nov 16, 2023

Show notes

Each week, we discuss a different topic about Clojure and functional programming.

If you have a question or topic you'd like us to discuss, tweet @clojuredesign, send an email to feedback@clojuredesign.club, or join the #clojuredesign-podcast channel on the Clojurians Slack.

This week, the topic is: "taking the REPL beyond your application". We free our REPL to explore and automate the world around us.

Our discussion includes:

What are the different ways of working with the REPL?
How can you be more productive by using the REPL?
What is the connected editor?
How to use the REPL beside writing code for your application.
What is often missing from API docs.
Moving from bash to Clojure.
Using the REPL for exploration.
What is a "fiddle" approach to using the REPL? What is it good for?
Why should you use your editor for non-coding activities?
How to save time when you're stuck with manual testing.
Interacting with databases.
When is the REPL better than a script?
How a REPL is like a bash prompt, and how it's not.
What supports the supporting activities of software development?
Using the REPL as your application interface.
Migrating data using the REPL.
Why your REPL is a natural place for difficult to access resources.
Why the REPL saves you from extra coding.

Selected quotes:

"We share because we care."
"The connected editor is an interface to productivity."
"I like to call it whiplash-driven development because it's so fast that you literally have no time between when you write the code to when you execute it. You're just blown back by the productivity!"
"This is a Clojure Podcast, so I bet you know where this is going."
"The REPL as a window into another system."
"I actually wrote the API, so I know how it should behave...but not how it does!"
"Isn't that one of the goals of your programming language and experience: to spend less time doing the things that are really mundane and repetitive and more time actually doing new things?"
"I don't want to just let that go into the history file. I want to save it someplace more important."
"I have all of the power of Clojure before the query and then after the query. I don't have to trick psql to write that data out somewhere so I can read it in my REPL. It's already there!"
"It's not that there aren't other ways to do this. That's not the point. The point is that all of a sudden you realize there's a lot of interactive exploration and processing and task automation you can do from the REPL because you don't need to write a script to do it."
"You can just execute a form, and boom! It's off. It's running."
"But then, I was like 'Wait, there's got to be a better way!' You know, infomercial style."
"It's functional programming, so we're going to talk about composition. It'll happen."
"Whoa! The REPL could be a terminal! A super powerful terminal into a vast warehouse of data, and I can slice it and dice it all sorts of different ways and discover things."
"The REPL is just a way of doing structured execution very rapidly and very flexibly."
"With the REPL, every function or form is a potential entry point. You can have all kinds of entry points."
"The malleability of it is its power."

Links:

REPL Series
Composition Series
- Ep 093: Waffle Cakes (first episode)
- Ep 098: Composed Learnings (summary episode)
Talks mentioned
- "Running With Scissors: Live Coding With Data" by Stuart Halloway. Presented at Strange Loop 2018.
- "Data Science in Clojure" by Soren Macbeth. Presented at Clojure/West 2015.
Projects mentioned
- Nate's tabl project
- Nate's guide: Developing Clojure in Vim (2023 edition)
- Conjure for Neovim
- next.jdbc
- Honey SQL

Ep 098: Composed Learnings Nov 09, 2023

Show notes

Each week, we discuss a different topic about Clojure and functional programming.

If you have a question or topic you'd like us to discuss, tweet @clojuredesign, send an email to feedback@clojuredesign.club, or join the #clojuredesign-podcast channel on the Clojurians Slack.

This week, the topic is: "composition is life". We reflect on keeping the necessary mess at the edges so our core can be composed together with beauty and simplicity.

Our discussion includes:

Our reflections on the episodes in this series.
The best concepts from the episodes in this series.
How to separate data from behavior.
Why zucchini bread is at the core of functional programming.
What baking has to do with functional programming.
How to get objectivity for better understanding.
Why you should focus on trade offs.
How Clojure and immutability steer you toward composition.
An inventory of different kinds of functions.
Why side effects ruin composition.
How Clojure lets you focus on your problem.
How composition works in the small and the large.
The paradox of constraints providing more freedom.
The cognitive load of functional programming vs object-oriented programming.

Selected quotes:

"This episode we thought we would take it and put it all together." "The last draft."
"Functional programming is built on composition."
"Object-oriented programming tends to have at least a little bit of behavior and data together, so you can't separate them if you want to make a new thing."
"If you just want classes to be one thing, just data or just methods, all of a sudden you end up with something that looks a lot like functional programming."
"Constraints breed freedom and clarity. If you can't reach other functionality through data, then data will never hurt you."
"It takes a while to discover what is worth separating and what's fine to leave in larger chunks." "You have to use it."
"So by moving [a problem] into a separate domain, you're able to see the essentials, the fundamentals, more clearly because you're not stuck in those ruts of thinking that you do without realizing."
"I've been known to eat the same thing for breakfast every day, for weeks on end."
"Clojure core plus immutability really steers you in the direction of composition."
"'Transforms' is a little unfair of a category because that's almost all of functional programming."
"Data cake. Delicious!"
"I want to do something with this data that affects the world around me besides generating heat."
"Side effects ruin composition because side effects are a second dimension that is difficult to compose."
"When you write functions in the way that Clojure expects them, this whole world of core opens up, and the only thing you had to implement was your the code that was relevant to your domain."
"There's almost nothing to Clojure itself. Most of my time writing in Clojure is thinking about my problem--not thinking about how I'm going to express it or how I'm going to model the object graph or any of that stuff."
"I'm just left thinking about my own problem."
"The key in all composition is a clear delineation and separation of responsibilities."
"Because they're smaller, you can understand them at a glance."
"With side effects, there's an infinite number of additional dimensions that are possible. You can't just worry about what the function says it does, you have to worry about all the other things that it could be doing!"
"Side effects are like really advanced politics between hostile countries. There are the words that come out of their mouth, and then there's all the stuff that really matters that no one's talking about!"
"Clojure is for the peaceful."
"If you like to keep all the messiness at the edges so the core of your application can be composed together with beauty and simplicity, making your day wonderful, then Clojure might be for you!"

Common kinds of functions:

Predicates: provide truth values
Reducers: take the current "state" and an input and return a new state
Transforms: broad category that covers many kinds of functions
Conversions: take one kind of thing and turn it into another kind of thing eg. parse-long
Extractors: return part of a data object
Mergers: combine data together
Decorators/enrichers: takes a data shape and adds more into it while preserving the original data shape
Side effectors: affects the world in a clear and specific way

Links:

Ep 097: Application of Composition Nov 02, 2023

Show notes

Each week, we discuss a different topic about Clojure and functional programming.

If you have a question or topic you'd like us to discuss, tweet @clojuredesign, send an email to feedback@clojuredesign.club, or join the #clojuredesign-podcast channel on the Clojurians Slack.

This week, the topic is: "composing your application". We get a handle on bringing I/O resources together in an application.

Our discussion includes:

What is a "handle"? Why is it called that?
More puns!
How do you handle I/O handles?
How do you keep the pure and side-effecting parts away from each other?
Managing and organizing application components.
What is a framework vs a library?
"Injection style" vs "singleton style".
How far down the call stack should handles travel?
Figuring out a start-up order and a shut-down order.
How obtaining a resource can negatively affect composition.
Separating the knowledge of finding a resource vs using a resource.
The concept of an "application index".
Why all this matters for long-term maintenance.
Using feature flags.
The two developers on every software project.
What is the "band-aid test"?

Selected quotes:

"If a program does a bunch of computation, but it doesn't have any I/O, did it do anything?"
"Handles inherently are going to hurt you. You don't even have a hold on the whole thing. You have a little bit that you can use to to access that external system."
"I visualized an axe or a knife. You have a handle, but you have to watch out for what the handle is connected to!"
"In Clojure, I think of frameworks as an integration between your code and the purpose of that framework as opposed to the foundational layer that glues your whole world together."
"Even in OO, it's a smell if I/O handles travel too far and wide!"
"Lots of assuming!"
"Sometimes ad hoc is confused with flexibility. You didn't have to think about it, so it felt flexible, but it just happened."
"Composition is about being able to use things in multiple ways."
"If you are accessing a singleton state from a function, you are no longer side effect free."
"Why would I ever save anything anywhere other than the place the application has configured as its database?"
"Have you ever had a physical "dead tree" book?"
"Where are all the components?"
"With the index style, you have a clear delineation of all the parts of the software and how they're connected together."
"Whenever you start using a library or framework, you are hopefully solving a problem, but you're also inviting complexity in. You have to be wary of what it allows you to do, and what it allows future developers to do."
"If you pull that band-aid off, how many little hairs are going to come off with it? How badly is it going to hurt?"
"One of the tests of composability is the surface area of contact. More is not better!"

Links:

Injection style: Component + component.repl, Integrant
Singleton style: redelay, mount
Built on Component: system
Others: donut.system, Components in Biff
Ep 063: Web of Complexity
Ep 067: Handling Handler's Handles
Ep 093: Waffle Cakes
Ep 094: Concrete Composition
Ep 095: Composing Core
Ep 096: Gaming Data

Ep 096: Gaming Data Oct 26, 2023

Show notes

Each week, we discuss a different topic about Clojure and functional programming.

If you have a question or topic you'd like us to discuss, tweet @clojuredesign, send an email to feedback@clojuredesign.club, or join the #clojuredesign-podcast channel on the Clojurians Slack.

This week, the topic is: "playing games with data." We go back to start and play through a composition strategy to see where we land.

Our discussion includes:

The return of Tic Tac Toe. It's back!
The biggest difference between object-oriented and functional composition.
Can a game board play its own pieces? Isn't that the stuff of horror films?
What does it mean to be "complected"?
What's more important: data or behavior?
Why separate data from behavior?
The simple domain of batch processing.
The dark magic of hidden side effects.
What lasts longer: data or your application?
Representation vs operations in an information domain.
Common kinds of functions.
How do schemas fit in?
Where does I/O fit in?
Rationale for organizing your namespaces.
The horror of code organization in Java.
The stability of pure information models.
What is language imposed complexity?

Selected quotes:

"It's been a few years for us, but it could have been a few days if you're really on a binge on this podcast!"
"The biggest and most important difference between object-oriented programming and functional programming is the relationship between data and behavior. Functional programming keeps those separate, whereas object-oriented programming likes to mix them together into classes."
"When I want to play a piece, does the board know how to play pieces onto itself? Or, does a piece know how to place itself on the board?"
"You can't just have the functionality sit on its own. It has to be attached."
"I arrived at a point where I thought, 'What am I doing?!'"
"All kinds of different scripts that operate on the same data file don't need to know about each other at all."
"I'm just going to get the name attribute from the Person object, right? You don't know. Am I getting a field, or am I getting some magical overloaded getter thingy that does a bunch of side effects?"
"Data is simple, and data will almost certainly outlast your application. Often, the data that your application deals with came from somewhere else in the first place."
"This reminds me of the fun abomination known as object-relational mapping where you take the data that was there before your program and you pour it somehow into your objects, then you do something with it, and then you pour it back out into the database. Why is this such a hard problem? Because it's a hard thing to do! It's something that doesn't make sense."
"In OO, there are way more dimensions of potential organization, so therefore, more things for a software development team to fight over."
"The only place you can put functionality in object-oriented language is attaching it to classes."
"In Clojure, you don't have a lot to fight over in your bike shedding sessions."
"When you're talking about which object to put it in, you're not actually talking about your problem. It's a problem that is introduced by the tool choice, not by the domain of the problem."
"Because they're separated, you get reuse. You get data composition and behavioral composition as separate kinds of composition--because they don't often happen the same way."

"I think the lack of reusability comes in object-oriented languages, not functional languages. Because the problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.

If you have referentially transparent code, if you have pure functions all the data comes in its input arguments and everything goes out and leave no state behind it’s incredibly reusable."

~ Joe Armstrong in "Coders at Work"

Links:

Ep 095: Composing Core Oct 19, 2023

Show notes

Each week, we discuss a different topic about Clojure and functional programming.

If you have a question or topic you'd like us to discuss, tweet @clojuredesign, send an email to feedback@clojuredesign.club, or join the #clojuredesign-podcast channel on the Clojurians Slack.

This week, the topic is: "core and composition." We venture toward the core of a solution.

Our discussion includes:

Why do functional programmers like to talk about composition?
What composition means in object-oriented programming vs functional programming.
Must simple be simplistic?
What is idiomatic composition?
Common kinds of functions.
Why functional programming is more like Legos than taxonomies.
What Clojure already knows and what you have to teach it.
Why Clojure allows you to put things together quickly.
Why side effects can ruin everything.
How Clojure encourages composition.

Selected quotes:

"I don't think you want me to read code to you. That sounds like an excellent way to fall asleep if you have insomnia!"
"Maybe we need a white noise track of keyboard noise."
"Composition in a functional language is much simpler because we just have functions."
"Why have we spent so much time talking about composition when it's just functions calling other functions?"
"These names are a little on the nose, but programmers aren't always the best at originality!"
"Functional programming is essentially based on transformation. Everything is a transform at some point in time."
"The only way to get anything done is to return a new thing."
"Core is a backbone, a spine, and you're connecting a progression of things together."
"Your job, as a functional developer, is to teach Clojure core about your domain."
"They're all functions that remix very well."
"Everything must be pure because side effects mess up this whole world."
"Make functions small because functional programming makes it very easy to combine smaller functions into bigger functions. Build up your functionality from those pieces."

Links:

Ep 094: Concrete Composition Oct 12, 2023

Show notes

Each week, we discuss a different topic about Clojure and functional programming.

If you have a question or topic you'd like us to discuss, tweet @clojuredesign, send an email to feedback@clojuredesign.club, or join the #clojuredesign-podcast channel on the Clojurians Slack.

This week, the topic is: "decomposition." We help our code through a breakup so it can find its true colors.

Our discussion includes:

How to process text and add color.
When is it time to decompose?
Return of the box mix!
How to separate transformation from I/O.
How to use reducing functions to repeat computation.
What makes code orthogonal?
The woes of packing useful data into bits.
Signs of complexity in the Java underlayer.
What is the difference between isolation and decomposition?
What are some natural points of separation?

Selected quotes:

"We are composing ourselves!"
"I'm a terminal guy, so this is all in the terminal."
"You can go look it up on the Internet. I'm not going to try to speak ANSI right now."
"The box mix makes it really easy to make a cake, but it also constricts your ability to do more things with it."
"By definition, any side effect is an orthogonal concern."
"It's screaming for decomposition!"
"Separating these out makes it so that it's easier to understand each part by itself."
"We have our 'actual code' badge again as a programming podcast!"

Links:

Ep 093: Waffle Cakes Oct 05, 2023

Show notes

Each week, we discuss a different topic about Clojure and functional programming.

If you have a question or topic you'd like us to discuss, tweet @clojuredesign, send an email to feedback@clojuredesign.club, or join the #clojuredesign-podcast channel on the Clojurians Slack.

This week, the topic is: "effective composition." We search for that sweet spot between full-featured mixes and simple ingredients when crafting your software recipes.

Our discussion includes:

What makes code "composable"? What makes it "not composable"?
What baking has in common with software design.
What baking does not have in common with software design.
Are you using ingredients or a box mix?
How to know when you need to split something apart.
When is a part too big? When is a part too small?
What is too flexible?
The principle of orthogonality.
Decomposing without the smell.

Selected quotes:

"This is a Clojure podcast. We have to have a definition every once in a while."
"When you try to take code that someone has made and combine it with other things, how much resistance, how much difficulty, do you begin to encounter?"
"A cake is a composition of smaller things."
"You're still composing a cake. You're just composing it out of bigger things."
"Let's compose dinner together."
"You might be fighting against some of the ingredients, because you have a whole lot of stuff that's been premixed that comes along for the ride."
"What if you want waffles?"
"Everything is made of atoms! If I could assemble atoms, I have ultimate flexibility!"
"If it's narrowly focused, it's hard for it to get in the way of other things."
"You're making well-suited things, that have small scopes of responsibility, so that you can weave them together appropriately for your domain."
"Who owns the recipe?"
"Ah yes, you are the cause and the solution of the problem!"
"Are you able to write a new recipe and reuse all the ingredients?"

Links:

Ep 092: Freeing Limits Sep 28, 2023

Show notes

Each week, we discuss a different topic about Clojure and functional programming.

If you have a question or topic you'd like us to discuss, tweet @clojuredesign, send an email to feedback@clojuredesign.club, or join the #clojuredesign-podcast channel on the Clojurians Slack.

This week, the topic is: "freedom through constraints." We bump into limiting constraints and learn to love their freedoms.

Our discussion includes:

Why expressiveness isn't everything.
Causes of combinatorial complexity.
The long-term benefits of decreased complexity.
Problems Clojure eliminates with its language design.
Why complexity feels so good when you're problem solving.
How the right limits create freedom.
Why Clojure's limiting constraints make it hard to switch from object-oriented programming.
Reasons software teams start using microservices.
Integrating around behavior vs integrating around data.
Awesome hair.

Selected quotes:

"Complexity really adds up the more you load it into your application."
"Clojure eliminates the time sink related to combinatorial complexity while giving you the ability to craft things faster."
"When you're inside a method of an object, there's all those delicious member variables, instance variables, that are just sitting there ready to be touched--ready to be modified--and you have to be super disciplined not do that."
"You feel so good because of all the systems you come up with, and all the structure, and all the rules. You notice patterns in the different rules, and you publish books about them, and you think, 'Wow! Look how productive we've been in coming up with all these ways of managing all this complexity! Programming is so hard!'"
"Limiting constraints create freedom through limitation."
"Sorry, I mutated it out from underneath us."
"Eventually, over time, [the OO system] grows and then it becomes unmanageable. It becomes ungovernable. There are no rules that you can actually have, so the only solution is to rewrite."
"You know it's a good metaphor when you can take it to the level where it starts falling apart."
"This is a big downside of Clojure: you don't just pick it up like your last four programming languages that were all from imperative land."
"It's not just a functional style that hangs out as a little part of your program. This is functional: top to bottom, ceiling to floor."
"You think of zucchini bread as a naturally mom-shaped problem."
"You have to discover another way to do it, and that can take time."
"It appeared again! Great! It's for me!"
"I just want my program to work, and some guy, with awesome hair, has told me that this is better, but I don't know how to get there!"

Links:

Ep 091: Combo Boost Sep 22, 2023

Show notes

Each week, we discuss a different topic about Clojure and functional programming.

If you have a question or topic you'd like us to discuss, tweet @clojuredesign, send an email to feedback@clojuredesign.club, or join the #clojuredesign-podcast channel on the Clojurians Slack.

This week, the topic is: "effective expressiveness." We compose our thoughts on why Clojure expressiveness is so effective but can be so hard to learn.

Our discussion includes:

Why Clojure can give you a boost as a developer—in the short and long term.
Our definition of expressiveness, and why it's not simply about conciseness.
Why object-oriented developers often struggle to learn functional programming.
What makes some abstractions better than others.
The deep implications of immutability.
How to work your way up to an expert functional programmer.

Selected quotes:

"Getting rid of problems over time really adds up."
"More of the code is solving the problem instead of being boilerplate."
"You hold things at a higher level, but still very clearly, because they're well defined."
"Because all of the verbs in Clojure work on all the data structures, they become more powerful."
All of these new pieces have names and concepts associated with them, and you're not going to know them."
"You can do tiny things, but tiny things are toys. You want big things. You want to solve problems."
"It's not a small adaptation of thinking in a little region of the code, but it affects how you structure and organize everything."
"You have to go in levels. You can't go all the way from zero to done."

Links:

Clojure Core

Ep 090: Conditional Results Dec 18, 2020

Show notes

Each week, we discuss a different topic about Clojure and functional programming.

If you have a question or topic you'd like us to discuss, tweet @clojuredesign, send an email to feedback@clojuredesign.club, or join the #clojuredesign-podcast channel on the Clojurians Slack.

This week, the topic is: "cond-> and cond->>." We devote some time to two functions that are indispensable when computations require variation.

Selected quotes:

"Our love of Clojure is unconditional!"
"These are all about conditional operations."
"It's shorter and easier to understand, which is uncommon in development."
"That gave me data I could reason about in the program."

Links:

Our TOPPODCAST Picks

Follow Us

Stay Connected

Functional Design in Clojure

Related Podcasts

Links

Stay Connected