Hacker News Reader

Comment by bgilroy26 | Hacker News Reader

Thanks for the great read!

It's my life's dream to do a real-life process vs. algorithm design comparison like this one.

Some day, I will visit hundreds of the world's best kitchens (normalized for ingredients budget) and survey how the instructions filter down from the head chefs there to the prep cooks.

I would love to see the best practices in the process from raw ingredients to completed dishes abstracted to the highest level and then compared with concurrency libraries/best practices to see if there are any places where software design and kitchen instruction exhibit convergent evolution due to pressures they face that are similar on an abstract level.

View on HN

I, too, would love to see this kitchen-algorithm study done. Not just in how the instructions filter down, but also in how resources are allocated and locked.

What happens when two chefs are ready to fulfill an order at the same time? What happens if a resource, such as a stovetop, is under contention? Does the higher-up chef in the social hierarchy win whenever a resource is under contention (giving a whole new meaning to master-slave), or is there weight given to the priority of the task? Do kitchens evolve a verbal "code" to communicate hierarchy? Are there any large kitchens that don't use the strategy of tacking all orders on the same wall... and how was that strategy developed in the first place? And are any of these things taught in cooking schools?

Heck, this could be a whole book exploring a whole bunch of industries... construction, door-to-door marketing, and more. I have no idea who the ideally-situated person would be to do something like this (maybe it's you, or the OP), but if the right person started a Kickstarter campaign, I'd definitely contribute.

> It's my life's dream to do a real-life process vs. algorithm design comparison like this one.

I've done some simple analysis of card sorting. I've timed myself vs. other people sorting cards, where I use bucket sort and they use whatever they want. I usually beat them by about 20%, but that may just be because I've practiced more. I think bucket sort would have a clear advantage over naïve sorting if the deck had about 100 cards or more.

I've also tested bucket sort against merge sort, and they're about the same speed.

For my bucket sort algorithm, I use two iterations. First I sort the cards into three buckets, where the first contains cards 2 thru 5, the second contains 6 thru 10, and the third contains face cards. Then I do insertion sort on the buckets. On mergesort, I switch to insertion sort for sufficiently short lists.

Atul Gawande (surgeon and writer for The New Yorker) has done some of what you mention.

Read this. http://www.newyorker.com/reporting/2012/08/13/120813fa_fact_...

Reply on news.ycombinator.com