1.1--- a/core/man.org	Sat Sep 07 22:34:47 2024 -0400
     1.2+++ b/core/man.org	Fri Sep 13 21:21:53 2024 -0400
     1.3@@ -17,30 +17,39 @@
     1.4 :PROPERTIES:
     1.5 :ID:       156ffb70-9e00-4532-be47-b921c1825a91
     1.6 :END:
     1.7-Welcome to the core, the software development ecosystem of [[comp:][CC]].
     1.8+Welcome to the *core*, the software development ecosystem of [[comp:][CC]].
     1.9 
    1.10-The idea of a =core= is probably one that you are quite familiar with
    1.11-as a developer of software. It implies something that is fundamental;
    1.12-the 'machine behind the machine', whatever the machine may be.
    1.13+The idea of a =core= is one that is quite common in software
    1.14+design. It implies something that is fundamental - the machine behind
    1.15+the machine, whatever the machine may be.
    1.16 
    1.17 The =core= is often the most important part of your application - the
    1.18 one you want to get right. Where things get tricky is when you have
    1.19-many different applications, all which have a =core=, which you
    1.20-need to get right to avoid embarassment.
    1.21+many different applications, all which have a =core=, which you also
    1.22+need to get right.
    1.23 
    1.24 The natural evolution is to start abstracting away the commonalities
    1.25 between your application core, refactoring them into a new project. As
    1.26-your applications grow, you keep searching for common patterns and
    1.27-refactoring. The circle of life goes on.
    1.28+your applications grow, new patterns appear. You keep searching for
    1.29+common patterns and refactoring. This pattern repeats and all is good
    1.30+and dandy.
    1.31+
    1.32+That is, until your applications start to die. No matter the manner or
    1.33+pace of death, there is a symbiotic link with the =core= that is
    1.34+broken when your application is no longer useful, or there is another
    1.35+application that takes its place. As a result, the parts of your
    1.36+=core= that were heavily influenced by the deceased application start
    1.37+to become less useful too. If left unchecked, your core will turn into
    1.38+bloat.
    1.39 
    1.40 This is *not* how the CC core is developed. Our core does not inherit
    1.41-from applications. It is not a 'top-down' system. Instead, it is built
    1.42-'bottom-up' from scratch and kept insulated (but not completely
    1.43-isolated) from applications.
    1.44+from applications and is not dependent on them. We are not building a
    1.45+'top-down' system. Instead, we build 'bottom-up' from scratch and keep
    1.46+our core insulated (but not completely isolated) from applications.
    1.47 
    1.48-This design decision is rooted in a philosophy which favors the
    1.49-developer, or more specifically the /hacker/ over all other
    1.50-stake-holders in our systems.
    1.51+** On Lisp
    1.52+
    1.53+** On Rust
    1.54 
    1.55 * Overview
    1.56 :PROPERTIES: