Having it closed (like this server rack) allows for controlled air circulation if fans are installed and flow paths are designed properly. Also, in case heating is needed, for example, if operated in the basement the heat loss can be reduced.

I also built something similar. In the end I appreciated the services our nature provides to us even more. Replicating all this artificially is really hard and energy intensive. Planting and growing plans outsides is fun and rewarding; adding all the tech in the end felt like a big waste of resources.

My motivation to work on such a project was my disbelief in human mankind to keep our planet earth habitable.

Tony advised me to make money with the software model checker I have been writing. In contrast to the typical practice to make these tools open source and free for use. Would have loved to learn more from him. He was a great teacher but also a great and sharp listener. Still remember the detour we made on the way to a bar in London, talking too much and deep about refinement relations. RiP.

I can only agree. It is great work; I met Julia in several occasions were we other academics tried to push our formal methods stuff for checking properties of the Linux kernel. Also ours worked but in a way more complicated way, very resource intense, and less effective than Julia’s work.

In the end, facts are useless. You belief what you think your social bubble, and in particular, the group you think you belong to, is thinking. And many people do not speak up. Mostly those with strong (often selfish) interests speak up, and often in a manipulative way. Having narcissist or sociopaths as leader can indeed be a bad thing. Some sort of media control is good, to protect core values, to protect the law against mass manipulation.

Using em dash is just fine. Academic writing teached me using it. However, I have to admit that use of AI is accelerating its „adoption“.

Have the problem for YouTube now for several minutes

Having a close look at the problems to be solved should be the first step. Also, Africa is big and rather heterogeneous. AI can help but is no silver bullet.

It depends on how you define testing now: Property-based testing would test sets of behaviors. The main idea is: Formalize your goal before implementing. So specification driven development would be the thing to aim for. And at some point we might be able to model check (proof) the code that has been generated. Then we are the good old idea of code synthesis.

Don't worry, you're going to be searching for logic vs requirements mismatches instead if the thing provides proofs.

That means, you have to understand if it is even proving the properties you require for the software to work.

It's very easy to write a proof akin to a test that does not test anything useful...

No, that misunderstands what a proof is. It is very easy to write a SPEC that does not specify anything useful. A proof does exactly what it is supposed to do.

No, a proof proves what it proves. It does not prove what the designer of the proof intended it to prove unless the intention and the proof align. Proving that is outside of the realm of software.

Yes, indeed, a proof proves what it proves.

You confuse spec and proof.

The reason why property testing isnt used that much is because it is useful at catching tests only for a specific type of code which most people arent writing.

I'm not sure that's true. In essence, property tests are a method for defining types where a language lacks natural expression. In a vacuum, nearly all code could benefit from (more advanced) types. But:

1. Tradeoffs, as always. The more advanced typing you head towards, the much more time consuming it becomes to reason about the program. There is good reason for why even the most staunch type advocates rarely push for anything more advanced than monads. A handful of assertive tests is usually good enough, while requiring significantly less effort.

2. Not just time consuming, but often beyond comprehension. Most developers just don't know how to think in terms of formal proofs. Throw a language with an advanced type system, like Coq or Idris, in from of them and they wouldn't have a clue what to do with it (even ignoring the unfamiliar syntax). And with property tests, now you're asking them to not only think in advanced types, but to also effectively define the types themselves from scratch. Despite #1, I fully expect we would still see more property testing if it weren't for this huge impediment.

>Most developers just don't know how to think in terms of formal proofs

Formal proofs are useful on the same class of bug property tests are.

And vice versa.

The issue isnt necessarily that devs cant use them, it's that the problems they have which cause most bugs do not map on to the space of "what formal proofs are good at".

What do you consider to be the source of most bugs?

Just try and VW ID7 or Audi A6 etron.