Linus Torvalds' good taste argument for linked lists, explained • Hacker News Board

Re: Linus Torvalds' good taste argument for linked lists, explained

#81

Post by alisonkisk » Sun, Dec 06, 2020, 11:08 PM UTC

zem wrote: post #49

macspoofing wrote: post #7

I 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 maintaina…

i think a lot of the reason it looks more "clever" than elegant is because c's syntax makes the "get the address of this field in a struct" operation so hard to read at a glance.

It's a lot easier to "get the address of this field in a struct" in C than in Java or Python or JavaScript.

Re: Linus Torvalds' good taste argument for linked lists, explained

#82

Post by Animats » Sun, Dec 06, 2020, 11:09 PM UTC

userbinator wrote: post #54

Linus isn't the first nor only person to discover this simplification, although I've usually encountered it as a "virtual head" using only a single indirection: https://news.ycombinator.com/item?id=18997420 It's interesting to see how divisive the opinions are. I see it as the difference between the "growth mindset" and not.

Isn't it in Knuth, vol. 1?

Re: Linus Torvalds' good taste argument for linked lists, explained

#83

Post by lordnacho » Sun, Dec 06, 2020, 11:09 PM UTC

bigyikes wrote: post #71

eloff wrote: post #26

Earlier quoted context omitted.

Looking at the code there are not just fewer lines, but fewer conditionals too. It's much simpler to read and understand. I got it at a glance, whereas I skimmed the typical approach and would still need to go over it more carefully to be sure it is correct. I think Linus is correct on this one.

Linus’ solution seems to add a layer of indirection, which I think is harder to grok than a simple condition.

But there's comments that explain it, so I think it's okay. I wouldn't leave a thing that has a mix of &, *, and -> without saying what it was supposed to do, but he does explain it.

I'm ok with clever code when it's explained in words.

Re: Linus Torvalds' good taste argument for linked lists, explained

#84

Post by [deleted] » Sun, Dec 06, 2020, 11:10 PM UTC

varjag wrote: post #69

Taniwha wrote: post #53

Earlier quoted context omitted.

While I mostly agree with you, I think that use of double indirect pointers is rare enough that in effect each use of one probably counts as a "line of code" when trying to understand what's going on. The one Linus doesn't like likely runs faster (at a microarchitectural level), it's also the thing I've done for 40 years now, it's what comes out of my fingers when I code linked lists, for me at least it's more unders…

It's very unlikely it is faster.

[deleted]

Re: Linus Torvalds' good taste argument for linked lists, explained

#85

Post by ewindal » Sun, Dec 06, 2020, 11:14 PM UTC

eloff wrote: post #26

macspoofing wrote: post #7

I 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 maintaina…

Looking at the code there are not just fewer lines, but fewer conditionals too. It's much simpler to read and understand. I got it at a glance, whereas I skimmed the typical approach and would still need to go over it more carefully to be sure it is correct. I think Linus is correct on this one.

Conditionals are so simple it’s basically the first thing anyone learns. Anyone can understand the first approach. The latter requires knowledge that is specific to lower level languages,concepts that are certainly not taught universally.

The latter approach is definitely not the easiest to understand. It is, however, what Linus considers «good taste in coding.»

Re: Linus Torvalds' good taste argument for linked lists, explained

#86

Post by GnarfGnarf » Sun, Dec 06, 2020, 11:14 PM UTC

Been programming since 1965. Strongly object to #2.

I respect the cleverness of Linus' solution. However, it really has no place in production code where not all journeymen are at the same lofty level.

The fact that it requires a detailed explanation exposes its impracticality.

Re: Linus Torvalds' good taste argument for linked lists, explained

#87

Post by coldtea » Sun, Dec 06, 2020, 11:17 PM UTC

macspoofing wrote: post #7

I 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 maintaina…

Only in this case the second solution is clearer, and not clever in the "old school Perl" way...

Re: Linus Torvalds' good taste argument for linked lists, explained

#88

Post by jariel » Sun, Dec 06, 2020, 11:17 PM UTC

In most cases clarity should win out over succinctness. (Sometimes succinct is more clear).

I absolutely prefer the first one in almost all cases, and would probably reject the second one on a code review.

Unless we're dealing with such a core, hyper-sensitive part of the system wherein the compiler would not find rough equivalence anyhow, and the material gains from supposedly 'fewer instructions' would be better.

i.e. a pragmatic performance optimization that was realized in the real world, due to the pervasive utilization of the code ... this would be acceptable.

But for the vast majority of what we do, this won't be the case.

Double-pointers are like flame throwers - they are very 'cool' to some, and technically, they do 'burn things faster', but are just excessively dangerous and almost assuredly not the right too. Unless, they actually are, wherein you get to be the dude who uses the flamethrower, but again, that's rare.

Reading this it seems more clear to me why git has such tremendous - and mostly unnecessary UX problems. There's a dimensionality of the craft being ignored.

Re: Linus Torvalds' good taste argument for linked lists, explained

#89

Post by nickelpro » Sun, Dec 06, 2020, 11:20 PM UTC

ewindal wrote: post #85

eloff wrote: post #26

Earlier quoted context omitted.

Looking at the code there are not just fewer lines, but fewer conditionals too. It's much simpler to read and understand. I got it at a glance, whereas I skimmed the typical approach and would still need to go over it more carefully to be sure it is correct. I think Linus is correct on this one.

Conditionals are so simple it’s basically the first thing anyone learns. Anyone can understand the first approach. The latter requires knowledge that is specific to lower level languages,concepts that are certainly not taught universally. The latter approach is definitely not the easiest to understand. It is, however, what Linus considers «good taste in coding.»

If you're coding in Linus's world you're going to understand indirection, the example is excellent given the context

Re: Linus Torvalds' good taste argument for linked lists, explained

#90

Post by coldtea » Sun, Dec 06, 2020, 11:20 PM UTC

ewindal wrote: post #85

eloff wrote: post #26

Earlier quoted context omitted.

Looking at the code there are not just fewer lines, but fewer conditionals too. It's much simpler to read and understand. I got it at a glance, whereas I skimmed the typical approach and would still need to go over it more carefully to be sure it is correct. I think Linus is correct on this one.

Conditionals are so simple it’s basically the first thing anyone learns. Anyone can understand the first approach. The latter requires knowledge that is specific to lower level languages,concepts that are certainly not taught universally. The latter approach is definitely not the easiest to understand. It is, however, what Linus considers «good taste in coding.»

>Conditionals are so simple it’s basically the first thing anyone learns.

That's neither here, nor there though.

The simplicity of a concept does not directly translate to how hard it makes the code (assembly is simpler in the sense of having fewer and simpler constructs than e.g. Python but much much harder to code in).

Conditionals, and the exponential increase in state space they bring, are still one of the biggest source of errors and complexity in code.