[nigel_bree]

Hey Nils, love your work - back around '90 when I joined Mark Williams I was a big Scheme fan, so your whole t3x.org site and "Scheme 9 from Empty Space" particularly puts a smile on my dial.

I do think the fact that Coherent really hewed 100% to the original V6 approach based on the basic design constraints of bootstrapped minimalism was part of the charm. Doing the 4.0 release process I really pushed myself hard to get as much POSIX compatibility in as humanly possible, but the balancing act was the size-coding part - making /bin/sh still be 16-bit while having $(()) and shell functions and able to process those insane MB-sized GNU autoconf scripts that embedded >64kb here documents, etc. Another big part of why the size-coding style mattered was keeping the system comprehensible since with only a few developers everyone was spread so thin, but that's again part of the fascination.

I've always wanted to give Coherent a bit of a conceptual reboot for modern x86 (particularly multicore, which means a complete new kernel) but staying to the 16/32-bit size and with a style similar to your books walking through the process of making it and how all the design choices need to interlock to make that possible is something I wish I had the free time for.

[nils-m-holm]

Thanks, and always good to hear stories from Mark Williams! The minimalism of Coherent 3.x indeed gave it a special place in my heart. I still have a virtual machine image of it, now even with the complete source code.

A book about the internal workings of Coherent would really be cool! Why would you even need to create a new kernel? Just describe what is there. I think it would be a very interesting book (even though the audience might not be very big). Maybe you will have the time to write it some day.

[nigel_bree]

The big thing I think with any book is to aim to inspire people (especially younger ones) to create for themselves, and while there's probably a way to do that with an exegesis of the existing source I don't know what it would be. The approach you take in your books is one that I think is inspiring to people to get them trying these things on their own - which is after all where the real hard learning happens.

That's particularly true because so many point design decisions made in commercial codebases like Coherent were conditional on a wider context - both technological and business - that just doesn't exist any more, and that I think gets in the way of helping younger people reaching a deeper understanding and appreciation of the design decisions made.

Recontextualising that code, and re-examining those decisions in the light of the modern day is just more interesting to me, and as well provides the chance to lead people through the process of solving the design problems in a way that's narratively easier to follow. Bootstrapping forces an order on what you do that gives a particular structure to the presentation, while at the same time we have aspirations about what future elements we want to achieve that shape and give context to all kinds of decisions as we work out how to get there.

After showing how to build something today, we can do a compare-and-contrast against the existing Coherent code that's more meaningful, especially because we can then measure the outcomes. Anyone can do (and lots of people do) ill-informed hand-wavy postulations about what-ifs, but the process of actually building things that do work forces your hand in ways that armchair enthusiasts miss.