Towards a better programming by Chris Granger

• I kept asking myself "How can we make programming better?", but I never took a step back and concretely figured out what's wrong with programming.
• Programming should be about solving problems, but somewhere along the way it turned into us solving the problems around our problems.
• Programming is our way of encoding though such that the computer can help us with it.
• At the end of the day, what we're trying to do is build something that enables us to accomplish something new--programming just happens to be the way we talk to the computer to get it done.
•  Programming is unobservable.
• We can't see how our programs execute. We can't see how our changes affect our programs. And we can't see how our programs are connected together. That basically means we can't observe anything.
• The state of the art in observability is a stepwise debugger, which forces us to stop the world and look at a single instant in time. But the truth is that few errors occur in an instant; most are found only by observing the passage of time. And for that, the best we have is print statements. This is ridiculous.
• We should be able to observe the entire execution of our program, forward, backward, even branched into new futures--not just when our breakpoint hits.
• OOP's notion of encapsulation is by definition unobservable.
• We are quite literally throwing darts in the dark and praying that we at least hit the board. We simply cannot see what our programs do and that's a huge problem whether you're just starting out or have written millions of lines of beautiful code.
• Writing a program is an error-prone exercise in translation.
• All we get in code are symbols. We never see or interact with the real things, just symbolic representations of them.
• Translation is hard and using symbols is error-prone, especially coupled with operations on top of other symbols. This indirectness, this inability to represent things usefully and directly manipulate them, is killing us.
• A vast number of programming errors are simple translation problems. We has the solution in our head, but in trying to turn it into code we just forgot something or translated it very slightly wrong. We have to get away from that translation.
• We should express domains in the ways they most naturally present themselves in, not with our own homegrown obfuscations.
• Programming is incidentally complex.
• There is an immense amount of incidental complexity in writing software, by which I mean there's a bunch or work that needs to be done that isn't directly related to the real problem you're trying to solve.
• Every time we add an event handler or create a callback, we're doing time management.
• Every time we've found ourselves manually managing something, we've come up with a solution that does it for us.
• I think the next big step in terms of removing incidental complexity in code will come from automatically managing time. The implications of which would be tremendous for our ability to cleanly express intent.
• There are so many examples of incidental complexity in programming it would be disheartening to try and enumerate all of them, but we have to start addressing them at some point.
• We should be focused on solving our problems--not solving the problems around solving our problems.
• At the end of the day, we should be able to go from nothing to a solution in the time it takes us to think of one, not the weeks and months it takes us now.
• If you look at much or the advances that have made it to the mainstream over the past 50 years, it turns out they largely increased our efficiency without really changing the act of programming. I think the reason why is something I hinted at in the very beginning of this post: it's all been reactionary and as a result we tend to only apply tactical fixes.
• We've made things better but we keep reaching local maxima because we assume that thees things can somehow be addressed independently.
• Each time we fix something, we push ourselves up some, but eventually we're working under so many layers of abstraction that the tower starts to lean and threatens to fall down.
• We have to stop thinking about these issues individually, and instead start imagining what it would take to address them all simultaneously.
•  Another layer of abstraction won't be enough. Instead, we have to address these fundamental problems at the very foundation of our solution.
• Excel is inherently observable since it doesn't have any hidden state and all values are there for you to see and manipulate.
• In the long run, I do believe manipulating computers will be a fundamental skill, but unlike most of the "programming is literacy!" movements lately, I think it'll have very little to do with writing out 'if' statements. The best path forward for empowering people is to get computation to the point where it is ready for the masses. Any attempt to do so with what we have now is destined to fail. It turns out masochism is a hard sell.
• I think one of the most interesting aspects to a complete rethinking of programming is the potential for a reboot in the culture of technology.