3 ms·

Counter-point to 5: Complex algorithms over simple data can have big performance payoffs, remove obstacles, and even simplify things. For instance, binary sea

by mrkeen 3y ago

Counter-point to 5: Complex algorithms over simple data can have big performance payoffs, remove obstacles, and even simplify things. For instance, binary search over a sorted array (as opposed to a BinaryTree object): • simplifies merging (it's just concat & sort) • no pointers, which makes serialisation easier, but also... • bypasses the need for serialisation • an array can be on disk, or in memory, or both (via mmap) • the data can be bigger than your ram • allows for 'cold starts': just point your program at the file/mapping and tell it to run, no 'loading into ram' step. • it's also cache-oblivious Another example is huffman coding. If you studied it at uni, you probably saw it as a Tree-based algorithm with the associated O(n logn) time complexity. I was unaware that there was an in-place, array-based method of constructing a Huffman tree in linear time. Of course 99% of the time, I'm doing back-end microservices and just using standard collection data structures. But if I ever had a 'big data' task at work, I would strongly prefer to be able to do it on a single machine with a big disk locally rather than buy into whatever the current flavour of MapReduce is.

rapsin4 3y ago
Don't forget, you, the dev is 99% of the time the most expensive resource. Maintainability and first to market are usually way more important.
- wredue 3y ago
  >dev is the most expensive resource This is not true. Ask Facebook, who have rewritten things multiple times explicitly because this is not true, but someone assumed it was >maintain ability and first to market are usually more important Maintainability and first to market are not trade offs for performance in most cases, no matter how much you want to propagate this ridiculous propaganda.
  - arp242 3y ago
    But the question is, would Facebook still be around if they didn't "just ship this turd lol"? I don't really have any insight in Facebook engineering over the years and it's a "what if" type of question that's essentially unanswerable, but the answer to that being "no" is very plausible. And Facebook really does have unique(-ish) scalability problems, and I bet rewrites would have been inevitable even with the best possible engineering, because who can write an application to deal with a billion users (2012, currently 3 billion) right from the start? When Facebook launched in 2004 this was pretty much unheard of, and even in today it remains pretty rare (much less 2012).
- bigstrat2003 3y ago
  This type of thinking is what has turned everyone's "desktop" app into an Electron piece of shit. It turns software into a race to the bottom where as long as it's just good enough for users to not drop it, companies say "ok let's do it". It's not good advice to give, imo.
  - zelphirkalt 3y ago
    I would not count electron app build on top of NPM or similar as a good example of what the GP was stating.
- RetroTechie 3y ago
  > Don't forget, you, the dev is 99% of the time the most expensive resource. That boils down to not valuing time of the people who use your software. Despicable attitude imho. Developer time is wasted once. User time is wasted for every user, each time the software is used, for as long as it remains in use. All these can be large: billions of users, many uses each day, software in use for decades. If you're the only user, no point to spend time on optimizing anything, unless you perceive it as too slow. If software has billions of users, then almost any effort in optimizing the tiniest bottleneck in it, is worth the effort. A good example of "the needs of the many (users) outweigh the needs of the few (developers)". A lot of software sits somewhere in between though (not that many users & performs at acceptable speed).
kagakuninja 3y ago
IMO binary search is not a fancy algorithm. Modern sort functions are fancy, and can have subtle bugs, which is why ordinary devs should not write their own. Even quicksort has foot guns. Rob Pike's response would probably be to profile the code first, then see if your fancy code or alternate data structure makes it faster.
returningfory2 3y ago
I don't see this as being a counterpoint. From the perspective of Pike's advice both "binary search over a sorted array" and a "BinaryTree object" are identical. They are just different implementations of the same data structure.

by mrkeen 3y ago

rapsin4 3y ago

Don't forget, you, the dev is 99% of the time the most expensive resource. Maintainability and first to market are usually way more important.

wredue 3y ago
>dev is the most expensive resource This is not true. Ask Facebook, who have rewritten things multiple times explicitly because this is not true, but someone assumed it was >maintain ability and first to market are usually more important Maintainability and first to market are not trade offs for performance in most cases, no matter how much you want to propagate this ridiculous propaganda.
- arp242 3y ago
  But the question is, would Facebook still be around if they didn't "just ship this turd lol"? I don't really have any insight in Facebook engineering over the years and it's a "what if" type of question that's essentially unanswerable, but the answer to that being "no" is very plausible. And Facebook really does have unique(-ish) scalability problems, and I bet rewrites would have been inevitable even with the best possible engineering, because who can write an application to deal with a billion users (2012, currently 3 billion) right from the start? When Facebook launched in 2004 this was pretty much unheard of, and even in today it remains pretty rare (much less 2012).
bigstrat2003 3y ago
This type of thinking is what has turned everyone's "desktop" app into an Electron piece of shit. It turns software into a race to the bottom where as long as it's just good enough for users to not drop it, companies say "ok let's do it". It's not good advice to give, imo.
- zelphirkalt 3y ago
  I would not count electron app build on top of NPM or similar as a good example of what the GP was stating.
RetroTechie 3y ago
> Don't forget, you, the dev is 99% of the time the most expensive resource. That boils down to not valuing time of the people who use your software. Despicable attitude imho. Developer time is wasted once. User time is wasted for every user, each time the software is used, for as long as it remains in use. All these can be large: billions of users, many uses each day, software in use for decades. If you're the only user, no point to spend time on optimizing anything, unless you perceive it as too slow. If software has billions of users, then almost any effort in optimizing the tiniest bottleneck in it, is worth the effort. A good example of "the needs of the many (users) outweigh the needs of the few (developers)". A lot of software sits somewhere in between though (not that many users & performs at acceptable speed).

kagakuninja 3y ago

IMO binary search is not a fancy algorithm. Modern sort functions are fancy, and can have subtle bugs, which is why ordinary devs should not write their own. Even quicksort has foot guns. Rob Pike's response would probably be to profile the code first, then see if your fancy code or alternate data structure makes it faster.

returningfory2 3y ago

I don't see this as being a counterpoint. From the perspective of Pike's advice both "binary search over a sorted array" and a "BinaryTree object" are identical. They are just different implementations of the same data structure.