@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?

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.

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;"

Money Incinerator Lang would be fitting name as well.

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'm not sure what this is about, would anyone mind ELI5?

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?

What is a motivating use case that this solves?

Nice try. We will eventually get there, but I think this can and need to get better.

Next step, an LLM that writes convo-lang programs to programs with an LLM

How is it different than DSPy?

It’s a noisy / busy syntax. Just my own opinion.

Why not as a library in Ruby or Python?

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