Domain-Specific Languages (DSL): "Code That Doesn't Look Like Code" in the Backend World

Introduction

In a real-world case, engineer Armin used AI to build a set of infrastructure services at his new company, totaling about 40,000 lines of code (Go + YAML + Pulumi + SDK glue code), of which over 90% was generated by AI. This case involved many terms unfamiliar to beginners: YAML, Pulumi, HCL, Lua, SDK glue code... They're neither Python nor JavaScript, yet they're ubiquitous in backend projects. This article will systematically introduce these technologies from a unified perspective — Domain-Specific Languages (DSL).

Learning Objectives

In backend development, beyond the business logic written in general-purpose programming languages (Python, Go, Java, etc.), there are numerous files and code with different purposes, different syntaxes, but none belonging to general-purpose programming languages. They share a common umbrella concept: DSL (Domain-Specific Language).

After reading this article, you will be able to:

Understand the essential difference between DSL and general-purpose programming languages (GPL)
Master the DSL classification system: data serialization formats, embedded scripting languages, infrastructure definition languages
Distinguish the applicable scenarios of XML, JSON, YAML, TOML, CSV, Protobuf, and other data formats
Understand the design purpose of embedded scripting languages like Lua
Explain the principles and differences between Terraform (HCL) and Pulumi
Understand how the OpenAPI specification and SDK auto-generation work
Judge which types of code are suitable for AI generation

Chapter	Topic	Core Concepts
Chapter 1	DSL overview	DSL vs GPL definitions, classification system, and landscape
Chapter 2	Data serialization formats	XML, JSON, YAML, TOML, CSV, Protobuf, etc.
Chapter 3	Embedded scripting languages	Design philosophy and typical applications of Lua and similar languages
Chapter 4	Infrastructure as Code	Principles and comparison of Terraform (HCL) and Pulumi
Chapter 5	Glue code and SDK generation	OpenAPI specification and client code auto-generation
Chapter 6	AI and DSL	Why AI is particularly good at generating DSL code

1. DSL Overview: Another World Beyond General-Purpose Languages

1.1 What Is a DSL?

DSL (Domain-Specific Language) is a language designed for a specific domain or specific task. In contrast, GPL (General-Purpose Language), such as Python, Java, Go, C++, etc., is designed to solve arbitrary computational problems.

The core differences:

Dimension	GPL (General-Purpose Language)	DSL (Domain-Specific Language)
Design goal	Solve arbitrary computational problems	Solve problems in a specific domain
Expressive range	Turing-complete, can theoretically compute anything	Usually intentionally limited in expressive range
Learning cost	Higher, requires understanding the full language system	Lower, only need to understand domain concepts
Typical examples	Python, Java, Go, C++, JavaScript	SQL, HTML/CSS, Regular expressions, YAML, HCL

You've actually been using DSLs all along:

SQL is a DSL for the database querying domain — you use SELECT * FROM users WHERE age > 18 to query data, rather than manually writing traversal logic in Python
HTML/CSS are DSLs for web structure and styling — you use tags and attributes to describe pages, rather than manipulating pixels in C++
Regular expressions are a DSL for text pattern matching — you use \d{3}-\d{4} to match phone numbers, rather than writing character comparison loops by hand

1.2 DSL Classification

DSLs can be divided into two major categories based on "whether they are Turing-complete":

External DSL

Has independent syntax and parser, not dependent on any general-purpose programming language. The code written by users is processed by a dedicated interpreter or compiler.

Pure data description type: JSON, YAML, XML, TOML, CSV, Protobuf (contains no logic whatsoever)
Query/operation type: SQL, GraphQL, regular expressions (limited logic capability)
Domain modeling type: HCL (Terraform), Dockerfile, Nginx configuration syntax (declaratively describes the state of a specific domain)

Internal DSL (Embedded DSL)

Parasitically lives inside a general-purpose programming language, using the host language's syntax to build domain-specific expressions. The code itself is valid host language code, but reads like a specialized language.

Pulumi (written in TypeScript/Python/Go, but the API design reads like declarative configuration)
Ruby on Rails route definitions (get '/users', to: 'users#index' — valid Ruby code, but reads like configuration)
Test framework assertion syntax (expect(value).toBe(42) — valid JavaScript, but reads like natural language)

1.3 DSL Landscape in Backend Projects

In a typical backend project, you'll encounter the following categories of DSLs:

DSLs in Backend Projects
├── Data Serialization Formats (describe data structures)
│   ├── Text formats: JSON, YAML, XML, TOML, CSV, INI
│   └── Binary formats: Protobuf, MessagePack, Avro, BSON
├── Embedded Scripting Languages (programmable configuration layer)
│   ├── Lua (game engines, Nginx, Redis)
│   ├── GDScript (Godot engine)
│   └── Jsonnet (configuration template generation)
├── Infrastructure and Ops DSLs (declaratively describe system state)
│   ├── HCL (Terraform)
│   ├── Dockerfile / Docker Compose YAML
│   └── Nginx / Apache configuration syntax
└── Interface Description Languages (describe API contracts)
    ├── OpenAPI / Swagger
    ├── Protocol Buffers (.proto files)
    └── GraphQL Schema

With this landscape in mind, the following chapters will unfold each branch one by one.

2. Data Serialization Formats: Describing Structured Data in Text

2.1 What Is Data Serialization?

Serialization is the process of converting in-memory data structures (objects, dictionaries, arrays, etc.) into a storable or transmissible text/byte stream. The reverse process — restoring in-memory data structures from text/byte streams — is called deserialization.

Data serialization formats are the most fundamental category of DSLs — they are pure data description external DSLs with no logic capability, responsible only for statically describing "what the value is."

2.2 Why Do We Need These Formats?

Suppose you've developed a backend service with a database address of localhost:5432. If you hardcode this address in the source code, local development works fine, but when deploying to production, the database address changes to db.prod.company.com:5432, and you'd need to modify the source code and recompile.

The standard engineering practice is: separate variable parameters from code and store them in independent configuration files. The program reads the configuration file at startup and determines its behavior based on the values within.

Beyond configuration, data serialization formats are widely used for: data exchange between systems (API requests/responses), data persistence storage, cross-language communication, and more.

2.3 Human-Readable Text Formats

The following are the most common text serialization formats in engineering, introduced in chronological order.

INI

The earliest configuration format, originating from Windows systems. Simple structure, composed of sections and key-value pairs:

ini

[database]
host = localhost
port = 5432

[server]
debug = true

The advantage is strong readability. The limitation is no support for nested structures or array types, making it unable to express complex configurations. Currently mainly found in legacy systems and some Linux configurations (like php.ini, my.cnf).

CSV

CSV (Comma-Separated Values) is the simplest tabular data format:

csv

name,age,city
Alice,30,Beijing
Bob,25,Shanghai

Each row is a record, with fields separated by commas. CSV is widely used for data import/export, spreadsheet exchange, and data analysis pipelines. Its limitation is that it can only express flat two-dimensional tables, doesn't support nested structures, and has no type information (all values are strings).

XML

XML (eXtensible Markup Language) was born in 1998 and was once the mainstream standard for data exchange:

xml

<?xml version="1.0" encoding="UTF-8"?>
<config>
  <database>
    <host>localhost</host>
    <port>5432</port>
  </database>
  <server>
    <debug>true</debug>
    <allowed_origins>
      <origin>https://example.com</origin>
      <origin>https://app.example.com</origin>
    </allowed_origins>
  </server>
</config>

XML has very strong expressive power, supporting nesting, attributes, namespaces, Schema validation, and other advanced features. But its syntax is verbose — large amounts of opening/closing tags result in a low signal-to-noise ratio, and the experience of writing and reading by hand is poor.

XML is still widely used in:

Java ecosystem (Maven's pom.xml, Spring configuration, Android layout files)
Enterprise web services (SOAP protocol)
Office document formats (.docx, .xlsx are essentially ZIP-compressed collections of XML files)
RSS/Atom feeds, SVG vector graphics

JSON

JSON (JavaScript Object Notation) was born in 2001 and rapidly replaced XML as the de facto standard for Web API data exchange due to its simplicity:

json

{
  "database": {
    "host": "localhost",
    "port": 5432
  },
  "server": {
    "debug": true
  }
}

Its advantages are clear structure and native parsing support in virtually all programming languages. The main drawback is no support for comments, and the numerous brackets and quotes are error-prone when writing by hand. JSON is also the standard format for frontend project configuration (package.json, tsconfig.json).

YAML

YAML (YAML Ain't Markup Language) was also born in 2001 and is currently the most widely used configuration format in the backend and DevOps world. Docker Compose, Kubernetes, GitHub Actions, and other tools all use YAML:

yaml

# Database configuration
database:
  host: localhost
  port: 5432

# Server configuration
server:
  debug: true
  allowed_origins:
    - https://example.com
    - https://app.example.com

Advantages include comment support, concise syntax, and the ability to express complex nested structures. The disadvantage is that it relies on indentation to represent hierarchy — indentation errors cause parsing failures, which is the most common issue for beginners.

Note: YAML's full name "YAML Ain't Markup Language" is a recursive acronym.

TOML

TOML (Tom's Obvious Minimal Language) was born in 2013 and is adopted by Rust's package manager Cargo and Python's pyproject.toml:

toml

[database]
host = "localhost"
port = 5432

[server]
debug = true
allowed_origins = [
  "https://example.com",
  "https://app.example.com"
]

TOML attempts to combine INI's simplicity with YAML's expressiveness while avoiding indentation-sensitivity issues.

2.4 Binary Serialization Formats

The above formats are all human-readable text. For scenarios with higher performance and size requirements, there are also binary serialization formats — they sacrifice readability for smaller sizes and faster parsing speeds.

Format	Developer	Characteristics	Typical Use Cases
Protocol Buffers (Protobuf)	Google	Requires pre-defined `.proto` Schema files, strongly typed, extremely small size	gRPC communication, Google internal services, high-performance microservices
MessagePack	Community	Binary version of JSON-like format, no Schema required	Redis internal encoding, cross-language high-performance communication
Avro	Apache	Supports Schema evolution, suitable for big data scenarios	Hadoop/Kafka ecosystem data serialization
BSON	MongoDB	Binary extension of JSON, supports more data types	MongoDB database internal storage format

Taking Protocol Buffers as an example, you need to define the Schema first:

protobuf

// user.proto
syntax = "proto3";

message User {
  string name = 1;
  int32 age = 2;
  string email = 3;
}

Then the compiler (protoc) automatically generates serialization/deserialization code for various languages. This "define Schema first, then generate code" pattern is consistent with the OpenAPI SDK generation approach introduced later.

2.5 Complete Comparison

Format	Type	Year Born	Readability	Supports Comments	Typical Use Cases
INI	Text	1980s	High	Yes	System configuration, legacy projects
CSV	Text	1972	High	No	Data import/export, spreadsheet exchange
XML	Text	1998	Medium	Yes	Java ecosystem, enterprise web services, document formats
JSON	Text	2001	High	No	Web API data exchange, frontend configuration
YAML	Text	2001	High	Yes	Docker, K8s, CI/CD, backend service configuration
TOML	Text	2013	High	Yes	Rust/Python project configuration
Protobuf	Binary	2008	None	—	gRPC, high-performance microservice communication
MessagePack	Binary	2008	None	—	High-performance cross-language communication
Avro	Binary	2009	None	—	Hadoop/Kafka big data pipelines
BSON	Binary	2009	None	—	MongoDB internal storage

Key takeaway: The essential function of all these formats is the same — converting structured data into a storable, transmissible form. Text formats prioritize human readability and ease of editing; binary formats prioritize parsing performance and transmission size. Which format to choose depends on the trade-offs required by the specific scenario.

3. Embedded Scripting Languages: The Programmable Configuration Layer

3.1 Concept Definition

Python, JavaScript, Go, and similar languages are general-purpose programming languages (GPLs) that can run independently and build complete applications.

In contrast, there is another category of languages specifically designed to be embedded within other host programs, providing programmable extension capabilities for the host program. These are called embedded scripting languages.

The core problem they solve: when static configuration files (YAML/JSON) lack sufficient expressiveness and conditional logic, loops, and other logic are needed, how to achieve dynamic behavior without modifying the host program's source code.

3.2 Lua: The Most Representative Embedded Scripting Language

Lua (meaning "moon" in Portuguese) is an extremely lightweight scripting language; the entire interpreter is only a few hundred KB when compiled. Its design goal is not to run independently, but to serve as an embeddable extension layer.

Typical Lua application scenarios:

Game engines: World of Warcraft's addon system and Roblox's game scripts both use Lua. Game engines implement core rendering and physics computation in C/C++, while delegating frequently-changing parts like level logic and NPC dialogue to Lua scripts. This way, designers can modify game content without recompiling the engine.
Web servers: OpenResty embeds Lua inside Nginx, enabling ops personnel to implement request filtering, rate limiting, authentication, and other logic using Lua scripts without modifying Nginx's C source code.
Databases: Redis supports sending Lua scripts to the server for execution, used to implement composite operations requiring atomicity guarantees (such as "read-then-write").

Here's an example of a Lua script embedded in Nginx (OpenResty):

lua

-- Function: Token authentication for /api/secret path
local uri = ngx.var.uri
local token = ngx.req.get_headers()["Authorization"]

if uri == "/api/secret" and token ~= "Bearer my-secret-token" then
    ngx.status = 403
    ngx.say("Access denied")
    return ngx.exit(403)
end

3.3 Other Embedded Scripting Languages

Language	Host Environment	Typical Use
Lua	Game engines, Nginx (OpenResty), Redis	Game logic, gateway policies, cache operations
VimScript / Lua	Vim / Neovim editor	Editor plugin development
Emacs Lisp	Emacs editor	Editor behavior customization
GDScript	Godot game engine	Game logic scripts
Jsonnet	Kubernetes ecosystem / configuration generation tools	Template-based generation of large numbers of similar JSON/YAML configurations

Key takeaway: Embedded scripting languages occupy the boundary between internal DSL and external DSL in the DSL classification — they are independent languages (with their own syntax and interpreters), but their design goal is to be embedded in host programs rather than independently build applications. They fill the gap between "static configuration files" (pure data description DSLs) and "general-purpose programming languages" (GPLs): when configuration needs to express logic (conditional branching, loops, function calls), embedding a lightweight scripting language is the standard engineering solution.

4. Infrastructure as Code

4.1 What Is "Infrastructure"

In backend engineering, "infrastructure" refers to the underlying resources that applications depend on to run:

Compute resources: Servers (virtual machines or containers)
Data storage: Database instances, object storage buckets
Networking: Firewall rules, load balancers, DNS configuration
Middleware: Message queues, cache clusters

In the cloud computing era, these resources are created and managed through cloud providers' (AWS, Alibaba Cloud, Tencent Cloud) consoles via graphical interfaces.

4.2 Limitations of Manual Management

Manual operations via the console are feasible for small-scale projects, but as project scale grows, the following problems emerge:

Not repeatable: Operations aren't recorded; you can't precisely reproduce the same environment
Not auditable: Can't trace "who changed what configuration, when"
Not collaborative: Operations can't be put under version control or code review
Error-prone: Manual operations in production carry the risk of mistakes

Infrastructure as Code (IaC) has the core idea: declaratively define infrastructure resources using code, giving them version control, automated execution, and repeatable deployment capabilities.

4.3 Terraform

Terraform is the most widely used IaC tool, developed by HashiCorp. It uses the dedicated HCL (HashiCorp Configuration Language).

Terraform adopts a declarative paradigm: users describe the desired end state, and Terraform automatically calculates the operations needed to transition from the current state to the target state.

hcl

# Define a cloud server
resource "aws_instance" "my_server" {
  ami           = "ami-0c55b159cbfafe1f0"  # OS image
  instance_type = "t3.micro"               # Instance type

  tags = {
    Name = "my-first-server"
  }
}

# Define a PostgreSQL database instance
resource "aws_db_instance" "my_database" {
  engine         = "postgres"
  instance_class = "db.t3.micro"
  username       = "admin"
  password       = "please-use-secrets-manager"
}

Execution flow:

bash

terraform plan    # Preview the changes to be made
terraform apply   # Confirm and execute, automatically creating resources on the cloud platform

4.4 Pulumi

Pulumi offers a different approach: directly use general-purpose programming languages (TypeScript, Python, Go, etc.) to define infrastructure, rather than learning the dedicated HCL syntax.

The same server definition, expressed with Pulumi + TypeScript:

typescript

import * as aws from "@pulumi/aws";

const server = new aws.ec2.Instance("my-server", {
    ami: "ami-0c55b159cbfafe1f0",
    instanceType: "t3.micro",
    tags: { Name: "my-first-server" },
});

const bucket = new aws.s3.Bucket("my-bucket", {
    acl: "private",
});

export const serverIp = server.publicIp;

Since it uses general-purpose programming languages, developers can leverage language features like loops, conditional branching, and function abstraction to handle complex infrastructure logic.

4.5 Terraform vs Pulumi Comparison

Dimension	Terraform	Pulumi
Language	HCL (dedicated language)	TypeScript / Python / Go and other general-purpose languages
Learning cost	Need to learn HCL syntax	Use already-mastered programming languages, lower learning cost
Community ecosystem	Very mature, covers nearly all cloud providers	Rapidly growing, but smaller scale than Terraform
Use cases	Ops-team-led standardized infrastructure management	Developer-led projects needing complex logic
AI code generation fit	High (fixed patterns)	Very high (essentially general-purpose language code)

Key takeaway: HCL in IaC tools is a typical external DSL — it has independent syntax and a parser, specifically for declaratively describing infrastructure state. Pulumi adopts an internal DSL strategy — using general-purpose programming language syntax to express domain-specific concepts. Both share the same goal (transforming infrastructure management from manual operations to code-driven), but take different paths (dedicated language vs general-purpose language). Code can be put under Git version control, undergo team review, and be automatically executed and rolled back.

5. Glue Code and SDK Auto-Generation

5.1 What Is Glue Code

In software engineering, glue code refers to code that itself contains no business logic but merely connects two systems or modules.

Typical glue code includes:

HTTP request code written when the frontend calls backend APIs (URL construction, header settings, response parsing)
HTTP client code written when backend service A calls service B's interface
Interface adaptation code between different programming languages

The characteristics of such code: highly repetitive, pattern-fixed, but indispensable.

5.2 OpenAPI Specification and Code Auto-Generation

Since glue code has highly pattern-based characteristics, the engineering world's solution is: first describe API interfaces in a standard format, then use tools to automatically generate client code.

The OpenAPI Specification (formerly Swagger) is the industry standard for describing REST APIs. It uses YAML or JSON format to precisely define API paths, parameters, request bodies, and response structures:

yaml

openapi: 3.0.0
info:
  title: Email Service API
  version: 1.0.0

paths:
  /emails:
    post:
      summary: Send email
      requestBody:
        content:
          application/json:
            schema:
              type: object
              properties:
                to:
                  type: string
                  example: "user@example.com"
                subject:
                  type: string
                body:
                  type: string
      responses:
        '200':
          description: Sent successfully

Based on this specification file, tools like openapi-generator can automatically generate client SDKs in multiple languages:

Python: client.emails.send(to="user@example.com", subject="Hi", body="Hello")
TypeScript: client.emails.send({ to: "user@example.com", subject: "Hi", body: "Hello" })
Go: client.Emails.Send(ctx, &SendEmailRequest{To: "user@example.com", ...})

The generated SDK encapsulates all HTTP request details; callers don't need to care about URL paths, request methods, serialization formats, or other low-level implementation details.

5.2 Revisiting Armin's Case

Returning to the case from the beginning of this article, we can now accurately understand each component:

Component	Nature	Description
Go	Business logic code	Core functionality implementation of the email service
YAML	Configuration files	Service configuration, CI/CD pipeline definitions, OpenAPI specification files
Pulumi	Infrastructure code	Define cloud resources (servers, databases, networking) using Go/TypeScript
SDK glue code	Auto-generated client libraries	Python and TypeScript SDKs auto-generated from the OpenAPI specification

The YAML configuration, Pulumi resource definitions, and SDK glue code are all highly pattern-based code with clear specification constraints — precisely the areas where AI code generation is most capable. Therefore, "90% of 40,000 lines generated by AI" is entirely reasonable.

6. AI and DSL

6.1 AI Code Generation Applicability Analysis

Characteristic Dimension	Suitable for AI Generation	Not Suitable for AI Generation
Pattern level	Highly repetitive, has fixed templates	Requires creative design, no precedent to follow
Specification constraints	Has clear schema or syntax specification	Vague requirements, unclear boundaries
Context dependency	Locally self-consistent, individual definitions don't depend on global understanding	Requires understanding the entire system's architectural intent
Verifiability	Can be automatically validated by tools (e.g., `terraform validate`)	Can only rely on human judgment of design reasonableness

The four categories of technologies introduced in this article — configuration files, embedded scripts, IaC code, and SDK glue code — all share the characteristics in the left column. This explains why AI's code generation effectiveness in these areas is significantly better than for business logic code.

6.2 Evaluation Framework

When judging whether a piece of code is suitable for AI generation, you can reference these three criteria:

Is there an existing specification or schema? — If yes, AI-friendly
Is it a large number of repeated patterns? — If yes, AI-friendly
Can the generated result be automatically verified by tools? — If yes, AI-friendly

Code that satisfies all three criteria (like generating SDKs from OpenAPI specifications, or batch-defining homogeneous resources with Terraform) can heavily rely on AI generation. Code that satisfies none of the criteria (like designing a new distributed consistency protocol) still requires engineers to complete themselves.

7. Glossary

Term	Full Name	Definition
DSL	Domain-Specific Language	A language designed for a specific domain, contrasted with general-purpose programming languages
GPL	General-Purpose Language	A programming language that can solve arbitrary computational problems, e.g., Python, Java, Go
External DSL	External DSL	A domain-specific language with independent syntax and parser, e.g., SQL, HCL, YAML
Internal DSL	Internal DSL / Embedded DSL	A domain-specific expression built using host language syntax, parasitic within a GPL, e.g., Pulumi
Data Serialization	Data Serialization	The process of converting in-memory data structures into a storable or transmissible format
INI	Initialization	The earliest key-value configuration format, originating from Windows systems
CSV	Comma-Separated Values	A plain text tabular format with comma-separated fields
XML	eXtensible Markup Language	A tag-based text data format with strong expressiveness but verbose syntax
JSON	JavaScript Object Notation	A lightweight key-value-based data exchange format, the de facto standard for Web APIs
YAML	YAML Ain't Markup Language	An indentation-based configuration file format, widely used in backend and DevOps
TOML	Tom's Obvious Minimal Language	An explicit-syntax configuration format, commonly used in Rust and Python ecosystems
Protobuf	Protocol Buffers	A binary serialization format developed by Google, requires pre-defined Schema, small size and fast
MessagePack	—	A JSON-like binary serialization format, no Schema required
Lua	—	A lightweight embedded scripting language, commonly used for game engine, web server, and database extensions
IaC	Infrastructure as Code	The engineering practice of defining and managing cloud computing resources with code
Terraform	—	An IaC tool developed by HashiCorp, using the HCL declarative language
HCL	HashiCorp Configuration Language	The dedicated configuration language used by Terraform
Pulumi	—	An IaC tool supporting general-purpose programming languages
OpenAPI	—	The industry standard specification for describing REST API interfaces (formerly Swagger)
SDK	Software Development Kit	A client library that encapsulates API calling details
Glue Code	Glue Code	Adapter code without business logic, used only to connect two systems

Summary

There is a large amount of non-business-logic code in backend engineering. They share a common umbrella concept: DSL (Domain-Specific Language) — languages designed for specific domains, contrasted with general-purpose programming languages.

The DSLs introduced in this article can be categorized into four groups:

Data serialization formats (XML / JSON / YAML / TOML / CSV / Protobuf, etc.) — Pure data description external DSLs, converting structured data into storable, transmissible forms
Embedded scripting languages (Lua, etc.) — Between configuration and general-purpose languages, providing programmable extension capabilities for host programs
Infrastructure definition languages (HCL / Dockerfile, etc.) — Declarative external DSLs describing the desired system state; Pulumi achieves the same goal as an internal DSL
Interface description languages and glue code generation (OpenAPI / .proto) — Automatically generating inter-system connection code through specification descriptions

Understanding the DSL classification framework enables you to quickly identify the nature of "code that doesn't look like code" in backend projects: which category of DSL it belongs to, what domain problem it solves, and why it isn't written in a general-purpose programming language.

At the same time, because DSL code has the characteristics of being highly pattern-based, specification-driven, and automatically verifiable, it is also the most effective application area for current AI code generation technology.

Domain-Specific Languages (DSL): "Code That Doesn't Look Like Code" in the Backend World ​

1. DSL Overview: Another World Beyond General-Purpose Languages ​

1.1 What Is a DSL? ​

1.2 DSL Classification ​

1.3 DSL Landscape in Backend Projects ​

2. Data Serialization Formats: Describing Structured Data in Text ​

2.1 What Is Data Serialization? ​

2.2 Why Do We Need These Formats? ​

2.3 Human-Readable Text Formats ​

2.4 Binary Serialization Formats ​

2.5 Complete Comparison ​

3. Embedded Scripting Languages: The Programmable Configuration Layer ​

3.1 Concept Definition ​

3.2 Lua: The Most Representative Embedded Scripting Language ​

3.3 Other Embedded Scripting Languages ​

4. Infrastructure as Code ​

4.1 What Is "Infrastructure" ​

4.2 Limitations of Manual Management ​

4.3 Terraform ​

4.4 Pulumi ​

4.5 Terraform vs Pulumi Comparison ​

5. Glue Code and SDK Auto-Generation ​

5.1 What Is Glue Code ​

5.2 OpenAPI Specification and Code Auto-Generation ​

5.2 Revisiting Armin's Case ​

6. AI and DSL ​

6.1 AI Code Generation Applicability Analysis ​

6.2 Evaluation Framework ​

7. Glossary ​

Summary ​