Parse, Don't Validate (2019) • Hacker News Board

Re: Parse, Don't Validate (2019)

#141

Post by [deleted] » Sat, Jun 26, 2021, 4:20 PM UTC

vikingcaffiene wrote: post #127

jimmaswell wrote: post #119

Earlier quoted context omitted.

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.

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…

[deleted]

Re: Parse, Don't Validate (2019)

#142

Post by tikhonj » Sat, Jun 26, 2021, 4:25 PM UTC

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…

The example with pattern matching doesn't have anything to do with static types. You'll have exactly the same problem if you pattern match against positional arguments in Python:

    match event.get():
        case Click((x, y)):
            handle_click_at(x, y)

(Example from PEP 636[1].)

In both Python and statically typed languages you can avoid this by matching against field names rather than positions, or using some other interface to access data. This is an important design aspect to consider when writing code, but does not have anything to do with dynamic programming. The only difference static typing makes is that when you do change the type in a way that breaks existing patterns, you can know statically rather than needing failing tests or runtime errors.

The same is true for the rest of the things you've mentioned: none are specific to static typing! My experience with a lot of Haskell, Python, JavaScript and other languages is that Haskell code for the same task tends to be shorter and simpler, albeit by relying on a set of higher-level abstractions you have to learn. I don't think much of that would change for a hypothetical dynamically typed variant of Haskell either!

[1]: https://www.python.org/dev/peps/pep-0636/#matching-sequences

Re: Parse, Don't Validate (2019)

#143

Post by mixmastamyk » Sat, Jun 26, 2021, 4:29 PM UTC

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…

Sounded familiar. Worked correctly the first time it was run, sans types.

https://www.python.org/about/success/esr/

Re: Parse, Don't Validate (2019)

#144

Post by giovannibonetti » Sat, Jun 26, 2021, 4:31 PM UTC

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…

When you said "idempotency mismatch" you were meaning impedance mismatch, right?

Re: Parse, Don't Validate (2019)

#145

Post by tome » Sat, Jun 26, 2021, 4:33 PM UTC

giovannibonetti wrote: post #144

lukashrb wrote: post #135

Earlier quoted context omitted.

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…

When you said "idempotency mismatch" you were meaning impedance mismatch, right?

Strange if so because it's the "Object-relational impedance mismatch" not the "Static type-relational impedance mismatch".

https://en.wikipedia.org/wiki/Object%E2%80%93relational_impe...

Re: Parse, Don't Validate (2019)

#146

Post by pengwing » Sat, Jun 26, 2021, 4:36 PM UTC

I'd call it: pattern match, don't validate.

Gotta go and program more Elixir...

Re: Parse, Don't Validate (2019)

#147

Post by wrycoder » Sat, Jun 26, 2021, 4:37 PM UTC

spinningslate wrote: post #38

This is a great post. I come back to it frequently. There's beautiful clarity in the articulation, and the essence is easy to grasp yet powerful. It reminds me a bit of Scott Wlaschin's Railway Oriented Programming (ROP) [0]. As a technique, ROP nicely complements "parse don't validate". As an explanation, it's similarly simple yet wonderfully effective. I've a real admiration for people who can explain and present t…

Those are the extras. This is the post:

https://fsharpforfunandprofit.com/posts/recipe-part2/

Re: Parse, Don't Validate (2019)

#148

Post by JPKab » Sat, Jun 26, 2021, 4:38 PM UTC

jimmaswell wrote: post #119

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…

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.

I've worked with plenty of coders who talk about how awesome their code is even though they just write unit test as an afterthought. They also talk about how they don't need validation and everything is just awesome.

I hated working with those coders because they weren't really very good and their code was always the worst to maintain. They are the equivalent of a carpenter who brags about how quickly they can bang nails but can't build a stable structure to save their life.

Re: Parse, Don't Validate (2019)

#149

Post by dgb23 » Sat, Jun 26, 2021, 4:38 PM UTC

sgift wrote: post #89

dgb23 wrote: post #28

This principle can be applied to dynamic languages as well if you have some mechanism such as type hinting, pre-conditions etc. that are checked by a linter during development, even if it isn't, you can still use it at runtime with sufficient error handling. The essential point of this blog post is to avoid "shotgun parsing", where parsing/validating is done just from a procedural standpoint, where it matters when ex…

> This principle can be applied to dynamic languages as well if you have some mechanism such as type hinting, pre-conditions etc. that are checked by a linter during development, even if it isn't, you can still use it at runtime with sufficient error handling. Every time I read something like this my mind translates it to "after building an ad-hoc compiler you can do all the things a compiler can do. Just not as well…

I know of the advantages of static typing and very much appreciate them. My point was more about how the concept in the article may be translated to other types of tooling.

Re: Parse, Don't Validate (2019)

#150

Post by JPKab » Sat, Jun 26, 2021, 4:45 PM UTC

vikingcaffiene wrote: post #127

jimmaswell wrote: post #119

Earlier quoted context omitted.

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.

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 afterthought attitude are typically rather arrogant in fool hardy.

The most recent incarnation I've encountered is the hotshot data scientist who did okay in a few Kaggle competitions using Jupyter notebooks, and thinks they can just write software the way they did for the competitions with no test of any kind.

I had one of these on my team recently and naturally I had to do 95% of the work to turn anything he produced into a remotely decent product. I couldn't even get the guy to use nbdev, which would have allowed him to use Jupyter to write tested, documented, maintainable code.