Layered design in functional programming
Functional programmers often talk about creating layered designs, where each layer represents a coherent level of abstraction. It's a way to organize your code.
Eric Normand: What do functional programmers mean when we talk about a layered design? Hi, my name is Eric Normand, and these are my thoughts on functional programming.
In the last episode, I was talking about organizing your code. I mentioned something about dependencies, and you should follow the dependencies because those are going to guide you into what goes with what.
As soon as I stopped recording, I realized that there was something I left out. Let's say, you have some functions, like function A, and it depends on B, and you have a function B that depends on C, and C depends on D.
If you have another function, E, that doesn't depend on any of those, it's probably separate and it should be in a separate module, if you're looking for things to split off into their own modules.
Very often, what you'll find is when you have these long chain of dependencies, the things at the end of the chain are actually very stable and universally usable in a way that the stuff at the top of the dependency chain is not.
What I mean is, let's say, you're writing a program with a lot of graphics. You have stuff that a lot of things depend on that are at the bottom, like how to draw a square or rectangle, how to place text.
Then when you're actually making your histogram, that's going to use the placing the text and placing the rectangle. Something that is higher than the histogram is going to do something and draw a histogram on it. That's going to be on top.
Your A is the thing on top, then B is drawing the histogram, C is your routine for drawing a rectangle. What you should notice is that those things that are at the bottom of that dependency graph, dependency tree, those things start to stabilize. They're not going to depend on stuff at a higher level of abstraction. They're going to stay on that low level.
What you're looking for is like a stratum, like a layer, where all these things are at a very similar level of abstraction. They don't depend on anything above them, in the level of abstraction, they depend on things lower than them.
That stratum, especially as it starts to stabilize and you're not modifying it too much, that could totally go in its own namespace or module. A goal is to put code in a file. It's so stable and so perfect for what you need that you never have to open that file again. You never edit it.
That's the endpoint past the horizon. That's what you're trying to move toward. Something that, I know the five functions in there or maybe it's 20 functions. I know the 20 functions in there, and I never have to modify them because they're just solid.
They're depending on stuff that is modified even more seldom. You're making this layered design where each layer is a level of abstraction. The things in that layer, at the similar level of abstraction, and the dependencies point down toward things at a lower level of abstraction, lower, and lower.
The things at the higher level, those are the things that are going to change a lot. They change the most. You're looking for level of abstraction, change, and direction of dependencies.
This is a design that is talked about, I think, at the right length in structure and interpretation of computer programs where you can design these layers so that you do have this property of things depending down on lower level of abstraction. The things at the top are the things that change.
I think they did a graphics thing, too, in structure and interpretation. The picture you're drawing is the thing that changes the most, because you're like an artist experimenting with what your picture is going to look like.
Then down at the bottom, you have these really fundamental routines, like plotting pixels and rotating and translating points. That's all going to be very stable. In between, you have things that are halfway between an artist making some masterpiece and drawing pixels.
It's some intermediate stuff like mirroring a picture or rotating a picture around an axis, that kind of thing. That's the layered design. That's what you're looking for.
It's also a handy way to organize your code, to be looking for these modules where the module itself is at a certain level of abstraction and the dependencies are all in one direction.
Awesome. Thank you so much for listening, for watching. My name is Eric Normand, and you can reach me on Twitter. I'm @ericnormand. I also appreciate getting emails. Email me, firstname.lastname@example.org. See you later.