Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Applying the Linus Torvalds “Good Taste” Coding Requirement

medium.com

Post reply on HN
Print view View original

241–250 of 302 posts

Re: Applying the Linus Torvalds “Good Taste” Coding Requirement

#241

Post by akkartik »

rndgermandude wrote: post #79
akkartik wrote: post #13

I dunno, the first example seems unsatisfying. The original has that ugly condition, the "good" version seems overly clever. And for all the talk of taste and aesthetics, both versions ignore an elephant in the room: defensively dealing with `entry` being absent from the list. Not that I've never abused addresses like this. But having written this multiple times, I currently prefer something like this: remove_list_en…

Like Linus example, this is just an example too and does not cover or comment on all the issues, so there are still elephants lurking in the shadows, just to name a few: - Can entry be NULL? (segfault) - Can head be NULL (list is empty)? (segfault) Since the Linus example has the apparent precondition that the entry to be removed must be present in the list, there are no segfaults with proper API use. Since your code…

I guess my fundamental criticism is this: how is a list traversal that doesn't check for the end of list being held up as an example of "good taste"?

You're right that they're all just examples. I'm just a random guy on the internet, and it's easy to push back against me. But we all have the tendency to nod along when someone we respect says something sagely on TED. It seemed useful to point out that the sage has no clothes on in this case. So go ahead, point at my skimpy cladding as well. I won't mind.

Re: Applying the Linus Torvalds “Good Taste” Coding Requirement

#242

Post by akkartik »

marcell wrote: post #54
akkartik wrote: post #13

I dunno, the first example seems unsatisfying. The original has that ugly condition, the "good" version seems overly clever. And for all the talk of taste and aesthetics, both versions ignore an elephant in the room: defensively dealing with `entry` being absent from the list. Not that I've never abused addresses like this. But having written this multiple times, I currently prefer something like this: remove_list_en…

This version is more clear for a human, but it does contain duplicate logic. This line: head = head->next; is another form of this line: prev->next = prev->next->next; Both delete by setting "->next". Code duplication is a common source of bugs, and that's the rationale behind Linus's version, which eliminates duped code.

See my comments regarding blindly removing "duplication" at https://news.ycombinator.com/item?id=12798796 (point 4)

Re: Applying the Linus Torvalds “Good Taste” Coding Requirement

#243

Post by RandomOpinion »

TickleSteve wrote: post #213
RandomOpinion wrote: post #188

Earlier quoted context omitted.

You have 20 years of experience on this kind of stuff and don't recognize the textbook example code for handling the head pointer case of a linked list? Well, okay... (It's at least 23 years old because I learned from textbooks that have this example code way back then. It probably dates all the way back to K&R.)

What textbook would that be exactly?? (not that it matters) The point isn't "can I understand it"... the point is "Would someone who hadn't seen it before have to do another mental operation to understand it?" ...and yes... dereferencing is another operation you have to do in your head to understand it.

Well, I'm at work so I can't dig around my library but it was easy enough using date range restrictions to find an academic example in Google that dates back to '99: http://cslibrary.stanford.edu/105/LinkedListProblems.pdf . (It was actually the first hit.) Searching further backwards in time is left as an exercise to the reader.

Multi-level pointer dereferencing is a fundamental C / assembly language skill and Linus' example was just about the most basic example there is.

Re: Applying the Linus Torvalds “Good Taste” Coding Requirement

#244

Post by [deleted] »

thomasahle wrote: post #135
PJDK wrote: post #2

I was given a piece of advice very early on in my career that I've always been grateful for, which is fundamentally the same as this. IF and FOR are both code smells. One case of this is just simplifying loops with some functional goodness var listOfGoodFoos = new List (); for(var i = 0; i VS return listOfAllFoos.Where(x => x.IsGood); But perhaps a more interesting point is it can also be a a sign of DRY gone wrong -…

This also comes easy, if you are using a more expressive language: remove e [] = [] remove e (e:xs) = xs remove e (x:xs) = x : remove e xs This even has the benefit of making it very clear whether you've remembered the case where 'x' is not in the list.

[deleted]

Re: Applying the Linus Torvalds “Good Taste” Coding Requirement

#245

Post by alkoumpa »

marcell wrote: post #54
akkartik wrote: post #13

I dunno, the first example seems unsatisfying. The original has that ugly condition, the "good" version seems overly clever. And for all the talk of taste and aesthetics, both versions ignore an elephant in the room: defensively dealing with `entry` being absent from the list. Not that I've never abused addresses like this. But having written this multiple times, I currently prefer something like this: remove_list_en…

This version is more clear for a human, but it does contain duplicate logic. This line: head = head->next; is another form of this line: prev->next = prev->next->next; Both delete by setting "->next". Code duplication is a common source of bugs, and that's the rationale behind Linus's version, which eliminates duped code.

Not only is it duplicate, it also contains nasty "behavior". If prev->next equals NULL then dereferencing this would result in segfault, so in this case another if statement is required.

Re: Applying the Linus Torvalds “Good Taste” Coding Requirement

#246

Post by YCode »

Noseshine wrote: post #232
YCode wrote: post #154

Earlier quoted context omitted.

Some food for thought: http://www.computerworld.com/article/3004387/it-management/h... "I’m not a nice person, and I don’t care about you. I care about the technology and the kernel — that’s what’s important to me."

See what I already wrote. This is like marketing research - what do you believe, what people tell you or the data about what they actually do? Because the data say what I already wrote. So you might as well interpret this as "Linus is a very humble guy" and have better support from the data. Or, alternatively, you can believe that a really mean person who doesn't care about others and behaves badly still managed to h…

I don't understand what this has to do with refuting the original claim:

> Ultimately I think Linus's contributions to Software are pantheon, but he should not be looked to for imitation or lessons. His lessons for success are detrimental to the vast majority of software engineers.

You're not supplying any examples others can learn from or benefit from imitating, you're just asserting they must exist.

Re: Applying the Linus Torvalds “Good Taste” Coding Requirement

#247

Post by jprzybyl »

akkartik wrote: post #224
zAy0LfpBZLC8mAC wrote: post #107

Earlier quoted context omitted.

Really, if you think the good version is overly clever, you probably have a very fundamental problem with your abstract reasoning. A very human one, as history is full of people having that problem--and ultimately, the good version taking over anyway. How about this: subtract(n){ if(n==0){ return m; } r=m; for(x=0;x People for a long time had strong objections to a number "0", because it doesn't make sense to have a…

".. if you think the good version is overly clever, you probably have a very fundamental problem with your abstract reasoning.." Just to show that you're talking out your ass, here's a code snippet where I did the address of address thing in precisely the same "remove from linked list" situation. In a VM and programming language and operating system that I wrote from scratch[1]. https://github.com/akkartik/mu/blob/a9…

I love your project! The of testing pervading the whole system is a very good one. I also like parameters being immutable unless they're a product, that's a great way of making passing references hurt less.

I still prefer the version Linus recommended. It's not for speed - I think it's more understandable. It's more simple (in the way Richard Hickey says, one strand rather than many) and there is less of it. Proving it correct would be easier, not that I actually would.

When people say "clever" to me, I think of code that is being tricky about something. (My canonical example of clever code is Duff's Device.) Linus' example doesn't read as tricky to me, it reads as very straightforward.

Re: Applying the Linus Torvalds “Good Taste” Coding Requirement

#248

Post by TickleSteve »

RandomOpinion wrote: post #243
TickleSteve wrote: post #213

Earlier quoted context omitted.

What textbook would that be exactly?? (not that it matters) The point isn't "can I understand it"... the point is "Would someone who hadn't seen it before have to do another mental operation to understand it?" ...and yes... dereferencing is another operation you have to do in your head to understand it.

Well, I'm at work so I can't dig around my library but it was easy enough using date range restrictions to find an academic example in Google that dates back to '99: http://cslibrary.stanford.edu/105/LinkedListProblems.pdf . (It was actually the first hit.) Searching further backwards in time is left as an exercise to the reader. Multi-level pointer dereferencing is a fundamental C / assembly language skill and Linus…

We will have to agree to disagree on that point.... And I have just as much experience in c as Linus.

Re: Applying the Linus Torvalds “Good Taste” Coding Requirement

#249

Post by akkartik »

jprzybyl wrote: post #247
akkartik wrote: post #224

Earlier quoted context omitted.

".. if you think the good version is overly clever, you probably have a very fundamental problem with your abstract reasoning.." Just to show that you're talking out your ass, here's a code snippet where I did the address of address thing in precisely the same "remove from linked list" situation. In a VM and programming language and operating system that I wrote from scratch[1]. https://github.com/akkartik/mu/blob/a9…

I love your project! The of testing pervading the whole system is a very good one. I also like parameters being immutable unless they're a product, that's a great way of making passing references hurt less. I still prefer the version Linus recommended. It's not for speed - I think it's more understandable. It's more simple (in the way Richard Hickey says, one strand rather than many) and there is less of it. Proving…

Thanks! I'm very happy that you noticed that little feature about immutability so quickly. I'd love to hear from you off-thread if you have any more questions or comments about Mu (email address in my profile).

I tried in my original comment not to bring Linus into it. I didn't want to be just another person on the internet poking holes at a famous person. If the examples had both included a guard for the end of the list I'd have been like, "eh, no accounting for taste, but ok," and moved on in silence. But we shouldn't be teaching/encouraging people to focus on minor considerations like the number of `if`s when there's a larger problem with undefined behavior. Since you already took a look at Mu, here's a place where I try to elaborate on this belief system: https://github.com/akkartik/mu/blob/07b54625f7/001help.cc#L7...

Re: Applying the Linus Torvalds “Good Taste” Coding Requirement

#250

Post by ptomato »

majewsky wrote: post #159
Noseshine wrote: post #95

Earlier quoted context omitted.

You make claim after claim, and I think they do need substantiating evidence. After all, I find it highly unlikely that if he were even 10% as bad as you make it sound he would be the head of one of the most successful projects - especially since everybody working with him does so voluntarily. There would have been breaks long ago. The fact that the Linux kernel held together under the original author loudly speaks a…

I won't argue with your main point, but a fair share of kernel devs are probably not working there voluntarily, since they write kernel code for their employer.

I'd expect that most devs capable of writing reasonable Linux kernel code would not have difficulty finding employment somewhere else doing something else.
Post reply on HN