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

161–169 of 169 posts

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

#161

Post by amterp »

Very much agree with the article, this is one of the reasons why I wrote Rad [0], which people here might find interesting. The idea is you write CLI scripts with a declarative approach to script arguments, including all the constraints on them, including relational ones. So you don't write your own CLI validation - you declare the shape that args should take, let Rad check user input for you, and you can focus your script on the interesting stuff. For example

  args:
      username str           # Required string
      password str?          # Optional string
      token str?             # Optional auth token
      age int                # Required integer
      status str             # Required string
  
      username requires password     // If username is provided, password must also be provided
      token excludes password        // Token and password cannot be used together
      age range [18, 99]             // Inclusive range from 18 to 99
      status enum ["active", "inactive", "pending"]
Rad will handle all the validation for you, you can just write the rest of your script assuming the constraints you declared are met.

[0]: https://github.com/amterp/rad

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

#162

Post by dboon »

delta_p_delta_x wrote: post #137
dboon wrote: post #124

Earlier quoted context omitted.

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…

> I think it’s better to skip this class of problem. I'll keep my templates, smart pointers, concepts, RAII, and now reflection, thanks. C and its macros are good for compile times but nothing much else. Programming in C feels like banging rocks together.

Agree to disagree, then! Templates, smart pointers, and RAII have cost me far, far more than they’ve paid me back. You should write whatever feels good to you.

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

#163

Post by dboon »

yunohn wrote: post #151
dboon wrote: post #125

Earlier quoted context omitted.

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.

I meant that it’s bundled with the binary such that you don’t need to make sure some random version of eg Node is available

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

#164

Post by delta_p_delta_x »

dboon wrote: post #162
delta_p_delta_x wrote: post #137

Earlier quoted context omitted.

> I think it’s better to skip this class of problem. I'll keep my templates, smart pointers, concepts, RAII, and now reflection, thanks. C and its macros are good for compile times but nothing much else. Programming in C feels like banging rocks together.

Agree to disagree, then! Templates, smart pointers, and RAII have cost me far, far more than they’ve paid me back. You should write whatever feels good to you.

Happy to. If I may, I have an analogy:

C feels a little like survival mode in Minecraft; you have a set of very simple abstractions, a relatively simple language, with which one can build the world (and in many cases, we have).

C++ feels like a complex city builder, with lots of tools, designs, and paradigms available, but also allows one to screw up in bigger ways.

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

#165

Post by antonvs »

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

> Someone is doing that validation.

The difference is (a) where and how validation happens, and (b) the type of the final result.

A parser is a function producing structured values - values of some type, usually different from the input type. In contrast, a validator is a predicate that only checks constraints on existing values.

For example, a parser can parse an email address into a variable of type EmailAddress. If the parser succeeds at doing that, assuming you're using a language with a decent type system, you now have a variable which is statically guaranteed to be an email address - not a string which you have to trust has passed validation at some point in the past.

This is part of the "Make illegal states unrepresentable" approach which allows for static debugging - debugging your code at compile time. It's a very powerful way to produce reliable systems with robust, statically proven guarantees.

But as Alexis King (who coined the phrase "Parse, don't validate") wrote, "Unless you already know what type-driven design is, my catchy slogan probably doesn’t mean all that much to you."

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

#166

Post by bakkoting »

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…

This is the approach taken by node's built-in argument parser util.parseArgs.

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

#167

Post by hdjrudni »

Lvl999Noob wrote: post #136
8n4vidtmkvmk wrote: post #66

Earlier quoted context omitted.

Everyone seems hung up on the type system, but I think the validity of the data is the important part. I'd still want to convert strings to ints, trim whitespace, drop extraneous props and all of that jazz even if I was using plain JS without types. I still wouldn't need to check the inputs again because I know it's already been processed, even if the type system can't help me.

Pure js without typescript also has "types". Typescript doesn't give you nominal types either. It's only structural. So when you say that you "know it's already been processed", you just have a mental type of "Parsed" vs "Raw". With a type system, it's like you have a partner dedicated to tracking that. But without that, it doesn't mean you aren't doing any parsing or type tracking of your own.

I don't think that's what people are talking about when they say types. They're talking about TypeScript types, not mental models of object structure.

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

#168

Post by hdjrudni »

dwattttt wrote: post #73
8n4vidtmkvmk wrote: post #66

Earlier quoted context omitted.

Everyone seems hung up on the type system, but I think the validity of the data is the important part. I'd still want to convert strings to ints, trim whitespace, drop extraneous props and all of that jazz even if I was using plain JS without types. I still wouldn't need to check the inputs again because I know it's already been processed, even if the type system can't help me.

The type isn't just there to make it easy to understand when you do it, it's for you a year later when you need to make a change further inside a codebase, far from where it's validated. Or for someone else who's never even seen the validation section of code. I'm hung up on the type system because it's a great way to convey the validity of the data; it follows the data around as it flows through your program. I don'…

Don't get me wrong, I love TypeScript types. And if I didn't have TypeScript, I'd use jsdoc.

I'm just saying that TypeScript and jsdoc don't actually do any runtime enforcement. It's important that the library does that part, with or without types.

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

#169

Post by yunohn »

dboon wrote: post #163
yunohn wrote: post #151

Earlier quoted context omitted.

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.

I meant that it’s bundled with the binary such that you don’t need to make sure some random version of eg Node is available

AFAIK all the other agent CLIs do that too? Which ones need you to bring the exact runtime?
Post reply on HN