3 ms·
I would say instead software is just communicating, and communicating is about abstraction. That's from the user to the CEO all the way down to the software/har
by muzani 5y ago
I would say instead software is just communicating, and communicating is about abstraction. That's from the user to the CEO all the way down to the software/hardware.
There's a shift from communicating in an imperative manner to communicating in a declarative manner. Even between humans, communicating to a junior/senior, there's a difference between how much imperative and how much declarative communication you do.
Business use case is very declarative - "This app should send me a reminder before my appointment."
The next level of abstraction breaks it down further: How many minutes before the appointment? How many reminders? Email, push notification, in-app? Which of these are practical given our resources?
Then the next levels break it down further. Do you want more control (imperative) or do you want more abstraction? Is it so dumb you have to explain to it step-by-step how to thread itself and clean up memory?
And then there's a different level where you have to explain it to the other person maintaining the same code.
- itsmefaz 5y agoSorry for the delayed response. This is interesting! I was thinking similar but more than just communication. I'm currently of the mindset that at a fundamental layer, engineering is more a human nature problem - understanding humans and helping them in completing a given task.