←back to thread

Parse, Don't Validate (2019)

(lexi-lambda.github.io)
389 points melse | 4 comments | 26 Jun 21 07:23 UTC | HN request time: 0.817s | source
Show context
kortex ◴[26 Jun 21 14:15 UTC] No.27642049[source]▶
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... and it worked. I just sat there shocked, waiting for the inevitable crash and traceback to dive in and fix something, but it never came. In Python! Incredible.

[0] https://pydantic-docs.helpmanual.io/

replies(8): >>27642308 #>>27642664 #>>27643276 #>>27643474 #>>27644758 #>>27645737 #>>27646367 #>>27647141 #
jimmaswell ◴[26 Jun 21 15:23 UTC] No.27642664[source]▶
I've found this to be simply a matter of experience, not tooling. As the years go by I find the majority of my code just working right - never touched anything like pydantic or validation boilerplate for my own code, besides having to write unit tests as an afterthought at work to keep the coverage metric up.
replies(5): >>27642800 #>>27642869 #>>27643369 #>>27643588 #>>27644097 #
vikingcaffiene ◴[26 Jun 21 15:41 UTC] No.27642800[source]▶
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 afterthought to keep the coverage up.”

replies(4): >>27643101 #>>27643190 #>>27643436 #>>27644382 #
1. hardwaregeek ◴[26 Jun 21 18:16 UTC] No.27644382[source]▶
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.
replies(1): >>27645074 #
2. mixmastamyk ◴[26 Jun 21 19:35 UTC] No.27645074[source]▶
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.
replies(1): >>27652262 #
3. kortex ◴[27 Jun 21 15:21 UTC] No.27652262[source]▶
> However, the top post approaches religious dogma.

I don't deny it. Join the cult of Static Python. We have cookies! And lower stress levels!

I usually wrap that spiel with my caveat "this depends greatly on your neurotype, style, environment, and other things." I have ADHD and my brain struggles with keeping bits of state in memory, so having to remember the type of every variable without my IDE tracking it for me is a huge performance drain.

However, I would contend even if your neurotype supported that mental workflow... it isn't actually better. Humans on average can handle 7 +/- 2 "pieces" of information in focus. Why spend any of your precious half-dozen pieces of salient consciousness on something a machine is really good at doing?

replies(1): >>27656996 #
4. mixmastamyk ◴[28 Jun 21 01:00 UTC] No.27656996{3}[source]▶
Because it adds a lot of work that many projects don't need. Read wpietri's post on how candidates who write static get half as much accomplished in an interview.

Also since the tools are immature and bolted on afterward in Python, I think it's even a bit worse than it would be in something decent like C#.