The inverse is this...what is modern software doing that makes them so slow?
Why GNU grep is fast (2010)
51–60 of 133 posts
Re: Why GNU grep is fast (2010)
#52Re: Why GNU grep is fast (2010)
#53That's also a Forth way of looking at optimization. Also reminds me of Kent Beck's quip when he was asked to optimize Chrysler's C3 system. He asked for validated sets of input and output. The programmers on site said the the system wasn't producing correct results yet. His response: In that case, I can make this real fast!
Re: Why GNU grep is fast (2010)
#54Earlier quoted context omitted.
It's great that you posted this, but it would be greater if HN was capable of doing it automatically since it is mostly trivial, but provides a lot of value.
In the past, there were semi-automated accounts that did this, but they made more people upset than happy. I would also prefer to see this happen on every story.
Re: Why GNU grep is fast (2010)
#55Re: Why GNU grep is fast (2010)
#56Re: Why GNU grep is fast (2010)
#57That's also a Forth way of looking at optimization. Also reminds me of Kent Beck's quip when he was asked to optimize Chrysler's C3 system. He asked for validated sets of input and output. The programmers on site said the the system wasn't producing correct results yet. His response: In that case, I can make this real fast!
[deleted]
Re: Why GNU grep is fast (2010)
#58Earlier quoted context omitted.
I've found that taking a considerable amount of time (days even) to determine the very best solution to a problem always results in less effort and less time spent coding overall. It's also no coincidence that the code becomes incredibly simple, more readable, more efficient, more flexible, easier to build on top of, and fewer issues down the road. Plus, in the end, depending on the magnitude of the project, less tim…
I wholly agree that it's worth investing in finding the best solution. However, in my experience I found that having concrete code to work with is invaluable . The magic bullet for me is to slap something concrete together, then aggressively refactor / cut the crap out of it. In some sense, building software is like sculpture. You've got this amorphous block of half baked ideas, and you need to turn it somehow into a…
It's like Fred Brooks said:
...plan to throw one away; you will, anyhow.Re: Why GNU grep is fast (2010)
#59Earlier quoted context omitted.
In the past, there were semi-automated accounts that did this, but they made more people upset than happy. I would also prefer to see this happen on every story.
hey hey hey, if you want hacker news to stay fast you should't make it do too much!
Standard "wisdom" for start-ups includes "If you're not embarrassed by your first product then you didn't launch early enough," and "Try the minimal viable product before investing too much time." I both launched early, and made sure the "product" was absolutely minimal. It got slated by the people it was trying to help, so I didn't bother refining it.
The experience was educational and instructive.
(minor edit to remove some inappropriate snark - apologies)
Re: Why GNU grep is fast (2010)
#60The classic Boyer-Moore algorithm suffers from the phenomenon that it tends not to work so efficiently on small alphabets like DNA.
The skip distance tends to stop growing with the pattern length because substrings re-occur frequently.
By remembering more of what has already been matched, one can get larger skips through the text.
One can even arrange 'perfect memory' and thus look at each character at most once, whereas the Boyer-Moore algorithm, while linear, may inspect a character from the text multiple times.
1: http://stackoverflow.com/questions/12656160/what-are-the-mai...