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

51–60 of 288 posts

Re: Parse, Don't Validate (2019)

#51

Post by Attummm »

rmnclmnt wrote: post #43
mulmboy wrote: post #36

Earlier quoted context omitted.

How does Maat compare with pydantic? https://github.com/samuelcolvin/pydantic

If only for conciseness, readability and speed, I'd take Pydantic over any day. Being able to express 80% of type checking using Python native type hints + dataclasses is just so intuitive! And it's getting some wide adoption, for instance FastAPI which uses it for request validations.

Engineering is about tradeoffs, even though both projects do validation.

The points you made are all very valid points.

At my employer we use both projects. If the data is very nested, or really large Maat is used.

Re: Parse, Don't Validate (2019)

#53

Post by rmnclmnt »

Attummm wrote: post #51
rmnclmnt wrote: post #43

Earlier quoted context omitted.

If only for conciseness, readability and speed, I'd take Pydantic over any day. Being able to express 80% of type checking using Python native type hints + dataclasses is just so intuitive! And it's getting some wide adoption, for instance FastAPI which uses it for request validations.

Engineering is about tradeoffs, even though both projects do validation. The points you made are all very valid points. At my employer we use both projects. If the data is very nested, or really large Maat is used.

Mmmh interesting requirement! Indeed, defining very nested structure with Pydantic is one of its weaknesses.

And of course I agree 100% about tradoffs in engineering. However I usually advise against using 2 dependencies doing mainly the same thing if possible within the same project.

Anyway, good catch, thanks for enlightening me!

Re: Parse, Don't Validate (2019)

#54

Post by ukj »

pwdisswordfish8 wrote: post #3
ukj wrote: post #2

Software Engineers: Parse, don't validate. Mathematicians: Parsing is validation https://gallais.github.io/pdf/draft_sigbovik21.pdf

The point being, the converse of ‘parsing is validation’ is not true.

Then you have some formally inexpressible/impredicative notion of "validation" in mind. For posterity (lifting from the depths of the threads):

General case: Validating random data as input into some program.

Particular case: Validating random source code (data) as input into some compiler (program).

Do compilers parse or validate?

> "the converse of ‘parsing is validation’ is not true."

If that were the case then you should be able to give an example of a compiler validating random source code (data) but not parsing it.

What determines the validity of random input is precisely a compiler's ability to parse it.

Re: Parse, Don't Validate (2019)

#55

Post by benrbray »

seanwilson wrote: post #48

From the Twitter link: > IME, people in dynamic languages almost never program this way, though—they prefer to use validation and some form of shotgun parsing. My guess as to why? Writing that kind of code in dynamically-typed languages is often a lot more boilerplate than it is in statically-typed ones! I feel that once you've got experience working in (usually functional) programming languages with strong static ty…

Yeah, I remember I used to get frustrated when I had to read code that used map() or even .forEach() extensively, thinking a simple, imperative for loop would suffice. I slowly came to realize that a for loop gives you too much power. It's a hammer. It holds the place of a bug you just haven't written yet. Now I'm the one writing JavaScript like it's Haskell. Although Haskell could learn a thing or two from TypeScript about row polymorphism.

Re: Parse, Don't Validate (2019)

#56

Post by k__ »

benrbray wrote: post #55
seanwilson wrote: post #48

From the Twitter link: > IME, people in dynamic languages almost never program this way, though—they prefer to use validation and some form of shotgun parsing. My guess as to why? Writing that kind of code in dynamically-typed languages is often a lot more boilerplate than it is in statically-typed ones! I feel that once you've got experience working in (usually functional) programming languages with strong static ty…

Yeah, I remember I used to get frustrated when I had to read code that used map() or even .forEach() extensively, thinking a simple, imperative for loop would suffice. I slowly came to realize that a for loop gives you too much power. It's a hammer. It holds the place of a bug you just haven't written yet. Now I'm the one writing JavaScript like it's Haskell. Although Haskell could learn a thing or two from TypeScrip…

Is using "row polymorphism" the same as using a "structutal type system"?

I never heard about the former.

Re: Parse, Don't Validate (2019)

#57

Post by Drup »

ukj wrote: post #35
Drup wrote: post #19

Earlier quoted context omitted.

To everyone in this subthread: sigbovik is a conference published every 1st of April. This paper is an April's fool joke. I didn't think people could take that one seriously. I guess it's a good April's fool then. :)

The conference is indeed a spoof, but in so far as what Mathematicians call a "proof" - the paper contains one. Agda is a proof assistant in the spirit of the Calculus of Constructions ( https://en.wikipedia.org/wiki/Calculus_of_constructions ). So is the joke on Computer Scientists or Mathematicians? You decide ;) Beware of bugs in the above code; I have only proved it correct, not tried it --Donald Knuth

Sigbovik's jokes are of the kind where the premise is completely bonkers. The rest of the development is made with the utmost rigor to highlight said bonkersitude, Reductio ad absurdum.

Re: Parse, Don't Validate (2019)

#58

Post by ukj »

Drup wrote: post #57
ukj wrote: post #35

Earlier quoted context omitted.

The conference is indeed a spoof, but in so far as what Mathematicians call a "proof" - the paper contains one. Agda is a proof assistant in the spirit of the Calculus of Constructions ( https://en.wikipedia.org/wiki/Calculus_of_constructions ). So is the joke on Computer Scientists or Mathematicians? You decide ;) Beware of bugs in the above code; I have only proved it correct, not tried it --Donald Knuth

Sigbovik's jokes are of the kind where the premise is completely bonkers. The rest of the development is made with the utmost rigor to highlight said bonkersitude, Reductio ad absurdum.

Yeah, but that is precisely how inductive types work.

"Bonkers" premises. Iterate, iterate, iterate. "Bonkers" conclusions. GIGO.

And yet the result is reified, exists and speaks for itself. So what is so "absurd" and "bonkers" about a result that is right before your eyes?

https://en.wikipedia.org/wiki/Reification_(computer_science)

Re: Parse, Don't Validate (2019)

#59

Post by adamlett »

I think making this about the type checker is a bit of a red herring. There is nothing in this – otherwise excellent – advice that can’t be applied to a dynamically typed language like Ruby. It’s the same insight that leads OOP folks to warn against the Primitive Obsession code smell (http://wiki.c2.com/?PrimitiveObsession). It’s also the insight that leads to the Hexagonal Architecture ( https://en.wikipedia.org/wiki/Hexagonal_architecture_(softwa... ).

Re: Parse, Don't Validate (2019)

#60

Post by inbx0 »

k__ wrote: post #56
benrbray wrote: post #55

Earlier quoted context omitted.

Yeah, I remember I used to get frustrated when I had to read code that used map() or even .forEach() extensively, thinking a simple, imperative for loop would suffice. I slowly came to realize that a for loop gives you too much power. It's a hammer. It holds the place of a bug you just haven't written yet. Now I'm the one writing JavaScript like it's Haskell. Although Haskell could learn a thing or two from TypeScrip…

Is using "row polymorphism" the same as using a "structutal type system"? I never heard about the former.

Not really, and correct me if I'm wrong but afaik TS doesn't actually do row polymorphism so much as structural subtyping - although the difference between the two is pretty small and you can get pretty close to row polymorphism with structural subtyping + generics.

But even if these were the same thing and we want to be a bit pendantic since this is HN after all, structural type systems often support some kind of subtyping or row polymorphism, but it's not a strict requirement for a type system to be "structural". You could have a structural type system that doesn't allow

  { a: int, b: int }
to be used where

  { a: int }
is expected. How practical such a type system would be... I don't know. Flow type checker for JavaScript makes a distinction between "exact" types, i.e. object must have exactly the properties listed and no more, and "inexact" types where such subtyping is allowed.
Post reply on HN