Hacker News Reader

I don't think it's a critique of writing performant code. I always took it to mean don't optimize your code before you know where the bottlenecks are. For example, I could spend a lot of time on a Boyer Moore string matching algorithm only to find later that my program actually spends very little time searching strings.

View on HN

I think of that quote as being in the context of the sorts of 'music box' programs people were writing in the 1970's. This little gear also has a cam that operated the ballerina's arm. It's the sort of thing you do when you need to stuff a FORTRAN compiler in 32k of memory.

If you write your code right then refactoring it to use a different more whatever algorithm should be if not easy at least 'not hard'.

> I could spend a lot of time on a Boyer Moore string matching algorithm

Could you?

It's like an hour to copy/paste a reference implementation and set up unit tests. Maybe an hour or two fine tuning the implementation for your language and benchmarking some use cases.

I'd been using the same C# Boyer-Moore impl for like 15 years, and happened to have just recently updated it for Span support. I doubt I have 8 hours into it in total, and it's thoroughly benchmarked and tested.

You're missing my point. Pick coding up something that for you would be an egregious waste of your time on this earth.

Reply on news.ycombinator.com