Library patterns: Why frameworks are evil - Tomas Petricek
This article continues my mini-series on functional library design. Previously, I discussed why your library should provide multiple levels of abstraction. Today, we look at composability and avoiding callbacks. These two often go together - frameworks are based on callbacks and are not composable, while good libraries avoid callbacks and compose well.
Library patterns Why frameworks are evil This article is a follow up to my previous blog post about functional library design , but you do not need to read the previous one, because I'll focus on a different topic. In the previous article, I wrote about a couple of principles that I find useful when designing libraries in a functional style. This follows from my experience with building F# libraries, but the ideas are quite general and can be useful in any programming language. Previously, I wrote how multiple layers of abstraction let you build libraries that make 80% of scenarios easy while
related reading
- The cost of convenience — surma.devsurma.dev
- Write code that is easy to delete, not easy to... — programming is terribleprogrammingisterrible.com
- Essays on programming I think about a lot | benkuhn.netbenkuhn.net
- 3. Functions - CS2030S Programming Methodology IInus-cs2030s.github.io
- combinators in Rubymooreniemi.github.io
- Tao of React - Software Design, Architecture & Best Practices | Alex Kondovalexkondov.com
- A practical introduction to functional programmingmaryrosecook.com
- An introduction to functional programmingcodewords.recurse.com
- What’s so great about functional programming anyway?jrsinclair.com
- How to write complex softwaregrantslatton.com
- A Software Library with No Codedbreunig.com
- It's hard to write code for computers, but it's even harder to write code for humans · Erik Bernhardssonerikbern.com