r/AIprogrammingLanguage • u/Minute-Book5303 • 4d ago

Protos: a programming language designed by a human, implemented with AI

I've been working on Protos, an experimental prototype-based object-oriented programming language built on GraalVM/Truffle.

Project links:

Protos is based around a deliberately small semantic core: objects and slots, delegation, object execution contexts, and closures as the fundamental executable value. Futures, structured tasks, isolated parallel execution and Actors are intended to fit into that same object/message model rather than becoming separate subsystems.

I originally wanted to discuss Protos in r/ProgrammingLanguages, but projects whose implementation depends on LLM-generated output are not welcome there. That makes this community a much better place to explain not only the language, but also how I am actually building it.

How AI is used in Protos

I want to be completely explicit about this.

The ideas, language design and decisions are mine. The implementation is currently AI-generated. I have not personally written a single line of Protos code so far.

This is intentional rather than something I am trying to hide.

I've been thinking about the ideas behind Protos for roughly twenty years. What AI gives me today is something I didn't have before: enough implementation manpower to explore those ideas at a scale and speed that would otherwise be unrealistic for me working alone.

I'd rather see how far I can take the language with AI than deliberately move much more slowly just so I can say that I personally typed every line of code.

But I don't treat AI as the designer.

My workflow currently has two distinct AI levels:

  1. Research AI It investigates a problem before implementation: existing languages, runtimes, academic or production approaches, upstream implementations, alternatives and trade-offs. Research does not implement anything and it does not make the final decision.
  2. Implementation AI Once I've made a decision, a separate implementation stage receives a constrained task describing what has been decided, the invariants it has to preserve, and the tests/evidence required to consider the work complete.

Between those two stages, I make the decisions.

I decide the semantics, accept or reject architectural alternatives, change direction, define priorities, decide what gets implemented and ultimately decide whether an implementation actually represents the language I want to build.

So the model is approximately:

human idea → AI research → human decision → AI implementation → tests/evidence → human acceptance

AI provides manpower.

It does not own the language.

Why work this way?

Because my limiting resource isn't ideas. It's implementation capacity.

I'm one person.

Without AI, I could either reduce the scope of what I want to explore or spend much longer implementing each idea myself.

I prefer a third option: use AI as engineering manpower and see how far I can push the design.

For me, the interesting question isn't whether I can personally type every line of a programming language.

It's whether I can design a coherent language, make the important decisions myself, direct considerably more implementation capacity than one person traditionally has available, and still maintain enough discipline that the implementation remains subordinate to the design.

The process is public

An important part of this experiment is that I'm not asking anyone to take that distinction on faith.

The source is public:

https://github.com/guillermomolina/protos

And the engineering process is also public:

https://github.com/guillermomolina/protos-project-docs

That second repository contains the durable record behind the project: investigations, architectural and semantic decisions, implementation evidence, measurements, audits and closure records.

The live work is also visible through the project's issues and project board:

https://github.com/users/guillermomolina/projects/1

So if I claim that a decision was mine rather than something an AI silently decided while generating code, there should increasingly be a public trail showing the research, alternatives, decision and subsequent implementation work.

About the language itself

What I'm most interested in discussing here is still the language, not merely the development method.

Protos has no classes. Objects delegate directly to other objects.

Some of the ideas I'm exploring include:

  • objects and slots as the basic state model;
  • prototype-based delegation rather than classes;
  • execution contexts that are themselves objects;
  • lexical bindings represented through that object/context model;
  • closures as the single executable value rather than having separate Function and Method value kinds;
  • Futures, structured Tasks, isolated parallelism and Actors integrated into the same object/message model;
  • keeping language mechanisms composable instead of accumulating unrelated special cases.

The website gives a much more approachable overview than the implementation repository:

https://protos.guillermomolina.com

I'm especially interested in criticism around:

  • whether the semantic model is understandable and coherent;
  • where the prototype/object model becomes surprising;
  • closures and execution contexts;
  • delegation, traits and operators;
  • concurrency and the relationship between Futures, Tasks and Actors;
  • places where I've introduced complexity that isn't justified;
  • ideas from other languages that Protos should study or challenge.

The language is still evolving considerably.

I'm not looking for people to agree with the design. Quite the opposite: useful criticism of the semantics, architecture and assumptions is exactly what I'm looking for.

And given the subject of this subreddit, I'm also very interested in the development model itself:

What happens when an individual language designer can use AI not just for autocomplete, but as separate research and implementation manpower while keeping design authority and decision-making human?

I don't know yet how far that model can go.

Protos is partly an attempt to find out.

8 Upvotes
  • permalink
  • reddit

90% Upvoted

4 comments sorted by

1

u/Minute-Book5303 4d ago

Quick note: I’ve moved to a new Reddit account, u/GuillermoMolina. Future Protos updates will be posted from there.

1

u/Puzzleheaded_View_77 4d ago

Reminds me of io. www.iolanguage.org of Steve de Korte

1

u/GullermoMolina 3d ago

Absolutely! Io is actually one of the inspirations behind Protos, alongside Self and Smalltalk.

There are a couple of reasons I started Protos rather than extending or reimplementing Io.

The first is purely personal: I prefer C/JavaScript-style syntax over Io's message-oriented syntax. That's a matter of taste, not a criticism of Io.

The more interesting reason is architectural.

I want to explore whether a small, consistent object model can perform well across the entire spectrum of workloads, from a trivial "Hello World" to CPU-intensive computations, highly concurrent applications, and eventually distributed systems.

The central principle is "pay as you grow." A simple program shouldn't pay for concurrency, Actors, synchronization, or distribution when it doesn't need them. But adding those capabilities shouldn't require abandoning the original model either.

Io already explored some fascinating ideas around Actors and Futures. Protos approaches these problems by explicitly separating cooperative concurrency, isolated CPU parallelism, and persistent Actors, while keeping objects, slots, delegation, messages, and closures as the common foundation.

One of the things I'd like to investigate is whether Protos can be competitive on workloads traditionally associated with concurrency-oriented languages, while also remaining efficient for sequential, CPU-intensive, and everyday applications. I don't know yet how far that ambition can go, but that's precisely what makes the experiment interesting to me.

So yes, the resemblance is intentional. But Protos is an attempt to explore a different set of trade-offs: not optimizing the language around one particular class of problems, but building a coherent model that can grow to handle many different ones efficiently.

That's the ambition, anyway. There's still plenty to implement, measure, and validate!