build tool is now blocked on file-based checksum and i am L O C K E D the fuck in
that's why it's so deceptive to say "a hash function produces a smaller output". no it doesn't!!!!
; printf '' | wc -c
0
; printf '' | sha256sum
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 -
that's an encryption! and that sucks if i actually want to know what my data is, as opposed to wanting my data to be secret. using the same construct for cryptographic signatures is completely fucked when applying it to data integrity
and it's also just completely not the way hashes are used literally ANYWHERE else. the reason bloom filters work is because the hash functions are crafted to achieve collisions without having to calculate pairwise bit-for-bit equality over each pair of database entries!
radix sort gets better than n log n runtime for this exact reason!
so i refuse to call it a "hash". it's a "checksum" at best
i fervently believe that describing an actual literal parse forest for the file content that comes from actually parsing the data in an application-specific context is the correct way to achieve both data compression as well as integrity.
if the value of a single bit modifies the semantics of the entire rest of the file, that's information you kinda do need to know!
i actually refer to it as a "parse graph" to be fully general, because in fact most data serialization formats do not neatly compose into nested paired delimiters and a single "parse tree".
once you describe the relationships between atomic data blocks, you can directly use the parse graph to record checksum values that summarize not just the bits in your data, but what the bits mean.
and you (the application developer with domain expertise) can and should be able to construct a hash function that clearly summarizes the important facets of your data structure