Sign up to save your podcasts
Or
Share Absurd Abstractions | Coder Radio 371
Share to email
Share to Facebook
Share to X
Share to email
Share to Facebook
Share to X
Or
Absurd Abstractions | Coder Radio 371
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.
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.
View all episodes
By Jupiter Broadcasting
4.9
1616 ratings
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.
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.