Here is my relation with Object Orientation / Functional Programming / any other Approach X inspiring my architecture & development process.

That’s a (self-)respecting conversation with myself. 😅

KC Green

- Shall my codebase built with X be [1-TESTED] ? (Handcrafted tests.)

- Sure! So I can add the features of my unit I am testing step by step. And ofc I can make an exhaaaaaaausting set of tests to make sure the integration & the whole system works as expected. However it is (not) surprising I still have a lot of bugs and I do feel slow/repetitive at (many) times.

- Shall my codebase built with X be [2-PROPERTY-TESTED] ? (Quickcheck like & partially automatically generated tests.)

- Sure, the more I code, the more I prefer these! It really does seem I am wasting so much time & effort when I forget about edge cases. Especially when requirements change in different parts of the system at the same time, so some nice constraints I observed and used in my hacky but KISS-simple solution do not hold anymore. In best case it’s documented — but the related (dead) tests & (dead) code still live in the codebase. The fact they still exist is a lie and makes it hard to distinguish the code of past from present and future. So having generated tests can help with this.

- Shall my codebase built with X tested via [3-MODEL CHECKING] ?

- Omg! That would be nice! When the edge cases mentioned above have a lot to do with async/timing/concurrency that would be a huge gain! Otherwise it is literally impossible to know and enumerate everything works as expected… But to be honest I have no experience with it. I doubt the language/ecosystem I am using personally (or with my team) will have the access to use something like that in the near future. Let’s say I model it in TLA+. So how can I use it as a Typescript/React Native dev? (Not to mention if someone has a django-shop.) I have to duplicate at least part of the codebase, right? One for sanity, one for the ecosystem. And I have to maintain both… that’s a real “subscription”. That might mean complete reimplementation of the business logic in the model checking world, right? I mean… to be really exhaustive without defects…

- Shall my codebase built with X tested/verified via [4-FORMAL PROOFS] ?

- Ah that would be nice! But how can I use Isabelle, Coq or even just Agda/ Idris today? I am not sure. I am working with React Native. I live in the .js/.ts world though so it has a chance to join forces “early as possible”. Yes, Agda and Idris can generate js. But what about the DX in IDEs, integration with the current libs & ecosystem? Is it all gone? The process just does not seem straightforward at all. If it is not laid out well that will be more pain than gain. Maybe I am just too scared — say “ill-experienced” and forgive me.

- Ok, let’s get back for a moment. So the best I can have is Formal Proofs. It might be tedious to create, but that would be Truth — with all its advantages . Do I really care about FP/OO/ Approach X at this point/level/criteria - when I already have a formal proof?

- Hmm… Maybe no. But… but… but FP/OO/Approach X might impact the “Architecture” of my system… and its about “Tradeoffs”… and their… “Consequences”.

- Sure, but in theory I have all my requirements set up. If I want OO like or Approach X like extendibility/any kind of property for any part of my system I can virtually design it “my way” but I can still write a proof proving the necessary property holds. Why not to focus more on Formal Proofs & specific properties of the system than overloaded, bloated terms which claim to rescue from headache but fail. Formal Proofs do not seem to have (as much?) testing problems. FP, OO do not really address this that deeply and seriously. OO says “unit tests”, FP says “simple functions, easy to test” / “pushing IO & side effects to the boundaries”. Hey, I appreciate that… and it still sucks.

- Ah yeah… that’s might be true… But Formal Proofs seem like its for the big guys… I might be not that big…. Car/airplane companies, space businesses, banks, government (lol) might have the necessity and the workforce & experts to go down the rabbit hole, but is that really accessible now? For an indie?

It feels like being too broke to afford these “luxuries”. The “luxury of engineering”. No one does that. Even the most famous lib/framework authors do not ever mention that. They spin up the good ol’ {X}Unit and solve (fix, haha) the problem.

Let’s say I am not that big to afford these luxuries. What now? I think I will go back to the complexity I can manage. Hmm… this is handcrafted tests and property based testing maximum - which are available in my ecosystem.

And… in that particular case… without formal proofs…

I have one tiny question left to answer…

OO, FP or Approach X?