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

121–130 of 169 posts

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

#121

Post by craftkiller »

goku12 wrote: post #92
dcminter wrote: post #86

Earlier quoted context omitted.

You do you, obviously, but "now let npm work its wicked way" is an offputting step for some of us when narrowing down which tool to use. My most comfortable tool is Java, but I'm not going to persuade most of the HN crowd to install a JVM unless the software I'm offering is unbearably compelling. Internal to work? Yeah, Java's going to be an easy sell. I don't think OP necessarily meant it as a political statement.

There should be some way to define the CLI argument format and its constraints in some sort of DSL that can be compiled into the target language before the final compilation of the application. This way, it can be language agnostic (though I don't know why you would need this) without the need for another runtime. The same interface specification should be able to represent a customizable help/usage message with sane…

docopt: https://github.com/docopt/docopt

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

#122

Post by bschwindHN »

perching_aix wrote: post #112
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.

Like shell scripts? Cause I mean, I agree, I think this world would be a better place if starting tomorrow shell scripts were no longer a thing. Just probably not what you meant.

> I think this world would be a better place if starting tomorrow shell scripts were no longer a thing.

Pretty much agreed - once any sort of complicated logic enters a shell script it's probably better off written in C/Rust/Go or something akin to that.

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

#123

Post by foundart »

The author of the article also wrote a CLI parser library for Typescript, called Optique. I really appreciate them including a "When Optique makes sense" section in the docs. It would be great if more projects did that.

https://optique.dev/why#when-optique-makes-sense

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

#124

Post by dboon »

delta_p_delta_x wrote: post #108
dboon wrote: post #105

Earlier quoted context omitted.

That’s the first rule anyone writing portable binaries learns. Compile against an old libc, and stuff tends to just work.

> Compile against an old libc This clause is abstracting away a ton of work. If you want to compile the latest LLVM and get 'portable C++26', you need to bootstrap everything , including CMake from that old-hat libc on some ancient distro like CentOS 6 or Ubuntu 12.04. I've said it before, I'll say it again: the Linux kernel may maintain ABI compatibility, but the fact that GNU libc breaks it anyway makes it a moot p…

Definitely, and I know this sounds like ignoring the problem, but in my experience the best solution is to just not use the bleeding edge.

Write your code such that you can load it onto (for example) the oldest supported Ubuntu and compile cleanly and you’ll have virtually zero problems. Again, I know that if your goal is to truly ship something written in e.g. C++26 portably then it’s a huge pain. But as someone who writes plain C and very much enjoys it, I think it’s better to skip this class of problem.

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

#125

Post by dboon »

rs186 wrote: post #96
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.

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

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

#126

Post by Lvl999Noob »

lock1 wrote: post #63
bigstrat2003 wrote: post #40

Earlier quoted context omitted.

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".

When I first saw "Parse, don't validate" title, it struck me as a catchy but perhaps unnecessarily clever catchphrase. It's catchy, yes, but it felt too ambiguous to be meaningful for anyone outside of the target audience (Haskellers in this case). That said, I fully agree with the article content itself. It basically just boils down to: When you create a program, eventually you'll need to process & check whether inp…

The difference, in my opinion, is that you received the cli args in the form

``` some_cli --some-option --no-some-option ```

Before parsing, the argument array contains both the flags to enable and disable the option. Validation would either throw an error or accept it as either enabled or disabled. But importantly, it wouldn't change the arguments. If the assumption is that the last option overwrites anything before it then the cli command is valid with the option disabled.

And now, correct behaviour relies on all the code using that option to always make the same assumption.

Parsing, on the other hand, would put create a new config where `option` is an enum - either enabled or disabled or not given. No confusion about multiple flags or anything. It provides a single view for the rest of the program of what the input config was.

Whether that parsing is done by a third party library or first party code, declaratively or imperatively, is besides the point.

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

#128

Post by kiliancs »

Great project. Clear goal, well executed, very nice API (safe, terse, clear).

I use Effect CLI https://github.com/Effect-TS/effect/tree/main/packages/cli for the same reasons. It has the advantage of fitting within the ecosystem. For example, I can reuse existing schemas.

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

#129

Post by andreygrehov »

lock1 wrote: post #63
bigstrat2003 wrote: post #40

Earlier quoted context omitted.

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".

When I first saw "Parse, don't validate" title, it struck me as a catchy but perhaps unnecessarily clever catchphrase. It's catchy, yes, but it felt too ambiguous to be meaningful for anyone outside of the target audience (Haskellers in this case). That said, I fully agree with the article content itself. It basically just boils down to: When you create a program, eventually you'll need to process & check whether inp…

What is ValidatedData? A subset of the Data that is valid? This makes no sense to me. The way I see it is you use ‘validate’ when the format of the data you are validating is the exact same format you are gonna be working with right after, meaning the return type doesn’t matter. The return type implies transformation – a write operation per se, whereas validation is always a read operation only.

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

#130

Post by ycombobreaker »

perching_aix wrote: post #112
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.

Like shell scripts? Cause I mean, I agree, I think this world would be a better place if starting tomorrow shell scripts were no longer a thing. Just probably not what you meant.

Shell scripts are a byproduct of the shell existing. Generations of programmers have cut their teeth in CLI environments. Anything that made shell scripts "no longer a thing" would necessarily destroy the interactive environment, and sounds like a ladder-pull to the curiosity of future generations.
Post reply on HN