DEV Community: Server-lab

🧱 Bytecraft — The Missing Layer Between AI and Your Filesystem

Server-lab — Sat, 28 Mar 2026 19:59:49 +0000

We’ve all seen it.

You ask an AI to build something, and it gives you…
a wall of code.

Now you’re stuck:

creating folders manually
copying files one by one
fixing small mistakes
wiring everything together

It works—but it’s friction.

⚠️ The real limitation of AI dev tools

Tools like Google Gemini or Claude are great at generating code…

…but they can’t actually create your project.

They stop at:

“Here’s what your files should look like”

Not:

“Here’s your working project”

🧱 Enter Bytecraft

Bytecraft is a human-readable DSL that turns simple instructions into real files and folders—instantly.

Instead of writing scripts or boilerplate, you describe what you want:

set-working-folder "my-project"

make-folder "src"
make-file "src/main.py" with "print('Hello, world!')"
make-file "README.md" with ---
# My Project

Built with Bytecraft.
---

Then run:

bytecraft project.bc

And just like that:

folders are created
files are written
your project exists

🔍 Why this matters

Bytecraft changes the workflow from:

AI → text → manual setup → working project

to:

AI → Bytecraft script → working project

It’s a small shift—but a powerful one.

⚡ Designed for both humans and AI

Bytecraft is intentionally:

forgiving (no strict quoting rules)
readable (no syntax noise)
predictable (explicit commands)

Which makes it:

perfect for AI to generate reliably

No escaping hell. No weird edge cases.

🧪 Safe by default

Before running anything, you can preview exactly what will happen:

bytecraft --dry-run project.bc

Output:

[DRY RUN] Would create folder: my-project/src
[DRY RUN] Would create file: my-project/src/main.py

No surprises. No risk.

🌐 It even runs remote scripts

bytecraft https://example.com/scaffold.bc

fetched in memory
nothing saved automatically
works with --dry-run

🧠 Bigger picture

Bytecraft isn’t just a DSL.

It’s a bridge between AI and real execution.

Instead of giving AI direct access to your filesystem (which is unsafe), Bytecraft acts as:

a controlled, transparent execution layer

🚀 Where this goes next

Imagine this:

bytecraft ai "make a fastapi app with auth and docker"

AI generates a Bytecraft script
Bytecraft executes it
Your project appears instantly

No setup. No copy-paste.

🧱 Final thought

AI is great at describing projects.

Bytecraft makes them real.

If you're building tools, automating scaffolds, or experimenting with AI workflows, I'd love your thoughts.

This is just the beginning.

Why Your Archives Deserve Better Than Markdown

Server-lab — Wed, 11 Mar 2026 12:56:59 +0000

If you've ever tried to open a document from 15 years ago, you know the anxiety. Will the app still exist? Will the formatting survive? Will a future developer even understand what flavor of syntax was used?

Markdown has become the default for developer documentation — and for good reason. It's lightweight, readable, and widely supported. But "widely supported" is doing a lot of heavy lifting in that sentence. Because the uncomfortable truth is: Markdown has a fragmentation problem, and that makes it a poor choice for anything you want to last.

The Markdown Flavor Problem

Ask ten developers what valid Markdown looks like and you'll get ten slightly different answers. There's:

CommonMark
GitHub Flavored Markdown (GFM)
MultiMarkdown
Pandoc Markdown
Reddit Markdown
...and many more

Each flavor handles edge cases differently — tables, footnotes, nested lists, inline HTML. A document written in GFM today might render incorrectly in a CommonMark parser a decade from now. And critically, there's nothing in the file itself to tell a future reader which flavor was used.

Open a .md file in the year 2045 and good luck knowing what spec it was written against.

Enter Celes

Celes is a tag-based markup language that takes a different approach. Here's what a Celes document looks like:

<!Celes-0.1>
<header -size=1>{Why Archives Matter}
<line>{This is a <bold>{bold} word in a paragraph.}
<list -bullet=circle>{First item}
<list -bullet=circle>{Second item}
<blockquote>{Preserve knowledge for the future.}

It maps cleanly from Markdown concepts but with one critical difference: the version is baked right into the file.

That <!Celes-0.1> declaration at the top tells any future parser, human or machine, exactly what spec was used to write this document. No ambiguity. No guessing.

What Makes Celes Good for Long-Term Archival

1. Explicit versioning

Every Celes file declares its spec version on line one. Future tools can branch their parsing logic by version. Future humans know exactly what they're reading.

2. Unambiguous tag-based syntax

Where Markdown relies on whitespace, indentation, and subtle punctuation rules that vary by flavor, Celes uses a consistent <tag>{content} structure with named attributes like -size=1 or -bullet=circle. There's far less room for parser ambiguity.

3. Plain text at heart

Like Markdown, Celes is plain text. It will open in any text editor in any decade. No proprietary format, no binary encoding, no dependency on a specific application.

4. Convertible

Celes ships with built-in converters to and from Markdown and HTML:

import celes

# Convert Markdown to Celes for archival
celes_output = celes.convert_md_to_celes(my_markdown)

# Convert back to Markdown or render to HTML anytime
html_output = celes.parse_celes(celes_output)

You don't have to abandon your existing Markdown workflow. Convert on the way into the archive.

A Real-World Example

We recently converted the Godot Engine's documentation files — README, AUTHORS, CONTRIBUTING, DONORS — from Markdown to Celes. The conversion was clean, lossless, and the resulting files are self-describing in a way the originals weren't.

A developer in 2045 picking up README.celes will see <!Celes-0.1> and immediately know the rules of the road. The same developer picking up README.md would be left guessing.

Who Should Care About This

Open source projects that want their documentation to outlive any particular platform or toolchain
Libraries and institutions digitizing historical records
Personal knowledge bases and journals you want to read in retirement
Legal and compliance teams storing long-lived documents
Anyone building a time capsule of knowledge

Getting Started

pip install celes

import celes

# Parse Celes to HTML
html = celes.parse_celes(source)

# Convert from Markdown
celes_doc = celes.convert_md_to_celes(markdown_source)

# Convert back to Markdown
md_doc = celes.convert_celes_to_md(celes_source)

The Bottom Line

Markdown is great for today. Celes is designed for decades from now.

If you're building something meant to last — documentation, archives, knowledge bases — the explicit versioning and unambiguous syntax of Celes makes it a more honest choice than hoping the right Markdown flavor is still around when someone needs your files.

The best archive format is one that tells the future exactly how to read it. Celes does that from line one.

Have you thought about the long-term survival of your documentation? Drop your thoughts in the comments.

Getting Started with Stick And String (SAS 1.1) — A Saner Config Format

Server-lab — Thu, 05 Mar 2026 12:32:06 +0000

Getting Started with Stick And String (SAS 1.1) — A Saner Config Format

If you've ever stared at a JSON file wondering why you're missing a comma on line 47, or wrestled with YAML indentation that looks right but somehow isn't — this post is for you.

I built SAS (Stick And String), a human-readable data serialization format designed to be strict, predictable, and free from the quirks that make JSON and YAML frustrating to write by hand. It maps 1:1 with JSON's data model, so you get all the expressiveness without the footguns.

Today I'll walk you through everything you need to know to start using it — the syntax, the libraries, and how to convert your existing JSON files.

Why Another Format?

Quick comparison before we dive in:

JSON — great for machines, annoying for humans. Trailing commas are errors. Comments aren't allowed. Every string needs quotes. One misplaced bracket and the whole file breaks.

YAML — human-friendly on the surface, but indentation-sensitive parsing leads to subtle bugs, and the implicit type coercion (yes becoming true, 1.0 staying a float, etc.) causes real-world headaches.

SAS takes a different approach:

No commas anywhere
No indentation rules (whitespace is ignored structurally)
No implicit type conversion
Named block closers so you always know what you're closing
Comments that just work

Here's what a real config file looks like:

# SAS 1.1 config
__sas_version__ -> "1.1"

app ::
    name -> "myservice"
    version -> "2.4.1"
    debug -> false

    db ::
        host -> "db.internal"
        port -> 5432
        credentials -> null
    :: db

    tags -> ["api" | "production" | "v2"]

    allowed_hosts ::
        - "localhost"
        - "127.0.0.1"
        - "myservice.internal"
    :: allowed_hosts
:: app

Readable, unambiguous, and valid. Let's break down the syntax.

The Syntax in 5 Minutes

Key → Value pairs

Every value is assigned with ->, with exactly one space on each side:

name    -> "Alice"
port    -> 8080
enabled -> true
ratio   -> 3.14
nothing -> null

SAS supports six value types: string, number, boolean, null, object, and array — exactly matching JSON's model.

Strings

Strings use double quotes and support standard escape sequences:

greeting -> "Hello, world!"
path     -> "C:\\Users\\dasso"
tab      -> "column1\tcolumn2"
emoji    -> "\u2728 sparkles"

Need a multiline string? Use triple quotes:

description -> """
This is line one.
This is line two.
Content is preserved exactly as written.
"""

Numbers, Booleans, Null

count    -> 42
negative -> -7
pi       -> 3.14159
mass     -> 1.2e10
active   -> true
disabled -> false
value    -> null

Note: True, False, NULL etc. are parse errors. SAS is strict — lowercase only.

Block Objects

Objects use named open/close pairs:

server ::
    host -> "localhost"
    port -> 8080
:: server

The :: server closer must match the opener exactly. This means you always know at a glance what block you're closing — no more hunting for mismatched brackets. Nesting works as deep as you need:

app ::
    database ::
        primary ::
            host -> "db1.internal"
            port -> 5432
        :: primary
    :: database
:: app

Inline Objects

For small flat objects, there's a compact inline form:

origin  -> { lat -> 37.77 | lon -> -122.41 }
padding -> { top -> 10 | right -> 20 | bottom -> 10 | left -> 20 }

Fields are separated by | (space, pipe, space). No nesting allowed in inline form.

Arrays

Inline arrays work great for scalars:

tags   -> ["api" | "production" | "v2"]
ports  -> [8080 | 8443 | 9000]
flags  -> [true | false | true]

For longer lists or arrays of objects, use block syntax:

servers ::
    - "web1.internal"
    - "web2.internal"
    - "web3.internal"
:: servers

Arrays of objects use anonymous blocks:

users ::
    - ::
        name -> "Alice"
        role -> "admin"
    :: -
    - ::
        name -> "Bob"
        role -> "viewer"
    :: -
:: users

Comments

# This is a comment
    # Leading whitespace is fine too

name -> "Alice"  # THIS IS NOT a comment — inline comments are not allowed

Installation

JavaScript / Node.js

npm install stick-and-string

Python

pip install stick-and-string

Using the JavaScript Library

import { parseSAS, sasToJSON, jsonToSAS } from 'stick-and-string';

// Parse a SAS document into a JS object
const config = parseSAS(`
app ::
    name -> "myservice"
    port -> 8080
    debug -> false
:: app
`);

console.log(config.app.name);  // "myservice"
console.log(config.app.port);  // 8080
console.log(config.app.debug); // false

Converting to JSON:

import { sasToJSON } from 'stick-and-string';
import { readFileSync } from 'fs';

const json = sasToJSON(readFileSync('config.sas', 'utf8'));
console.log(json);
// {
//   "app": {
//     "name": "myservice",
//     "port": 8080,
//     "debug": false
//   }
// }

Converting from JSON:

import { jsonToSAS } from 'stick-and-string';

const sas = jsonToSAS({
  server: {
    host: 'localhost',
    port: 8080,
    tags: ['api', 'v2']
  }
});

console.log(sas);
// __sas_version__ -> "1.1"
//
// server ::
//     host -> "localhost"
//     port -> 8080
//     tags -> ["api" | "v2"]
// :: server

Error handling:

import { parseSAS, SASParseError } from 'stick-and-string';

try {
  parseSAS('name -> "Alice"\nname -> "Bob"\n'); // duplicate key
} catch (e) {
  if (e instanceof SASParseError) {
    console.error(`Parse failed at line ${e.lineNum}: ${e.message}`);
    // Parse failed at line 2: [Line 2] E01: Duplicate key "name"
  }
}

CommonJS:

const { parseSAS, sasToJSON, jsonToSAS } = require('stick-and-string');

Using the Python Library

from sas_tools import parse_sas, sas_to_json, json_to_sas, SASParseError

# Parse SAS → dict
config = parse_sas(open("config.sas").read())
print(config["app"]["name"])  # "myservice"
print(config["app"]["port"])  # 8080

# SAS → JSON string
json_str = sas_to_json(open("config.sas").read())

# dict → SAS string
sas = json_to_sas({
    "server": {
        "host": "localhost",
        "port": 8080,
        "tags": ["api", "v2"]
    }
})
print(sas)

Error handling:

from sas_tools import parse_sas, SASParseError

try:
    parse_sas('name -> "Alice"\nname -> "Bob"\n')
except SASParseError as e:
    print(f"Line {e.line_num}: {e}")
    # Line 2: [Line 2] E01: Duplicate key "name"

The CLI

Both packages install a sas command for use in the terminal or CI pipelines.

Validate a file:

sas validate config.sas
# ✓  Valid SAS 1.1 document: config.sas

Convert SAS → JSON:

sas to-json config.sas
sas to-json config.sas --output config.json
sas to-json config.sas --compact   # minified JSON

Convert JSON → SAS:

sas to-sas data.json
sas to-sas data.json --output data.sas

Round-trip check (great for CI):

sas roundtrip config.sas
# Roundtrip: config.sas  (SAS → JSON → SAS)
#
#   ✓ Parse SAS
#   ✓ Re-encode to SAS and re-parse
#   ✓ Data preserved exactly
#
# ✓  Roundtrip OK

Migrating an Existing JSON File

Got an existing config.json you want to move to SAS? One command:

sas to-sas config.json --output config.sas

The converter handles everything automatically — nested objects become block objects, scalar arrays become inline arrays, large arrays of objects become block arrays with anonymous elements.

Error Codes

SAS parsers never silently skip errors. Every problem comes with a line number and a code:

Code	What it means
E01	Duplicate key in same scope
E02	Block closer doesn't match opener
E03	Unclosed block at end of file
E04	Invalid escape sequence in string
E05	Invalid number (leading zero, `NaN`, etc.)
E06	Wrong-case boolean or null (`True`, `NULL`)
E07	Inline comment
E08	Missing spaces around `->`
E09	Missing spaces around `\
E10	Trailing {% raw %}`\
E11	Non-scalar value in inline array
E12	Nested inline object
E13	Key beginning with {% raw %}`-`
E14	Mixed block content (pairs + array items)
E15	Anonymous closer outside array context

What's Next

The spec, full API docs, and source code are all on GitHub. Both implementations are fully tested — 69 tests for JavaScript, 68 for Python — and the format spec is available as a readable Markdown document in the repo if you want to build your own parser in another language.

GitHub: https://github.com/TheServer-lab/stick-and-string
npm: https://www.npmjs.com/package/stick-and-string
PyPI: https://pypi.org/project/stick-and-string/

Give it a try and let me know what you think in the comments. And if you do build a parser in another language, I'd love to know!

I Built DoScript: An Automation Language Because Bash Was Too Hard

Server-lab — Sun, 15 Feb 2026 12:42:30 +0000

The Problem That Started It All

I wanted to automate tasks. Build installers. Organize files. You know, the stuff we all need to do.

Bash? Too complicated with its cryptic syntax and arcane rules.

PowerShell? Powerful, sure, but felt like learning a new programming language.

Batch files? Outdated and painful to write.

I just wanted to write automation scripts that read like English. Why wasn't there something simple for that?

So I thought: What if I built my own?

Meet DoScript

DoScript is an automation language designed to be as easy as writing English. No cryptic symbols, no confusing syntax—just straightforward commands that do what they say.

Here's what backing up PDFs looks like:

make folder "PDFBackup"

for_each file_in "Documents"
    if_ends_with ".pdf"
        copy {file_path} to "PDFBackup"
    end_if
end_for

say "Backup complete!"

That's it. No pipes, no regex hell, no stackoverflow searches. Just readable automation.

What DoScript Can Do

DoScript handles the automation tasks I actually needed:

File Operations

make folder "ProjectBackup"
copy "report.docx" to "ProjectBackup"
move "old_data.csv" to "Archive"
delete file "temp.txt"

Loops & Conditionals

for_each file_in "Downloads"
    if_older_than {file_name} 30 days
        delete file {file_path}
        say "Deleted old file: {file_name}"
    end_if
end_for

System Operations

run "backup.bat"
open_link "https://example.com"
say "Opening website..."
wait 5 seconds

Data Processing

json_read data from "config.json"
json_get "settings.theme" from data into theme
say "Current theme: {theme}"

Plus: CSV handling, ZIP operations, HTTP requests, random generators, system monitoring, and more.

The Visual IDE

Here's where it gets interesting. I also built a visual node-based IDE for DoScript.

Drag commands, connect them with wires, and build automation workflows visually. When you're done, it generates clean DoScript code you can save and run.

Perfect for:

Visual learners who prefer flowcharts
Designing complex workflows
Learning the language interactively
Prototyping automation quickly

The Honest Truth About How I Built This

Let me be transparent about the development process:

What I designed:

The entire syntax (~90% of the language structure)
Every command and how it should work
The visual IDE concept
The design philosophy: "automation as easy as English"

How I built it:

Most of the Python implementation code was AI-generated
I designed the syntax, AI helped write the interpreter
I tested everything, debugged, and iterated
The visual IDE was coded with AI assistance

I'm not a Python expert. I'm someone who wanted better automation tools and had a clear vision of what the language should look like. AI helped me implement that vision.

My take: You don't need to write every line of code yourself to create something valuable. Good design and clear vision matter more than pure coding prowess.

Real Use Cases

Here are actual things I use DoScript for:

1. Daily File Cleanup

for_each file_in "Downloads"
    if_older_than {file_name} 7 days
        delete file {file_path}
    end_if
end_for

2. Project Backup Automation

make folder "Backup_{today}"
for_each file_in "Projects"
    if_ends_with ".py"
        copy {file_path} to "Backup_{today}"
    end_if
end_for
zip "Backup_{today}" into "Backups/backup_{today}.zip"

3. System Health Check

system_cpu into cpu_usage
system_memory into mem_usage

if greater_than {cpu_usage} 80
    say "Warning: CPU usage high at {cpu_usage}%"
end_if

Try DoScript

GitHub: github.com/TheServer-lab/DoScript

The repository includes:

The Python interpreter (doscript.py)
Visual IDE (single HTML file, runs in browser)
Installer (only 8.5 MB!) - Install once, run .do scripts from any terminal
VS Code extension - Syntax highlighting and support for DoScript files
Example scripts
Full command reference

Quick Start (with installer):

# After installing, just run from anywhere:
do myscript.do

Quick Start (without installer):

python doscript.py myscript.do

Current version: v0.6.6

What's Next?

I'm actively developing DoScript based on what I need and what the community suggests. Some ideas:

More built-in commands
Better error messages
Package manager for sharing scripts
More visual IDE features

Questions I'm Expecting

Q: Why not just learn Bash/PowerShell properly?

A: I did try. For complex automation, they're great. For quick tasks, DoScript is faster and more readable.

Q: Is this production-ready?

A: It works for my daily automation. Use it, break it, tell me what needs fixing.

Q: Can I contribute?

A: Absolutely! It's open source. Ideas, bug reports, and code contributions all welcome.

Q: Why Python as the base?

A: Cross-platform, widely available, and easy to extend.

Final Thoughts

I built DoScript because existing tools felt unnecessarily complex for simple automation. If you've ever felt the same frustration, give it a try.

Is it perfect? No.

Does it solve a real problem? For me, absolutely.

What would YOU automate if the language was this simple?

Drop a comment, star the repo, or just try it out. I'd love to hear what you think.

Built with: Vision (mine), Python (AI-assisted), and a lot of coffee.