That's a problem that is at least possible for the LLM to perceive and learn through training, while counting letters is much more like asking a colour blind person to count flowers by colour.
Why is it not possible? Do you think it's impossible to count? Do you think it's imposing to learn the letters in each token? Do you think combining the two is not possible.
How often can the hardness be exchanged with tediousness though? Can at least some of those problems be solved by letting the AI try until it succeeds?
To simplify for a moment, consider asking an LLM to come up with tests for a function. The tests pass. But did it come up with exhaustive tests? Did it understand the full intent of the function? How would it know? How would the operator know? (Even if it's wrangling simpler iterative prop/fuzz/etc testing systems underneath...)
Verification is substantially more challenging.
Currently, even for an expert in the domains of the software to be verified and the process of verification, defining a specification (even partial) is both difficult and tedious. Try reading/comparing the specifications of e.g. a pure crypto function, then a storage or clustering algorithm, then seL4.
(It's possible that brute force specification generation, iteration, and simplification by an LLM might help. It's possible an LLM could help eat away complexity from the other direction, unifying methods and languages, optimising provers, etc.)
I didn't know tardigrades can be big enough to be seen with the naked eye. Apparently big enough to be seen but not big enough to be recognised without magnification.
> I've not understood the propensity for using yaml for CI pipelines and workflows in general. A decent programming language would be a big improvement.
Because it's clear to write and read. You don't want your CI/CD logic to end up being spaghetti because a super ninja engineer decided they can do crazy stuff just because they can. Same reason why it's a bad idea to create your infrastructure directly in a programming language (unless creating infrastructure is a core part of your software).
> Why not just build the workflows themselves as docker images? I guess running other docker images in the workflow would then become a problem.
That's how Drone CI handled it. GitLab kind of does the same, where you always start as a docker image, and thus if you have a custom one with an entrypoint, it does whatever you need it to.
IME on a Pulumi for IaC team, writing infra in a real language (TypeScript) is MILES better than- you can do conditions, have typed outputs, etc and not have it be a bastardized imperative YAML mess.
YAML is fine for data, but inevitably stuff like workflows end up tacking on imperative features to a declarative language.
> IME on a Pulumi for IaC team, writing infra in a real language (TypeScript) is MILES better than- you can do conditions, have typed outputs, etc and not have it be a bastardized imperative YAML mess.
You can have conditions and types without having the full flexibility allowing madness of a full language with HCL.
I enjoy it, but I also think my platform team has set it up in the best possible way. YMMV if it’s done differently- I am sometimes uncertain if I love pulumi, or how we do pulumi.
I really really want to use dagger, but I don’t think there’s organizational interest in it.
After having to deal with shell rc files causing chaos and unpredictability, I can appreciate your top level code fundamental not being random code but something that is parsable and not subject to the halting problem.
it's wild I can wiz through a ton of code for hours on end but seeing a yaml file for something like a CI pipeline actually makes my brain eject i dunno why. my brain has some sort of proverbial capacity limit with how many different configuration-file looking things I can tolerate in a day, and the prospect of becoming intimately familiar with what is effectively an auto integration presented to me as some sort of config makes me completely unjustifiably butthurt for no reason. have i not suffered enough needless and often times limiting abstractions already
I think you'd need to write a tool that goes through all revisions of a file and does a count, but if that's cached then it's doable. There's a few tools to view that by file though, including some Git commands, it's a valuable tool to determine which files are edited the most (see also the word "churn").
I'm surprised there's no mention of fzf. fzf has greatly improved my terminal experience and I tend to incorporate it into almost every script that has any interactivity. I think any terminal of the future could incorporate fuzzy finding much better.
This makes me wonder if LLMs works better in Chinese.
reply