Eric Normand Newsletter 465: Abstraction is the essence of programming
Reflections 🤔
Abstraction is the essence of programming
I have been thinking a lot about what I want my next book to be about. I know there's a good book somewhere in the swirling nebula of domain modeling concepts that I've been exploring.
I've said before that I don't want to define a process or methodology. I'd hate to start a movement that some people follow as a silver bullet. Our industry is too full of those already.
I also know that I don't want to offer "design advice." We focus too much on the style of programming and not enough on the content. People want to design their code to be maintainable, but I still contend that the most maintainable code is code that models essential concepts in the domain. How do we do that?
The more I research it, the more I realize that what's missing is a coherent description of what we do when we program. We teach people to write loops and call functions, but we never circle back to think about how loops and functions can do practical work in the real world.
The answer is abstraction. Abstraction is a mapping from a concrete domain to an abstract domain. We map the days of the week (concrete domain) to the integers 1-7 (abstract domain). Then we can write useful operations on them because computers handle integers easily. After performing operations on them, we can map them back to the days of the week. We have created a model of the "days of the week" domain.
The act of abstraction is the essence of programming. I want to re-examine programming from this lens and teach valuable skills that more experienced programmers employ.
For example, there are many decisions we need to make when building our model. Are integers the best way to represent the days? What other choices do we have? How do we choose between them? And further, how do we build something elegant and powerful? These are some of the things I want to explore. My goal is to help people build better software much sooner in their careers.
Housekeeping 🧹
PurelyFunctional.tv is now retired. Everything is now on ericnormand.me. Although I did my best to make the transition smooth for you, I may have made some mistakes. So please let me know if anything is broken for you. I'd appreciate it.
Awesome article📝
Preface to an Unwritten Programming Language Book
I love Avdi Grimm's work and this new article is no exception. It spoke right to me as a programming book author.
Awesome book 📖
How to Engineer Software: A Model-Based Approach by Steve Tockey is a very valuable book. Its main thesis is that modeling the software up-front can deliver software on time and on budget. Software is late because no one figures out what is really needed (requirements), so the wrong software is built. That wrong software needs to be corrected and reworked.
The book shares a lot of practical skills, like how to draw UML diagrams that everyone can understand. According to Tockey, code is a poor place to define how the software should work. Code describes what the computer should do, but it does not describe what the customer wants or needs.
It's also got lots of advice from a grizzled developer, such as "Stop calling them bugs!" The term bug is too cute. You should call them defects.
I really enjoyed the book, though it is a bit of a slog to get through. It's dense! I found that after a couple of hundred pages, my mind was too full to absorb any more ideas.
The book presents a style of programming that I'm not really a fan of: Model things in UML (the interesting part), then (mostly) mindlessly translate all the diagrams into classes. It strikes me as a bit defeatist that you can't find better tools than the programming language at hand. It's as if your language were just a higher-level assembly language, not something meant to think in. I much prefer the more functional/Lispy approach of developing a language in which you can model things. But who has used that approach to build large software on time and on budget?
In the end, I think there's a lot to learn from someone who has successfully delivered many large projects throughout their career. The book captures a ton of great knowledge.
Book update 📘
More Twitter messages like this one in my feed. I love it:
You can order the book on Amazon. Please leave a rating and/or review. Reviews are a primary signal that Amazon uses to promote the book. They help others learn whether the book is for them.
You can order the print and/or eBook versions on Manning.com (use TSSIMPLICITY for 50% off).
Clojure Challenge 🤔
This week's challenge
Single letter swaps
Write a function that takes a sequence of strings and a target string. For each string in the sequence, determine if it is equal to the target string after exactly one letter swap. Return the sequence of letter pairs that are swapped, or nil if it doesn't exist.
Example
(letter-swaps ["bacd" "abdc" "abcde" "abcc" "abcd"] "abcd")
;=> [#{\a \b} #{\c \d} nil nil nil]
Swapping a and b in "bacd" gives you the target string. Swapping c and d in "abdc" gives you the target string. But there is no way to swap to get an extra e. And trading a d for a c is not possible. Finally, the last string has no swaps, and exactly one is required.
Thanks to [this site](https://edabit.com/challenge/QwAwAC4xgahcCTjP %20o) for the problem idea, where it is rated Very Hard in PHP. The problem has been modified.
Please submit your solutions as comments on this gist.
Rock on!
Eric Normand
