Thirty-one years ago I had an idea about the future of coding, and since then I've directed my education, research and career towards realizing that vision. I've studied programming languages, compilers, modelling, knowledge representation, design patterns, functional programming, operating-systems, data-structures, and any other subject which I thought would contribute towards my goal. The current manifestation of this idea is called FOAM, the Feature-Oriented Active Modeller (see: foamdev.com). A short video: and a long one: . Besides that, I enjoy 3d printing, camping, playing go, slingshotting, and I coach track & field (pole vault).

hi! foam looks insanely great! why haven’t i heard about it before?

Thanks. When I worked on it at Google we were actively hindered (and prevented from publicising) by competitors, and since I left Google we've been busy using it rather than promoting it. I'm now the CTO of a company called nanopay (nanopay.net), which is using FOAM to create an OS for money. We won the Canadian Blockchain Company of the Year award in 2019. FOAM is ten years old this year. Besides nanopay, and a couple projects by ex-Googlers, it is mostly only used inside of Google.

Interesting! The syntax reminds me of the way components for Vue.js can be defined as Objects (name, data, props, methods, …). I’ve watched the first video. What I don’t quite understand is how code from methods/actions are compiled to Java/Swift/etc. — like one example used a DOM API. My impression was that FOAM might be used for cross-platform code generation but I might be wrong. I see the benefit of defining “implementation-independent” models like that. But I still wonder what FOAM actually does with code.

The syntax is just JSON + functions (although, you can also use XML syntax or GUI syntax, since models are modelled and you can use MVC to decouple their view from their representation). Yes, FOAM is used for cross-platform code generation. This short video shows more of that: For Javascript, since it is a very dynamic language, the class and prototype implementations are created from object and function composition at runtime. No code is ever actually generated. This is what keeps the download size small. For Java and Swift we statically generate code as part of the build process. One of the things' that's unusual about FOAM is that it isn't entirely "implementation-independent". It doesn't mind being merely a 95-98% solution and then leave you to write the last little bit potentially in multiple languages. By not trying to be a 100% solution, it can be much smaller, and the result seems more natural on each target platform. See: https://github.com/foam-framework/foam/wiki/How-FOAM-is-Different

I see! Makes a lot of sense to generate code and allow for extension rather than modification. Modeling is indeed super useful and one way to code less.