[Request] Looking for resources on terrible algorithms, architecture, and design
Hey folks! I think this request is right up this comm's alley. I'm sure that we all know bogo sort but, what other terrible/terribly inefficient algorithms, software architecture, or design choices have you been horrified/amused by?
I, sadly, lost a great page of competing terrible sorting algorithms, but I'll lead with JDSL as a terrible (and terribly inefficient) software architecture and design. The TL;DR is that a fresh CS guy got an internship at a company that based its software offering around a custom, DSL based on JSON that used a svn repo to store all functions in different commits. The poor intern had a bad time due to attempting to add comments to the code, resulting in customer data loss.
I unironically had a screening interview with a recruiter that asked "If you were creating a startup, would you use microservices?". She didn't like that my answer was "It depends, I don't have enough information to answer".
There are subfields of computer science dedicated to this question. A good starting point for the theory would be Pessimal algorithms and simplexity analysis, which lays out two concepts:
The time & space simplexity of an algorithm indicates best-case lower bounds on resource usage, and
An algorithm is pessimal if no equivalent algorithm wastes more time/space/etc.
For example, common folklore is that sorting has O(n lg n) time complexity, depending on assumptions. In the paper, they give that sorting has Ω(n ** (lg n / 2)) time simplexity; any algorithm which takes more time, like bogosort, must do so through some sort of trickery like non-determinism or wasting time via do-nothing operations.
Sleep sort is kind of like count sort but with added overhead. Both have a complexity of O(n+m) with n being the length and m the value of the max element.
The optimum of O(n * log n) is based on the assumption that the only information about the values is obtained by comparison. If you operate on integer keys I would recommend radix sort. It has a complexity of O(n * w) where w is the length (read logarithm) of the key.
I can't find the name/source at the moment, but if you enumerate all turing machines and run them concurrently* you will find the optimal algorithm for your problem in O(1) and executed that.
To my knowledge the algorithm is so inefficient on small input that it takes hours to solve integer addition.
* You run the first turing machine one step, than the first two one additional step, that the first tree... This allows you to run an unlimited amount of TMs an unlimited amount of steps.