4 ms·

Can you give more info on how "parse, don't validate" has been helping you? I'm trying to get on the train, but I have so much validating code.

chriswarbo 5y ago
Not OP, but "parse, don't validate"[0] says that data (including config, etc.) should go through a "parsing step" (no "shotgun parsing"[1]) which outputs specific data-types for the main processing code to deal with ("invalid states should be unrepresentable"[2]). For example, we might have a "parsing step" which takes in Bytes (e.g. '[{"email": "chriswarbo@example.com"}]') and outputs a 'NonEmptyList[ContactDetails]' (e.g. 'NonEmptyList(Email(NonEmptyString('c', "hris"), NonEmptyString('e', "xample.com")), Nil)'). Compare this to a "validate" approach, e.g. parsing the bytes to a 'JsonArray', and using a boolean function to check whether it's empty, and whether its entries match the 'contact details' schema. That's problematic, since (a) it leads to "boolean blindness"[3] (the function tells us 'attempting to get those fields should work', whereas the parsing approach actually gives us those fields) and (b) such a boolean function is actually redundant, since deleting all of its call sites (or forgetting to write them to begin with) would give us a program that still compiles and runs (whereas the parsing approach would give a type error: 'Given JsonArray, expected NonEmptyList[ContactDetails]'). CUE's approach seems to be similar to passing JSON values around, and occasionally performing validation checks (if we remeber to); i.e. validating, not parsing. [0] https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va... [1] http://langsec.org/brucon/ShotgunParsersBruCON.pdf http://langsec.org/brucon/ShotgunParsersBruCON.pdf [2] https://fsharpforfunandprofit.com/posts/designing-with-types-making-illegal-states-unrepresentable https://fsharpforfunandprofit.com/posts/designing-with-types... [3] https://existentialtype.wordpress.com/2011/03/15/boolean-blindness https://existentialtype.wordpress.com/2011/03/15/boolean-bli...
- joshuamorton 5y ago
  Its not clear how this complaint applies to a configuration language, since there is no mutability or change, configuration is statically evaluated. I'd consider cue to be a config language that by and large tries to make invalid states unrepresentable.

chriswarbo 5y ago

Not OP, but "parse, don't validate"[0] says that data (including config, etc.) should go through a "parsing step" (no "shotgun parsing"[1]) which outputs specific data-types for the main processing code to deal with ("invalid states should be unrepresentable"[2]). For example, we might have a "parsing step" which takes in Bytes (e.g. '[{"email": "chriswarbo@example.com"}]') and outputs a 'NonEmptyList[ContactDetails]' (e.g. 'NonEmptyList(Email(NonEmptyString('c', "hris"), NonEmptyString('e', "xample.com")), Nil)'). Compare this to a "validate" approach, e.g. parsing the bytes to a 'JsonArray', and using a boolean function to check whether it's empty, and whether its entries match the 'contact details' schema. That's problematic, since (a) it leads to "boolean blindness"[3] (the function tells us 'attempting to get those fields should work', whereas the parsing approach actually gives us those fields) and (b) such a boolean function is actually redundant, since deleting all of its call sites (or forgetting to write them to begin with) would give us a program that still compiles and runs (whereas the parsing approach would give a type error: 'Given JsonArray, expected NonEmptyList[ContactDetails]'). CUE's approach seems to be similar to passing JSON values around, and occasionally performing validation checks (if we remeber to); i.e. validating, not parsing. [0] https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va... [1] http://langsec.org/brucon/ShotgunParsersBruCON.pdf http://langsec.org/brucon/ShotgunParsersBruCON.pdf [2] https://fsharpforfunandprofit.com/posts/designing-with-types-making-illegal-states-unrepresentable https://fsharpforfunandprofit.com/posts/designing-with-types... [3] https://existentialtype.wordpress.com/2011/03/15/boolean-blindness https://existentialtype.wordpress.com/2011/03/15/boolean-bli...

joshuamorton 5y ago
Its not clear how this complaint applies to a configuration language, since there is no mutability or change, configuration is statically evaluated. I'd consider cue to be a config language that by and large tries to make invalid states unrepresentable.