> In my version of computational thinking, I imagine an abstract machine with just the data types and operations that I want. If this machine existed, then I could write the program I want. But it doesn’t. Instead I have introduced a bunch of subproblems — the data types and operations — and I need to figure out how to implement them. I do this over and over until I’m working with a real machine or a real programming language. That’s the art of design.
Love the way she put this. Good software design is a process of coming up with layers of vocabularies that most expressively describe what needs to be described, until you hit the bedrock of something that already exists that you can hand the rest off to.
Which is why I prefer working with a strongly typed functional language.
Domain Driven Development (well, my version of it) is the first step. Get all the types right.
The necessary operations should be obvious by this point.
Code them up!
Write unit tests as you go along. You're likely to do some refactoring as your operations materialize, and unit tests are going to help you stay safe.
That's the fun part. Too often forgotten is that, now that you've invented a new vocabulary, you need to teach it to others, or you're just speaking your own private dialect.
The key point is the top-down approach. Many programmers come up with their abstractions by thinking "what can I make?", but it's often better to think "what do I want to make, and in a perfect world, how would I want to express that?", and going down from there.
You have to consider the hardware if you want any amount of efficiency. You should consider your 'wishful thinking', because those wishes sometimes come true (not always, but often enough that its worthwhile to think about the ideal)
Love the way she put this. Good software design is a process of coming up with layers of vocabularies that most expressively describe what needs to be described, until you hit the bedrock of something that already exists that you can hand the rest off to.