I've been working on E--, a compile-time-only language where the LLM's role is constrained to {{ ... }} slots in your source. Slots resolve once, cache to disk, and runtime is pure deterministic Python. You can dial per line how much English vs Python you write — 100% Python for structure you know, English slots for values you'd rather describe. Same syntax at expression and statement positions. Write-up: https://medium.com/@frmoded/e-the-middle-ground-between-engl... Happy to answer questions here. Especially interested in feedback from folks building tools where domain experts (musicians, biologists, designers, students) author programs.

The name conflicts with a somewhat obscure but very influential language: https://en.wikipedia.org/wiki/E_(programming_language).

next: a programming language named 码

So my very first reaction was Inwoukd rather write python. My second reaction was, can this make an awesome cucumber like test scenario language?

I think my issues are twofold

1. You still have a DSL (“give back” > “return”) so it’s not English - it’s a DSL that looks more like English than python

2. Where there is English language like flexibility (Set tempo to {{ a tempo appropriate for a slow blues }}.) we are still passing out to an LLM during the compile process - so it’s not entirely deterministic

There feels like there is something here - in the area of test definitions and subject matter experts and Fitnesse tests. But I just have never seen cucumber like tests work right - in the end it’s another DSL and the SMEs end up describing the problem to devs who write the cucumber test and the SME read it

First the problem and s a lack of software literacy - if everyone could code we would just write unit tests

And you cannot get past that. No matter what we do an SME who is English illiterate is not going to write down their knowledge and same goes for software literacy.

I think there might be more traction in having LLMs help the BA / SME write comprehensive docs upfront … but that has other problems

But love that there is willingness to try and explore - keep going

I don't understand the premise, maybe I'm missing something.

> LLM-generated code is fuzzy at runtime: non-reproducible, expensive per call, hard to debug.

Wouldn't you have the LLM generate code once, then check in that code. What's not reproducible about that? How is checking in an "E--" script any different from checking in a python script?

So it's a templating language.

Some of the esoteric syntax choices are a bit strange; for example, a function with a list argument would be

  [[myfunc]](< 2, 3, 4>)

If you're having symbols, why not just use python syntax there?

  myfunc([2, 3, 4])

A language like E seems about the right level for a simple user-friendly programmatic layer wrapping applications, i.e. enable the users to ask a natural language question or build a simple GUI layer which has question actions, with results displayed in the custom GUI or exported as files (CSV or spreadsheets etc).

I expect we'll see a blurring of the web app GUI, allowing users and LLMs to augment the GUI.

There are a few tools offering the GUI part of that; I had read about Google A2UI, and search finds more : Anthropic Claude Rivet, CopilotKit (uses AG-UI Standard), Chainlit (Python UI framework), Vercel AI SDK (React Server Components stream from the LLM to the client). URLs : https://github.com/google/A2UI, https://fast.io/resources/best-ui-frameworks-ai-agents/, https://rivet.ironcladapp.com/ and https://techcommunity.microsoft.com/blog/azure-ai-foundry-bl..., https://www.copilotkit.ai/generative-ui, https://www.thesys.dev/blogs/openui, ...