The paper has some nice justifications for the course. I really like their thinking. I think not focusing on proof so much is corroborated by industrial experience in high-assurance systems. They always noted just doing formal specifications and simplified versions of the systems caught lots of errors. It also increased developers’ understanding of the problem, esp subtle things. Although proofs had high costs, formal specs were usually affordable if the method was approachable and the folks had prior experience. You can also generate tests or code from them. So, I’m already siding with authors on describing logic as a tool for understanding and analyzing rather than proof by default.
I mean, teach proof as well. Just make sure they’re getting value out of logic way before that. Might even keep learners interested and using logic when they hit difficulties learning proof. People thinking logic is only good for proof might abandon interest in it hitting same difficulties.
This looks really interesting; I struggled with mathematics at university but was much more successful with formal logic. It would be fun to run through this as a refresher.