The art of solving the problem in question and ONLY the problem in question.
Why GNU grep is fast (2010)
41–50 of 133 posts
Re: Why GNU grep is fast (2010)
#42what is grep?
A text search utility in Unix. Name comes from a command in the text editor ed and stands for "global regular expression print".
Thank-you, guys, but I was kidding. I've been using Linux and other Unixes since 1998. I just got impressed in how this post became busy with everything, but Linux programming.
Re: Why GNU grep is fast (2010)
#43Earlier quoted context omitted.
You can do that in any programming language by, well, not computing unused values.
That's like saying anyone can make money by just making money. It's a null statement!
In the context of the comment I replied to, no, it's not.
Haskell gives you some constructs that makes this easier but there exists no program whose Haskell implementations will run faster because of this, only programs that are easier to make fast.
Re: Why GNU grep is fast (2010)
#44That'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)
#45The inverse is this...what is modern software doing that makes them so slow?
Re: Why GNU grep is fast (2010)
#46This applies very well to optimization, too. There are only really two ways to optimize code: 1) make it do less 2) make it do more at a time. The first corresponds to using more efficient algorithms and data structures. The second is parallelism.
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 svelte shape.
* We end up finding more crap to remove then we'd thought at the start.
* We can cut down misguided arguments from wannabe architects of "what if we'll need x" by saying "we'll add this back when someone asks for x". It's much easier to point out that x is currently pointless with concrete code than at the demiurge phase where everything is possible and timelines are ignored.
* We can chop at the problem as a team, without having a long sequential and solitary step of "designing the best system". Amdahl's law applies to dev teams as well.
Re: Why GNU grep is fast (2010)
#47Earlier quoted context omitted.
If this story was just a blogspam saying "Hey look I found this article from 1991 which is still relevant" then yes, because the story would be worth nothing by itself. But this story is actually an email (from 2010) written by the guy WHO ORIGINALLY WROTE GREP, making it a pretty damn interesting source in its own right. In that sense, the 1991 article is very much an aside. In conclusion, no.
> by the guy WHO ORIGINALLY WROTE GREP Just a pedantic remark: He (Mike Haertel) originally wrote GNU grep. Grep, on the other hand, was originally written by Ken Thompson.
Good point, well made :)
Re: Why GNU grep is fast (2010)
#48Earlier quoted context omitted.
> "The fastest method to execute is an empty method." The fastest method to execute is an empty method that was never called. The fastest method to execute is an empty method that was never called and never written. The fastest method to execute is an empty method that was never called and never written and never planned.
This is why I say I'm at my most efficient when I just don't do any work at all.
Wally? Is that you?
Re: Why GNU grep is fast (2010)
#49In other words the correct choice of algorithm and data structure can dramatically simplify a problem and the amount of code and time needed to solve it. It also means that having tools where you can quickly apply different techniques, ahem, composable functions, that you can search for more efficient solutions with a lot less effort. That doesn't solve the smartness problem but it makes it a lot more tractable.
>It also means that having tools where you can quickly apply different techniques, ahem, composable functions
The key word there is composable, and not functions.
Re: Why GNU grep is fast (2010)
#50In case you're interested to see what older HN contributors had to say about this, here are some of the previous submissions, all of which have significant discussion: https://news.ycombinator.com/item?id=1626305 , 1193 days ago, 115 comments https://news.ycombinator.com/item?id=2393587 , 972 days ago, 68 comments https://news.ycombinator.com/item?id=2860759 , 842 days ago, 43 comments ( ionelm also pointed out a pre…
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.