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

11–20 of 169 posts

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

#11

Post by dkubb »

yakshaving_jgt wrote: post #2

I've noticed that many programmers believe that parsing is some niche thing that the average programmer likely won't need to contend with, and that it's only applicable in a few specific low-level cases, in which you'll need to reach for a parser combinator library, etc . But this is wrong. Programmers should be writing parsers all the time!

The three most common things I think about when coding are DAGs, State Machines and parsing. The latter two come up all the time in regexps which I probably write at least once a day, and I’m always thinking about state transitions and dependencies.

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

#12

Post by whilenot-dev »

thealistra wrote: post #5

Isn’t this like argparse from Python for typescript?

What OP calls an "combinatorial parser" I'd call object schema validation and that's more similar to pydantic[0] than argparse in python land.

[0]: https://docs.pydantic.dev/latest/

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

#13

Post by parhamn »

> Try to access it and TypeScript yells at you. No runtime validation needed.

I was recently thinking about type safety and validation strategies are particularly thorny in languages where the typings are just annotations. E.g. the Typescript/Zod or Python/Pydantic universes. Especially in IO cases where the data doesn't originate in the same type system.

In a language like Go (just an example, not endorsing) if you parse something into say a struct you know worst case you're getting that struct with all the fields set to zero, and you just have to handle the zero values. In typescript-likes you can get a totally different structure and run into all sorts of errors.

All that is to say, the runtime validation is always somewhere (perhaps in the library, as they often are?), and the feature here isn't no runtime validation but typed cli arguments. Which is cool and great.

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

#14

Post by urxvtcd »

cazum wrote: post #7
HL33tibCe7 wrote: post #4

Stopped reading after realising this is written by ChatGPT

What makes you think that and not that it's just an average auto-translate job from the author's native language (Korean)?

I’ll go one step further: what makes you think it’s an average auto-translate job? I didn’t notice anything weird, felt like your average, slightly ranty HN post. I’m not a native speaker though.

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

#15

Post by eska »

yakshaving_jgt wrote: post #2

I've noticed that many programmers believe that parsing is some niche thing that the average programmer likely won't need to contend with, and that it's only applicable in a few specific low-level cases, in which you'll need to reach for a parser combinator library, etc . But this is wrong. Programmers should be writing parsers all the time!

I think most security issues are just due to people not parsing input at all/properly. Then security consultants give each one a new name as if it was something new. :-)

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

#17

Post by nine_k »

yakshaving_jgt wrote: post #2

I've noticed that many programmers believe that parsing is some niche thing that the average programmer likely won't need to contend with, and that it's only applicable in a few specific low-level cases, in which you'll need to reach for a parser combinator library, etc . But this is wrong. Programmers should be writing parsers all the time!

I'd say that engineers should use the highest-level tools that are adequate for the task.

Sometimes it's going down to machine code, or rolling your own hash table, or writing your own recursive-descent parser from first principles. But most of the time you don't have to reach that low, and things like parsing are but a minor detail in the grand scheme. The engineer should not spend time on building them, but should be able to competently choose a ready-made part.

I mean, creating your own bolts and nuts may be fun, but mot of the time, if you want to build something, you just pick a few from an appropriate box, and this is exactly right.

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

#19

Post by metaltyphoon »

parhamn wrote: post #13

> Try to access it and TypeScript yells at you. No runtime validation needed. I was recently thinking about type safety and validation strategies are particularly thorny in languages where the typings are just annotations. E.g. the Typescript/Zod or Python/Pydantic universes. Especially in IO cases where the data doesn't originate in the same type system. In a language like Go (just an example, not endorsing) if you…

> worst case you're getting that struct with all the fields set to zero, and you just have to handle the zero values

In the field I work, zero values are valid and doing it in Go would be a nightmare

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

#20

Post by jetrink »

nine_k wrote: post #16

This is a recurring idea: "Parse, don't validate". Previously: https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va... (2019, using Haskell) https://www.lelanthran.com/chap13/content.html (April 2025, using C)

The author credits Alexis King at the beginning and links to that post.
Post reply on HN