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

201–210 of 288 posts

Re: Parse, Don't Validate (2019)

#201

Post by b3morales »

justinpombrio wrote: post #97
bruce343434 wrote: post #61

Earlier quoted context omitted.

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 da…

I don't think this is the same as "make illegal states unrepresentable"; it's a corollary (or the converse maybe):

"Make assertions of legal states representable"

Re: Parse, Don't Validate (2019)

#202

Post by mixmastamyk »

hardwaregeek wrote: post #177
vikingcaffiene wrote: post #127

Earlier quoted context omitted.

Man, for a dev with as much experience as you’re claiming to have, this comment ain’t a great look. I’d argue that the more experience you get the more you write code for other people which involves adding lots of tooling, tests, etc. Even if the code works the first time, a more senior dev will make sure others have a “pit of success” they can fall into. This involves a lot more than just some “unit tests as an afte…

Agreed. It's like saying "oh well I just fly the airplane really carefully". A lot of codebases eclipse the point where one person can understand the whole system. Testing, static analysis and tooling are what allows us to keep the plane flying.

Agreed with the end of your post. However, the top post approaches religious dogma. I argue against that even if one has some good points.

Re: Parse, Don't Validate (2019)

#203

Post by justinpombrio »

ukj wrote: post #198
justinpombrio wrote: post #194

Earlier quoted context omitted.

That is not what dynamic dispatch means! It is an extremely well established term, with a very clear meaning, and that is not what it means. I thought you were just mistaken about something, but no, instead you've redefined a well understood term without telling anyone, then aggressively refused to clarify what you meant by it and argued for hours with people, while saying they were all wrong when they used the well…

“Well established” doesn’t mean anything. According to who? Computer scientists talk about “well formed” not “well established”. Those are categorical definitions.

> According to who?

Wikipedia, every textbook you can find, the top dozen search results for "dynamic dispatch", me who has a PhD in computer science plus all the other CS PhD people I know, everyone in my office who knows the term (who are industry people, not academia people), every blog post I have ever read that uses the term, and all the other HN commenters except you. I'm really not exaggerating; a lot of CS terms have disputed meanings but not this one.

EDIT: Sorry all for engaging the troll. I thought there might have been some legitimate confusion. My bad.

Re: Parse, Don't Validate (2019)

#204

Post by mixmastamyk »

JPKab wrote: post #150
vikingcaffiene wrote: post #127

Earlier quoted context omitted.

Man, for a dev with as much experience as you’re claiming to have, this comment ain’t a great look. I’d argue that the more experience you get the more you write code for other people which involves adding lots of tooling, tests, etc. Even if the code works the first time, a more senior dev will make sure others have a “pit of success” they can fall into. This involves a lot more than just some “unit tests as an afte…

It's an immediate tell when someone makes statements like the one you're replying to. It immediately tells me that they've never worked on large software projects, and if they have they haven't worked on ones that lasted more than a few months. I apologize to folks reading this for my rather aggressive tone but I've been writing software for a long time in numerous languages, and people with the unit tests as an afte…

You got paid to do the work presumably. You might also be able to push back on it. Coding standards should be a thing just about anywhere competent.

In short, there are choices besides, “I alone have to do all the hard work.”

Re: Parse, Don't Validate (2019)

#205

Post by ukj »

jhgb wrote: post #72
ukj wrote: post #21

Earlier quoted context omitted.

You are tripping up over polymorphism. "Is" means many things - which meaning you infer is precisely parsing! "A square is a rectangle" means "A square is a TYPE of rectangle" (at least, that is what I am parsing it as). "Parsing is Validation" means Parsing is isomorphic to Validation. How do I know? Because that is how I want you to parse it.

> "A square is a rectangle" means "A square is a TYPE of rectangle" (at least, that is what I am parsing it as). In that case your former statement that 'The word "is" implies an isomorphism' seems to be wrong.

It may be wrong in your model/interpretation of my words, but it's not wrong in my interpretation of my words.

Re: Parse, Don't Validate (2019)

#206

Post by samatman »

justinpombrio wrote: post #109
kortex wrote: post #96

Earlier quoted context omitted.

> 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 n…

Haha, "Those symbols need not be text", you say, right after quoting a definition that says they need to be "a string or text"! There's a field of study called "parsing", which studies "parsers". Hundreds of papers. Very well defined problem: turning a list of symbols into a tree shaped parse tree (or data structure). The defining aspect of parsing, that makes it difficult and an interesting thing to study, is that y…

Sure, but the list of symbols can be an arbitrary collection where the symbols are 0 and 1.

Voila, now your 'string' is 'binary data' not 'text'.

Parsing binary data is my bread and butter, so I might be biased but: it works fine.

Anything which comes over the wire is a string, anything which comes out of store is a string. If you're using something like protobufs, that's great, because having to marshal/serialize/parse along every process boundary is expensive and probably unnecessary.

But at some point, and anywhere on the 'surface' of the system, data has to be un-flattened into a shape. That's parsing.

Re: Parse, Don't Validate (2019)

#207

Post by ukj »

justinpombrio wrote: post #203
ukj wrote: post #198

Earlier quoted context omitted.

“Well established” doesn’t mean anything. According to who? Computer scientists talk about “well formed” not “well established”. Those are categorical definitions.

> According to who? Wikipedia, every textbook you can find, the top dozen search results for "dynamic dispatch", me who has a PhD in computer science plus all the other CS PhD people I know, everyone in my office who knows the term (who are industry people, not academia people), every blog post I have ever read that uses the term, and all the other HN commenters except you. I'm really not exaggerating; a lot of CS te…

So which textbook contains the meaning of "meaning"?

Oh, that's recursive! Which is Computer Science's domain of expertise, not the public domain.

We are talking about formal semantics here. What do programs (and computer languages are themselves programs) mean?

Point 0 of Wadler's law.

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

If you can type-check it at compile time then it is NOT dynamic dispatch. It's a contextual confusion.

Re: Parse, Don't Validate (2019)

#208

Post by pansa2 »

b3morales wrote: post #199
pansa2 wrote: post #153

“Parse, don’t [just] validate”. Say I have a string that’s supposed to represent an integer. To me, “Validate” means using a regex to ensure it contains only digits (raising an error if it doesn’t) but then continuing to work with it as a string. “Parse” means using “atoi” to obtain an integer value (but what if the string’s malformed?) and then working with that. I first thought this article was recommending doing t…

You seem to suggest that it's possible to parse without validating, which I'm not sure I follow. Surely validation is just one of the phases or steps of parsing?

Functions like `atoi` parse strings into integers, but will happily accept “ 10blah” and return 10. In my experience it’s best to validate that the string is well-formed (e.g. contains only digits) before passing it to one of those functions.

Re: Parse, Don't Validate (2019)

#209

Post by mixmastamyk »

wpietri wrote: post #112
RHSeeger wrote: post #78

Earlier quoted context omitted.

Plenty of people know multiple statically typed and dynamic languages, and multiple functional, imperative, and other languages; and use dynamic languages for some things but not other things. The set of people using dynamic languages isn't just "those that haven't had their eyes opened yet to what static languages can do". Different languages and paradigms make different things easier. I do believe that, for long la…

For sure. I do most of my work in situations of high volatility of domain and requirements and relatively high risk. (E.g., startups, projects in new areas.) Static typing really appeals to me on a personal level. I enjoy the process of analysis it requires. I love the notion of eliminating whole classes of bugs. It feels way more tidy. I took Odersky's Scala class for fun and loved it. But in practice, they're just…

This is the best comment on the subject and should be at the top rather the current dogmatic ones.

Re: Parse, Don't Validate (2019)

#210

Post by syngrog66 »

exdsq wrote: post #188
cortesoft wrote: post #130

Earlier quoted context omitted.

Tests aren't to make sure your code works when you write it, it is to make sure it doesn't break when you make changes down the line.

How do you know your code works when you write it if you don't test it?

you run it. look at the results or output. like the stdout, or a file it changed, or in a REPL or debugger. depends on situation
Post reply on HN