changelog shortlog graph tags branches changeset files revisions annotate raw help

Mercurial > org > blog / hello-world.org

changeset 17: b6380832df99
parent: 61204f8b2ff8
author: ellis <ellis@rwest.io>
date: Tue, 12 Dec 2023 21:50:58 -0500
permissions: -rw-r--r--
description: update
1 {{{header(hello world,
2 Richard Westhaver,
3 ellis@rwest.io)}}}
4 #+options: toc:t h:1
5 * Introduction
6 Hello World,
7 
8 I've worked in and around software systems for many years. Throughout
9 my journey I've worked with some incredibly capable programmers,
10 leaders, sales professionals, and curious minds from all walks of
11 life. I've been fortunate to witness some highly effective teams on
12 complex projects deliver under impossible constraints. I've also seen
13 the other side - where a team isn't effective for one reason or
14 another, even on simple problems.
15 
16 My work as of late is stemmed from the simple premise that there
17 exists an /environment/ in which a team can be highly effective. My
18 goal is to find those local optimums in my areas of interest where
19 such an environment can be built and /great work/ can be done.
20 
21 In my professional experience, it is becoming much more difficult to
22 build an /environment/ where people can be effective. There are
23 several contributing factors which muddy the waters but it all boils
24 down to capabilities and politics.
25 
26 Your environment must be capable. It must provide everything your team
27 needs now and /may/ need in the future. If the environment doesn't
28 provide something, you need to provide all building materials for it -
29 /even if you don't know what you're building yet/.
30 
31 To build a capable environment you need to discard politics from your
32 decision-making process. In other words, drop the ego. This requires a
33 high degree of introspection. It's hard enough for individuals, let
34 alone an entire team or company. In the world of software we tend to
35 have two camps - the pro-dev who prefers ergonomic but proprietary
36 tools and the foss-dev who prefers clunky but open-source
37 alternatives. You can't limit your environment based on the camp you
38 align with.
39 
40 * The Compiler Company
41 Without further ado, I'd like to announce /The Compiler Company,
42 LLC/. The purpose of /The Compiler Company/ is to /compile/
43 /companies/.
44 
45 More specifically, I'm writing a software suite which specializes in
46 building environments.
47 
48 The software isn't for everyone - modules will be rewritten
49 frequently, code may be terse in places, with specialized tools,
50 custom compilers, and advanced hardware features. It's for a specific
51 type of programmer - an /operator/ if you will, who may use it for
52 rapid-development of their own programs (or companies). The barrier to
53 entry is high.
54 
55 At this stage, I'm interested in *systems*, *processes*, and
56 *protocols* - not *products* and *services*. /The Compiler Company/'s
57 most valuable assett its ideas. A /demo/ system is being written which
58 serves as a reference implementation but this is currently designed
59 for internal benchmarking.
60 
61 ** [[https://compiler.company/docs/core][core]]
62 The =core= is a collection of applications and libraries built from
63 the bottom-up with modularity in mind. It's primarily written in
64 Common Lisp and Rust with minimal external dependencies.
65 
66 *Lisp* is a first-class citizen of our internal environment. We
67 currently rely on the Steel Bank Common Lisp compiler but even if we
68 switch to a different implementation there will always be Lisp. It's
69 our dedicated high-level programming language (and much more, as we'll
70 explain later).
71 
72 *Rust* is second-class. It meets an arbitrary criteria for what I
73 would consider /good enough/ but there are many contenders including
74 C, C++, and Zig. It helps fill the gaps in our Lisp environment which
75 would be extremely difficult to implement from scratch like
76 eliminating GC, compile-time type safety, cross-compilation features,
77 and advanced networking protocols. The community support and my
78 personal experience with the language are also contributing
79 factors. The trade-off is that we need to support another language
80 environment in parallel to Lisp.
81 
82 ** [[https://compiler.company/docs/infra][infra]]
83 Unfortunately, ideas can't host themselves. We need a robust
84 infrastructure to compensate for this. The project =infra= contains
85 scripts for building and maintaing the entire corporate
86 infrastructure.
87 
88 We typically host services on Arch Linux. Podman and QEMU are used for
89 virtualization. Modules can be built and deployed separately to make
90 host-migration easier as we expand.