Could we build Newtonian mechanics on purpose?
One of the greatest domain models ever built was Newtonian mechanics. Why did it take physics, as a field, thousands of years to figure it out? What can we learn from Newtonian mechanics to help us model our own domains?
Could we build Newtonian mechanics on purpose? Hi, my name is Eric Normand. This is my podcast. Today I'm going to be talking a little bit more about software design and domain modeling.
First, I want to talk about my book. I just got these on Saturday, the printed copy. That's done. It's ready. It's out there in the world. You can buy a copy, too. I know a lot of people have been waiting. It's been in early access. A lot of people have bought the book. I'm hearing lots of really good things.
If you were waiting, now is the time. Go buy it. You can buy it at manning.com. You can get this and the PDF version together for the same price, so go buy it.
It's all about Functional Programming. It starts where, I think, most Functional Programming books should have started, with eight chapters all about working with pure functions, what I call calculations in the book, side effects, refactoring, understanding, being able to identify what is a pure function and what is not, those kinds of things.
I could not find a book that I could recommend to someone when they asked me, "What is Functional Programming? Why should I care?" All the books were too academic. They were too focused on the cool things you can do when you're years into your Functional Programming. All that stuff is fun, it's cool, but it's not for the beginner.
That's the first part of the book. It's all about actions, calculations, and data. That is functions with side effects, functions without side effects, and then data. The second part is all about first-class functions, higher-order functions, and dealing with time.
Time is one of the hardest things we deal with in programming. Things change over time, and you need things to happen in the right order. You need things to happen the right number of times. That's really hard to do. Functional Programming has answers to some of those problems, so we talk about them.
That's enough talking about the book. Buy it now. It's called "Grokking Simplicity," Grokking Simplicity. Grokking has two Ks. Go search for it. My name is Eric Normand. I'm the author, so you can search for me, too. It's got a rabbit on the cover because it's a grokking book. That's a series for Manning. It's a lighthearted fun romp through Functional Programming.
Back to the topic of software design, and could we invent Newtonian mechanics on purpose? What do I mean by that? I mean physics was a thing for thousands of years. The main form of physics was Aristotelian physics, Aristotle.
He set up a bunch of ideas, bunch of explanations for things that were happening in the world. Philosophers spent thousands of years trying to reconcile problems with what he said with the things that they encountered in the world. Basically, it was buggy. It was the buggy model of the world.
Instead of throwing it out and doing a rewrite, they decided to do some patches, some bug fixes, and stuff for thousands of years. Then people started working on a new version of physics.
They were using a different process instead of sitting back and thinking about how something might work. How do you reconcile? Why do some rocks float, like a very light, porous rock can float? I thought rocks belong at the bottom of the ocean. This is the kinds of thoughts that people had. Wood is so heavy, but it can float on water? What's going on there? All these questions.
They went to a scientific process, what we consider science now. You have Galileo starting to make a model of gravity, how it works here, near the surface of the earth. You have Kepler figuring out a model for how the planets are moving. This is a much more data-oriented hypothesis, and then testing and experimenting. It's much closer to what we would consider to be science.
Then Newton came along. He came up with Newtonian mechanics, his three laws. He claims that he discovered it, he invented it in his mind, he imagined it, when he was young and thought it was so obvious that he didn't think much of it and decided not to tell anyone about it.
That might be true. If it is, it's not good. [laughs] That's not a good way of inventing new models, the very useful models of the world. Just hope that some kid discovers it and decides to share it instead of withholding it?
He was skeptical of it because he thought this is a very nice, elegant system, of course, but do planets really act that way? Can it really work? The model doesn't have anything about size of objects. The gravity, does it still work when you're talking about a big planet? It's got a volume to it. It's not a point mass.
He worked out the calculus, invented enough calculus to work out that, yes, it does all work out. The model is robust. That's the physics that we have today.
All this is to say that, like I talked about in my last episode, we need a way of not just doing it by chance, but somehow, with a set of skills or some process that we can follow, we can come up with some model. Might not be the best model, you don't always get it right the first time.
We need to come up with models. We need to look at our domain, come up with a model. Do that hard part and somehow dissect this continuous, undifferentiated phenomena in the world and dissect it into a set of concepts and relationships among those concepts, such that we can then encode that into the computer.
I hope that we can come up with a process like that. I don't know if this is a good idea or not, for me to be working on this, but it's in my brain. It's happening. I am thinking about it. I'm reading about how this process could possibly happen.
Let me just say I hope that there is something out there that perhaps software engineers could learn from something existing. Maybe they need someone to go out and find it and translate it into terms that they can understand. This idea of how do we develop these formal models of phenomena in the world, how do we build that Starbucks, that is what I am trying to come up with.
I've made a bunch of notes for part two of the process, which is, once you have that model, how do you turn it into software? I think that that is pretty well understood. Maybe not everyone knows all the terms and everything, but they're used to doing it. As programmers, they know how to do it. It's something that they do all the time.
This other problem of making discoveries in a domain -- discovering for yourself. I don't mean inventing something new -- you might talk to a domain expert and, through talking with them, come up with a sketch of their model.
How do you do that? How do you draw it out of them? What are you looking for? How do you know if you found something? Those are the kinds of questions that I don't know if we have good answers to.
That's the research that I'm doing now, and I hope you join me on the journey. All you got to do is hit Subscribe if you're listening in a podcast player. This is my podcast. My name is Eric Normand. If you are into Functional Programming or know someone who should be, you should get my book, Grokking Simplicity. It has a rabbit professor on the cover. The subtitle is, "Taming complex software with functional thinking."
Go buy that and read it. Then come back, and there will be more episodes, I hope, waiting for you after you've read it. Also, I appreciate if you tell your friends about it, about the podcast, or if you rate or review it. Five stars is the correct number of stars for you to click on. Please leave an honest review. That would be great. Let other people find it.
My name is Eric Normand. This has been a thought on software design and domain modeling. As always, rock on.