1.1--- a/hello-world.org	Tue Dec 12 21:50:58 2023 -0500
     1.2+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
     1.3@@ -1,90 +0,0 @@
     1.4-{{{header(hello world,
     1.5-Richard Westhaver,
     1.6-ellis@rwest.io)}}}
     1.7-#+options: toc:t h:1
     1.8-* Introduction
     1.9-Hello World,
    1.10-
    1.11-I've worked in and around software systems for many years. Throughout
    1.12-my journey I've worked with some incredibly capable programmers,
    1.13-leaders, sales professionals, and curious minds from all walks of
    1.14-life. I've been fortunate to witness some highly effective teams on
    1.15-complex projects deliver under impossible constraints. I've also seen
    1.16-the other side - where a team isn't effective for one reason or
    1.17-another, even on simple problems.
    1.18-
    1.19-My work as of late is stemmed from the simple premise that there
    1.20-exists an /environment/ in which a team can be highly effective. My
    1.21-goal is to find those local optimums in my areas of interest where
    1.22-such an environment can be built and /great work/ can be done.
    1.23-
    1.24-In my professional experience, it is becoming much more difficult to
    1.25-build an /environment/ where people can be effective. There are
    1.26-several contributing factors which muddy the waters but it all boils
    1.27-down to capabilities and politics.
    1.28-
    1.29-Your environment must be capable. It must provide everything your team
    1.30-needs now and /may/ need in the future. If the environment doesn't
    1.31-provide something, you need to provide all building materials for it -
    1.32-/even if you don't know what you're building yet/.
    1.33-
    1.34-To build a capable environment you need to discard politics from your
    1.35-decision-making process. In other words, drop the ego. This requires a
    1.36-high degree of introspection. It's hard enough for individuals, let
    1.37-alone an entire team or company. In the world of software we tend to
    1.38-have two camps - the pro-dev who prefers ergonomic but proprietary
    1.39-tools and the foss-dev who prefers clunky but open-source
    1.40-alternatives. You can't limit your environment based on the camp you
    1.41-align with.
    1.42-
    1.43-* The Compiler Company
    1.44-Without further ado, I'd like to announce /The Compiler Company,
    1.45-LLC/. The purpose of /The Compiler Company/ is to /compile/
    1.46-/companies/.
    1.47-
    1.48-More specifically, I'm writing a software suite which specializes in
    1.49-building environments.
    1.50-
    1.51-The software isn't for everyone - modules will be rewritten
    1.52-frequently, code may be terse in places, with specialized tools,
    1.53-custom compilers, and advanced hardware features. It's for a specific
    1.54-type of programmer - an /operator/ if you will, who may use it for
    1.55-rapid-development of their own programs (or companies). The barrier to
    1.56-entry is high.
    1.57-
    1.58-At this stage, I'm interested in *systems*, *processes*, and
    1.59-*protocols* - not *products* and *services*. /The Compiler Company/'s
    1.60-most valuable assett its ideas. A /demo/ system is being written which
    1.61-serves as a reference implementation but this is currently designed
    1.62-for internal benchmarking.
    1.63-
    1.64-** [[https://compiler.company/docs/core][core]]
    1.65-The =core= is a collection of applications and libraries built from
    1.66-the bottom-up with modularity in mind. It's primarily written in
    1.67-Common Lisp and Rust with minimal external dependencies.
    1.68-
    1.69-*Lisp* is a first-class citizen of our internal environment. We
    1.70-currently rely on the Steel Bank Common Lisp compiler but even if we
    1.71-switch to a different implementation there will always be Lisp. It's
    1.72-our dedicated high-level programming language (and much more, as we'll
    1.73-explain later).
    1.74-
    1.75-*Rust* is second-class. It meets an arbitrary criteria for what I
    1.76-would consider /good enough/ but there are many contenders including
    1.77-C, C++, and Zig. It helps fill the gaps in our Lisp environment which
    1.78-would be extremely difficult to implement from scratch like
    1.79-eliminating GC, compile-time type safety, cross-compilation features,
    1.80-and advanced networking protocols. The community support and my
    1.81-personal experience with the language are also contributing
    1.82-factors. The trade-off is that we need to support another language
    1.83-environment in parallel to Lisp.
    1.84-
    1.85-** [[https://compiler.company/docs/infra][infra]]
    1.86-Unfortunately, ideas can't host themselves. We need a robust
    1.87-infrastructure to compensate for this. The project =infra= contains
    1.88-scripts for building and maintaing the entire corporate
    1.89-infrastructure.
    1.90-
    1.91-We typically host services on Arch Linux. Podman and QEMU are used for
    1.92-virtualization. Modules can be built and deployed separately to make
    1.93-host-migration easier as we expand.