Equational

 My summer 2000 lunches were taken sitting under the twin towers in New York. I was there for the recently opened Actant's NY office , and would either have lunch at Battery Park or looking up at the towers. I have sometimes described my work as "if I were an architect, I would design skyscrapers", to then add "it is a pride thing, but also life is short, so let's push things forward". To eat my lunch below the towers, was in part to bask in the marvel of engineering tall buildings, but also to feel the ego that drives us to surpass ourself, and often others too.  These are some pictures of the towers I took: When the towers went down, I truly could not believe it. My old black and white TV had been switched on in the office (in Zug, Switzerland), my colleagues were huddled in front of it, I walked over, to hear someone say "one of the towers is down", to which I answered: "that is not possible, it must be hidden by the other". It was a s...

Not so long ago a good friend of mine mentioned his need for 'formal properties' in his code.   I asked him if he had already made the code purely monadic. He had. "Good", I said, "because the 'cheap route to formal properties' is first to ‘monadize' your code, and then 'reverse it' by bringing in 'co-execution'".  That last part needs some development.  Formal properties are not only about execution, actually mostly not about execution, but more about formal properties of state. So while you do need to show execution invariants, you often much more need to show that the ‘results’ happen within stateful invariants (e.g. of the ledger). The easiest way to do this is to  deconstruct / co-execute the state model backwards. This 'backwards' logic must 'match-up' with the 'forward execution' (monadic) model. My view has always been comonads are easiest for this, especially if your stateful model (e.g. a blockcha...

Dog Drives Car  Silly me shared the following picture with my sister-in-law yesterday, as she was stuck in a massive traffic jam with her dog (in photo) in her mini.  "How did you make the picture" was the question. "PowerPoint" was my reply. I used PowerPoint for that photo because it took me three minutes, and I had a slide deck open. Stop, you might say, this has nothing to do with programming, or software designs! It does if we want to design a software where a dog drives. Yet how would we approach that? Here I tell you how I have designed and communicated designs of 'big and bold' softwares quickly and with good properties. And will also sketch out how to approach exotic requirements, such as dogs driving cars. Arrows Away! Let me show you how I work. This how I use to draw design 28 years ago (from my PhD thesis): This is how I would have drawn that design 18 years ago (~2004): Here I use arrows to represent flows. Arrows are used to capture the Lagran...

Use your brains when developing abstract innovation. It is a game of 'balance': you think-up what is needed, you set goals that take advantage of your thinking, then you work towards your goals. If on the way something does not fit, review your goals or thinking. It is an iterative effort, you try, you repeat, until it works. Here are the three iterative steps in more details: State what you believe is true Express implementation goals that will leverage your beliefs Check consistency of goals with respect to your environment and to underlying beliefs Correct your beliefs if inconsistencies are found between goals and environment Develop towards your implementation goals Check consistency of development with respect to environment and underlying goals and beliefs Correct goals or beliefs if inconsistencies found between development and environment At first, one tends often to 'juggle' and develop just one idea at a time, when developing this way. Yet with experience it ...