Edwin Török on Nostr: nprofile1q…6gyrf nprofile1q…vqf9z nprofile1q…nq7hd Would be interesting to see ...
nprofile1qy2hwumn8ghj7un9d3shjtnddaehgu3wwp6kyqpqf3nlrmpjja65pzmvlegyl27l0y2m007nncxttdwqndrejajvdzask6gyrf (nprofile…gyrf) nprofile1qy2hwumn8ghj7un9d3shjtnddaehgu3wwp6kyqpqddazaa99ej9xryv6zmgv4s6d37rurjslslw6lrmzjfe6tpsa52tqsvqf9z (nprofile…qf9z) nprofile1qy2hwumn8ghj7un9d3shjtnddaehgu3wwp6kyqpqjxp9xgmd5yxdhl3gdkgvmh9z87963lf4yff8y35psy3rxflnjecqxnq7hd (nprofile…q7hd) Would be interesting to see a list of those invariant based programming books. (Ever since I've seen the 'theorems for free' paper I focus more on types and data structures than implementation).
One successful example of thinking about invariants/properties was the way backtracking was taught in high-school. There was a template with separate functions that you had to fill in with the properties specific to the problem, and a high-level , almost boilerplate, code for the actual algorithm. This was a lot more verbose than just coding it all directly in a single function, but was very useful for learning. In fact even at competitions there were some who started by typing out "the backtracking template" to save time, even before they got to see what the problem was. So in case they run out of time to implement a more efficient solution they'd at least score a few points on the smaller test cases, as it was relatively easy to fill in the template with the properties, and thinking about those properties was a necessary step to find a more efficient solution anyway.
Nowadays I tend to take this a step further and try to use the type system/abstraction to enforce invariants (at compile time if possible). Far too often I've seen code that claims to be OOP, but is so only in its syntax, and doesn't actually take advantage of abstraction and exposes all the internals with getters and setters that might destroy any invariant. Whereas when used properly, OOP (or abstract types in modules ), could ensure correct by construction values, that can only be modified by update functions that themselves guarantee to preserve invariants (ideally also immutable, which works nicely in a functional language).
One successful example of thinking about invariants/properties was the way backtracking was taught in high-school. There was a template with separate functions that you had to fill in with the properties specific to the problem, and a high-level , almost boilerplate, code for the actual algorithm. This was a lot more verbose than just coding it all directly in a single function, but was very useful for learning. In fact even at competitions there were some who started by typing out "the backtracking template" to save time, even before they got to see what the problem was. So in case they run out of time to implement a more efficient solution they'd at least score a few points on the smaller test cases, as it was relatively easy to fill in the template with the properties, and thinking about those properties was a necessary step to find a more efficient solution anyway.
Nowadays I tend to take this a step further and try to use the type system/abstraction to enforce invariants (at compile time if possible). Far too often I've seen code that claims to be OOP, but is so only in its syntax, and doesn't actually take advantage of abstraction and exposes all the internals with getters and setters that might destroy any invariant. Whereas when used properly, OOP (or abstract types in modules ), could ensure correct by construction values, that can only be modified by update functions that themselves guarantee to preserve invariants (ideally also immutable, which works nicely in a functional language).