changelog shortlog graph tags branches changeset files revisions annotate raw help

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

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