
GUID's are not strings - vincpa
http://www.depthinfinity.com/2016/02/treating-guids-as-strings/
======
flukus
I see the same with dates. A lot of people seem to think they're stored as
strings, not numbers.

~~~
niftich
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.

~~~
jschwartzi
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.

