Approaches

Dispatch tables (Python dictionaries)

The dispatch-table approach scattered data into many dictionaries acting as key-value maps, for example:

os_to_inception.py:

OS_TO_INCEPTION = {
    OS.CPM: 1974,
    OS.NETBSD: 1993,
    OS.PCDOS: 1981
}

os_to_platforms.py:

OS_TO_PLATFORMS = {
    OS.CPM: frozenset({Platform.I8080, Platform.I8085, Platform.I8086, Platform.M68K, Platform.Z80, Platform.Z8K}),
    OS.NETBSD: frozenset({Platform.ALPHA, Platform.ARM, Platform.M68K, Platform.MIPS, Platform.PARISC, Platform.SUPERH, Platform.VAX, Platform.X86, Platform.RISCV}),
    OS.PCDOS: frozenset({Platform.X86}),
}

os_to_proglangs.py:

OS_TO_PROGLANGS = {
    OS.CPM: frozenset({ProgLang.ASM, ProgLang.PLM}),
    OS.NETBSD: frozenset({ProgLang.ASM, ProgLang.C}),
    OS.PCDOS: frozenset({ProgLang.ASM, ProgLang.C}),
}

main.py:

def os_to_str(os: OS) -> str:
    inception = OS_TO_INCEPTION[os]
    return f"{os.value}@{inception}"


if __name__ == '__main__':
    print(list(map(os_to_str,OS)))

The main advantage is that the data is decoupled. We can add another key-value map without editing existing code (the Open—Closed Principle). os_to_str depends only on the map it needs, not on the rest.

The disadvantage is that the data is scattered (low cohesion). For example, adding a new OpenBSD entry requires editing four files.

Python dataclass

We can put all attributes into a dataclass.

kb.py:

OSES = [
    OS(name="CP/M",
       inception=1974,
       platforms=frozenset({Platform.I8080, Platform.I8085, Platform.I8086, Platform.M68K, Platform.Z80, Platform.Z8K}),
       proglangs=frozenset({ProgLang.ASM, ProgLang.PLM}),
    ),
    OS(name="NetBSD",
       inception=1993,
       platforms=frozenset({Platform.ALPHA, Platform.ARM, Platform.M68K, Platform.MIPS, Platform.PARISC, Platform.SUPERH, Platform.VAX, Platform.X86, Platform.RISCV}),
       proglangs=frozenset({ProgLang.ASM, ProgLang.C}),
    ),
    OS(name="PC-DOS",
       inception=1981,
       platforms=frozenset({Platform.X86}),
       proglangs=frozenset({ProgLang.ASM, ProgLang.C})
    ),
]

main.py:

class NameInception(Protocol):
    @property
    def name(self) -> str: ...

    @property
    def inception(self) -> int: ...


def name_inception_to_str(name_inception: NameInception) -> str:
    return f"{name_inception.name}@{name_inception.inception}"


if __name__ == '__main__':
    print(list(map(name_inception_to_str, OSES)))

This approach has high coherence; for example, adding OpenBSD could be done by editing only one block in one file. However, adding a new attribute requires editing an existing dataclass. To make a function less dependent on the dataclass, a protocol can be used, but it produces more boilerplate.

Clojure map

Using maps to store data and using keywords as keys is idiomatic in Clojure. The code is more concise. However, this approach does not support static type checking. A runtime validator can be used instead, but it is not included in this example.

kb part:

(def oses [{:name "CP/M"
            :inception 1974
            :platforms #{:I8080 :I8085 :I8086 :M68K :Z80 :Z8K}
            :proglangs=#{:ASM, :PLM}}
           {:name "NetBSD"
            :inception 1993
            :platforms #{:ALPHA, :ARM, :M68K, :MIPS, :PARISC, :SUPERH, :VAX, :X86, :RISCV}
            :proglangs #{:ASM, :C}}
           {:name "PC-DOS"
            :inception 1981,
            :platforms #{:X86}
            :proglangs #{:ASM, :C}}])

main part:

(defn name-inception-to-str [{:keys [name inception]}]
  (str name "@" inception))

(println (map name-inception-to-str oses))

Storing all attributes in a Clojure map results in high cohesion, and with dynamic typing, a function does not depend on a type. The code is more concise than the Python dataclass approach. However, adding a new attribute still requires editing the existing file, and there is no static type checking (Typed Clojure can be used instead if static type checking is needed).

Logic (Prolog)

We can store our OS information as Prolog facts. In this example, the facts are grouped by OS, which leans toward the dataclass approach; however, we can also group facts by their predicates (e.g., platform, proglang), which would lean more toward the dispatch table approach.

% CP/M
name(cpm,"CP/M").
inception(cpm,1974).
platform(cpm,i8080).
platform(cpm,i8085).
platform(cpm,i8086).
platform(cpm,m68k).
platform(cpm,z80).
platform(cpm,z8k).
proglang(cpm,asm).
proglang(cpm,plm).

% NetBSD
name(netbsd,"NetBSD").
inception(netbsd,1993).
platform(netbsd,alpha).
platform(netbsd,arm).
platform(netbsd,m68k).
platform(netbsd,mips).
platform(netbsd,parisc).
platform(netbsd,superh).
platform(netbsd,vax).
platform(netbsd,x86).
platform(netbsd,riscv).

% PC-DOS
name(pcdos,"PC-DOS").
inception(pcdos,1981).
platform(pcdos,x86).
proglang(pcdos,asm).
proglang(pcdos,c).

main :- forall((name(OS, Name), inception(OS, Year)),
           format("~w@~w~n", [Name, Year])).

In the Prolog example, we use a rule to produce strings of name and inception instead of a function. The rule is concise and does not depend on unnecessary facts.

The advantage of Prolog is that we can switch between higher cohesion and lower coupling just by changing the way we group the facts, while every fact stays the same.

Since few people are familiar with Prolog, Datalog adapted to Python or Clojure can be used instead, but it would be harder to get accepted than a more idiomatic approach.

1.1 The Decomposition Problem

A subsystem decomposes a codebase into smaller, cohesive units. Two primary axes of decomposition exist:

• Technical axis: grouping by component type (controller, service, model, view)
• Functional axis: grouping by business capability (cataloguing, circulation, etc.)

1.2 Tension Between Framework Prescriptions and Decomposition Strategy

Organizing top-level subsystems functionally may create friction with frameworks that prescribe a technical-first structure. Concrete examples:

• Rails enforces model, view, and controller directories at the root level, making functional decomposition awkward without additional mechanisms like Rails Engines
• Sinatra (a microframework) imposes minimal structure, leaving architectural decisions entirely to the team

Frameworks with rigid prescriptions constrain architectural choices. Frameworks with no structure shift the entire burden onto the team with no guidance. This second approach might be fine for teams that know what they are doing and how to shape the architecture properly. Not everyone needs guidance from the framework.

1.3 Contexts as a Middle Ground

Phoenix provides contexts as a compromise:

• Explicit, guideline-oriented subsystems that enable functional decomposition without rigid enforcement
• Contexts define functional boundaries while allowing technical organization to remain nested within them
• Functional blocks may later evolve into microservices, but this is optional
• The same decomposition serves equally well in a modular monolith or a distributed architecture
• The choice depends on team needs, scaling requirements, and operational maturity, not on the decomposition strategy itself

2. Pipeline Topology and Data Flow

2.1 The Unix Pipeline Model

Unix pipelines model data flow through a single stream connecting stdout to stdin. This forms a linear chain where each stage's output becomes the next stage's input. Key characteristics:

• Each stage has exactly one input and one output
• Cognitive overhead is minimized because the topology is trivial to trace
• The linear, single-stream characteristic is not mandatory for a pipeline, but it reduces complexity significantly

2.2 Arbitrary DAG Topologies

Orchestrators like Airflow allow arbitrary DAG topologies with fan-in and fan-out edges. Tradeoffs:

• Powerful for expressing complex dependencies
• DAGs with dense interconnections tend to become hard to read even with visual rendering
• Complex function-call topologies with many parameters outside Airflow and Unix pipelines also produce unreadable code

2.3 Byte Streams and Opaque Containers

Unix-like pipelines connect programs by passing data through unidirectional byte-streams:

• Programs at each end agree on a structure such as JSON, CSV, or tar archives
• The pipe mechanism itself transports only raw bytes
• This has a direct analogue in dynamically typed languages: in Lisp and Clojure, collections (lists, maps, vectors) serve as opaque containers that can hold almost arbitrary data
• The consumer interprets the contents rather than the container dictating them

3. Typing Heterogeneous Pipeline Data

3.1 The Problem

Strict type systems introduce complications when handling heterogeneous data flowing through a pipeline where each stage transforms the shape slightly.

3.2 Failed Approaches

Single large type with many optional fields:

• Creates dependencies between all pipeline steps
• Loses the ability to reject illegal data
• Makes reuse difficult
• Changes to one field propagate everywhere

Many separate types for each step:

• Exhaustive and adds noise to the program
• Structures may not be mutually exclusive yet are treated as such
• Maintenance burden grows with every new stage

Both approaches fail because each pipeline stage depends on more than it needs.

3.3 Partial Fixes From Functional Programming

Two techniques alleviate but do not fully resolve the problem:

• Functional record update: enables creating modified copies without mutation, reducing coupling related to state changes
• Sum types: restore the ability to discriminate valid from invalid data and support exhaustiveness checking

Remaining limitation: every step that pattern-matches on a sum type must know about all variants. Adding a new case still propagates changes through the pipeline.

3.4 Structural Type Compatibility

Structural type compatibility offers a complementary solution:

• Independently defined types become compatible based on shape alone without requiring any inheritance relationship
• A consumer can specify only the subset of fields it needs via a structural interface
• Each step depends on a minimal projection of the data rather than the full type
• This decouples pipeline stages more effectively than either naive approach or sum types alone

3.5 Python Implementation

Python implements several of these patterns:

• dataclasses.replace(): supports immutable record updates
• The | union operator: simplifies union type expressions
• Protocol classes: enable structural subtyping, allowing independent types to satisfy contracts based on method and attribute signatures
• Tagged unions: modeled using Literal discriminator fields on dataclasses or TypedDicts
• typing.assert_never with mypy: enforces exhaustiveness checking on pattern matching or if chains, providing compile-time guarantees similar to sum types in functional languages

Combined approach:

• Protocols decouple steps through structural conformance
• Tagged unions enable variant discrimination with exhaustiveness checking
• Functional record updates reduce mutation-related coupling

4. Microservices, Processes, and Isolation Patterns

4.1 The Shared Principle: Isolated State by Default

A microservice and a Unix process share architectural similarities:

• Microservices: in well-designed architectures, a service does not share variables or databases with other services. Communication happens through well-defined interfaces. This is a best practice, not a hard technical constraint.
• Unix processes: each process has its own virtual address space and does not share memory directly with other processes. Explicit sharing is possible through mechanisms such as shm_open (POSIX shared memory) or mmap.

4.2 Historical Lineage

Microservices on GNU/Linux are literally processes communicating via HTTP over TCP/IP. The historical chain:

• TCP/IP: first implemented in 4.2BSD Unix in 1983
• HTTP: developed at CERN in 1989 to 1990, building upon these networking foundations
• Tim Berners-Lee wrote the first HTTP server and web browser on a NeXT workstation running NeXTSTEP in fall 1990
• NeXTSTEP was heavily influenced by BSD Unix
• GNU/Linux copied many initial ideas from Unix while remaining free and open

The modern distributed system traces an unbroken lineage back to Unix.

4.3 Pipes as an Alternative to Microservices

Piping via stdin-stdout chains is another mode of interprocess communication:

• Not as powerful or generic as TCP/IP or HTTP
• Easy to use and reason about
• Naturally fits data pipelines
• A data pipeline can be built using command-line tools piped together, running as processes on GNU/Linux instead of using microservices and a full orchestration system
• Scalability can be achieved by SSH and distribution through GNU Parallel, which launches jobs across multiple machines accessed over the network

4.4 Erlang and Clojure as Additional Isolation Models

Erlang processes:

• Lightweight alternative to Unix processes
• Rich high-level interprocess communication via mailbox message passing
• The Erlang VM enforces process isolation as a runtime guarantee

Clojure and other functional runtimes:

• Do not have the same process isolation constraints as the Erlang VM
• Provide lightweight isolation via persistent data structures and Software Transactional Memory (STM)
• STM allows memory sharing while preventing conflicts even when multiple functions run in parallel or concurrently

Bottom Line: Think Twice Before Going Micro

Here is the real talk. You might want to pause before spinning up your first microservice. Ask yourself these questions:

• Do I actually need physical isolation, or will logical separation suffice?
• Can a simple pipe between processes do the job just as well?
• Am I solving a scaling problem that does not exist yet?
• Do I have the ops maturity to handle distributed tracing, service meshes, and deployment pipelines?
• Will my team understand this architecture six months from now?

The truth is, Unix pipes have been doing data transformation reliably since 1973. Erlang processes have handled millions of concurrent connections since the 1980s. Functional isolation with STM has been working since Clojure showed up in 2009. None of these require Kubernetes. None of them need a dedicated platform team. And none of them will haunt you with debugging nightmares at 3am.

Microservices are not evil. They are just heavy. They are the nuclear option for isolation. Use them when the problem demands the weight. Otherwise, reach for the lighter tool. A pipe, a context boundary, a protocol type. Try the easy solution first. If it breaks, then scale up. Most teams never get to that point. And their systems stay simpler, cheaper, and easier to maintain because of it.

So yeah, think twice. Maybe thrice. Then build the smallest thing that could possibly work.

Thanks to the creators of 40ants-mcp, the library provides a nice pattern and code structure that I really like. However, I struggled significantly with installation and getting started. What should have taken minutes ended up taking days.

I'm sharing my experience here so that others who want to build MCP servers in Common Lisp can get started in minutes, not days like I did.

Prerequisites

Before you begin, make sure you have the following installed:

• SBCL – A high-performance Common Lisp compiler
• Roswell – A Common Lisp implementation manager and script runner
• Quicklisp – The de facto package manager for Common Lisp
• Ultralisp – A community-driven distribution of Common Lisp libraries

Installing Ultralisp

In SBCL with Quicklisp, you can enable Ultralisp by:

(ql-dist:install-dist "http://dist.ultralisp.org/" :prompt nil)

(How to install SBCL and Quicklisp is in the appendix.)

The Gotcha: Loading 40ants-mcp

Here's the issue that cost me days: when you try to load 40ants-mcp with:

(ql:quickload :40ants-mcp)

You might encounter errors. The solution is simple but not obvious—load jsonrpc first:

(ql:quickload :jsonrpc)
(ql:quickload :40ants-mcp)

This dependency isn't automatically resolved, which was the source of my frustration.

Creating Your MCP Server

Here's a minimal example from my mcp-exper package:

(in-package :mcp-exper)

(openrpc-server:define-api (mi-tools :title "mi-tools"))

(40ants-mcp/tools:define-tool (mi-tools add) (a b)
  (:summary "just add")
  (:param a integer "a")
  (:param b integer "b")
  (:result text-content)
  (make-instance 'text-content :text (format nil "~a" (+ a b))))

(defun start-server ()
  (40ants-mcp/server/definition:start-server mi-tools))

Key points:

1. Use openrpc-server:define-api to define your API
2. Use 40ants-mcp/tools:define-tool to define tools
3. Return text-content instances for text results (MCP requires specific content types)

Running the Server

Create a Roswell script (mi-mcp-server.ros):

#!/bin/sh
#|-*- mode:lisp -*-|#
exec ros -Q -- $0 "$@"
|#
(progn
  (ros:ensure-asdf)
  #+quicklisp(ql:quickload '(:mcp-exper) :silent t))

(defun main (&rest argv)
  (declare (ignorable argv))
  (mcp-exper:start-server))

Quick Test

Run directly with Roswell:

ros mi-mcp-server.ros

Production Installation

Build and install as an executable:

ros build mi-mcp-server.ros
install -m 0755 mi-mcp-server $HOME/.local/bin/

Make sure $HOME/.local/bin is in your PATH.

Integrating with Opencode

To enable your MCP server in opencode, add this to ~/.config/opencode/opencode.json:

{
    "mcp": {
        "mi-tools": {
            "type": "local",
            "command": ["mi-mcp-server"],
            "enabled": true
        }
    }
}

Conclusion

Building MCP servers with Common Lisp is straightforward once you know the tricks. The 40ants-mcp library is well-designed, and the OpenRPC integration works smoothly.

I hope this guide saves you the days of frustration I experienced. Happy hacking!

The full source code for this example is available at mcp-exper.

Appendix: Installing SBCL

macOS

brew install sbcl

Debian/Ubuntu

apt install sbcl

Arch Linux

pacman -S sbcl

Appendix: Installing Quicklisp

Download and install Quicklisp:

wget https://beta.quicklisp.org/quicklisp.lisp
sbcl --load quicklisp.lisp \
        --eval '(quicklisp-quickstart:install)' \
        --eval '(ql-util:without-prompting (ql:add-to-init-file))' \
        --quit

Thanks to the creators of 40ants-mcp, the library provides a nice pattern and code structure that I really like. However, I struggled significantly with installation and getting started. What should have taken minutes ended up taking days.

I'm sharing my experience here so that others who want to build MCP servers in Common Lisp can get started in minutes, not days like I did.

Prerequisites

Before you begin, make sure you have the following installed:

• SBCL – A high-performance Common Lisp compiler
• Roswell – A Common Lisp implementation manager and script runner
• Quicklisp – The de facto package manager for Common Lisp
• Ultralisp – A community-driven distribution of Common Lisp libraries

Installing Ultralisp

In SBCL with Quicklisp, you can enable Ultralisp by:

(ql-dist:install-dist "http://dist.ultralisp.org/" :prompt nil)

(How to install SBCL and Quicklisp is in the appendix.)

The Gotcha: Loading 40ants-mcp

Here's the issue that cost me days: when you try to load 40ants-mcp with:

(ql:quickload :40ants-mcp)

You might encounter errors. The solution is simple but not obvious—load jsonrpc first:

(ql:quickload :jsonrpc)
(ql:quickload :40ants-mcp)

This dependency isn't automatically resolved, which was the source of my frustration.

Creating Your MCP Server

Here's a minimal example from my mcp-exper package:

(in-package :mcp-exper)

(openrpc-server:define-api (mi-tools :title "mi-tools"))

(40ants-mcp/tools:define-tool (mi-tools add) (a b)
  (:summary "just add")
  (:param a integer "a")
  (:param b integer "b")
  (:result text-content)
  (make-instance 'text-content :text (format nil "~a" (+ a b))))

(defun start-server ()
  (40ants-mcp/server/definition:start-server mi-tools))

Key points:

1. Use openrpc-server:define-api to define your API
2. Use 40ants-mcp/tools:define-tool to define tools
3. Return text-content instances for text results (MCP requires specific content types)

Running the Server

Create a Roswell script (mi-mcp-server.ros):

#!/bin/sh
#|-*- mode:lisp -*-|#
exec ros -Q -- $0 "$@"
|#
(progn
  (ros:ensure-asdf)
  #+quicklisp(ql:quickload '(:mcp-exper) :silent t))

(defun main (&rest argv)
  (declare (ignorable argv))
  (mcp-exper:start-server))

Quick Test

Run directly with Roswell:

ros mi-mcp-server.ros

Production Installation

Build and install as an executable:

ros build mi-mcp-server.ros
install -m 0755 mi-mcp-server $HOME/.local/bin/

Make sure $HOME/.local/bin is in your PATH.

Integrating with Opencode

To enable your MCP server in opencode, add this to ~/.config/opencode/opencode.json:

{
    "mcp": {
        "mi-tools": {
            "type": "local",
            "command": ["mi-mcp-server"],
            "enabled": true
        }
    }
}

Conclusion

Building MCP servers with Common Lisp is straightforward once you know the tricks. The 40ants-mcp library is well-designed, and the OpenRPC integration works smoothly.

I hope this guide saves you the days of frustration I experienced. Happy hacking!

The full source code for this example is available at mcp-exper.

Appendix: Installing SBCL

macOS

brew install sbcl

Debian/Ubuntu

apt install sbcl

Arch Linux

pacman -S sbcl

Appendix: Installing Quicklisp

Download and install Quicklisp:

wget https://beta.quicklisp.org/quicklisp.lisp
sbcl --load quicklisp.lisp \
        --eval '(quicklisp-quickstart:install)' \
        --eval '(ql-util:without-prompting (ql:add-to-init-file))' \
        --quit

Bash Example

I wrote a Bash script consisting of four files:

a.bash

a.bash orchestrates everything. “Orchestration” might be too grand a word for these toy scripts, but I want to convey that it performs a role similar to Apache Airflow.

#!/bin/bash

. ./b.bash
. ./c.bash
. ./d.bash

init
print_count
inc
print_count

b.bash

b.bash contains only one function, inc, which increments the counter, which is the global variable in this example.

inc() {
    counter=$((counter + 1))
}

c.bash

c.bash contains print_count, which simply displays the value of the global variable counter.

print_count() {
    echo $counter
}

d.bash

In Bash, counter can be initialized globally from within a function by default.

init() {
    counter=1
}

Python Example

The following section shows the result of porting the Bash script above to Python, highlighting the key differences.

a.py

This is the orchestration part. Note the use of namespaces or module names.

import c, b, d

d.init()
c.print_count()
b.inc()
c.print_count()

b.py

In the Python version, inc must refer to the module d to access the variable. Alternatively, counter could be explicitly imported.

import d

def inc():
    d.counter += 1

c.py

Similarly, print_count in Python must also refer to module d.

import d

def print_count():
    print(d.counter)

d.py

Unlike in Bash, initializing a global variable from within a function—even in the same module—requires an explicit global declaration.

def init():
    global counter
    counter = 1

Key Differences

As you can see, a global variable in Bash is truly global across files. In Python, however, a global variable is only global within its module, i.e., file. Furthermore, mutating a global variable in Bash requires no special syntax, whereas in Python a function must explicitly declare global to modify a module-level variable.

Consequently, although both are called “global variables,” Python's are scoped to the module. This means they won’t interfere with variables in other modules unless we deliberately make them do so. For developers who use one class per module, a Python global variable behaves much like a class variable. Additionally, variable assignment inside a Python function is local by default, preventing accidental modification of global state unless explicitly intended.

In short, many traditional precautions about global variables in languages like Bash or MBASIC no longer apply in Python. Therefore, we might reconsider automatically rejecting global variables based on past advice and instead evaluate their use case thoughtfully.

It retains explicit calls to configure and make, preserving the transparency of a manual installation. This demonstrates that while increased abstraction can make code shorter, it can also hinder understanding.

Another potential advantage of greater abstraction is the ability to change the configure command for every package by modifying just one location. However, since GNU Autotools has continued to use the configure command for decades, it may not be worth sacrificing clarity for this particular benefit.

Expanding Emacs functionality is as simple as defining a new function instead of creating an entire extension package, as is often done in many other extensible editors. This function can then be re-evaluated, tested, and modified entirely within Emacs using just a few clicks or keyboard shortcuts, with no need to restart or reload Emacs.

An actively-maintained-implementation, long-term-stable-specification programming language

There are many programming languages that don't change much, including Common Lisp, but Common Lisp implementations continue to be developed. For example, SBCL (Steel Bank Common Lisp) released its latest version just last month.

Common Lisp can be extended through libraries. For example, cl-interpol enables Perl-style strings to Common Lisp without requiring a new version of Common Lisp. cl-arrows allows Common Lisp to create pipelines using Clojure-style syntax without needing to update the Common Lisp specification. This exceptional extensibility stems from macro and particularly reader macro support in Common Lisp.

Feature-packed

Common Lisp includes many features found in modern programming languages, such as:

• Garbage collection
• Built-in data structures (e.g., vectors, hash tables)
• Type hints
• Class definitions
• A syntactic structure similar to list comprehensions

Multi-paradigm

While Lisp is commonly associated with functional programming, Common Lisp doesn't enforce this paradigm. It fully supports imperative programming (like Pascal), and its object-oriented programming system even includes advanced features. Best of all, you can freely mix all these styles. Common Lisp even embraces goto-like code via TAGBODY-GO.

Performance

Common Lisp has many implementations, and some of them, such as SBCL, are compilers that can generate efficient code.

With some (of course, not all) implementations, many programs written in dynamic programming languages run slower than those in static ones, such as C and Modula-2.

First, an example of the generated assembly will be shown, along with more explanation about why it might be slowed down by some dynamic implementations

The code listing below is a part of a program written in Modula-2, which must be easy to read by programmers of languages in the extended ALGOL family.

    TYPE
      Book = RECORD
        title: ARRAY[1..64] OF CHAR;
        price: REAL;
      END;

    PROCEDURE SumPrice(a, b: Book): REAL;
    BEGIN
      RETURN a.price + b.price;
    END SumPrice;

The code is mainly for summing the price of books, and only the part 'a.price + b.price' will be focused on.

'a.price + b.price' is translated into X86-64 assembly code list below using the GNU Modula-2 compiler.

    movsd   80(%rbp), %xmm1
    movsd   152(%rbp), %xmm0
    addsd   %xmm1, %xmm0

“movsd 80(%rbp), %xmm1' and 'movsd 152(%rbp), %xmm0' are for loading 'prices' to registers '%xmm1' and '%xmm0', respectively. Finally, 'addsd %xmm1, %xmm0' is for adding prices together. As can be seen, the prices are loaded from exact locations relative to the value of the '%rbp' register, which is one of the most efficient ways to load data from memory. The instruction 'addsd' is used because prices in this program are REAL (floating point numbers), and '%xmm0', '%xmm1', and 'movsd' are used for the same reason. This generated code should be reasonably efficient. However, the compiler needs to know the type and location of the prices beforehand to choose the proper instructions and registers to use.

In dynamic languages, 'SumPrice' can be applied to a price whose type is an INTEGER instead of a REAL, or it can even be a string/text. A straightforward implementation would check the type of 'a' and 'b' at runtime, which makes the program much less efficient. The checking and especially branching can cost more time than adding the numbers themselves. Moreover, obtaining the value of the price attribute from 'a' and 'b' might be done by accessing a hash table instead of directly loading the value from memory. Of course, while a hash-table has many advantages, it's less efficient because it requires many steps, including comparing the attribute name and generating a hash value.

However, compilers for dynamic languages can be much more advanced than what's mentioned above, and SBCL is one such advanced compiler. SBCL can infer types from the code, especially from literals. Moreover, with information from type hints and 'struct' usage, SBCL can generate code that's comparably as efficient as static language compilers.

Given, the Common Lisp code listing below:

    (defstruct book
      title
      (price 0 :type double-float))

    (declaim (ftype (function (book book) double-float) add-price)
         (optimize (speed 3) (debug 0) (safety 0)))
    (defun add-price (a b)
      (+ (book-price a)
         (book-price b)))

SBCL can generate assembly code for '(+ (book-price a) (book-price b))' as shown below:

    ; 86:       F20F104A0D       MOVSD XMM1, [RDX+13]
    ; 8B:       F20F10570D       MOVSD XMM2, [RDI+13]
    ; 90:       F20F58D1         ADDSD XMM2, XMM1

The assembly code format is slightly different from the one generated by the GNU Modula-2 compiler, but the main parts, the 'MOVSD' and 'ADDSD' instructions and the use of XMM registers—are exactly the same. This shows that we can write efficient code in Common Lisp at least for this case. This shows that we can write efficient code in Common Lisp, at least in this case, that is as efficient as, or nearly as efficient as, a static language.

This implies that Common Lisp is good both for high-level rapid development and optimized code, which has two advantages: (1) in many cases, there is no need to switch between two languages, i.e., a high-level one and a fast one; (2) the code can be started from high-level and optimized in the same code after a profiler finds critical parts. This paradigm can prevent premature optimization.

Interactive programming

Interactive programming may not sound familiar. However, it is a common technique that has been used for decades. For example, a database engine such as PostgreSQL doesn't need to be stopped and restarted just to run a new SQL statement. Similarly, it is akin to a spreadsheet like Lotus 1-2-3 or Microsoft Excel, which can run a new formula without needing to reload existing sheets or restart the program.

Common Lisp is exceptionally well-suited for interactive programming because of (1) integrated editors with a REPL (Read Eval Print Loop), (2) the language's syntax, and (3) the active community that has developed libraries specifically designed to support interactive programming.

Integrated editors with a REPL

With an integrated with a REPL, any part of the code can be evaluated immediately without copying and pasting from an editor into a REPL. This workflow provides feedback even faster than hot reloading because the code can be evaluated and its results seen instantaneously, even before it is saved. There are many supported editors, such as Visual Studio Code, Emacs, Neovim, and others.

the language's syntax

Instead of marking region arbitrarily for evaluating, which is not very convenient when it is done every few seconds, in Common Lisp, we can mark a form (which is similar to a block in ALGOL) by moving a cursor to one of the parentheses in the code, which is very easy with structural editing, which will be discussed in the next section.

Moreover, even a method definition can be evaluated immediately without resetting the state of the object in Common Lisp. Since method definitions are not nested in defclass, this allows mixing interactive programming and object-oriented programming (OOP) smoothly.

Here's the corrected code listing:

    (defclass toto ()
      ((i :initarg :i :accesor i)))

    (defmethod update-i ((obj toto))
      (setf (i obj) (+ i obj) 1))

According to the code listing above, the method 'update-i' can be redefined without interfering with the pre-existing value of 'i'.

Structural editing

Instead of editing Lisp code like normal text, tree-based operations can be used instead, such as paredit-join-sexps and paredit-forward-slurp-sexp. Moving cursor operations, such as paredit-forward, which moves the cursor to the end of the form (a block). These structural moving operations are also useful for selecting regions to be evaluated in a REPL.

Conclusion

In brief, Common Lisp has unparalleled combined advantages, which are relevant to software development especially now, not just an archaic technology that just came earlier. For example, Forth has a long-term-stable specification, and works well with interactive programming, but it is not designed for defining classes and adding type hints. Julia has similar performance optimization and OOP is even richer, but it doesn't have a long-term-stable specification. Moreover, Common Lisp's community is still active, as libraries, apps, and even implementations continue to receive updates.

No one actually cares about my programming environment journey, but I’ve often been asked to share it, perhaps for the sake of social media algorithms. I post it here, so later, I can copy and paste this conveniently.

My first computer, in the sense that I, not someone else, made the decision to buy it, ran Debian in 2002. It was a used Compaq desktop with a Pentium II processor, which I bought from Zeer Rangsit, a used computer market that may be the most famous in Thailand these days. When I got it home, I installed Debian right away. Before I bought my computer, I had used MBasic, mainly MS-DOS, Windows 3.1 (though rarely), and Solaris (remotely). For experimentation, I used Xenix, AIX, and one on DEC PDP-11 that I forgot.

Since I started with MBasic, that was my first programming environment. I learned Logo at a summer camp, so that became my second. Later, my father bought me a copy of Turbo Basic, and at school, I switched to Turbo Pascal.

After moving to GNU/Linux, I used more editors instead IDEs. From 1995 to 2010, my editors were pico, nvi, vim, TextMate, and Emacs paired with GCC (mostly C, not C++), PHP, Perl, Ruby, Python, JavaScript, and SQL. I also used VisualAge to learn Java in the 90s. I tried Haskell, OCaml, Objective C, Lua, Julia, and Scala too, but it was strictly for learning only.

After 2010, I used IntelliJ IDEA and Eclipse for Java and Kotlin. For Rust (instead of C), I used Emacs and Visual Studio Code. I explored Racket for learning purposes, then later started coding seriously in Clojure and Common Lisp. I tried using Vim 9.x and Neovim too, they were great, but not quite my cup of tea.

In 2025, a few days ago, I learned Smalltalk with Pharo to deepen my understanding of OOP and exploratory programming.

Update 2025/07/20: I forgot to mention xBase. In the '90s, I used it in a programming competition, but none of my programs in xBase reach production.

I've been told to avoid linked lists because their elements are scattered everywhere, which can be true in some cases. However, I wonder what happens in loops, which I use frequently. I tried to inspect memory addresses of list elements of these two programs run on SBCL.

CL-USER> (setq *a-list* (let ((a nil)) (push 10 a) (push 20 a) (push 30 a) a))
(30 20 10)
CL-USER> (sb-kernel:get-lisp-obj-address *a-list*)
69517814583 (37 bits, #x102F95AB37)
CL-USER> (sb-kernel:get-lisp-obj-address (cdr *a-list*))
69517814567 (37 bits, #x102F95AB27)
CL-USER> (sb-kernel:get-lisp-obj-address (cddr *a-list*))
69517814551 (37 bits, #x102F95AB17)
CL-USER> (sb-kernel:get-lisp-obj-address (cddr *a-list*))
69517814551 (37 bits, #x102F95AB17)

CL-USER> (setq *a-list* (let ((a nil))
			  (push 10 a)
			  (push 20 a)
			  (push 30 a) 
			  a))
(30 20 10)
CL-USER> (sb-kernel:get-lisp-obj-address *a-list*)
69518319943 (37 bits, #x102F9D6147)
CL-USER> (sb-kernel:get-lisp-obj-address (cdr *a-list*))
69518319927 (37 bits, #x102F9D6137)
CL-USER> (sb-kernel:get-lisp-obj-address (cddr *a-list*))
69518319911 (37 bits, #x102F9D6127)

In both programs, the list elements are not scattered. So, if scattered list elements were an issue for these simple cases, you probably used the wrong compiler or memory allocator.