←back to thread

Parse, Don't Validate (2019)

(lexi-lambda.github.io)
389 points melse | 1 comments | 26 Jun 21 07:23 UTC | HN request time: 0.213s | source
Show context
adamlett ◴[26 Jun 21 12:35 UTC] No.27641319[source]▶
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/wiki/Hexagonal_architecture_(softwa... ).
replies(3): >>27641644 #>>27646073 #>>27646525 #
Zababa ◴[26 Jun 21 13:31 UTC] No.27641644[source]▶
The advantage of the type checker is that it automatically check types for you. If you have only one function that produces a parsedArray and multiple functions that accept a parsedArray, you can be sure where they come from.
replies(1): >>27641921 #
1. adamlett ◴[26 Jun 21 14:00 UTC] No.27641921[source]▶
Yes, that’s literally the advantage of a static type checker. I don’t dispute that. I’m just saying that the advice in the article is just as applicable in a dynamic language and confers the same benefits. True, you’re not protected against accidentally using one type where another was expected, but that’s not really the point as I see it. The point is to use better types. Types you can lean on instead instead of nervously tiptoe around.