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

Parse, Don't Validate (2019)

lexi-lambda.github.io

Post reply on HN
Print view View original

91–100 of 288 posts

Re: Parse, Don't Validate (2019)

#91

Post by kortex »

bruce343434 wrote: post #27

This still sounds like validation but with extra steps. (or less?)

Validation is checking if something looks like a data structure. Parsing is smashing data into a data structure, and failing out if you can't do it.

At the end of parsing, you have a structure with a type. After validation, you may or may not have a structure with that type, depending on how you chose to validate.

But I think the big win is, parsers are usually much easier to compose (since they themselves are structured functions) and so if you start with the type first, you often get the "validation" behavior aspect of parsing for "free" (usually from a library). Maybe title should have been "Parse, don't manually validate."

But if your type doesn't catch all your invariants, yeah it does feel kinda just like validation.

Re: Parse, Don't Validate (2019)

#92

Post by dkersten »

ukj wrote: post #85
ImprobableTruth wrote: post #83

Earlier quoted context omitted.

Huh? Could you give a specific example? Because e.g. C++ and Rust definitely have dynamic dispatch through their vtable mechanisms.

Do you understand the difference between compile time and runtime? Neither C++ nor Rust give you static type safety AND dynamic dispatch because all of the safety checks for C++ and Rust happen at compile time. Not runtime.

Dynamic languages do it at runtime too, JUST LIKE rust and C++ do. What's the difference?

C++ and Rust let you have compile-time safety, until you choose to give it up and have runtime checks instead. Dynamic languages only allow the latter. Static languages let you choose, dynamic languages chose the latter for you in all cases. Both can have dynamic dispatch.

Besides, static languages can have compile-time type safe dynamic dispatch, if you constrain the dispatch to compile-time-known types (eg std::variant). You only lose that if you want fully unconstrained dynamism, in which case you defer type checking to runtime. Which is what dynamic languages always have.

So both C++ and Rust DO have dynamic dispatch and the programmer gets to choose what level of the dynamism/safety trade off they want. And yes, these features ARE first class features of the languages.

Re: Parse, Don't Validate (2019)

#93

Post by jsnell »

ukj wrote: post #85
ImprobableTruth wrote: post #83

Earlier quoted context omitted.

Huh? Could you give a specific example? Because e.g. C++ and Rust definitely have dynamic dispatch through their vtable mechanisms.

Do you understand the difference between compile time and runtime? Neither C++ nor Rust give you static type safety AND dynamic dispatch because all of the safety checks for C++ and Rust happen at compile time. Not runtime.

I think you might need to define what you mean by dynamic dispatch, because it is very clearly something totally different than how the term is commonly understood.

Re: Parse, Don't Validate (2019)

#94

Post by ukj »

dkersten wrote: post #86
ukj wrote: post #81

Earlier quoted context omitted.

Everything comes at a cost of something in computation! That is what “trade offs” means. You can have any feature in any language once you undermine the default constraints of your language. You can implement Scala in Brainfuck. Turing completeness guarantees it! But this is not the sort of discourse we care about in practice. https://en.wikipedia.org/wiki/Brainfuck

Yes, and? How is that relevant here? You said "you can't" , kortex said "you can" and then you moved the goal posts to "you can because of turing completeness, but its bad, Why do you even bother making the point?" to which I replied "because its a valid response to you're `you can't`" now you moved them again to "everything comes at a cost" (which... I also said?). Of course everything comes at a cost and yes, that'…

Tractability vs possibility.

You don't grok the difference.

You can implement EVERYTHING in Brainfuck. Tractability is the reason you don't.

The goalposts are exactly where I set them. With my first comment.

"Every programming paradigm is a good idea if the respective trade-offs are acceptable to you."

Re: Parse, Don't Validate (2019)

#95

Post by ukj »

detaro wrote: post #90
ukj wrote: post #85

Earlier quoted context omitted.

Do you understand the difference between compile time and runtime? Neither C++ nor Rust give you static type safety AND dynamic dispatch because all of the safety checks for C++ and Rust happen at compile time. Not runtime.

> Neither C++ nor Rust have dynamic dispatch You appear to be using some other definition of dynamic dispatch than the rest of the software industry...

You appear to be conflating compilers with runtimes.

Dynamic dispatch happens at runtime.

C++ and Rust are compile-time tools, not runtimes.

Re: Parse, Don't Validate (2019)

#96

Post by kortex »

bruce343434 wrote: post #61
_vufv wrote: post #31

Earlier quoted context omitted.

The post is saying: - don't drop the info gathered from checks while validating, but keep track of it - if you do this, you'll effectively be parsing - parsing is more powerful that validating "Extra steps" would be keeping track of info gathered from checks.

Right. My takeaway was "verify and validate once, then put it in a specially marked datastructure, or if your language allow it make the typesystem guarantee some conditions of the data, then work with that from there". Where does parsing come in the picture?

> verify and validate once, then put it in a specially marked datastructure

Not to steal vvillena's thunder, but that's pretty much the dictionary definition of "parsing"

> analyze (a string or text) into logical syntactic components, typically in order to test conformability to a logical grammar.

Parsing is taking some collection of symbols, and emitting some other structure that obeys certain rules. Those symbols need not be text, they can be any abstract "thing". A symbol could be a full-blown data structure - you can parse a List into a NotEmptyList, where there's some associated grammar with the NEL that's a stricter version of the List grammar.

Re: Parse, Don't Validate (2019)

#97

Post by justinpombrio »

bruce343434 wrote: post #61
_vufv wrote: post #31

Earlier quoted context omitted.

The post is saying: - don't drop the info gathered from checks while validating, but keep track of it - if you do this, you'll effectively be parsing - parsing is more powerful that validating "Extra steps" would be keeping track of info gathered from checks.

Right. My takeaway was "verify and validate once, then put it in a specially marked datastructure, or if your language allow it make the typesystem guarantee some conditions of the data, then work with that from there". Where does parsing come in the picture?

You understand it. It's using the word "parse" metaphorically, to mean "validate, then put it in a specially marked data structure". For example, `parse_int :: string -> maybe int` is a parsing function, and it "validates that the string is an integer, then puts it in a specially marked data structure called int". However, the post uses the word "parse" not only for true parsing functions (that convert text into a data structure), but also for conversions from data structure to data structure.

I also find this a confusing use of the word "parse", and it's not explained in the post, and I think "parse, don't validate" is a poor slogan as a result. The traditional slogan is "make illegal states unrepresentable", though that's a bit narrower of a concept.

Re: Parse, Don't Validate (2019)

#98

Post by ukj »

dkersten wrote: post #92
ukj wrote: post #85

Earlier quoted context omitted.

Do you understand the difference between compile time and runtime? Neither C++ nor Rust give you static type safety AND dynamic dispatch because all of the safety checks for C++ and Rust happen at compile time. Not runtime.

Dynamic languages do it at runtime too, JUST LIKE rust and C++ do. What's the difference? C++ and Rust let you have compile-time safety, until you choose to give it up and have runtime checks instead. Dynamic languages only allow the latter. Static languages let you choose, dynamic languages chose the latter for you in all cases. Both can have dynamic dispatch. Besides, static languages can have compile-time type saf…

>until you choose to give it up

PRECISELY

You have to give up the safety to get the feature.

So you "want type-safety". Until you don't.

>static languages can have compile-time type safe dynamic dispatch

"Compile-time dynamic dispatch" is an oxymoron. Dynamic dispatch happens at runtime.

Re: Parse, Don't Validate (2019)

#99

Post by themulticaster »

ChrisMarshallNY wrote: post #45
spinningslate wrote: post #38

This is a great post. I come back to it frequently. There's beautiful clarity in the articulation, and the essence is easy to grasp yet powerful. It reminds me a bit of Scott Wlaschin's Railway Oriented Programming (ROP) [0]. As a technique, ROP nicely complements "parse don't validate". As an explanation, it's similarly simple yet wonderfully effective. I've a real admiration for people who can explain and present t…

I agree. It's a very well-written post. I am not a Haskell person, but it was quite clear to me. I feel that we don't put enough value, these days, on the ability to write clear, articulate exposition. Also, I believe that many people are not willing to read articles, books, or papers, of any meaningful length. Everything needs to be boiled down to <10 min. read time, or <18 min. TED talks.

The way you somewhat randomly mention the value of clear and articulate exposition makes me assume you just had to wade through a 300-page specification document for a government contract regarding pencil sharpeners or something similar. If that's the case, you have my sympathy.

Anyways, I definitely agree.

Re: Parse, Don't Validate (2019)

#100

Post by catlifeonmars »

vorticalbox wrote: post #41
errnesto wrote: post #14

Earlier quoted context omitted.

For js / typescript I like: https://github.com/paperhive/fefe basically ist’s just functions that take a value of one type and return a other one

There is also joi, zod, myzod just to name a few. I personally use myzod as its fast it parsing, zero dependancies and you can infre types from your schemas.

Don’t forget https://github.com/gcanti/io-ts
Post reply on HN