Hard Things in Computer Science

TTL certainly isn't the only or even best way to achieve cache invalidation - if the cache stores the result of time-intensive computations, then using a key that is a hash of all the inputs is sufficient (though you still need to deal with cleaning out old entries to reclaim space). From what I've observed often the "hard" problem with caching is knowing when it makes sense to use it at all - I've seen dramatic improvements in system behavior and reliability both from adding and removing caching.

Computing with limited numerical precision (aka floating point) is 1.000000000000003534 additional hard thing to deal with.

As another problem of applied CS I also suggest to add "Character Encoding" to the list of strongly underestimated complex problems :)

Proving code correct is orders of magnitude harder than the rest IMHO. It is amazing that enough progress has been made that large scale projects like CompCert and seL4 can now be done successfully by small teams of people.

There are lots of domains, where the domains are hard (compression and compiler design comes to mind), but when it comes to pure computing I would say: Lockless high contention multi-threading. Its the thing that has made everything easy hard and fun again for me.

I would add “synchronization of any kind”. Anything from versioning/code collaboration to syncing any kind of state between separate systems. I have worked with a lot of (mostly inexperienced) engineers who underestimated just how complex something like Git can be and the incredible amount of engineering behind it.

The hardest things in CS are also the simplest things:<p>* Strings (think Unicode, collations, string sizes, etc)<p>* Numbers (think currencies, precision, explaining floats to people, etc)<p>* Dates (as mentioned in the post)<p>And it&#x27;s funny that we start teaching programming with these concepts.

Not to diminish how hard these things can be. It just reads more like a &quot;hard things in (somewhat advanced) software engineering&quot; more than computer science IMO. I expected reading things like &quot;is graph isomorphism NP-complete?&quot; at least included.

&gt; The only reliable way to have bug-free code is to prove it. It requires solid mathematical foundations and a programming language that allows formal proofs.<p>I&#x27;m going to be the &quot;actually&quot; guy and say that, actually, you can formally verify some studff about programs written in traditional&#x2F;mainstream languages, like C. Matter of fact, this is a pretty lively research area, with some tools like CBMC [0] and Infer [1] also getting significant adoption in the industry.<p>[0]: <a href="https:&#x2F;&#x2F;github.com&#x2F;diffblue&#x2F;cbmc" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;diffblue&#x2F;cbmc</a><p>[1]: <a href="https:&#x2F;&#x2F;fbinfer.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;fbinfer.com&#x2F;</a>

I stopped reading when he mentioned TTL and only TTL as a valid cache invalidation method. It may be in some contexts where stale data is not a deal-breaker, but certainly not in the general or even most cases. Fail.

Over the years I added my own: the hardest thing in computer science is making something useful usable.

Not explicitly listed, but obviously hard, by definition, in (theoretical) CS: NP-Hard and NP-Complete problems.<p>Ex:<p>* knapsack (fit the most “boxes” into min number of containers, sometimes 4D+ “boxes”)<p>* traveling salesman

People say DNS is hard to get right but I don&#x27;t see why. It&#x27;s just cache invalidation and naming things, how hard can it be?

I think the hard part of cache invalidation is talking about reliably invalidating caches in response to data changes. If you don&#x27;t care about stale data then cache invalidation is not at all hard. You can just use TTL. TTL is not hard.<p>Anyway yeah there are definitely lots of hard things.