Generics and code correctness

Clean code is all right but pretty overused by now. Simplification coming at the cost of degraded performance should never be a choice (sorry python fans). Testable chunks of code carry way too much importance. Your code can be however you like in my opinion if there is a test suite explaining all what the particular module covers.

Readability, as Churchill said of courage, is rightly esteemed the first of qualities, because it is the quality which guarantees all others.

Who's arguing for unreadable code? Not me, but there seems to be a lot of it around, all the same. It's not that anyone deliberately sets out to write unreadable code, of course; it just ends up that way because we mistakenly prioritise other virtues over readability. Performance is one such virtue, and there are cases where performance genuinely matters.

Anyway, that's about being CRISP. Moving to generics, it has been a while since I have been dabbling into lambda calculus and functional programming. The more I see myself applying such ideas to day to day work, the more sensible it seem to me. Generics are an example of the same.

So I had a situation wherein I was supposed to use an SQL connector and a bunch of select queries to populate a list which was then compared to a different list (yeah think of it being something like git diff). Now initially I ended up using something like db *sql.DB like everyone does, save all the query result in an array, did index based comparison after that and get the results.

This worked, but it sucked at a lot of levels, first, no one would agree that my logic works under all circumstances. Why? The module lacked tests. I wrote the SELECT query knowing that it would work that way given the schema, but explaining that to people is tough, which makes sense as well, if they were to sit and understand whatever I am up to why not do it themselves in probably lesser time. Okay, time to write tests, ah shit you see the trouble? db *sql.DB. Now do I create an in memory db, change the connection string and then write tests for my function? No that's too ugly, might as well test in prod.

Read about this a bit, and came across the use of a widely famous design pattern, the Adapter Pattern which was a bliss, changing the direct database pointer to an abstract (generic) store with similar features as the ORM was pretty interesting to ponder about. Even came up with a few optimizations in the way I was SELECTing.

Moving on, the huge list, now it is to bad that tuple like data structures cannot be compared directly, which makes sense as well. But that was no reason for me to put everything in a list and then compare the indexes. To improve that, I ended up implementing a generic data structure with one indexable entry which has partial order implemented. This helped me to shift the comparison right while saving it in memory and always maintain a fixed index to access it in O(1).

Think of it as something like:

type Structure(type T comparable) map[T]int

Implementing operations on this improved upon the logic and in turn the execution time of the whole package exponentially (not going into details but we are talking about 1000x improvement). This was a pretty interesting experience. You should also, at times, try playing with the math being the mundane tasks like these. I mean I ended up storing this structure in the same structure definition generic and it was all proven pretty systematically, which was pretty cool tbh.

Anyway, if you want more about generics a bit more consider visiting here.

Cheers!