I think we do largely agree in a lot of ways. > This is just a different formulation about the "volatility" of a lot of requirements of software by the users/c

I think we do largely agree in a lot of ways. > This is just a different formulation about the "volatility" of a lot of requirements of software by the users/customers. Yes. I would say that this is a defining feature of computer programming - change. The complexity of change is what computer programmers primarily want to use abstractions to deal with (where such a concern is really absent to a mathematician. Everything is immutable to them). And yes, reasoning about the code is part of that too, but in computer programming often its in the form of being able to reason about a code base that is slowly shifting under you as other programmers make changes in other parts (in the context of a large project with many devs. I suppose its a different story for a solo project) To bring it back to the original start of the thread, i guess what i'm saying is that what makes an abstraction good for math is different then what makes it good for a computer program, so naturally they are going to look a little different.