I understood the article's point as saying that in strongly typed languages, GUIDs / UUIDs should be handled as an instance of the standard lib's built-in UUID datatype, rather than anything else (string, number, char[], etc). In strongly typed languages, this is good practice for type safety, with the pleasant side-effect of allowing for denser storage vs. some toString() or other exploded form.
The core idea here is that underlying every data type is a number and presentation of that data type can often lead to it being interpreted and used incorrectly.
I agree with you. This is actually part of a larger problem with the way strongly typed languages are used in practice, where usually whatever "primitive" numeric types are available are used everywhere, rather than any thoughtful attempt at creating a coherent meaning for each input value. My favorite abuse of language is when we pass around two integers to represent a fixed-point number, rather than passing around a data type like struct { int32_t exponent; int32_t mantissa; } fixedPoint.
This becomes an issue because now everywhere you operate on these data types you have to implement the math to add, subtract, multiply, and divide these values, and the syntax becomes much dirtier. You wind up repeating the same rounding rules everywhere except in one place, and then it happens that there's a bug caught during system-level testing that's specific to that rounding error. This is an issue I have seen repeatedly with the project I'm currently working on, and it's a huge pain in the ass.
Meanwhile with some reasonably clever use of syntax and the creation of a fixed point arithmetic library at the start of the project, you're always applying the same rounding rule, and you don't have to do wonky stuff just to round your numbers.
5 comments
[ 1.8 ms ] story [ 37.2 ms ] threadThis becomes an issue because now everywhere you operate on these data types you have to implement the math to add, subtract, multiply, and divide these values, and the syntax becomes much dirtier. You wind up repeating the same rounding rules everywhere except in one place, and then it happens that there's a bug caught during system-level testing that's specific to that rounding error. This is an issue I have seen repeatedly with the project I'm currently working on, and it's a huge pain in the ass.
Meanwhile with some reasonably clever use of syntax and the creation of a fixed point arithmetic library at the start of the project, you're always applying the same rounding rule, and you don't have to do wonky stuff just to round your numbers.
That's because a lot of people do store dates as strings, not numbers.
Take, for example, sqlite. The documentation clearly states that it stores dates as text strings.
https://sqlite.org/datatype3.html#date_and_time_datatype