PurelyFunctional.tv Newsletter 280: Datomic Ions, Costly Code, Monad drama
Issue 280 - June 25, 2018 · Archives · Subscribe
Howdy Clojurers,
I finished something big on Friday---a new guide to Clojure's collections. I had started it a few months ago. Finishing it was therapeutic. It had been on my TODO list since March.
The final stages of the process reminded me that some things that take time require extraordinary effort. Sometimes, like the Augean Stables, we need to do lots of work all at once, or we stand no chance of completing it.
On Friday, I was tired of this work hanging over my head. I worked all day on it, starting in the morning, with a few breaks, until 3am, when it was published.
It's moments like these that make me question the prevailing wisdom of steady, regular progress to get things done. I often find the many distractions of the day drag out work indefinitely. It's like trying to pay off high-interest loans. Small payments make small dents. But really, you're never paying off any of the principal, so the debt grows larger. If you could just make larger payments, you'd make progress.
But where do you get the time to make those payments---those extreme bouts of productivity? For me, they come at the expense of sleep.
Instead of swapping out all the working memory I've built up for the day, I kept my mental cache hot and work into the night. The work got done. I got less sleep than I would have liked. But I got it done. And it felt right.
I sometimes think the "eight-hour workday" and the "eight-hours of sleep" prescriptions miss something deeply important about life. Life comes in cycles and rhythms. We can't smooth out the ups and downs, and spread it out evenly over the eight hours we are supposed to be at work. We build up tension around a project, and we can't relieve that tension without first increasing it to a climax. My best and most fulfilling work is completed at moments like those.
What is your experience?
Rock on!
PS Want to get this in your email? Subscribe!
The Ultimate Guide to Clojure Collections
I've written a ~30-page guide to Clojure's collections. Collections play a huge role in how Clojure programmers build systems. It starts by explaining the mindset Clojure programmers use for choosing collections, then goes into common patterns, and ends with brief explanations of the main data structures.
Please hit reply with any comments. I'd love for this to be a great reference for those who are learning.
The monad complaint pipeline
Julie Moronuki meditates on the difficulties of trying to do something different with your language, do something that requires a bit of study, and how internet discussions seem to go round and round but never get anywhere.
The Ten Rules of Schema Growth
Datomic has a nice list of guidelines for helping you evolve your system over time. These rules are a good idea regardless of your database. As an industry, we've got to develop best practices for evolving our software over time because the software now exists in a system that is beyond our control. A lot of what we release today will need to remain unchanged for the indefinite future. We should think about ways we can change, and ways we shouldn't.
Default data reader function and tagged literals
Alex Miller talks about additions that Clojure has made along the way to support tagged literals. I learned a lot from this article. I've used custom tagged literals myself and they are super handy. We should use them more!
Datomic Ions YouTube
I am not up-to-date on my Datomic, but this nice presentation by Stuart Halloway was a great refresher. Plus, it updated me on the new Ions feature, which lets you deploy and run code in the same JVM as your Datomic Cloud nodes. As a way to leverage AWS services, Datomic seems like a really cool piece of infrastructure. I am very tempted to try Datomic Cloud for my next project.
The Carrying-Cost of Code: Taking Lean Seriously
What if we had to rewrite every line of code every three months? It's an interesting question, but (fortunately, yet sadly) the question is not answered in the post.
Perhaps we could answer another question: what would code look like if it was valuable enough to keep forever?
How to Write Software
Back in 2010, I was lamenting one of my personal projects that exploded due to scope creep. What did ship basically sucked up all my time, then even when it was released, it just sucked. And that was right after a super successful project, which didn't suck up my time and was awesome.
So what happened? Well, basically, I let the scope get out of hand. And later I was thinking about what I could learn from it, so I wrote down this process for writing software.
Does it hold up? Would I still recommend this process? I think I would. One of the biggest killers of software is unnecessary complexity. Neck-and-neck with that is not being a good fit for any real users (but I don't have a good process for that :).
Anyway, complexity in software is a constant battle, so it makes sense to armor up.
[Functional Data
Structures](https://cs.uwaterloo.ca/~plragde/flaneries/FDS/) Book
We've all heard that Clojure uses persistent data structures in its main collection library. Chris Okasaki's thesis and book have been the GOTO reference up to now. But I've got it on good authority that this one may be a better reference to functional data structures than Okasaki.
Clojure Combinators
Combinators are functions that "combine" their aguments (often
functions) into a new function. These are functions like
parial,
complement,
fnil,
and
comp.
There's nothing too complicated about them. They're just a little
abstract.
So in this course, I go through a eight of them, show what they do, and implement them. It's like watching over my shoulder as I code and explain what I'm doing. None of them are more than a line or two of code.