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