Ep 113: Highlightify!

Functional Design in Clojure

Contenido proporcionado por Christoph Neumann and Nate Jones, Christoph Neumann, and Nate Jones. Todo el contenido del podcast, incluidos episodios, gráficos y descripciones de podcast, lo carga y proporciona directamente Christoph Neumann and Nate Jones, Christoph Neumann, and Nate Jones o su socio de plataforma de podcast. Si cree que alguien está utilizando su trabajo protegido por derechos de autor sin su permiso, puede seguir el proceso descrito aquí https://es.player.fm/legal.

9M ago 27:13

MP3•Episodio en casa

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: "highlight highlights". We highlight the highlights of the Sportify! series.

Our discussion includes:

Sportify: The Highlights!
Why is Clojure so well suited for situated problems?
Why should you work with real-world data ASAP?
How does REPL-driven development move seamlessly from exploration to implementation?
Don't invent your domain model, let it emerge!
How do you grow the application domain?
How does Clojure help facilitate bottom-up development?
Why is early integration just as important as exploration?
How is reliability related to frequency of use?
How does pureness affect reliability?
What is the think-do-assimilate pattern?
Are pure functions even needed in I/O heavy applications?
How do you shift a code base from imperative to pure?
Why is data-centric simpler than behavior-centric?

Selected quotes

"Let's put it all together into one context to rule them all and in the darkness bind them!" "But we're trying to spread the light of sports highlights across the Internet!"
There's nothing like actually seeing real data come from real APIs. No amount of talking to your boss or talking to the intern or reading documentation can replace what you get from touching the real-world situation.
Clojure helps you figure out how to bring the pieces together because you can just run the pieces in an ad-hoc way. You can just work on each of the parts without having to unify them into some kind of global proof system that's being foisted on you by static analysis.
It's like whiplash-driven development: you're moving so fast, you have to take a break just to take a breath!
The bottom-up way of constructing in Clojure has two properties: you're grounded in the real world, and you're just making what you need as you go along. It's very efficient.
Some of that code is going to find its way into your final working solution.
You're always making progress. You're always grounded in reality. You're just building what you need as you go along. It's not wasteful. It's very iterative. Very lean. Always forward motion.
If your system exploration is in Clojure, you can cross information streams a lot easier than if you're using separate tools. In Clojure, it's all data. You can just hand data back and forth.
You're not only discovering the properties of each information silo you're working with, but you're discovering the properties of how that data might fit and merge together. It's a grounded, incremental process for each of the parts, but also as the parts come together.
Sometimes you don't know what the final solution is going to be even though you have all the necessary parts. It's greater than the sum of its parts.
It isn't until you start running things over and over more frequently that you begin to discover the smaller percentage reliability issues.
The way you increase reliability is by minimizing things with side effects and maximizing things that are pure.
You're learning, at every step, what point needs more reliability.
The more pure data you have, the more visibility you have. The more pure functions you have, the more testability you have. So, reliability and pureness are definitely related.
It is amazing how much opportunity there is to move things into pure functions. The actual fetching or querying of the thing ends up constituting a pretty small part of your application. Working with the data tends to dominate.
The think-do-assimilate pattern allows you to maximize the testable surface in your application by factoring all the I/O out.
You start minimizing the I/O parts because your domain has emerged.