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

221–230 of 288 posts

Re: Parse, Don't Validate (2019)

#221

Post by garethrowlands »

giantrobot wrote: post #157
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…

I have had the exact same experience. There's lots of utility in statically typed languages. They're great if your problem space is well defined. With respect to type checking, it's like a jig in wood or metal working. You trade flexibility for correctness. When the problem space is less well defined the type-related boiler plate adds a lot of friction. It's not impossible to overcome that friction but it slows down…

"type-related boiler plate"

That phrase makes me sad. Mainstream languages have a lot of scope for improvement in their type systems.

Re: Parse, Don't Validate (2019)

#222

Post by globular-toast »

exdsq wrote: post #190
globular-toast wrote: post #158

Earlier quoted context omitted.

I agree. I'm often baffled by some developers who seem to think dynamic typing is a minefield that inevitably goes wrong all the time. I note these are almost always Javascript programmers, though. In practice, experience developers in dynamic languages like Python, Lisp etc. rarely make such errors. The number of bugs we deal with that would have been caught early by static typing are vanishingly small. The best arg…

It's okay if you're working on a blog site, less so if you're working on an air-planes autopilot.

JPL sent Lisp to space https://flownet.com/gat/jpl-lisp.html

Re: Parse, Don't Validate (2019)

#223

Post by garethrowlands »

adamlett wrote: post #59

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/w…

I don't think types are a red herring here. Because if you follow this advice, then just using logic and your source code, you can prove what data is valid. And, since types and (constructive) logic are so strongly related, then the types are, in some sense "there" even if you don't see them. To put it another way, it's nice if your computer can make the proofs but if it can't, does that make the theorems any less true?

Re: Parse, Don't Validate (2019)

#224

Post by exdsq »

globular-toast wrote: post #222
exdsq wrote: post #190

Earlier quoted context omitted.

It's okay if you're working on a blog site, less so if you're working on an air-planes autopilot.

JPL sent Lisp to space https://flownet.com/gat/jpl-lisp.html

Sure and I know people who write Python that goes into space too, but it doesn't mean it'd the norm or even a good idea

Re: Parse, Don't Validate (2019)

#225

Post by exdsq »

syngrog66 wrote: post #210
exdsq wrote: post #188

Earlier quoted context omitted.

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

Sounds laborious to manually check edge cases each time you change that code or its dependencies. I'd rather just write a test.

Re: Parse, Don't Validate (2019)

#226

Post by Attummm »

Attummm wrote: post #49
mulmboy wrote: post #36

Earlier quoted context omitted.

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

Pydantic is using classes and typehinting. The new dataclasses style. Currently Maat doens't have a parser for dataclasses, it could come in the future. Pydantic works great with typehinting. Maat was created before dataclasses existed. For validation Maat offers the same. But it also allows for some really neat features such as validation on encrypted data. https://github.com/Attumm/Maat/blob/main/tests/test_validat…

Unable to change my comment.

Benchmarks of pydantic has Maat around twice the speed of Pydantic

Re: Parse, Don't Validate (2019)

#227

Post by lolinder »

lukashrb wrote: post #135
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…

For what its worth: People don't use dynamic language because they don't know better or never used a static language. To better understand what dynamic languages bring to the table, here are some disadvantages of static types to consider: Static types are awesome for local reasoning, but they are not that helpful in the context of the larger system (this already starts at the database, see idempotency mismatch). Code…

This argument is common, but I've never understood how a dynamically typed language is supposed to avoid coupling algorithms to data structures.

When using a data structure, I know what set of fields I expect it to have. In TypeScript, I can ask the compiler to check that my function's callers always provide data that meets my expectations. In JavaScript, I can check for these expectations at runtime or just let my function have undefined behavior.

Either way, if my function's assumptions about the data's shape don't turn out to be correct, it will break, whether or not I use a dynamic language.

It seems that most of the people who make this argument against static typing are actually arguing against violations of the Robustness Principle[0]: "be conservative in what you send, be liberal in what you accept".

A statically typed function that is as generous as possible should be no more brittle against outside change than an equally-generous dynamically typed function. The main difference is that the statically typed function is explicit about what inputs it has well-defined behavior for.

[0] https://en.wikipedia.org/wiki/Robustness_principle

Re: Parse, Don't Validate (2019)

#228

Post by wpietri »

b3morales wrote: post #196
j1elo wrote: post #136

Earlier quoted context omitted.

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

Yeah, I've been using Python's gradual typing for a while. It's not perfect, but I'm excited for the possibilities. But the real test is to see what it's like on a large, long-lived project, so I'm keeping any open mind. I figure if that doesn't work fully, it'll still be a nice step toward things that can be pulled out as isolated services.

Re: Parse, Don't Validate (2019)

#229

Post by wpietri »

giantrobot wrote: post #157
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…

I have had the exact same experience. There's lots of utility in statically typed languages. They're great if your problem space is well defined. With respect to type checking, it's like a jig in wood or metal working. You trade flexibility for correctness. When the problem space is less well defined the type-related boiler plate adds a lot of friction. It's not impossible to overcome that friction but it slows down…

Definitely. And for me the early stages of a product are often about buying information. "Users say they want X, so let's ship X and see." Key to exploring a product space is tight feedback loops between having an idea and seeing what people really do. It's only once I have enough active users (especially active paying users) to justify the project that I have some confidence about what "long term" really means for the code base.

Re: Parse, Don't Validate (2019)

#230

Post by nsajko »

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…

The point is that validation is (or should/can be) a byproduct of parsing. I.e., you shouldn't "do both", rather the validation should be encompassed by the parsing, as much as it makes sense.
Post reply on HN