371: Absurd Abstractions

It’s a Coder Radio special all about abstraction. What it is, why we need it, and what to do when it leaks.

Plus your feedback, Mike’s next language challenge, and a functional ruby pick.

Support Coder Radio

Links:

• Feedback: Clojure, Racket, and Extempore — Thinking about the problem could take the form of leveraging the REPL to work out code to solve a problem or you could spend some time away from your computer screen (or in “Hammock Time”) working out problems.  If I have learned anything from Clojure’s creator, “Rich Hickey” its “Programming is not about not about typing, it’s about thinking”.
• Knuth's Sensitivity Conjecture One-Pager
• Law Of Leaky Abstractions — All non-trivial abstractions, to some degree, are leaky.
• The Law of Leaky Abstractions – Joel on Software — This is what I call a leaky abstraction. TCP attempts to provide a complete abstraction of an underlying unreliable network, but sometimes, the network leaks through the abstraction and you feel the things that the abstraction can’t quite protect you from.
• Forget about Leaky Abstractions — Even if an abstraction is leaky it can still be useful. Sometimes you cannot escape it (uniform memory) and sometimes the workaround is costly to implement (TCP, SQL). So you accept the technical debt for now. Hope the debt does not kill the project. Maybe there will come a time where it is worthwhile to pay off the debt.
• All Abstractions Are Failed Abstractions — It's our job as modern programmers not to abandon abstractions due to these deficiencies, but to embrace the useful elements of them, to adapt the working parts and construct ever so slightly less leaky and broken abstractions over time.
• Appropriate Levels of Abstraction — Instead of aspiring to higher levels of abstraction, we should instead seek to work at the appropriate level of abstraction for the problem at hand. The appropriate level is sometimes very high and sometimes very low. It varies for different situations even in the same software project. Just as other engineering disciplines require different tools for different situations, software development also requires tools and languages that support our work at multiple levels of abstraction.
• Choosing The Proper Level of Abstraction — In software development, choosing the right abstraction can be tricky. If you make it too simple, it won’t let you create a model to satisfy even the immediate requirements. If you make it restricted to the urgent needs, you might have to change it almost immediately to implement the next iteration of the model. However, if you make your abstraction too generic and all-encompassing, modeling solutions might get so complicated that you’ll go out of business before you are finished.
• The Crystal Programming Language — Crystal is statically type checked, so any type errors will be caught early by the compiler rather than fail on runtime. Moreover, and to keep the language clean, Crystal has built-in type inference, so most type annotations are unneeded.
• affect: Algebraic effects for Ruby — Affect is a tiny Ruby gem providing a way to isolate and handle side-effects in functional programs. Affect implements algebraic effects in Ruby, but can also be used to implement patterns that are orthogonal to object-oriented programming, such as inversion of control and dependency injection.
• Algebraic Effects for the Rest of Us — Imagine that you’re writing code with goto, and somebody shows you if and for statements. Or maybe you’re deep in the callback hell, and somebody shows you async / await. Pretty cool, huh? If you’re the kind of person who likes to learn about programming ideas several years before they hit the mainstream, it might be a good time to get curious about algebraic effects. Don’t feel like you have to though. It is a bit like thinking about async / await in 1999.
• MinIO — The 100% Open Source, Enterprise-Grade, Amazon S3 Compatible Object Storage