The referenced paper, What Every Computer Scientist Should Know About Floating-Point Arithmetic, is essential reading. I would also add Kahan’s “mindless” How Futile are Mindless Assessments of Roundoff in Floating-Point Computation?. The reader might be a little sad after those, but Herbie will cheer them up, even if it is “mindless”.
See also Boolean blindness, which is sometimes described as a code smell.
Primitive types come with primitive operations, and it is the totality of those operations which is being highlighted. An integer type can represent all integers and also have total primitive operations, if division is not included in those operations. This reveals why a programmer can spoil the invariants of custom types even though those types should be just as sound as the primitives: the programmer is responsible for designing and enforcing the invariants of their custom operations.
(To use a pinch of category theory, the category of sets and total functions is a subcategory of the category of sets and partial functions. If we start with only total primitive operations, then we can’t build partial primitive operations; we’re stuck in the subcategory. The general construction is called a restriction category and it lets us generalize this concept to languages whose programs aren’t functions.)
In type-oriented PLT, the current thinking is that refinement types should suffice to express any constraints on primitive values. The programmer is given full control over the small details of whether a value is a valid member of a type, as well as how it can be transformed.
I disagree with the assertion near the end that coding in C, because it requires attention to many details, causes the programmer to sharpen their senses and write better code. Lazy Fish Barrel has yet to run out of material to post, and as long as we encourage folks to write C then they never will.
That’s a great paper. I read it a while back and wanted to link/save it. I’ve added it to the article.
I read your comment and followed it, but I’m afraid that the average programmer would not grok it. (Having said that, I don’t want to get into a refinement type discussion)
I’m of a mixed mind about Greg’s C assertion. I didn’t want to nitpick too much during the video. I think that under the right circumstances, if you do things mindfully with a learning attitude, you’ll learn a lot more than if you simply study or read about them. See paragraph above. I think what’s needed here is some kind of approachable bridge between the average workaday coder an the parts of theory that will actually improve their product drastically. It’s tough to do that in a way that both sides will engage, however. Thanks for the comment.
Note: One thing to remember here in regards to “just do it in C kid!” is that CS theory isn’t new. Yes, a lot of the terms and teaching is new, but programmers have been down these pathways years before anybody stuck a label on them and put them in a book. They’re baked into the art of coding. There have been many occasions where I’ve come across cool ideas and labels only to realize that all that’s happening is that the formal community is catching up. (I don’t say that to dis the CS folks. My point is that for many of these foundational items, you can learn most of these concepts through traditional instruction or you can go out and find them. Coding is still very much an undiscovered country)