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

191–200 of 288 posts

Re: Parse, Don't Validate (2019)

#191

Post by ukj »

detaro wrote: post #189
ukj wrote: post #187

Earlier quoted context omitted.

So, there is nothing dynamic about that dispatch. Because the implementation details of Foo are actually know at compile time. Which is why you are able to type-check it. You have literally declared all allowed (but not all possible) implementations of Foo. What happens when Foo() is a remote/network call?

so you are using a different definition of dynamic dispatch than the rest of the software industry.

I am using a conception (NOT a definition) that is actually dynamic.

If you can type-check your dispatcher at compile time then there is nothing dynamic about it.

Decidable (ahead of time) means your function is fully determined. Something that is fully determined is not dynamic.

It is the conception computer scientists use.

Re: Parse, Don't Validate (2019)

#192

Post by exdsq »

kortex wrote: post #84

This principle is how pydantic[0] utterly revolutionized my python development experience. I went from constantly having to test functions in repls, writing tons of validation boilerplate, and still getting TypeErrors and NoneTypeErrors and AttributeErrors left and right to like...just writing code. And it working ! Like one time I wrote a few hundred lines of python over the course of a day and then just ran it... a…

Just started working on a new SaaS startup and using FastAPI & Pydantic. The development experience has been great.

Re: Parse, Don't Validate (2019)

#193

Post by dkersten »

bidirectional wrote: post #167
ukj wrote: post #94

Earlier quoted context omitted.

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.

Just as a Turing machine requires an infinitely sized tape to compute any computable function, so too would brainfuck require an indirect sized tape (or whatever it’s called in BF) to compute any computable function. Since memory is finite, neither of these properties are actually available on real hardware.

Re: Parse, Don't Validate (2019)

#194

Post by justinpombrio »

ukj wrote: post #187
justinpombrio wrote: post #176

Earlier quoted context omitted.

Aha! I think I have debugged your thinking. Wow you made that hard by arguing so much. Apparently you do know what dynamic dispatch is, you're just wrong that it can't be type checked. In Java, say you have an interface called `Foo` with a method `String foo()`, and two classes A and B that implement that method. Then you can write this code (apologies if the syntax isn't quite right, it's been a while since I've wri…

So, there is nothing dynamic about that dispatch. Because the implementation details of Foo are actually know at compile time. Which is why you are able to type-check it. You have literally declared all allowed (but not all possible) implementations of Foo. What happens when Foo() is a remote/network call?

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 established term to mean its well established meaning.

The thing you're talking about is an interesting concept, but it's not called dynamic dispatch, and you will confuse everyone you talk to if you call it that. I don't know if there's a term for it.

Re: Parse, Don't Validate (2019)

#195

Post by ukj »

codetrotter wrote: post #76
ukj wrote: post #42

Earlier quoted context omitted.

You are over-complicating this into obscurity. 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? "parsing is validation, but validation is not parsing" if that were true then you should be able to give an example of a compiler doing some sort of validation on the random source co…

But I’m not talking about compilers here

Why not?

Compilers are computable functions.

If “Parsing is validation, but validation is not parsing” is true then it is also true about compilers.

Re: Parse, Don't Validate (2019)

#196

Post by b3morales »

j1elo wrote: post #136
wpietri wrote: post #112

Earlier quoted context omitted.

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…

Great comment. There are no silver bullets. I am Team static typing , but recognize how heavy of a burden would be to start a purely exploratory development in Rust or Java. It just "cuts your wings" in the name of correctness... well some times it is useful to have the ability to start with a technically incorrect implementation that anyways only fails in a corner case that is not your main point of research. On the…

Perhaps the Goldilocks mixture will be languages that allow type annotations but don't require it (e.g. Typescript, Elixir, Racket, and I think this is how Python's works).

Re: Parse, Don't Validate (2019)

#197

Post by jolux »

hardwaregeek wrote: post #179
jolux wrote: post #161

Earlier quoted context omitted.

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

I agree but guardrails are pretty awesome. And if people were saying "don't use guardrails, just drive properly", I'd ask why they think guardrails and driving properly are mutually exclusive.

Exactly. To be clear I’m very pro-type systems.

Re: Parse, Don't Validate (2019)

#198

Post by ukj »

justinpombrio wrote: post #194
ukj wrote: post #187

Earlier quoted context omitted.

So, there is nothing dynamic about that dispatch. Because the implementation details of Foo are actually know at compile time. Which is why you are able to type-check it. You have literally declared all allowed (but not all possible) implementations of Foo. What happens when Foo() is a remote/network call?

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.

Re: Parse, Don't Validate (2019)

#199

Post by b3morales »

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?

Re: Parse, Don't Validate (2019)

#200

Post by mixmastamyk »

kortex wrote: post #172
mixmastamyk wrote: post #137

Earlier quoted context omitted.

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 helps the most with large, venerable projects I disagree. I've started using types from the ground up and it helps almost equally at every stage of the game. Also I aggressively rely on autocomplete for methods. It's faster this way than usual "dynamic" or "pythonic" python. Part of it might be exactly because writing my datatypes first helps me think about the right abstractions. The big win with python is…

I don’t need to aggressively rely on tools, they are merely in the background. Perhaps what the earlier post about experience was thinking.

Also, what makes you think I’m not aware of datatypes? Currently working eight hours a day on Django models.

Post reply on HN