changelog shortlog graph tags branches changeset files revisions annotate raw help

Mercurial > org > blog / draft/hello-world.org

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