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've been experimenting with Cucumber lately and I think it starts to make more sense now because you can write the .feature files first and have an LLM write the unit test code that interprets them. So you're actually writing English language specifications, with just enough mandatory syntax to enable some useful tooling like unit test reports and IDE navigation, but not so much that it's hard to learn.
But with respect to SMEs reading/writing them, I think we need to be realistic here. That concept of an SME died out a long time ago. How many projects still have business analysts on them? The idea that you have SMEs writing or even reading requirements, handing them off to an architect who hands a spec off to an army of programmers is an IBM era idea.
What we've seen over time as coding got easier is a blurring and compression of all these different roles into one super role: the Developer. Modern "full stack" developers are expected to be subject matter experts, coders, architects, UI designers, testers, and perhaps also know how to deploy their software and run it in production. Heck, a significant number are also expected to learn how to run a business and do fund raising from investors!
Historically, all these things were totally different roles and people. But even predating LLMs we were designing better developer tools which took away much of the manpower requirements, freeing up the time of people who were once full time programmers to take over the other roles.
And this coincided with a cultural shift where most people decided they did not want to be in charge of a software project at almost any cost. Software projects fail in mysterious ways that to non-technical people seem random and uncontrollable. Much better to outsource it or use a SaaS even if you lose flexibility, than experience the career death of being an executive responsible for a failed software project.
With the exit of SMEs and BAs stage right, developers had to step in to fill the gaps by both taking on the commercial risks themselves (bootstrapped SaaS) and also learning the subject they're trying to automate to the same depth as a genuine SME.
With LLMs making all of this stuff far easier still, I don't see any reversal of this trend. The successful SaaS solopreneur is the archetypical meta-competent man well known from the Victorian era, someone who has mastered many different domains, AI assisted or not. He will use languages at whatever level of abstraction make sense. Sometimes that will be English, sometimes code, sometimes reading and sometimes writing. But all the tools will be designed for that one type of person, not specialised roles.
I had the same exact feeling. Python is so natural that I also feel it is hard to beat human reading-wise. When I first learned python, I remember thinking that the professor I was watching online was writing in pseudocode just to explain some sorting concept. Little did I know it was runnable Python. It was a laughable moment at my own experience at least. It was so easy to understand I genuinely thought runnable Python was a made up on the fly programming simplification. That's why I recommend to non-dev technical people to learn Python if they want to learn how to program. Now it's different I guess the Claude/ChatGPT/Grok/Copilot/Gemini does everything but still maybe you want to learn at least one programming language so you can officially be a bit more powerful than a vibe coder. That something can be Python.
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?
Was confused about this as well. The whole thing sounds as if someone confused LLMs writing code and inspecting or executing that code - and then ran with it.
Still, the idea of mostly formal code with dedicated sections that the LLM fills in doesn't sound so bad - but also a bit outdated. It would have been useful a year ago, but not when coding agents generate the entire project in a coffee break.
If the audience are people who aren't necessarily able to inspect the generated code, but still want more structure and determinism than pure "vibe coding", this makes more sense.
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.
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.
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've been experimenting with Cucumber lately and I think it starts to make more sense now because you can write the .feature files first and have an LLM write the unit test code that interprets them. So you're actually writing English language specifications, with just enough mandatory syntax to enable some useful tooling like unit test reports and IDE navigation, but not so much that it's hard to learn.
But with respect to SMEs reading/writing them, I think we need to be realistic here. That concept of an SME died out a long time ago. How many projects still have business analysts on them? The idea that you have SMEs writing or even reading requirements, handing them off to an architect who hands a spec off to an army of programmers is an IBM era idea.
What we've seen over time as coding got easier is a blurring and compression of all these different roles into one super role: the Developer. Modern "full stack" developers are expected to be subject matter experts, coders, architects, UI designers, testers, and perhaps also know how to deploy their software and run it in production. Heck, a significant number are also expected to learn how to run a business and do fund raising from investors!
Historically, all these things were totally different roles and people. But even predating LLMs we were designing better developer tools which took away much of the manpower requirements, freeing up the time of people who were once full time programmers to take over the other roles.
And this coincided with a cultural shift where most people decided they did not want to be in charge of a software project at almost any cost. Software projects fail in mysterious ways that to non-technical people seem random and uncontrollable. Much better to outsource it or use a SaaS even if you lose flexibility, than experience the career death of being an executive responsible for a failed software project.
With the exit of SMEs and BAs stage right, developers had to step in to fill the gaps by both taking on the commercial risks themselves (bootstrapped SaaS) and also learning the subject they're trying to automate to the same depth as a genuine SME.
With LLMs making all of this stuff far easier still, I don't see any reversal of this trend. The successful SaaS solopreneur is the archetypical meta-competent man well known from the Victorian era, someone who has mastered many different domains, AI assisted or not. He will use languages at whatever level of abstraction make sense. Sometimes that will be English, sometimes code, sometimes reading and sometimes writing. But all the tools will be designed for that one type of person, not specialised roles.
I had the same exact feeling. Python is so natural that I also feel it is hard to beat human reading-wise. When I first learned python, I remember thinking that the professor I was watching online was writing in pseudocode just to explain some sorting concept. Little did I know it was runnable Python. It was a laughable moment at my own experience at least. It was so easy to understand I genuinely thought runnable Python was a made up on the fly programming simplification. That's why I recommend to non-dev technical people to learn Python if they want to learn how to program. Now it's different I guess the Claude/ChatGPT/Grok/Copilot/Gemini does everything but still maybe you want to learn at least one programming language so you can officially be a bit more powerful than a vibe coder. That something can be Python.
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?
Was confused about this as well. The whole thing sounds as if someone confused LLMs writing code and inspecting or executing that code - and then ran with it.
Still, the idea of mostly formal code with dedicated sections that the LLM fills in doesn't sound so bad - but also a bit outdated. It would have been useful a year ago, but not when coding agents generate the entire project in a coffee break.
Edit: The author explains it a bit more in another post: https://news.ycombinator.com/item?id=48863898
If the audience are people who aren't necessarily able to inspect the generated code, but still want more structure and determinism than pure "vibe coding", this makes more sense.
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, ...
The name conflicts with a somewhat obscure but very influential language: https://en.wikipedia.org/wiki/E_(programming_language).
Also https://en.wikipedia.org/wiki/Amiga_E
E-- != E
Excuse me if I'm wrong, but since that's postfix wouldn't it always come out false?
Some of the esoteric syntax choices are a bit strange; for example, a function with a list argument would be
If you're having symbols, why not just use python syntax there?It's like English... But with worse sigils than Python...
Ooo this is cool. It reminds me of AppleScript. Did you guys use that as inspiration for this?
Interesting project. As an improvement, it can also be translated into other languages besides Python.
So it's a templating language.
next: a programming language named 码
Context: 码 means "code" in Chinese and prominently appears in words like, e.g. 源代码 (source code).
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.