Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

LLM=True

blog.codemine.be

Post reply on HN
Print view View original

71–80 of 155 posts

Re: LLM=True

#71

Post by lelanthran »

mikkupikku wrote: post #68
DoctorOetker wrote: post #36

So frequently beginners in linux command lines complain about the irregularity or redundance in command line tool conventions (sometimes actual command parameters -h --help or /h ? other times: man vs info; etc...) When the first transformers that did more than poetry or rough translation appeared everybody noticed their flaws, but I observed that a dumb enough (or smart enough to be dangerous?) LLM could be useful i…

It has long been a pet peeve of mine that the *nix world has no standard reliable convention for how to interrogate a program for it's available flags. Instead there are at least a dozen ways it can be done and you can't rely on any one of them.

That's not specific to unix though.

Re: LLM=True

#72

Post by [deleted] »

mikkupikku wrote: post #68
DoctorOetker wrote: post #36

So frequently beginners in linux command lines complain about the irregularity or redundance in command line tool conventions (sometimes actual command parameters -h --help or /h ? other times: man vs info; etc...) When the first transformers that did more than poetry or rough translation appeared everybody noticed their flaws, but I observed that a dumb enough (or smart enough to be dangerous?) LLM could be useful i…

It has long been a pet peeve of mine that the *nix world has no standard reliable convention for how to interrogate a program for it's available flags. Instead there are at least a dozen ways it can be done and you can't rely on any one of them.

[deleted]

Re: LLM=True

#74

Post by mikkupikku »

iainmerrick wrote: post #53
latexr wrote: post #44

Earlier quoted context omitted.

Part of doing it well is adding comments as you add options. When I used vim, every line or block in the config had an accompanying comment explaining what it did, except if the config’s name was so obvious that a comment would just repeat it.

That's a good call. It's a big problem for JSON configs given pure JSON's strict no-comments policy. I like tools that let you use .js or better yet .ts files for config.

A lot of json parsers will permit comments even though it isn't meant to be valid. Worth trying it, see if a comment breaks the config, and if not then use comments and don't worry about it.

Re: LLM=True

#75

Post by hirako2000 »

robkop wrote: post #46

We’ve got a long way to go in optimising our environments for these models. Our perception of a terminal is much closer to feeding a video into Gemini than reading a textbook of logs. But we don’t make that ax affordance at the moment. I wrote a small game for my dev team to experience what it’s like interacting through these painful interfaces over the summer www.youareanagent.app Jump to the agentic coding level or…

Beautiful simulation.

Re: LLM=True

#76

Post by mikkupikku »

lelanthran wrote: post #71
mikkupikku wrote: post #68

Earlier quoted context omitted.

It has long been a pet peeve of mine that the *nix world has no standard reliable convention for how to interrogate a program for it's available flags. Instead there are at least a dozen ways it can be done and you can't rely on any one of them.

That's not specific to unix though.

I didn't say it was, but I simply don't care what problems any other kind of system has because they aren't my problems. Last time I had windows on any of my computers it was windows 98.

Re: LLM=True

#77

Post by kubanczyk »

lucumo wrote: post #27

> Then a brick hits you in the face when it dawns on you that all of our tools are dumping crazy amounts of non-relevant context into stdout thereby polluting your context windows. Not just context windows. Lots of that crap is completely useless for humans too. It's not a rare occurrence for warnings to be hidden in so much irrelevant output that they're there for years before someone notices.

Yeah. Maybe we only need:

   BATCH=yes    (default is no)

   --batch   (default is --no-batch)
for the unusual case when you do want the `route print` on a BGP router to actually dump 8 gigabytes of text throughout next 2 minutes. Maybe it's fine if a default output for anything generously applies summarization, such as "X, Y, Z ...and 9 thousand+ similar entries".

Having two separate command names (one for human/llm, one for batch) sucks.

Having `-h` for human, like ls or df do, sucks slightly less, but it is still a backward-compatibility hack which leads to `alias` proliferation and makes human lifes worse.

Re: LLM=True

#78

Post by xyzsparetimexyz »

eptcyka wrote: post #64

If the output of your build tool is too verbose for a mechanical brain to keep on top of, did the meat brain ever stand a chance? Why was the output so verbose in the first place then?

So you can debug it without having to do a second build with extra flags, and in order to have a sense of what the build is doing at any particular time.

Re: LLM=True

#79

Post by tovej »

isoprophlex wrote: post #35

Huh. I've noticed CC running build or test steps piped into greps, to cull useless chatter. It did this all by itself, without my explicit instructions. Also, I just restart when the context window starts filling up. Small focused changes work better anyway IMO than single god-prompts that try do do everything but eventually exceed context and capability...

cc is the C compiler.

Please don't overload that term with trendy LLM products. You can use the full name.

Re: LLM=True

#80

Post by sirk390 »

I would use this as a human. That npm output is crazy. Maybe a better variable would be "CONCISE=1". For LLMs, there are a few easier solutions, like outputing in a file (and then tail)., or running a subagent
Post reply on HN