The author doesn't mention that the grid being initalized is square, and simply describes it as grid[rows][cols]. However, all his solutions are only correct for a square grid. One solution for arbitrary dimensions could be for (i = 0; i
You're updating the corners twice. Not really a problem with a simple assignment, but as no_protocol pointed out elsewhere [0], it could be if you ever wanted to change that to, say, an increment. Replace your second for statement with for (i = 1; i and you're golden. [0] https://news.ycombinator.com/item?id=12794235
Applying the Linus Torvalds “Good Taste” Coding Requirement
221–230 of 302 posts
Re: Applying the Linus Torvalds “Good Taste” Coding Requirement
#222Re: Applying the Linus Torvalds “Good Taste” Coding Requirement
#223I 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…
I don't think anyone's mentioned that there are two functional benefits to Linus's version: testability and performance. The author touched on testability. Dropping the "if" case eliminates one code path that may contain bugs. But also, the revised code may perform a lot better if you're searching a lot of short lists. In that case, the target item has a large, though not likely, chance of being first in the list. Th…
I do the exact same techniques in my game engine (sadly proprietary) - even in JavaScript its dead easy to run circles around both Three.js and Babylon.js in terms of performance to the point I'm simply amazed at how fast JavaScript VMs can be if you really push them.
Eliminating branches, cache misses and allocations in the main loop yielded by far the biggest performance boost. (For the curious, we abused ArrayBuffers to guarantee contiguous memory allocations in JavaScript)
Re: Applying the Linus Torvalds “Good Taste” Coding Requirement
#224I 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…
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…
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/a90faae990/edit/003-shor... [2]
Moreover, I lived with it for months before I decided it wasn't worth the cleverness[3]. In this case. So I have some plausible claim to having found the "simplicity on the other side of complexity" in this case[4].
As a general rule I'd recommend not reaching conclusions about people from things they write in a comment on the internet. You're looking at them through a tiny peephole into their belief system. When in doubt, ask questions. "Excuse me sir, do you have much experience with C?", "Are you saying pointers to pointers are always bad?", and so on.
(Clever analogy there about 0. Totally agree with it. Utterly non-applicable in this instance.)
[1] https://github.com/akkartik/mu
[2] Hard to read, I admit. There's a colorized version at http://akkartik.github.io/mu/html/edit/003-shortcuts.mu.html, but I only host the most recent version there.
[3] https://github.com/akkartik/mu/commit/ea5e7fd4cb from Apr 2016. The previous version was from Sep 2015.
Re: Applying the Linus Torvalds “Good Taste” Coding Requirement
#225These are great examples, and they hint to, but do not mention, the big counterpoint: development time. In his own examples, the author admitted that though the code was ugly, it worked. He then spent extra time reworking the existing code to make it, well, prettier. "If I had more time, I would have written a shorter letter." -- Voltaire The problem is that, in many (most?) professional settings, the developer is un…
"If I had more time, I would have written a shorter letter." -- Voltaire You're quoting Pascal, not Voltaire ;)
Re: Applying the Linus Torvalds “Good Taste” Coding Requirement
#226These are great examples, and they hint to, but do not mention, the big counterpoint: development time. In his own examples, the author admitted that though the code was ugly, it worked. He then spent extra time reworking the existing code to make it, well, prettier. "If I had more time, I would have written a shorter letter." -- Voltaire The problem is that, in many (most?) professional settings, the developer is un…
>Some projects, I daresay mostly open-source projects, can afford to be detached from the pressure of deadlines that corporations require That's partly why open source has staying power and so many corporate projects get junked.
Re: Applying the Linus Torvalds “Good Taste” Coding Requirement
#227I 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…
Another issue both versions have is that they will not tolerate head being NULL. Don't be afraid of double pointers, although they may seem overly clever at first glance, they can be really helpful for situations like this. Linus's code is considerably shorter, and not particularly difficult to debug or to understand, assuming you understand double pointers. Another case where double pointers can be really useful is…
That last bit, though, I wouldn't recommend it as a slogan :) How about something like "adapt to the situation for life"?
Re: Applying the Linus Torvalds “Good Taste” Coding Requirement
#228Re: Applying the Linus Torvalds “Good Taste” Coding Requirement
#229Earlier quoted context omitted.
At some point that breaks down though doesn't it. I mean from one perspective a conditional in high level code doesn't describe "what is actually happening, either." That's especially true if an optimizing compiler or interpreter mangled it up. From another perspective your argument can be applied to any function call in library code. In either case I don't think your position is that strong.
> I mean from one perspective a conditional in high level code doesn't describe "what is actually happening, either." Sure, and from another perspective even the most efficient code does nothing to stop the heat death of the universe and is therefore functionally equivalent to doing anything else or nothing at all. However, that's just splitting hairs. It's not really an argument anyway, but rather a preference.
Re: Applying the Linus Torvalds “Good Taste” Coding Requirement
#230Earlier 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.