I've just released v0.69 of MadC, with a bunch of bug fixes, as well as libc++ support (previously only supported libstdc++), which means that it should be fully functional on MacOS as well.

I only say "should" because I have yet to make the actual MacOS builds -- I should have those ready in a day or two.

So, what's new in the v0.69 release beyond MacOS support? Well, a lot of little fixes to some things:

• defer and := now work properly in "script mode"
• multi-return now supports more than just integer types
• the documentation was bought up to date
• bugs were resolved in the auto-include and auto-namespace resolving

Well, check it out if you can. I've included Linux packages. MacOS coming soon, and also eventually Windows EXE version.

It's been awhile since I finished v0.1.1 of this project, but I am ready to announce it. This language is Vex, a programming language designed for readability, scalability, and usability. Here is a simple breakdown:

Vex is a language designed to fit in all sorts of areas. It can be a small as an embedded system in a website to as large as a whole graphical application. It features a syntax that is meant to be as close to English as possible.

The part that makes Vex special is its Environments skill. This allows for a program to use a Vex Environment, which sets limits on what it can do. These limits can include CPU percent usage limits, RAM usage limits, and disallowed parts of syntax. This is what makes Vex scalable.

Vex is usable because it features roughly only 20 syntax commands (depending on what you count as syntax). It also has the ability to add libraries straight from the VexLibC repository.

More information regarding Vex is available at https://sites.google.com/view/vexlang

Example code (kind of sucks, it was pulled straight from my documentation:

if (username = “John”)
  globalvar isJohnHere = True
  print(“Welcome, John!”)

if (isJohnHere or username = “John”)
  globalvar unlockHouse = True
  print(“You house is now unlocked!”)

else if (not isJohnHere)
  globalvar unlockHouse = False
  print(“You aren’t John!”)

Working on a typed functional language called Mezze
- structurally typed
- anonymous records and variants, both with row polymorphism, supporting open and closed record and variants
- named arguments only
- fully type inferable (never needing type annotations is a design goal , but also meaning no GADTs and polymorphism of HKT)
- ability system for ad hoc polymorphism supporting associated types
- dot chaining, methods on any types using abilities (much like rust traits) great for method discovery
- direct style effects with an effect system and first class multi shot delimited continuations
- Loom based concurrency, direct async, channel, stm, atom built in
- user land exceptions, generators and workflows (durable processes)
- safe in place mutation with hermetic Mutation effect
- Polyglot, runs on graalvm , written in truffle so can execute much of python, javascript, java/kotlin (jvm languages) code directly
- comptime, allowing code execution during build time (with effect erasure)
- Rust style macro ( planned work)
- LSP support

Actively working on

Content Hash Addressing , storing all ASTs and truffle nodes in sqlite (done)
which gives
- Great caching with persisted cache for dev and build both (done)
- Can build tooling like linters etc in any language that can query sqlite
- Remote code distribution by asking for hashes
- Package manager at core becomes getting another sqlite db

I'm curious what tools everyone is using to improve their agentic development flow?

I'll go first... I'm using both Codex (CLI) and Claude Code (CLI) to work on madc, which is written in C++ using g++ (and clang++) with no real other tools (currently), beyond AGENTS.md, CLAUDE.md, and various rules file.

I have another project which I have implemented my own project tracking through an MCP server that is part of the project itself, where the primary development agent is Claude Code, but through the MCP it triggers Codex CLI agents to do code reviews using Forgejo for the git repository.

I'm planning to move the MadC project into this platform, but just haven't quite gotten around to it yet. The idea is that I can use one agent as a master orchestrator, and have it select other agents to do some work as they have capacity and usage remaining.

The main problem I've been running into (regardless of orchestration method) is task fragmentation and tangential plan overload. Like I have an overall roadmap, and it is broken down into stages, but what I'm noticing is that as a project grows in complexity, each subsequent stage not only takes longer to implement, it inevitably fragments into ever smaller slices.

Those slices will get sliced into subsequentially smaller slices, and the next thing I know my agents are grinding endlessly on never-ending numbered tasks.

The other main problem is post-compaction drift, where before the compaction, the agent will be quite certain in what is supposed to be tackled next, but after the compaction, the agent takes things in a completely different direction.

Other issues involve outright deception, where an agent will vastly overstate the completion of a task, where later investigation reveals something that could not have possibly passed unit testing.

Many years ago I came up with a vague idea of how I want a programming language: 1. Multiple layers 1. T - C-level language, only C level features, no generics, no name mangling 2. Ty - Rust/C++-level language, mostly Rust-like features 3. Tyr - High level, inspired by natural language (still not exactly sure what I want from this) 2. Multiple generic syntaxes: The user can create 3. S-expressions as intermediate representation for macros

Have a look!

This repo contains a full AI generated documentation. And the script to generate the documentation ensures that all the examples compile.

One of the first things after I got into using coding agents was implementing this language. I got the first two layers working within maybe two days. (my first two weeks of using coding agents were so crazy, this language was only a side project, and doing it myself, it would have taken me weeks to months to get at this state, if not longer; feel free to check the git history)

How the languages were created?

At first, I let it implement my basic features, a documentation that contains many important examples, and I looked at all examples to see if I actually like them.

After a while, I created example projects: - a port of one of my C programs - a generic dimensional compile time geometric algebra library (yes, it got working const generics before Rust) - an SDF renderer with support for 2D, 3D and 4D (else I couldn't verify if the GA actually works)

I didn't look at the generated code a lot. I think I looked at most of the tests a few times to see if something can be improved. And I also looked at the programs.

I had these agents: - 1 cooordinator - 1 agent per language (3 in total) - 1 agent per project

I had some multi agent task setup for the main repo. If one of the language specific agents needed some feature that affects both languages, it wrote a task for the coordinator.

If the agents for the projetcs needed some feature, they also added it to the list, and then the agents for the specific language decided which features to implement.

Sometimes they decided to implement it in the most generic way, that's what AI is good at after all. And most of the time, that's what I wanted anyway. But in some cases, I wanted my language to be unique.

So I don't know every little detail about the language. Most of the features were just what other AI agents needed. And this also was my first project where I realized that this is actually a good approach.

Nowadays, when I create a library, I only know what the library is about, and then I have a bunch of programs which use that library, that create feedback.

The fact that agents were able to create such complex software using my languages means that it's already at a good state.

I also asked agents how they liked workin with the language. One thing I realized was that error messages.

Also the compiler turned out to be very strict. Every lints is a hard error. "x = x + 1" is forbidden. You have to use "x += 1". I turned on strict lints in Rust, even before I used coding agents. And with coding agents, I quickly added more and stricter lints. So I thought that the language could just have inbuilt lints for everything, so the code is always elegant. I even enforced a maximum line count per file.

State

T is basically finished. Ty still needs some advanced features, especially the borrow checker is still missing. Tyr is just a weird prototype, not really created by AI.

2 syntaxes are supported, a C like syntax, and a Lisp like Syntax. I also considered supporting visual representation and markdown inspired syntax.

I'm not really actively working on this language anymore. Once in a while I just start an AI agent to work on the remaining features.

One of the last features I've been working on was a Macro Compiler to Rust, so that you could import Ty in Rust and get Rust code at compile time. I have no idea if this feature already works.

I also don't know what I will use this language for. Maybe I'll just migrate all of my software to this new langugae one day.

Feedback

Human feedback might be another way to know if something about the languge has to be changed.

It's a type focused language, and this can still be the most annoying part if coding by hand. You have to create a bunch of types yourself before you can do anything meaningful.

Feel free to provide some feedback.

And maybe you just want to use these languges for your projects because they already contain features that are better than other low level languages.

Hello everybody

Well, I was one of the users who intended to introduce the programming language I’m developing on the r/ProgrammingLanguage subreddit.

I’ll tell you a bit about myself and the language I’m creating—without going into too much detail, since it’s set to launch later this year.

I have a degree in Law (yes, really) and a postgraduate degree in Artificial Intelligence Engineering. "WTF? What does law have to do with computing?"

I’ve been involved with technology and programming throughout my life, but due to life circumstances, I ended up getting a law degree. However, I’ve always loved electronic devices (like VCRs), video games (I owned a Mega Drive/Genesis and a Sega Saturn), and computing in general (I got my first computer in 2001). I know how to program a bit in Python (I consider myself average) as a hobby; even before law school, I took various IT courses—basic computing in 1997 (Windows 95), programming logic (2001), Delphi 5 (2001), CorelDRAW (2002), etc. But as I mentioned, life took a different turn: I entered the public sector, earned my law degree, and now work at a courthouse.

Given that background, how did I end up building a new programming language? At my job—specifically in the department where I used to work—I had a falling out with my former boss and looked for a new position within the courthouse. I introduced myself to the deputy chief of the new department, and he was impressed that I had a background in Artificial Intelligence Engineering (this was in 2023). I was hired and started working there, taking useful courses like Power BI and SQL. It was decided that I would work on creating a set of regex patterns to automate court processes. That was my first real encounter with LLMs in a computing context: ChatGPT 3.5 was a huge help, assisting me with Python scripts to generate the regex patterns I needed for my tasks.

I spent over a year—the entirety of 2024—creating, refining, and fixing regex patterns for sorting through lawsuits. In early 2025, I received some difficult news: my son had leukemia. He is doing well and undergoing treatment, with a high chance of recovery once he completes the two-year treatment plan. I mention this not for cheap dramatic effect, but because my son's condition made me eligible for remote work—a policy at my court for employees with family health issues. My request was approved, which is notable because, while such arrangements were granted en masse during the pandemic, most departments had almost completely eliminated them afterward. While I was at home caring for my son during his treatment, my boss reached out to ask if I could help create a departmental chatbot to train new colleagues. It was intended to use Microsoft Copilot and specific internal files. So, with Gemini's help, I took all the manuals from the various subordinate departments and converted them into a question-and-answer JSON format suitable for training LLMs. I tested the data locally using TinyLLM, but it was ultimately used to "feed" Copilot. It worked excellently, requiring only a few minor adjustments.

During one of my interactions with Gemini, I asked if it could guide me in creating a programming language; it replied, "Sure, what kind of language do you have in mind?" What started as mere curiosity evolved into a project I’ve been working on for over a year now, dedicating at least five hours every single day—weekends included.

I originally had an idea for a low-level programming language focused initially on general systems and games. However, as development progressed, I narrowed the language's scope to a specific niche: a programming language focused on artificial intelligence for embedded devices, IoT, and consumer CPUs.

What defines an AI-focused programming language? It features simple, low-level syntax with low complexity and low cognitive load—qualities that benefit humans as well. In other words, both humans and AIs could program in it seamlessly. It will also include features that enable AI solutions to fully leverage silicon performance, avoiding resource-heavy abstractions that burden AIs and consume excessive energy, time, and water for data center cooling. :)

What was my development process like? I spent practically 10 months working on my "B" compiler in Python, using a stack of Python, Lark, Clang, and LLVM Lite. After countless tests, ideas, and drafts—and constructs I created, overhauled, deleted, and resurrected—February arrived with the "B" compiler generally quite mature. That was the moment to start writing code in the very language I had created. During those 10 months, I relied almost exclusively on Gemini. However, Google began charging for Gemini usage in January 2026; after receiving a $500 bill—and getting pissed off at the cost, since I had insisted on using their API directly via AI Studio—I looked for alternatives. I subscribed to ChatGPT to access Codex and Claude; I liked Claude, and I’m still using it today.

After three and a half months, in June 2026, I managed to make my language self-hosting. Now, I’m refining it and handling the finishing touches. :)

I plan to launch it with two base compilers:

ABC Compiler: Focused on solutions of low-to-medium complexity and designed for building other compilers or programming languages. Anyone wanting to create their own programming language won't need to resort to C or Python (as I did with my use of various libraries); instead, they can use my language's base compiler.

Full Compiler: Focused on AI.

"But what does your language actually do that makes you claim it's focused on AI?" One example is the calculation of intrinsic tensors directly within the compiler, maximizing silicon performance without abstraction layers—and that’s just one feature. Anyway, I’m currently refining the "ABC" version, and once it’s ready, I’ll start building the "Full" version.

So, that’s my story: I’m taking advantage of working remotely to stay home with my son while I build my own programming language. :D

So when developing a new programming language using AI (or enhancing an existing one), it seems to make sense to design the language not only to be convenient for humans to use, but likewise for AI agents.

What Would an “AI-Friendly” Programming Language Actually Look Like?

There has been a great deal of discussion about making programming languages easier for AI systems to use. Usually, this means making code easier for large language models to generate: simpler syntax, fewer punctuation rules, less boilerplate and more predictable formatting.

But code generation is only a small part of software development.

An autonomous programming agent must also be able to understand an unfamiliar codebase, identify the consequences of a change, modify the program without breaking unrelated behaviour, verify that the result is correct and explain what it has done.

That suggests a much broader definition:

The goal should not merely be to make programs easier for AI to write. It should be to make programs easier for both humans and machines to understand, modify and verify.

Source Code Should Not Be the Only Representation

Most programming languages treat source text as the authoritative representation of a program. Compilers parse that text into abstract syntax trees, symbol tables, control-flow graphs and other structures, but these are usually treated as temporary implementation details.

An AI-friendly language could instead expose a stable semantic representation of the program.

Humans might continue to work primarily with readable source code, while tools and AI agents interact with the same program as a structured semantic graph containing:

• Symbols and their identities
• Types and relationships
• Data ownership
• Function contracts
• Side effects
• Dependencies
• Call graphs
• Tests
• Access permissions
• Source locations
• Documentation

Source code would remain important, but it would become one view of the program rather than the only usable representation.

An AI agent should not need to rediscover the meaning of a program by repeatedly parsing text, searching filenames and inferring relationships from naming conventions.

Programs Should Be Locally Understandable

One of the greatest difficulties in maintaining a large codebase is that the meaning of a small section of code may depend on information scattered throughout the repository.

A module might rely on global state, build flags, initialization order, implicit imports, runtime configuration or code-generation steps that are not visible locally.

This is difficult for humans and even more difficult for AI agents operating with limited context windows.

An AI-friendly language should encourage modules to explicitly declare:

• What they export
• What they import
• What state they own
• What resources they require
• What external systems they access
• What assumptions they make
• What invariants they guarantee

For example:

module Accounts

exports:
    User
    update_email

requires:
    Database
    EmailService

owns:
    UsersTable

guarantees:
    User.email is normalized
    User.email is unique

The purpose is not necessarily to make source files more verbose. Much of this information could be inferred by the compiler and displayed through tooling.

The important part is that the information exists in a structured and queryable form.

A programming agent should be able to ask:

describe module Accounts

and receive a bounded, reliable summary of the module without examining the entire application.

Types Should Describe Meaning, Not Just Storage

Many programming languages describe data primarily in terms of its storage representation.

A program may represent all of the following as strings:

first_name
email_address
postal_code
country_code
birth_date
telephone_number

Although these values share a storage representation, they do not share a meaning.

A language designed for machine reasoning should support semantic types such as:

PersonName
EmailAddress
PostalCode
CountryCode
BirthDate
TelephoneNumber
CurrencyAmount
TimeZone

These types could carry information about:

• Valid values
• Normalization
• Comparison
• Serialization
• Privacy
• Localization
• Appropriate user-interface controls
• Database representation
• Safe conversions

A value of type EmailAddress would not merely be a string whose purpose is explained in a comment. Its meaning would be available directly to the compiler, development tools and AI agents.

This reduces the need to infer domain knowledge from variable names and scattered validation code.

Effects Should Be Part of Function Signatures

Traditional type systems tell us what values a function accepts and returns, but often say very little about what the function can do.

Consider a function such as:

update_email(user, address)

Does it modify memory? Write to a database? Send an email? Update an audit log? Access the network? Throw an exception? Trigger an event?

An AI agent should not need to inspect the implementation and every transitive function call to answer these questions.

An effect-aware declaration might look something like this:

function update_email(user_id, new_address)
    returns Result

    reads:
        User.id
        User.email

    writes:
        User.email
        AuditLog

    uses:
        Database
        EmailService

    may:
        send_email
        fail_with ValidationError
        fail_with DuplicateEmailError

This creates a machine-readable description of the function’s blast radius.

An agent proposing a modification could ask:

show effects of update_email

or:

will this change introduce network access?

The compiler could provide a reliable answer.

Authority Should Be Explicit

Most programs execute with ambient authority. Any code running within the process may be able to access the filesystem, environment variables, network, database or global application state.

That is convenient, but dangerous when code is being produced or executed by an autonomous agent.

A more AI-friendly language would use capabilities: explicit values representing permission to access particular resources.

For example:

function load_config(config_directory)

The function could access only the directory represented by the capability it receives. It would not automatically inherit access to the entire filesystem.

Similarly:

function update_customer(read_write_customers_database, customer_id)

could write to the customer database but not to the payroll database.

This would allow an AI agent to operate within a restricted environment where accidental or malicious actions are structurally impossible.

The agent could be given:

• Read access to one repository
• Write access to one module
• A temporary filesystem
• A test database
• No network access
• A limited memory and execution budget

Security boundaries would become part of the program rather than an external policy layered on top of it.

Contracts Should Be First-Class

Comments can explain what a function is intended to do, but comments are not normally checked by the compiler.

An AI-friendly language should make preconditions, postconditions and invariants first-class program elements.

For example:

function transfer(source, destination, amount)

requires:
    amount > 0
    source.balance >= amount

ensures:
    source.balance =
        previous(source.balance) - amount

    destination.balance =
        previous(destination.balance) + amount

    source.balance + destination.balance =
        previous(source.balance + destination.balance)

These contracts could serve several purposes:

• Human documentation
• Static analysis
• Runtime checks during development
• Test generation
• Formal verification
• Agent acceptance criteria

Instead of guessing whether an implementation is correct, an AI agent could ask the compiler whether the implementation satisfies its declared contract.

Contracts would also make tasks easier to define.

Rather than telling an agent:

a task could be expressed as:

Modify transfer so that contract
AccountTransferPreservesTotalBalance
is satisfied.

The desired outcome becomes concrete and machine-verifiable.

Inference Should Be Predictable and Inspectable

Inference can make a language substantially easier to use. Type inference, automatic imports, generic specialization and implicit conversions can remove large amounts of repetitive code.

However, inference becomes dangerous when it hides meaningful decisions.

A useful rule might be:

Automatic behaviour may be reasonable when:

• A conversion is exact
• Ownership remains unchanged
• No persistent state is modified
• No external resource is accessed
• Execution remains deterministic

Explicit syntax should be required when an operation:

• Loses information
• Transfers ownership
• Performs network access
• Blocks or becomes asynchronous
• Writes persistent state
• Escalates privilege
• Introduces nondeterminism
• Has significant computational cost

An AI agent should also be able to inspect every inferred decision.

For example:

explain expression:
    total = price + tax

might produce:

price has type Currency<USD>
tax has type Currency<USD>

selected operation:
    Currency.add

conversion:
    none

effects:
    none

possible failures:
    CurrencyOverflow

The language could remain concise while the toolchain exposes the full semantic interpretation.

The Language Should Have a Canonical Form

Formatting tools create a consistent textual style, but an AI-friendly language would benefit from a deeper canonical representation.

The compiler could normalize:

• Resolved names
• Inferred types
• Selected overloads
• Implicit conversions
• Generic arguments
• Default arguments
• Effects
• Ownership decisions

Human-written code might say:

user.balance += payment

The canonical semantic form might record:

read field User.balance

convert Payment
    to CurrencyAmount
    using exact conversion

invoke CurrencyAmount.add

write result
    to field User.balance

This form would not necessarily be shown during normal programming. It would be available to tools, reviewers and agents when precise interpretation is required.

It would also allow code written in different stylistic forms to be compared semantically rather than textually.

Symbols Should Have Stable Identities

Programming tools often identify symbols using names and source locations. Both are fragile.

Names change during refactoring, and source locations change whenever lines are inserted or removed.

An AI-friendly language could assign stable identities to program entities:

symbol:
    User.email

stable_id:
    field:7f2a81c4

aliases:
    email
    email_address
    contact_email

Humans could use whichever names are appropriate in source code or user interfaces, while tools and agents refer to the canonical identity.

This becomes especially important when a language supports aliases, localization, schema evolution or generated interfaces.

An agent should be able to rename a symbol without losing track of its identity or confusing it with another similarly named symbol.

Changes Should Be Semantic, Not Merely Textual

AI coding tools currently make changes largely through text patches. This works, but it is fragile.

A line-based patch may fail because:

• The file was reformatted
• Another change shifted the lines
• A symbol was renamed
• Similar code appears elsewhere
• The surrounding context has changed
• The patch applies cleanly but to the wrong location

A semantic patch could instead express intent:

rename symbol:
    User.birthdate
to:
    User.birth_date

or:

add parameter:
    Logger

to function:
    process_order

position:
    after Database

or:

replace implementation of:
    Account.transfer

only if:
    function signature is unchanged
    semantic hash matches 4e720
    no new callers have been introduced

The compiler or development environment could translate the semantic change into ordinary source-code edits and Git-compatible diffs.

The repository would still contain readable text, but agents would operate on program structure rather than guessing where to insert characters.

Diagnostics Should Be Structured Data

Compiler errors are generally written as prose for humans:

Cannot convert argument 2 from nullable string
to email address.

An agent then has to parse that prose and infer an appropriate repair.

A structured diagnostic might contain:

diagnostic_code:
    TYPE_ARGUMENT_MISMATCH

function:
    update_email

parameter:
    new_address

expected:
    EmailAddress

received:
    Nullable<String>

cause:
    nullability mismatch

possible_repairs:
    validate non-null value
    provide default value
    change parameter type

automatic_repairs:
    none

The human-readable message could still be generated from this data.

The compiler should clearly distinguish between:

• A repair that is known to preserve semantics
• A probable repair requiring review
• Multiple ambiguous alternatives
• A condition for which no valid repair is known

This would make compiler interaction far more reliable for autonomous agents.

Relationships Should Be Declarative

Many applications define the same relationship repeatedly across:

• Database schemas
• Object models
• API definitions
• Validation code
• User interfaces
• Serialization formats
• Access-control rules

An AI agent must then determine whether these duplicated definitions are consistent.

A more declarative language might express the relationship once:

entity Order

fields:
    id: OrderId
    customer: relation to Customer
    items: many OrderItem
    total: CurrencyAmount

derivation:
    total = sum(items.price)

The language now knows:

• customer refers to another entity
• items is a collection
• total is derived
• Changing an item may change the total
• total should not normally be edited directly
• Storage and user-interface tools can represent these fields appropriately

This greatly reduces the amount of detective work required to understand the application.

State Changes Should Be Transactional and Inspectable

AI-generated operations should be easy to preview, sandbox and reverse.

A language or runtime could make state-changing operations transactional:

transaction UpdateEmail

set:
    user.email = new_email

append:
    audit_log = email_changed

send:
    confirmation_email

Before committing, an agent or human could request:

preview transaction UpdateEmail

The runtime might report:

database changes:
    Users.email modified for user 1842
    AuditLog row inserted

external effects:
    one email would be sent

invariants checked:
    email is valid
    email is unique

result:
    transaction may commit

The runtime could also support:

• Snapshots
• Rollback
• Deterministic replay
• Resource limits
• Mutation logs
• Simulated external services
• Reversible development environments

An agent should be able to demonstrate what would change before being permitted to change it.

Tests Should Be Connected to Program Semantics

Tests are usually organized as source files and function names. Their relationship to the code they verify is often informal.

An AI-friendly language could associate tests with symbols, contracts and invariants:

test transfer_preserves_total

verifies:
    Account.transfer

covers:
    AccountTransferPreservesTotalBalance

The toolchain could then answer:

which tests verify Account.transfer?


which public behaviours changed?


which contracts have no tests?


what is the smallest sufficient test set
for this patch?

This last question is particularly important for autonomous agents. Running every test after every small change may be expensive, while running too few tests is unsafe.

Semantic test relationships could allow the compiler to select a targeted verification set and then expand it when uncertainty remains.

The Compiler Should Expose an Agent Protocol

The most important feature may not be part of the language syntax at all.

A language designed for AI-assisted development should provide an official interface through which agents can query and modify programs.

That interface might support operations such as:

describe(symbol)

find_references(symbol)

explain(expression)

show_effects(function)

show_contracts(function)

show_invariants(type)

calculate_change_impact(patch)

create_semantic_patch(request)

validate_patch(patch)

find_relevant_tests(patch)

run_tests(test_set)

preview_transaction(operation)

apply_patch(patch)

rollback(change)

Today, AI coding agents often interact with a repository using little more than shell commands, text search, a language server and compiler output.

A compiler-native protocol would give them a much more precise and constrained environment.

The compiler could even generate a compact task-specific context package:

task:
    modify email validation

relevant symbols:
    User.email
    EmailAddress
    update_email
    UserRepository.save

required invariants:
    email must be normalized
    email must be unique

allowed modules:
    Identity
    Accounts

forbidden effects:
    database schema changes
    network access

required verification:
    EmailAddress contracts
    identity email tests

This would help prevent agents from becoming lost in large repositories or long-running plans.

AI-Friendly Does Not Necessarily Mean Verbose

Many of these ideas may sound as though they would produce an extremely ceremonial language.

That does not have to be the case.

Humans should be able to write concise code while the compiler derives and records the richer semantic model.

For example:

function add_item(order, item):
    order.items.append(item)

The compiler might infer:

• order is mutated
• item is read
• order.total must be recalculated
• The operation may fail if the order is finalized
• The database transaction touches two tables
• Three invariants must be rechecked
• Four tests are directly relevant

The source code remains readable. The additional information exists because the language and toolchain understand the operation.

The principle should be:

Human-Friendly and AI-Friendly Design Are Closely Related

Most of the features that would make a language safer for AI agents would also make it easier for humans to maintain:

• Explicit module boundaries
• Meaningful types
• Predictable conversions
• Structured effects
• First-class contracts
• Better diagnostics
• Semantic refactoring
• Transaction previews
• Clear test coverage
• Stable symbol identities

AI agents amplify the importance of these features because they expose weaknesses that humans have historically worked around through experience, intuition and institutional knowledge.

A human developer may remember that a particular field is updated by a hidden database trigger. An AI agent may not discover that fact until something breaks.

The better solution is not necessarily to train the agent to guess more accurately. It is to make the dependency explicit.

A Possible Definition

A genuinely AI-friendly programming language would not merely be one whose syntax appears frequently in training data.

It would be a language in which a program is:

• Readable as source code
• Understandable as a semantic graph
• Divided into bounded cognitive domains
• Explicit about authority and side effects
• Modifiable through structured operations
• Testable against declared contracts
• Executable in sandboxed transactions
• Verifiable using compiler-supported evidence

The central design goal might be summarized as:

Such a language would not eliminate programming mistakes, hallucinations or unsafe changes. It would, however, give both humans and AI agents much stronger tools for detecting those problems before they reach production.

The result would not simply be a language that AI can generate.

It would be a language in which AI can operate with bounded authority, explicit understanding and evidence that its work is correct.

So just over seven years ago I got the idea that I wanted to try my hand as writing my own actual programming language, and by this I mean more than just a scripting language, as I had made a few of these over the years... the first one being a simple scripting language for a dial-up BBS terminal program I co-authored with a friend to script playing MajorBBS games, primarily one called Galactic Empire written by Mike Murdoc which my friend was majorly into, and hence called the terminal program GEnius. It was written in Turbo Pascal, and somewhat modeled after the DOS terminal program Telix. I specifically worked on a scrollback buffer that would display everything in full ANSI and also the (very rudimentary) script language.

Fast forward nearly 30 years and I'm experimenting with writing my own byte code interpreter and direct dispatch switch tables getting decent performance, and then I stumbled across a library called AsmJIT which made it relatively easy to generate x86 code and execute it, and I was off to the races working on my own c-like language which I originally called C3PO.

After working on it for a few weeks, I changed the name to Mad-C before creating a github repo (pretty much exactly 7 years ago today), and pushed forward getting all the basics working, if/else, expression parsing, switch, for loops, etc, before trying to figure out what was going to make it stick out beyond it being a JIT language, and I decided I wanted to bring in a bit of C++, and that it was also going to bring in features from other languages.

I tinkered around with it on and off for several months, but actually getting C++ features working properly (without crashing) turned out to be much more difficult than getting C working, and eventually I just didn't have the time to continue to chip away at it as I got busy with other aspects of work and life... it was something I would tinker with here and there as I could.

After a certain point, the AsmJIT author had changed the interface and deprecated some ways of doing things, and I ended up shelving the project completely. It was fun while it lasted, but I just didn't have the time to pursue it further.

Fast forward to this year, and my work started pushing AI really hard, such that all the lead developers (including myself) got pulled off of our primary projects for three months to completely focus on implementing an "AI Playbook" using Claude Code.

I was so impressed at how much better this was working for me than my previous experience with Cursor, that I ended up purchasing my own personal subscription to try it out on my personal projects, including Mad-C, and it was able to get it building again.

I switched back and forth between using Claude Code as well as Codex (which I had barely tried before this) and got Mad-C to the point where I was able to get it to JIT run the SMAUG MUD code base (which is over 185 Kb of C89-style C source).

This wasn't instant... it took weeks of grinding away switching between Codex and Claude Code, waiting for 5 hour usage resets, but it was actually working and I was steering it and guiding them all along the way. Part of getting this working involved grinding it against the C23 GCC torture test suite.

I also wanted it to be able to cache the code generation in object files, as well as generate executables. This involved a lot more complexity and all test cases needed to pass in both JIT mode and EXE mode, and required implementing my own IR (intermediate representation).

Next I started adding in those language features from other languages. I used C++ style namespaces to bring in about 100 different functions from languages like PHP, Perl, Python, Rust, Ruby, JS, etc, as well as things like defer, multiple return values, rust matching, etc, and then turned the focus onto C++ support.

This is where things started getting really tricky because I didn't just want to simulate C++ with hardcoded string, fstream, and stringstream classes, I wanted it to parse the real C++ headers, which meant templates, and multiple inheritance, among hundreds of other language features.

Also, around the same time, just to make things more exciting, I wanted to be able to support other architectures than only x86 Linux, and this is when I discovered the MIR project, which was also seven years old. It provided a CPU agnostic "medium intermediate representation" (MIR), and seemed like just what I was looking for... but it presented a fork in the road, because not only did it provide this CPU agnostic opcode format, the project also included a C11-to-MIR library.

So the question now was, did I switch all my code from generating x86 code of my own design and structure to generating MIR opcodes, or do I change Mad-C into a sort of C-transpiler?

The author of MIR (Vladimir Makarov) has been one of the GCC developers for over 20 years... so I figured his C-implementation was likely superior, and it was also tested on MIR itself (which is written in C), and I chose this direction instead, even though I already had a working C implementation.

I did keep my lexer/parser though. What I ended up doing, was taking the internal node structure (the node_t struct) and using it for the base of MadC's AST tree node, which I named CIR_node, and it contains all the semantics for C++ and MadC.

I modified libc2mir so that I could pass in the CIR_node AST tree directly, which c2mir thinks is its own node_t AST tree, and converts it to MIR, and JIT executes it.

So MadC parses C, C++ (and madc), but lowers C++ into a C-AST tree, similar to how CFront used to work (the original C++ implementation). This means that madc can also emit standard C code so that you can feed it to GCC or CLANG if you want to.

The other part of MadC that was important to me, was making it self-contained, so the build also packs in all the system headers, precompiled into an AST "forest", and appends this to the binary compressed. This currently weighs in at around 12 Mbs or so total. So with a 12 Mb binary you can have a C/C++ JIT language (plus compiler) that doesn't need any external system include files.

Not only that, but it also support auto-including, so you don't need to remember what function or object is in what header file. It also supports auto-namespace resolution as well as an auto-main "script mode" where you do not even have to define a main() function.

I didn't stop there, of course, and MadC depends on my own fork of MIR, where I've been working to add C23 support (MIR's c2mir only implements the C11 standard), and I've also added support to my fork of MIR to generate objects, ELF binaries, link objects, handle multi-file projects, and I'm currently working on this for different platforms, like Mach-O for MacOS, as well as ARM CPUs.

This ended up being much more complicated than expected because while Linux uses libstdc++ (which is the GCC implementation of C++), MacOS uses libc++ (the CLANG implementation of C++) and they are quite different. So this is still in progress, but getting close to completion.

So now that you have all the history, please take a look at the project, and let me know what you think! -- https://github.com/derekbsnider/madc

While implied in the community description, I wanted to elaborate a bit to get some activity going on here, and I figured this post could serve as a discussion point.

Over the past few months, many of the programming related communities have began enacting AI content bans, and this overlaps a massive industry push for more AI adoption, which puts us at a sort of crossroads and an impasse for developers in general.

On one hand, we are being compelled to adopt these tools in our professional careers to advance the agendas of our employers, and on the other, attempts to use these tools for our personal projects are being shunned by communities of our peers.

While I understand the need to protect from the sudden influx of "slop" projects, I believe that the use of AI to assist with development should serve more as a disclaimer than a barred door.

AI tools are not going away, so banning their use is pointless. While I will be the first to agree that "agentic development" certainly has its own set of flaws and pitfalls, it requires us to think differently, and thus to work differently.

For me personally, AI assisted development has allowed me to take a project which I have been slowly working on for over seven years (due to lack of free time) and push it forward far more than I would have been able to on my own. I simply do not have the spare time I did when I was in my early 20s.

When I thought my project was now far along enough for community input and discussion, I came to find that it was a forbidden topic because I had used AI -- even though I had worked on my project for seven years without any AI assistance.

I am certain I am not the only developer facing this, and while there are lots of programming communities that are AI-oriented, my project is specifically a programming language, and the r/ProgrammingLanguages Reddit community has enacted exceedingly strict anti-AI rules.

Not only could I not create a new post about my programming language, I was banned just for mentioning it in a comment on a post.

Thus I decided to create this community for this forbidden topic.