The new COBOL. The next step is obviously to add syntax when you need to specify the type of the variables: put the type first, then the name and its value, and finish with a semicolon because it's fun, like "int n = 0;"
Perhaps when LLMs introduce a lot more primitives for modifying behvavior such a programming language would be necessary.
As such for anyone working with LLMs, they know most of the work happens before and after the LLM call, like doing REST calls, saving to database, etc. Conventional programming languages work well for that purpose.
Personally, I like JSON when the data is not too huge. Its easy to read (since it is hierarchical like most declarative formats) and parse.
One pain point such a PL could address is encoding tribal knowledge about optimal prompting strategies for various LLMs, which changes with each new model release.
I have thought of this issue quite a few times. I use Claude Code, Gemini CLI, etc. for all my new projects. Each of the typical CLAUDE.md/GEMINI.md file exists. I do not use MCPs. I ask agents to use `gh` command, all my work happens around Git/GitHub.
But text is just that, while scripts are easier to rely on. I can prompt and document all mechanisms to, say, check code format. But once I add something, say a pre-commit hook, it becomes reliable.
I am looking for a human readable (maybe renderable) way to codify patterns.
Cool concept that brings a little structure to prompts. I wouldn't use the semantic part that much, English is fine for this, but there is a real need for machine instructions. There is no need for an LLM guess if "main" is a function or a file for exemple.
I like it. Much nicer than having to use some python SDK in my opinion. Is this a standalone language or it requires Python or other languages to run it?
Not sure I'm sold on this particular implementation, but here's my best steelman: working with LLMs through plain text prompts can be brittle...tiny wording changes can alter outputs, context handling is improvised, and tool integration often means writing one-off glue code. This is meant to be DSL to add structure: break workflows into discrete steps, define vars, manage state, explicitly control when and how the model acts, and so on.
It basically gives you a formal syntax for orchestrating multi-turn LLM interactions, integrating tool calls + managing context in a predictable, maintainable way...essentially trying being some structure to "prompt engineering" and make it a bit more like a proper, composable programming discipline/model.
@on user
> onAskAboutConvoLang() -> (
if(??? (+ boolean /m last:3 task:Inspecting message)
Did the user ask about Convo-Lang in their last message
???) then (
@ragForMsg public/learn-convo
??? (+ respond /m task:Generating response about Convo-Lang)
Answer the users question using the following information about Convo-Lang
???
)
)
> user
Who in their right mind would come up with such a "syntax"? An LLM?
I haven't used DSPy this much, but as I understand it: this lang is more like an orchestration DSL for writing and running LLM conversations and tools, whereas DSPy is a framework that compiles and optimizes LLM programs into better-performing prompts...like DSPy has automatic improvement of pipelines using its compilers/optimizers. With DSPy you deal with modules and signatures.
This looks a lot like another effective way of interacting with LLMs: english-lang. Some of english-lang 's features are that it can be used to convey meaning, and it's largely accepted (network effect!). I'm excited to see what convo brings to the table /s
The new COBOL. The next step is obviously to add syntax when you need to specify the type of the variables: put the type first, then the name and its value, and finish with a semicolon because it's fun, like "int n = 0;"
COBOL ? Hurrah! If there’s anything that would improve vibe coding, it’s a “come from“ statement. :P
"Divide by zero error encountered."
Like terraform for prompts.
Put that on the landing page.
Perhaps when LLMs introduce a lot more primitives for modifying behvavior such a programming language would be necessary.
As such for anyone working with LLMs, they know most of the work happens before and after the LLM call, like doing REST calls, saving to database, etc. Conventional programming languages work well for that purpose.
Personally, I like JSON when the data is not too huge. Its easy to read (since it is hierarchical like most declarative formats) and parse.
One pain point such a PL could address is encoding tribal knowledge about optimal prompting strategies for various LLMs, which changes with each new model release.
I have thought of this issue quite a few times. I use Claude Code, Gemini CLI, etc. for all my new projects. Each of the typical CLAUDE.md/GEMINI.md file exists. I do not use MCPs. I ask agents to use `gh` command, all my work happens around Git/GitHub.
But text is just that, while scripts are easier to rely on. I can prompt and document all mechanisms to, say, check code format. But once I add something, say a pre-commit hook, it becomes reliable.
I am looking for a human readable (maybe renderable) way to codify patterns.
This is a really great experiment that gets a lot of things right!
Cool concept that brings a little structure to prompts. I wouldn't use the semantic part that much, English is fine for this, but there is a real need for machine instructions. There is no need for an LLM guess if "main" is a function or a file for exemple.
I like it. Much nicer than having to use some python SDK in my opinion. Is this a standalone language or it requires Python or other languages to run it?
Money Incinerator Lang would be fitting name as well.
Why not library?
How do you think about remote configurability?
Stuff like a lot of this needing to be A/B tested, models hot swapped, and versioned in a way thats accessible to non technical people?
How do you think about this in relation to tools like BAML?
I'm not sure what this is about, would anyone mind ELI5?
Not sure I'm sold on this particular implementation, but here's my best steelman: working with LLMs through plain text prompts can be brittle...tiny wording changes can alter outputs, context handling is improvised, and tool integration often means writing one-off glue code. This is meant to be DSL to add structure: break workflows into discrete steps, define vars, manage state, explicitly control when and how the model acts, and so on.
It basically gives you a formal syntax for orchestrating multi-turn LLM interactions, integrating tool calls + managing context in a predictable, maintainable way...essentially trying being some structure to "prompt engineering" and make it a bit more like a proper, composable programming discipline/model.
Something like that.
Next step, an LLM that writes convo-lang programs to programs with an LLM
What is a motivating use case that this solves?
Riding the LLM hype train to its exhaustion.
ChooChoo!
I have to agree, it looks wild, even the simpler examples don't feel ergonomic.
… I think I’ll just stick with pydantic AI for now
Nice try. We will eventually get there, but I think this can and need to get better.
It’s a noisy / busy syntax. Just my own opinion.
Why not as a library in Ruby or Python?
How is it different than DSPy?
I haven't used DSPy this much, but as I understand it: this lang is more like an orchestration DSL for writing and running LLM conversations and tools, whereas DSPy is a framework that compiles and optimizes LLM programs into better-performing prompts...like DSPy has automatic improvement of pipelines using its compilers/optimizers. With DSPy you deal with modules and signatures.
This looks a lot like another effective way of interacting with LLMs: english-lang. Some of english-lang 's features are that it can be used to convey meaning, and it's largely accepted (network effect!). I'm excited to see what convo brings to the table /s
You're absolutely right!