Linus Torvalds' good taste argument for linked lists, explained
1–10 of 339 posts
Re: Linus Torvalds' good taste argument for linked lists, explained
#2Thank you, very well written.
Re: Linus Torvalds' good taste argument for linked lists, explained
#3Good post. Not a "show hn" though, is it?
Re: Linus Torvalds' good taste argument for linked lists, explained
#4Good post. Not a "show hn" though, is it?
Correct—reading material doesn't qualify for Show HN. Otherwise every submission could have "Show HN" on it. We've taken that out of the title now.
Submitters: before putting Show HN on a title, please read the rules: https://news.ycombinator.com/showhn.html.
Re: Linus Torvalds' good taste argument for linked lists, explained
#5I don't disagree with it being written well. I don't feel like using C and pointers is helpful for getting the point across.
After reading for a minute I realized it's all about pointer and C specific stuff, I am not going to revisit that just for an article...
Re: Linus Torvalds' good taste argument for linked lists, explained
#6Although I liked the 'elegant' code after reading it, in general I would try to shy away from 'elegant' solutions that are actually harder to understand. Unless you are working with high-performance programs, most of the time you don't care about one or two extra branches. It's usually more beneficial to write code that can be easily understood by a future-you or by another person in your team: less time invested in understanding code, more time dedicated to actually fixing issues that matter. If performance becomes an issue, you'll catch that in profiling easily (because everybody here is profiling before trying to improve the performance of a piece of code, right?).
Re: Linus Torvalds' good taste argument for linked lists, explained
#7I understand the general point (and value) of reframing the problem or the solution in a way that removes special cases ... but in this case I would actually prefer the first solution over the second. The second solutions reminds me of the old-school perl culture, and JavaScript culture, where 'cleverness' (which always manifests itself as terseness as if lines of code were expensive), takes precedence over maintainability and understandability. Your code is going to be potentially maintained years in the future by developers of all levels - make it easy on them by practicing the principle of least surprise. In this case, this means using a traditional implementation of a linked list that most developers would be familiar with.
Re: Linus Torvalds' good taste argument for linked lists, explained
#8Good post. Not a "show hn" though, is it?
Correct—reading material doesn't qualify for Show HN. Otherwise every submission could have "Show HN" on it. We've taken that out of the title now. Submitters: before putting Show HN on a title, please read the rules: https://news.ycombinator.com/showhn.html .
Author here. Thanks for fixing the title, I should have seen that!
Re: Linus Torvalds' good taste argument for linked lists, explained
#9How does an interviewer measure good taste? You the interviewer could have been the result of a variety of metrics, none of which are good taste related. Bad taste is endemic in corporate and corporate startups(if you enter the millions in funding budget) for the simple reason that adequate taste is more reliable.
Edit: Within 30 seconds this got downvoted by cowards with no response. Enough with lurker culture. Say something.
Re: Linus Torvalds' good taste argument for linked lists, explained
#10> A particularly beautiful outcome is that the implementation has consistent semantics for the edge cases
Not sure if this is actually a benefit or not. Edge cases are notoriously hard to debug, so it's sometimes actually nice to have a branch that specifically handles edge cases. Conceptually, it's also much more difficult to wrap one's head around. I would be interested to see how much of the cs101 solution is compiled away and if there are any tangible benefits of being clever here.
PS: If the linked list is stored in contiguous memory (if you're using a slab allocator, for example), you can actually be even more clever (I'll leave that as an exercise to the reader).