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

Stop writing CLI validation. Parse it right the first time

hackers.pub

Post reply on HN
Print view View original

151–160 of 169 posts

Re: Stop writing CLI validation. Parse it right the first time

#151

Post by yunohn »

dboon wrote: post #125
rs186 wrote: post #96

Earlier quoted context omitted.

Apparently that ship has sailed. Claude Code and Gemini CLI requires Node.js installation, and Gemini README reads as if npm is a tool that everybody knows and has already installed. https://www.anthropic.com/claude-code https://github.com/google-gemini/gemini-cli

Opencode is a great model agnostic alternative which does not require a separate runtime

Opencode uses TS and Golang, it definitely needs a runtime for the TS part. CPU usage hovers around 100% for me on an MBP M3 Max.

Re: Stop writing CLI validation. Parse it right the first time

#152

Post by exe34 »

3836293648 wrote: post #141
craftkiller wrote: post #118

Earlier quoted context omitted.

Don't let your dreams be dreams $ wget 'https://github.com/BurntSushi/ripgrep/releases/download/14.1.1/ripgrep-14.1.1-x86_64-unknown-linux-musl.tar.gz' $ tar -xvf 'ripgrep-14.1.1-x86_64-unknown-linux-musl.tar.gz' $ ldd ripgrep-14.1.1-x86_64-unknown-linux-musl/rg ldd (0x7f1dcb927000) $ file ripgrep-14.1.1-x86_64-unknown-linux-musl/rg ripgrep-14.1.1-x86_64-unknown-linux-musl/rg: ELF 64-bit LSB pie executable, x86-64, v…

Which only works on linux. No other OS allows static binaries, you always need to link to libc for syscalls.

try cosmopolitan!

Re: Stop writing CLI validation. Parse it right the first time

#153

Post by geon »

bschwindHN wrote: post #82

Rust with Clap solved this forever ago. Also - don't write CLI programs in languages that don't compile to native binaries. I don't want to have to drag around your runtime just to execute a command line tool.

This seems like a really weird stance. Who are you to dictate what language people should use? Why CLIs in particular?

Re: Stop writing CLI validation. Parse it right the first time

#154

Post by geon »

1718627440 wrote: post #145
MrJohz wrote: post #50

Earlier quoted context omitted.

I think the key part, although the author doesn't quite make it explicit, is that (a) the parsing happens all up front, rather than weaving validation and logic together, and (b) the parsing creates a new structure that encodes the invariants of the application, so that the rest of the application no longer needs to check anything. Whether you do that with Zod or manually or whatever isn't important, the important th…

But when you parse all arguments first before throwing error messages, you can create much better error messages, since they can be more holistic. To do that you need to represent the invalid configuration as a type.

Sure. Then you return that validated data structure from the parsing function and never touch the invalid data structure again. That's exactly what "Parse, don't validate" means.

Re: Stop writing CLI validation. Parse it right the first time

#155

Post by AnimalMuppet »

Well, they're dictating that if you want them to use it, do it this way. Some people want others to use the programs they write; for such people, the GP actually has been given the right to have some valid say in the matter.

Why CLIs in particular? Because they usually are smaller tools. For a big, important tool, you might be willing to jump through more hoops (installing the right runtime), but for a smaller, less important tool, it's just not worth it.

Re: Stop writing CLI validation. Parse it right the first time

#156

Post by geon »

bigstrat2003 wrote: post #40
jmull wrote: post #9

> Think about it. When you get JSON from an API, you don't just parse it as any and then write a bunch of if-statements. You use something like Zod to parse it directly into the shape you want. Invalid data? The parser rejects it. Done. Isn’t writing code and using zod the same thing? The difference being who wrote the code. Of course, you hope zod is robust, tested, supported, extensible, and has docs so you can und…

Yeah, the "parse, don't validate" advice seems vacuous to me because of this. Someone is doing that validation. I think the advice would perhaps be phrased better as "try to not reimplement popular libraries when you could just use them".

This might be a clearer phrasing: "Parse and validate ONCE AND FOR ALL, instead of sprinkling validation everywhere you need to access the data."

But I suppose it isn't as catchy.

Re: Stop writing CLI validation. Parse it right the first time

#157

Post by geon »

I just recently implemented my own parser combinator lib in typescript too. It was surprisingly simple in the end.

This function parses a number in 6502 asm. So `255` in dec or `$ff` in hex: https://github.com/geon/dumbasm/blob/main/src/parsers/parseN...

I looked at several typescript libraries but they all felt off. Writing my own at least ensured I know how it works.

Re: Stop writing CLI validation. Parse it right the first time

#158

Post by 3836293648 »

exe34 wrote: post #152
3836293648 wrote: post #141

Earlier quoted context omitted.

Which only works on linux. No other OS allows static binaries, you always need to link to libc for syscalls.

try cosmopolitan!

Cosmopolitan isn't statically linked, it's just a hack that works on all systems, dynamically linking on windows and macos (I think with a statically linked custom dynamic linker?)

Re: Stop writing CLI validation. Parse it right the first time

#159

Post by bschwindHN »

geon wrote: post #153
bschwindHN wrote: post #82

Rust with Clap solved this forever ago. Also - don't write CLI programs in languages that don't compile to native binaries. I don't want to have to drag around your runtime just to execute a command line tool.

This seems like a really weird stance. Who are you to dictate what language people should use? Why CLIs in particular?

I'm just making an opinionated suggestion for the case when you're shipping a tool to end users and you don't want the tool to suck. Attaching a python or nodejs runtime to your tool is a quick way to make it suck for end users. It's laziness on the dev's part who didn't bother learning a better tool for the job.

Re: Stop writing CLI validation. Parse it right the first time

#160

Post by einpoklum »

MrJohz wrote: post #103
einpoklum wrote: post #101

Exactly the opposite of this. We should parse the command-line using _no_ strict types. Not even integers. Nothing beyond parsing its structure, e.g. which option names get which (string) values, and which flags are enabled. This can be done without knowing _anything_ about the application domain, and provide a generic options structure which is no longer a sequence of characters. This approach IMNSHO is much cleaner…

Can you give some examples of this working well? It certainly goes against all of my experience working with CLIs and with parsing inputs in general (e.g. web APIs etc). In general, I've found that the quicker I can convert strings into rich types, the easier that code is to work with and the less likely I am to have troubles with invalid data.

Think of it this way: Your code for quickly converting things into rich types - just run it on a map of argument-to-string value map rather than on a sequence of characters. It's still "quick": This is just like we current get an array-of-strings instead of a single-string command-line; it's initial domain-agnostic parsing, which can't even fail.
Post reply on HN