Ep 105: Codify!

Functional Design in Clojure

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 [email protected], or join the #clojuredesign-podcast channel on the Clojurians Slack.

This week, the topic is: "building up a solution". We grow beyond our REPL-driven pieces toward an end-to-end solution.

Our discussion includes:

• How to move from exploration to implementation.
• The overall process for Sportify highlights.
• How our REPL exploration set us up for implementation.
• What is a "tracer bullet" implementation? How is it useful?
• What is "imperative decomposition"?
• What is "imperative composition"?
• How to handle surprises in the data.
• The first code solution for an I/O-heavy process.
• How to build up a solution incrementally.
• Running and testing the intermediate process.
• How to visualize intermediate data.
• What approach is both "coding first" and "coding light"?
• How does Clojure allow a domain to speak for itself?

Selected quotes

• The learning is complete. Now it's time to get to the programming!

• We didn't sign up to be a robot. We signed up to be a programmer.

• We want fighting teams. We're not going to have very many highlights if it's the Badgers versus the Doves.

• A tracer bullet is a minimalist solution where we try to get something working end to end.

• It's interesting that you would say "imperative decomposition", because in this case, we have the parts, so we are doing an imperative composition. We're putting them together.

• You get your learning, and you get a little bit of code out of it at the same time. Sure, that code may not be what you want to use in production, but you certainly have more actual code to work with than you did if you just opened up your database explorer and ran SQL statements.

• Just because it's a silver bullet doesn't mean all human intervention is no longer needed. A silver bullet has to be fired by someone!

• We're growing a function a piece at a time.

• So by naming that and giving it a function name, it makes it more readable. It helps document the information.

• It's like a mini language here in the let. ... It makes this process—that you're now documenting in code—a little more readable.

• You can launch this whole thing using a comment block!

• You're exploring your way toward a solution. Even though it's very imperative in this case, you're just continuing to explore your way towards the solution as you build it up.

• You're on your second rewrite of the code. You're not writing this code for the very first time. You're writing it for the second time, which means you're going to be picking variable names and function names better than the first time because you understand the concepts. You're not learning the concepts and writing the code at same time.

• Exploration was important, but this second step (of making the code again) is valuable, because you're learning what level of abstraction you want.

• With command line clients and browsing tools, you still learn a lot about the domain, but you don't learn a lot about how you want to represent it.

• It's a coding-first approach, but it's also a coding-light approach. Clojure doesn't make you model the universe in a proof system that you have to try to get right and revise and revise.

Links

• Sportify! series:
  • Ep 101: Sportify!
  • Ep 102: REPLify!
  • Ep 103: Explorify!
  • Ep 104: Assembleify!