But why? Why create a tool that does `git status` 10x faster?
Why be slow when you can be fast?
Fast Directory Listing on Linux
11–20 of 75 posts
Re: Fast Directory Listing on Linux
#12> As an added bonus, those casts will fend off the occasional frontend developer who accidentally wanders into the codebase.
https://blog.aurynn.com/2015/12/16-contempt-culture
Code that intentionally celebrates its unapproachability is not a badge of honor or pride, even as a joke. It might occasionally be an unavoidable necessity, in which case it needs enough documentation that the next person who has to deal with it has the best chance possible.
Re: Fast Directory Listing on Linux
#13 Every directory has entries "." and "..", which we aren't interested in. We filter them out with a helper function Dots().
bool Dots(const char* s) { return s[0] == '.' && (!s[1] || (s[1] == '.' && !s[2])); }
Re: Fast Directory Listing on Linux
#14> As an added bonus, those casts will fend off the occasional frontend developer who accidentally wanders into the codebase. https://blog.aurynn.com/2015/12/16-contempt-culture Code that intentionally celebrates its unapproachability is not a badge of honor or pride, even as a joke. It might occasionally be an unavoidable necessity, in which case it needs enough documentation that the next person who has to deal with…
I mean, I think that was a bit of a joke. It's ironic that you rail against this dude for "code that's hard to understand" in reply to a long-form prose article about understanding the code and how it got there..
We'll probably have to agree to disagree.. but that blog post doesn't really resonate for me... especially the end where it talks about keep it to your "own language." I've never had patience for identity politics especially in the case of a god-damn programming language.
Re: Fast Directory Listing on Linux
#15> As an added bonus, those casts will fend off the occasional frontend developer who accidentally wanders into the codebase. https://blog.aurynn.com/2015/12/16-contempt-culture Code that intentionally celebrates its unapproachability is not a badge of honor or pride, even as a joke. It might occasionally be an unavoidable necessity, in which case it needs enough documentation that the next person who has to deal with…
[deleted]
Re: Fast Directory Listing on Linux
#16But why? Why create a tool that does `git status` 10x faster?
Why create a computer when an abacus counts just as effectively :) Time, precious time! We're all born with a limited number of breaths, let's not waste them sighing while waiting for a simple task to complete. In this way faster tooling is a very real method otherwise pure-tech projects can prolong the lives of people. Fix a slow popular tool and the effect is multiplied
Re: Fast Directory Listing on Linux
#17Every directory has entries "." and "..", which we aren't interested in. We filter them out with a helper function Dots(). bool Dots(const char* s) { return s[0] == '.' && (!s[1] || (s[1] == '.' && !s[2])); } why would you iterate over every single file entry? both . .. entries will land at one end of sorted list anyway.
"." and ".." are filtered out before sorting. Sorting is O(N^2) in the common case (when there are fewer than 65 files in a directory), so it pays off to reduce the number of entries by 2 before we get there.
Re: Fast Directory Listing on Linux
#18> As an added bonus, those casts will fend off the occasional frontend developer who accidentally wanders into the codebase. https://blog.aurynn.com/2015/12/16-contempt-culture Code that intentionally celebrates its unapproachability is not a badge of honor or pride, even as a joke. It might occasionally be an unavoidable necessity, in which case it needs enough documentation that the next person who has to deal with…
I mean, I think that was a bit of a joke. It's ironic that you rail against this dude for "code that's hard to understand" in reply to a long-form prose article about understanding the code and how it got there.. We'll probably have to agree to disagree.. but that blog post doesn't really resonate for me... especially the end where it talks about keep it to your "own language." I've never had patience for identity po…
> It's ironic that you rail against this dude for "code that's hard to understand"
I'm sure that it was a joke, and that doesn't make it better. I'm not suggesting that this code was hard to understand, and I enjoyed the article. I'm calling out this particular point, and suggesting that even as a joke, mocking "frontend developers" is very much from the same territory that promotes "Real Programming" and mocks people for their choice of programming language or technology.
Re: Fast Directory Listing on Linux
#19> As an added bonus, those casts will fend off the occasional frontend developer who accidentally wanders into the codebase. https://blog.aurynn.com/2015/12/16-contempt-culture Code that intentionally celebrates its unapproachability is not a badge of honor or pride, even as a joke. It might occasionally be an unavoidable necessity, in which case it needs enough documentation that the next person who has to deal with…
You are quoting a self-deprecating joke. I care deeply about my code being readable, which can be quite challenging when writing high-performance code close to the metal. I'm self-consciously aware of every tricky bit I put in my code. I have to be confident it's worth it (usually because it makes things faster in the real world) and offset the added complexity by writing documentation.
Re: Fast Directory Listing on Linux
#20> As an added bonus, those casts will fend off the occasional frontend developer who accidentally wanders into the codebase. https://blog.aurynn.com/2015/12/16-contempt-culture Code that intentionally celebrates its unapproachability is not a badge of honor or pride, even as a joke. It might occasionally be an unavoidable necessity, in which case it needs enough documentation that the next person who has to deal with…
That was clearly tongue-in-cheek. No need to rail against the author. Lay down the outrage pitchforks man.