Show HN: E-- – A language you dial between English and Python
github.com
github.com
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
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.
DanLuu recently published something about “manually written automated tests” being phased out and LLMs just writing huge numbers of tests (he mentions 1000 servers as size of test cluster).
I have no idea how to get there but definitely feel I am slowing down the test writing process by being part of it !
> 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?
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.
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, ...
[[myfunc]](< 2, 3, 4>)
If you're having symbols, why not just use python syntax there? myfunc([2, 3, 4])