A programming language idea: no static code, explicit caller context (Kite)

Marconi soldate at gmail.com
Wed Apr 29 17:50:08 UTC 2026


Hi everyone,

I’ve been thinking about designing a new programming language 
called Kite — something lightweight, but designed with the 
ambition to “fly high.”

The core idea is simple, but strict:

There is no static code. Everything is object-oriented.

No static methods, no global functions, no hidden global state.

🔹 Core model

Every method call has two explicit references:

this → the object whose method is being executed
caller → the object that initiated the call

This means execution always carries both identity and 
responsibility.

Nothing happens without an owner.

🔹 Why introduce caller?

Most languages implicitly lose track of who requested an 
operation.

By introducing caller, we make this explicit:

The callee knows who is asking
The caller retains control over resources and error handling

🔹 What this enables

1. Memory allocation controlled by the caller

Instead of allocating memory implicitly, the callee can request 
it:

buffer = caller.alloc(size)

This prevents hidden allocations and makes ownership explicit.

2. Explicit error propagation

Instead of throwing exceptions globally:

caller.error("Something went wrong")

Errors always return to the origin of the operation.

3. No hidden global state

With no static constructs, everything flows through objects and 
their relationships.

4. Strong ownership model

The programmer always knows:

who called the function
who owns allocated memory
where errors go

🔹 Philosophy

Kite is built around a few core principles:

The programmer owns the flow.
No hidden control. No hidden allocation. No hidden errors.
Everything has a context. Everything has a caller.

🔹 Base Object

A root Object class could provide minimal operations like:

printing
memory allocation (via caller or delegated components)
error reporting

But ideally avoiding turning it into a “god object”, possibly by 
delegating to:

allocator
error handler
execution context

I’d love to hear your thoughts:

Does this model provide real advantages over existing languages?
Are there languages that already explore something similar?
What potential pitfalls do you see?

Thanks!


More information about the Digitalmars-d mailing list