Computing with limited numerical precision (aka floating point) is 1.000000000000003534 additional hard thing to deal with.
Hard Things in Computer Science
11–20 of 46 posts
Re: Hard Things in Computer Science
#12As another problem of applied CS I also suggest to add "Character Encoding" to the list of strongly underestimated complex problems :)
Agreed, and also just text in general, internationalization, line-breaks, horizontal vs vertical text, left-right vs right-left, etc, etc.
OTOH that starts getting quite "application oriented" and where do you draw the line? compsci is perhaps more about computation and how to achieve it, analyze it, etc, and in that case even dates and times should not be in the list, being an "application" domain concern.
Re: Hard Things in Computer Science
#13Not explicitly listed, but obviously hard, by definition, in (theoretical) CS: NP-Hard and NP-Complete problems. Ex: * knapsack (fit the most “boxes” into min number of containers, sometimes 4D+ “boxes”) * traveling salesman
I'm fascinated by problems, that are NP complete, but still can have a ton of optimizations that can reduce the time needed by many orders of magnitude (millions or more), like SAT solving. Or approximate solutions / heuristics like approx. traveling salesman. Seeing huge improvements on real-life problems, even if you know the problem is asymptotically exponential feels like you've fought against impossible odds and won.
Re: Hard Things in Computer Science
#14As another problem of applied CS I also suggest to add "Character Encoding" to the list of strongly underestimated complex problems :)
More than just Encoding the whole G11n is definitely the hardest.
Most do barely L10n, some do make it to proper I18n. Proper G11n...Maybe the fingers of one hand.
https://en.wikipedia.org/wiki/Internationalization_and_local...
Re: Hard Things in Computer Science
#15Not explicitly listed, but obviously hard, by definition, in (theoretical) CS: NP-Hard and NP-Complete problems. Ex: * knapsack (fit the most “boxes” into min number of containers, sometimes 4D+ “boxes”) * traveling salesman
funny, how many times in my career I've encountered the knapsack problem. but I can say off-by-one hit me many more times.
Re: Hard Things in Computer Science
#16Proving 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.
Interesting... I didn't realize there were large open projects that were formally verified. Are there other examples besides CompCert and seL4?
I don’t know if you’d count it as large, but portions of Amazon FreeRTOS.
Re: Hard Things in Computer Science
#17Not explicitly listed, but obviously hard, by definition, in (theoretical) CS: NP-Hard and NP-Complete problems. Ex: * knapsack (fit the most “boxes” into min number of containers, sometimes 4D+ “boxes”) * traveling salesman
I'm fascinated by problems, that are NP complete, but still can have a ton of optimizations that can reduce the time needed by many orders of magnitude (millions or more), like SAT solving. Or approximate solutions / heuristics like approx. traveling salesman. Seeing huge improvements on real-life problems, even if you know the problem is asymptotically exponential feels like you've fought against impossible odds and…
There's a whole subfield of CS, approximation algorithms, studying what you described. Interesting indeed.
Re: Hard Things in Computer Science
#18As another problem of applied CS I also suggest to add "Character Encoding" to the list of strongly underestimated complex problems :)
Agreed, and also just text in general, internationalization, line-breaks, horizontal vs vertical text, left-right vs right-left, etc, etc. OTOH that starts getting quite "application oriented" and where do you draw the line? compsci is perhaps more about computation and how to achieve it, analyze it, etc, and in that case even dates and times should not be in the list, being an "application" domain concern.
> where do you draw the line?
My language is written Right-to-Left. Jira couldn't care less about my market, so I don't use it, even though I could trivially add support myself in Firefox's User CSS file. But there are another 300 million people who speak RTL languages they are ignoring along with me. Is 300 million people a small market? "But everybody in tech speaks English" they argue.
Being _able_ to use their product in a language foreign to myself doesn't mean that I'll _choose_ to use their product given alternatives.
Re: Hard Things in Computer Science
#19Computing with limited numerical precision (aka floating point) is 1.000000000000003534 additional hard thing to deal with.
Modern computers can calculate with a very large finite precision using decimal types. We have so much machine to waste today that if calculations of that sort are relevant, just throw more iron at it.
Re: Hard Things in Computer Science
#20TTL 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 impr…
Yeah I stopped reading at that point, cache invalidation is not 'also known as TTL'.
It's a simplification but it isn't wrong. Mostly.