upvote
I think I had a pretty good understanding of set theory through programming, and although I tried to get into the more mathematical side of it, I found most things to be 1. trivial (because I was used to thinking in lists, sets, hashmaps, etc.), or 2. irrelevant to me. The latter was a shame, because I've always liked the abstraction of math, but I couldn't help but feel I wasn't learning anything actionable when learning more about sets (though maybe I'm wrong).

What had a big impact on me was the relational model, specifically after reading Richard Fabian's Data-oriented Design book [1]. I had watched Mike Acton's famous Data-oriented Design talk [2], then Andrew Kelley's talk [3] where he explains speedups in the Zig compiler using DoD principles (largely using methods from Acton's talk), but Fabian's book tied these concepts to database normalization and the relational model.

Most DoD advice is very "exercise left to the reader", because it's about matching a specific problem, but using the relational model and considering your data's primary and foreign key relations can be really powerful. I just wish more of that power was exposed through regular programming language interfaces, rather than having to pull in and marshal data through a DB. I might have to try C# and Linq.

1. https://www.dataorienteddesign.com/dodbook/

2. https://www.youtube.com/watch?v=rX0ItVEVjHc

3. https://www.youtube.com/watch?v=IroPQ150F6c

reply
Relational model too, yes. But the biggest "aha" moments I've had mentoring devs on thinking in SQL came when they understood that the result of a query is itself a set. So you can join two selects, join that result with another select, then group on the whole thing.

Those kinds of patterns would often replace manual loops in stored procedures and opened up set theory-focused way of thinking. These patterns are made more performant and easier with good relational modeling, of course.

reply