Hacker News Reader

Comment by kazinator | Hacker News Reader

Parsing simple English and converting it to ffmpeg commands can be done without an LLM, running locally, using megabytes of RAM.

Check out this AI:

  $ apt install cdecl
  [ ... ]
  After this operation, 62.5 kB of additional disk space will be used.
  [ ... ]
  $ cdecl
  Type `help' or `?' for help
  cdecl> declare foo as function (pointer to char) returning pointer to array 4 of pointer to function (double) returning double
  double (*(*foo(char *))[4])(double )

Granted, this one has a very rigid syntax that doesn't allow for variation, but it could be made more flexible.

If FFMpeg's command line bugged me badly enough, I'd write "ffdecl".

View on HN

> Granted, this one has a very rigid syntax that doesn't allow for variation, but it could be made more flexible.

That’s kind of the killer feature of an LLM. You don’t even need to have your fingers on the right place on the keyboard and it will parse gibberish correctly as long as it’s shifted consistently.

I tell Claude to do things like I have brainrot and it still understands me like "ok, gib fn innew codblock"

But that effectively takes Postel's ill-conceived law to a ridiculous degree.

Programs should precisely define what their inputs are and loudly reject all else.

Moreover, for this misfeature, you have to use a cloud API, where your syntax is analyzed by some massive cluster, using scads of processing and memory resources.

We could have a natural language command line for FFMpeg requiring at most megabytes (probably just kilobytes) that would work on an air-gapped machine.

In the early 70's, the SHRDLU project achieved amazing chat interaction with symbolic processing, on the hardware available then. It was a way more impressive hack than LLM. Not just because it required relatively low resources, but also because its author could actually explain its responses, and point to the responsible pieces of code behind them, which he designed.

> Programs should precisely define what their inputs are and loudly reject all else.

…when interfacing with other programs. Humans aren't programs, which is a somewhat important distinction.

Well, firstly, take a look at some tech news, because it sure looks to me like people left and right are interfacing programs with AI, desperately scrambling to get reliable, stable outputs out of their prompts.

Secondly, people need precision and stability in program behavior also. People learn that when they give a certain command, they get a certain effect, and they don't want it to break.

Interfaces that allow people to express some wish in many ways (language, direct manipulation, ...) can still be rigidly defined: appear flexible to the casual user, but rigid to someone who cares to study the several thousand rules under the hood (or whatever).

But we aren't talking about "interfacing programs with AI", and we aren't talking about "[giving] a certain command, [getting] a certain effect". We are talking about one-off invocations directly by a human. Tools like llmpeg aren't intended to be a component in your CI/CD scripts, but for the command line user who wants to casually convert some media files and who hasn't memorized ffmpeg's full CLI interface.

"declare foo as function (pointer to char) returning pointer to array 4 of pointer to function (double) returning double" i would not call English

Terms of art aren't not English just because they're inscrutable to non-experts.

That should be crystal clear to the hn crowd, or is that no longer the case?

reminiscent of https://news.ycombinator.com/item?id=9224

Reply on news.ycombinator.com