codegladiator

read it ? we dont do what kind of stuff here, i got my army of reader agents.

for me reliable = deterministically repeatable. if a llm has been able to do a task successfully and i ask it to do the same task again, i want the reliability that i get the same outcome (be if failure or success)

like if someone says "is this car reliable", i dont expect an infallible car. but if the cars third gear is 'you know sometimes it doesnt work', i wouldnt take that car out of city.

yeah and so llm cannot write C reliably

nothing wrong if your dsl stays small and you have deterministic validators/compilers to your actual target.

if dsl gets large, the number of potential interactions your dsl allow will grow exponentially (unless you are building an one dimensional action layer). and there will be semantic issues unless your dsl is "clear and intuitive", also comprehensive enough to accomodate your ongoing changes, else every change is now 2 changes.

so you now you need a comprehensive manual for your agent which needs to be sent in every /completion request.

any JSON or YAML that carries semantics with the syntax is a language

semantics are defined by the converter/compiler/interpreter, and that is the process which is going to consume the said json/yaml. if the json/yaml is going to be consumed by any process then the semantics are inherently defined, so by your definition all jsons/yamls are in their own a "language" (or they are not being consumed at all), which just defeats the purpose of calling it a language at that point.

The LLMs can write it fine. It wrote it almost acceptably on first sight

you are probably talking of some coding harness which looked up the existing code base and then made it and not something like first prompt to llm "write xyz testcase in my systems company dsl in tcl from early 2000".

LLMs can write it fine

sure, coding by examples is fine (it goes back to "system prompt describing the language"). but the claim we are arguing is reliability. did the llm generate 100% test case or code after reading your existing codebase, likely not as you mention it "almost acceptably on first sight".

i would probably be in denial if was suggesting llms not good at finding and fitting patterns.

you can have DSLs that are json/yaml, is my point

i disagree on the semantics of "DSL" vs "config in json". these are different.

and anyways both of them just pretend to be "reliable" by throwing the responsibility to an upper layer of validator/compiler/interpreter

it is worse because the tooling around it won't be as good

plantuml is good because of the the tooling around it. not sure if we are agreeing/disagreeing there, confused by the wording

its served me okay.

Perfect and deterministic? No, of course not. Just an improvement and mitigation.

exactly, not reliable, as the article tries to portray

DSL that is json/yaml helps a ton

it definitely does, and i would say json/yaml is not a dsl. this example of json/yaml keeps coming in the form of "DSL". i would say your configuration is not a dsl, it a declaration. llms are better at declarative stuff ? maybe but there are hardly that many of complex declarative frameworks.

PlantUML is a real dsl. not just declarative yaml.

less common DSLs like liquidsoap’s stream management DSL

seems to be on github since 2008 so definitely in the training data. i am not talking about less or more common. either "your dsl" would need to look something like someone elses dsl (at this point is it your dsl?) or you need some way to get your dsls examples in the training data for the llm, or feed it in the prompt.

LLMs respond well to clear, simple structure

and what a "clear simple structure" for a dsl is also quite not mentioned. clear and simple would be quite subjective based on the domain, the article says let the llm go in a loop trying to figure out the dsl for you.

checkpoints that have more structure than natural language

if llm is at any point in the structured generation part then either you have a deterministic validator/compiler or you are back to reading/reviewing it manually, what can you trust ?

The advantage holds while the DSL stays small and constrained enough that a few in-context examples can convey its usage. There is also a real upfront cost in designing and maintaining the language and its semantic model. The payoff is therefore concentrated in well-factored, genuinely constrained DSLs backed by a validator.

dsl stays small is doing all the heavy lifting here

the premise is that because of these few existing dsls (like PlantUML mentioned) my "new dsl" will be equally effective. PlantUML has millions of examples in the training data, my new dsls are not (specially if its not json/yaml or just function chain based). as the number of things that can mix and match increase you are basically looking at a whole system prompt just describing the new language.

this brings us to the second part. step 2: after dsl is 'planned' (note they use the java compiler), the dsl need to have a real compiler/executor, not just a validator. because if then you are going to ask the llm to "compile the dsl to implementation" we are back to square 1.

AlphaBaby ?

10 days

Its like someone reheating frozen food and saying I cooked it and they have not eaten it themselves and want me to buy it.

if its so critical then how about donating money and letting the maintainer decide where to spend it.

Master your craft. Don’t guess, know.

You mean add that to my prompt right ?

how far it can go ? complete page rewrites ?

what you are suggesting would be like a truck company using trucks to move things within the truck

algorithms are tools. like in any field every professional is supposed to be aware of "the basic standard tool set", what a good implemenation of a tool supposed to be like (i should be able to assess if a hammer is broken or good for use if i am civil engineer, or piano if i am a musician). it does not mean they should be able to "create that tool from scratch".

knowing the tools will only benefit you irrespective of your employer or other tools in town. (llm is also a tool, ides are tools, libraries are tools, design patterns is a tool)

once upon a time 'engineering' in software had some meaning attached to it...

no other engineering profession would accept the standards(or rather their lack of) on which software engineering is running.

She had no intention to misquote or misrepresent the rulings and that "the mistake occurred solely due to the reliance on an automatic source", the high court wrote

I don't think the intention matters here. Its the same deal with every profession using llm to "automate" their work. The onus in on the professional, not the llm. Arstechnica case could have been justified by same manner otherwise.

Not knowing the law isnt execuse to break law, so why is not knowing the tool an excuse to blame the tool.

Isnt bedrock and vertex pass thru to anthropic servers ? I didnt know aws/google are deploying the actual models

devnagri in the screenshot is wrongly rendered.

Also can you share some names of films you have been part of as film director.

This was human-directed, not autonomous code generation.

All my vibe coded projects are human directed, unless explicitly stated otherwise

zoo keeper

can vouch for SeaweedFS, been using it since the time it was called weedfs and my managers were like are you sure you really want to use that ?

Fair enough. I did not see this as a promotion of the product and more of as a show experimental side project. But if they really want to promote the product, the llm design isnt helping giving any confidence. A blog post would have sufficed.

Why does LLM generated websites feel so "LLM generated".

Its like a bootstrap css just dropped. People still giving "minimum effort" into their vibe code/eng projects but slap a domain on top. Is this to save token cost ?

And now Perplexity has mailed all of those "free" users to add a "card" (wont charge now) to continue with its free pro offer. Apart from airtel perplexity ran a lot of college based programs where students were basically referring each other for money.

vlc