3 ms·

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

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<n;x++){ r--; } return r; } People for a long time had strong objections to a number "0", because it doesn't make sense to have a number for nothing! Why not just have no number at all! 0 is not a number, it's a special case! Wrapping it up in arithmetic like that is just overly clever! After all, 0 is not a number! The whole problem with that is the preconceived and completely unjustified notion that 0 is not a number. Just accept that 0 is a number, and suddenly, things become much easier to reason about, much more elegant to work with. Similarly, the whole problem here is that you have the preconceived and completely unjustified idea that removing the first element is a special case. You can define it to be, just as you can define 0 to be a special case. But you could just as well simply let go of that preconceived idea and accept that it's not, and suddenly all the problems that you imagine are there disappear, and you have simpler code, just as having integer types with a zero makes for simpler code.

akkartik 10y ago
".. 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/a90faae990/edit/003-shortcuts.mu#L87 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 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 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 https://github.com/akkartik/mu/commit/ea5e7fd4cb from Apr 2016. The previous version was from Sep 2015. [4] https://en.wikipedia.org/wiki/Shuhari https://en.wikipedia.org/wiki/Shuhari
- jprzybyl 10y ago
  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.
  - akkartik 10y ago
    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#L75 https://github.com/akkartik/mu/blob/07b54625f7/001help.cc#L7...
- zAy0LfpBZLC8mAC 10y ago
  > 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]. I'm no sure what exactly that code/that change is supposed to tell me, so I can't tell whether it's a good argument. Mind condensing it down/pointing out what specifically you mean? > 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. Well, that depends on whether you want to make a point for other people in the discussion or discuss some issue with a specific person. As such, that was not really a judgement of your person, but rather a general statement about a group of people (which obviously might be wrong in some cases). > (Clever analogy there about 0. Totally agree with it. Utterly non-applicable in this instance.) You mean not applicable in the case of your code, or in the code in the article, or what else? (edit: and yeah, I realize how the wording might give the impression that I was talking specifically to/about you, but I really wasn't, I was just using what you wrote as the opportunity, so I ended up addressing you :-)

akkartik 10y ago

".. 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/a90faae990/edit/003-shortcuts.mu#L87 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 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 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 https://github.com/akkartik/mu/commit/ea5e7fd4cb from Apr 2016. The previous version was from Sep 2015. [4] https://en.wikipedia.org/wiki/Shuhari https://en.wikipedia.org/wiki/Shuhari

jprzybyl 10y ago
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.
- akkartik 10y ago
  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#L75 https://github.com/akkartik/mu/blob/07b54625f7/001help.cc#L7...
zAy0LfpBZLC8mAC 10y ago
> 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]. I'm no sure what exactly that code/that change is supposed to tell me, so I can't tell whether it's a good argument. Mind condensing it down/pointing out what specifically you mean? > 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. Well, that depends on whether you want to make a point for other people in the discussion or discuss some issue with a specific person. As such, that was not really a judgement of your person, but rather a general statement about a group of people (which obviously might be wrong in some cases). > (Clever analogy there about 0. Totally agree with it. Utterly non-applicable in this instance.) You mean not applicable in the case of your code, or in the code in the article, or what else? (edit: and yeah, I realize how the wording might give the impression that I was talking specifically to/about you, but I really wasn't, I was just using what you wrote as the opportunity, so I ended up addressing you :-)