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

161–170 of 288 posts

Re: Parse, Don't Validate (2019)

#161

Post by jolux »

mixmastamyk wrote: post #137
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…

Adding lots, no. I agree with the grandparent. Keeping the code simple, finding the right abstractions, untangling coupling, gets the most bang for the buck. See the “beyond pep8” talk for a enlightened perspective. That said, lightweight testing and tools like pyflakes to prevent egregious errors helps an experienced dev write very productively. Typing helps the most with large, venerable projects with numerous devs…

Typing is just another guardrail, it's not a substitute for finding the right abstractions and keeping things simple.

Re: Parse, Don't Validate (2019)

#162

Post by ukj »

mixedCase wrote: post #139
ukj wrote: post #115

Earlier quoted context omitted.

>I do dynamic dispatch all the time in strongly typed languages. I believe semantics is getting in our way of communicating. You don't do dynamic dispatch ___ALL___ the time. You only do it at runtime. And you only do static type safety at compile time. Those are different times. You can't have both of those features at the __SAME TME__, therefore you can't have both features ALL the time. They are mutually exclusive…

"All the time" is an english expression, please, look it up before going all-caps Python name mangle convention on me. Yes, of course dynamic dispatch is a runtime phenomenom, that's the dynamic part of it. But there's nothing stopping the code that performs dynamic dispatch from being strongly typed. Strong types are instructions used to prove that the code holds certain properties, they are a separate program from…

There is something stopping you from running the proof against your implementation!

Proof-checking happens only at compile time.

The implementation that you want to prove things about is only available at runtime!

Non-availability (incompleteness) of information is what is preventing you…

Re: Parse, Don't Validate (2019)

#163

Post by ukj »

justinpombrio wrote: post #125
ukj wrote: post #66

Earlier quoted context omitted.

Every programming paradigm is a good idea if the respective trade-offs are acceptable to you. For example, one good reason why strong static types are a bad idea... they prevent you from implementing dynamic dispatch. Routers. You can't have routers.

Are you sure you know what dynamic dispatch is? Java has dynamic dispatch, and it is a statically typed language. In Java, it's often called "runtime polymorphism". https://www.geeksforgeeks.org/dynamic-method-dispatch-runtim... And using it doesn't give up any of Java's type safety guarantees. The arguments and return type of the method you call (which will be invoked with dynamic dispatch) are type checked.

Are you sure you know when type-checking and when dynamic dispatching happens?

Compile time is not runtime.

The Java compiler is not the JVM.

The compiler does type checking. The JVM does the dynamic dispatching.

Neither does both.

Re: Parse, Don't Validate (2019)

#164

Post by ukj »

Jtsummers wrote: post #159
ukj wrote: post #122

Earlier quoted context omitted.

You are wrong about me being wrong. C++ is just a compiler. It outputs a binary for a target platform. The compiler does nothing for you at runtime - certainly not "type safety". Sometimes the 10 people on HN are wrong. This is one of those times.

C++ is not a compiler. C++ is a language with a specification from which people derive compilers and standard libraries and runtimes. C++ the language very much does tell you what to expect at runtime, though perhaps not everything you could ever want. I mean, it's not Haskell or Idris with their much richer type systems.

Perfect!

Please produce a piece of code (in a language such as Coq or Agda) which proves whether any given piece of random data has the type “C++ compiler” or “C++ program”.

That is the epitome of static type-checking, right?

Re: Parse, Don't Validate (2019)

#165

Post by justinpombrio »

kortex wrote: post #156
justinpombrio wrote: post #109

Earlier quoted context omitted.

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…

> Haha, "Those symbols need not be text", you say, right after quoting a definition that says they need to be "a string or text"! Ha yeah nice catch, that's why I added that in there. In this case the dictionary is slightly wrong. > The defining aspect of parsing, that makes it difficult and an interesting thing to study, is that you're starting with a list and ending with a tree. Ah, I didn't know that! Great bit to…

> I think my statement is still correct in that "a symbol could be a data structure," right? Like you could take a list of dicts and emit a tree of dicts.

Yeah I guess. Text combinator libraries like Haskell's Parsec and Rust's Nom are typically parametric over the type of "characters". Realistically I don't think I've ever seen anyone use one of those libraries for an input that wasn't text-like, though; do you have a use case in mind?

> But wait, a list is a kind of tree, or rather, there is a parse tree of recursive head/tail branches.

Yes, so you can run into parsing problems when working with trees, if you work really hard at it. But if you do the correct action is "reconsider your life choices" and not "use parsing theory".

Re: Parse, Don't Validate (2019)

#166

Post by ukj »

nsajko wrote: post #104
ukj wrote: post #54

Earlier quoted context omitted.

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

I think that you actually agree with the comment you responded to, it's just that you misinterpreted what it was trying to say.

I certainly don’t disagree (that doesn’t mean I agree).

The purpose of the conversation is to arrive at mutually acceptable interpretation.

Re: Parse, Don't Validate (2019)

#167

Post by bidirectional »

ukj wrote: post #94
dkersten wrote: post #86

Earlier quoted context omitted.

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

You can't actually implement everything in Brainfuck. You can implement something which is performing an equivalent computation in an abstract, mathematical sense. But there's no way to write Firefox or Windows or Fortnite in Brainfuck. Turing completeness means you can evaluate any computable function of type N -> N (and the many things isomorphic to that), it doesn't give you anything else.

Re: Parse, Don't Validate (2019)

#168

Post by justinpombrio »

ukj wrote: post #163
justinpombrio wrote: post #125

Earlier quoted context omitted.

Are you sure you know what dynamic dispatch is? Java has dynamic dispatch, and it is a statically typed language. In Java, it's often called "runtime polymorphism". https://www.geeksforgeeks.org/dynamic-method-dispatch-runtim... And using it doesn't give up any of Java's type safety guarantees. The arguments and return type of the method you call (which will be invoked with dynamic dispatch) are type checked.

Are you sure you know when type-checking and when dynamic dispatching happens? Compile time is not runtime. The Java compiler is not the JVM. The compiler does type checking. The JVM does the dynamic dispatching. Neither does both.

All those statements are correct. The people downvoting you know that too. I don't think anyone has figured out what point you're trying to make, though. Could you spell it out in more detail?

Consider addition. The compiler does type checking, and the JVM actually adds the numbers. Nonetheless, the addition is type checked, and does not represent a weakness of static type checking. How is dynamic dispatch different than this?

Re: Parse, Don't Validate (2019)

#169

Post by ChrisMarshallNY »

themulticaster wrote: post #99
ChrisMarshallNY wrote: post #45

Earlier quoted context omitted.

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.

Not recently (thank the Gods), but I used to work for a defense contractor, and I have dealt with many specification documents (like the Bluetooth spec).

Re: Parse, Don't Validate (2019)

#170

Post by ukj »

justinpombrio wrote: post #168
ukj wrote: post #163

Earlier quoted context omitted.

Are you sure you know when type-checking and when dynamic dispatching happens? Compile time is not runtime. The Java compiler is not the JVM. The compiler does type checking. The JVM does the dynamic dispatching. Neither does both.

All those statements are correct. The people downvoting you know that too. I don't think anyone has figured out what point you're trying to make, though. Could you spell it out in more detail? Consider addition. The compiler does type checking, and the JVM actually adds the numbers. Nonetheless, the addition is type checked, and does not represent a weakness of static type checking. How is dynamic dispatch different…

The point is trivial.

You can’t have both static type safety AND dynamic dispatch at the same time and in the same context about the same data.

Choose one. Give up the other. Make a conscious trade off.

The language that you are using is making such trade offs for you - they are implicit in the language design. Best you know what they are because they are meaningful in principle and in practice.

Post reply on HN