3 ms·

I have a tangentially related issue. It's completely irrational, but I can't shake it. Sometimes when writing code, I need to add a block that looks a lot like

I have a tangentially related issue. It's completely irrational, but I can't shake it. Sometimes when writing code, I need to add a block that looks a lot like an existing one, so I'll copy it and paste just below. (Yes, I know, DRY. Sue me :) The irrational part comes in when it's time for me to make the tweaks. Maybe I'm working on a yaml config file, and I need to specify two objects that are mostly the same, with minor changes to one of them. I'll make sure I'm working on "the copy", and not "the original". So, let's say I start with this: - author: E. Hemingway title: The Old Man and the Sea medium: hardcover edition: 1 published: 1952 And the project manager says I need to add the second edition paperback to the list. I'll find that block, copy the whole thing, and *then make sure I don't disturb the "original": - author: E. Hemingway title: The Old Man and the Sea medium: hardcover edition: 1 published: 1952 - author: E. Hemingway title: The Old Man and the Sea medium: trade edition: 2 published: 1953 Basically, I've internalized that my bits have a color[1]. [1] https://ansuz.sooke.bc.ca/entry/23 https://ansuz.sooke.bc.ca/entry/23

ccalloway 5y ago
It makes some sense. You don't want to accidentally make some of your edits on one version and some of them on the other version. That would mean that you end up with wrong data, and also have to slowly unwind your changes correctly, if you want to get back the original. So you have to arbitrarily choose one and keep in your mind that that's the one to be edited. You could choose the 'bottom' one. But because object persistence is pervasive, you choose the 'new' one.
samatman 5y ago
This is very closely related to a merge problem git can't solve which pijul can. Bits have a colour, sure, but they have a(t least one) history as well, and that at least can be reasoned about mathematically.
- function_seven 5y ago
  The irrationality comes from the fact that I end up with exactly the same text file no matter what. My edit path (directed graph of atomic edits that arrive at the new file) can go many ways to the same result, but I find myself hating one path, and liking another. Even in the "good" path results in more keystrokes during editing. When I save my changes to git or svn or whatever, the new file will be the same regardless of edit path taken to create it. But during the editing operations, I had a nagging pull to make sure the characters I changed were from the copy.
mellavora 5y ago
A) why is this irrational, and if so, why is irrational sub-optimal given that the issue involves a non-(fully)-rational system (you)? B) The habit seems very effective, why would you want to 'shake' a very efficient process? C) DRY is an end-state which makes sense for (some) code. It is not at all clear that it makes sense for i.e. yaml config files, where it is expected that numerous items may have many similarities. Sounds to me that by internalizing that bits are colored you have improved your engineering skills.
- function_seven 5y ago
  A, B) I'm not sure I did a good job illustrating with my example. But there are times when the new text needs to appear above the text I copied. In that case, I'll take extra effort to paste the section to edit above the existing, to make sure I'm editing the "new" text. Even if it takes a bit more effort to position my cursor above the copied text. So in vim, I might yank an entire line and paste it immediately ("yyp"). This automatically pastes below the yanked line and positions the cursor on the new line. But let's say I want to make the edit above the existing. This situation is wrong. The new line was just pasted below the existing. Even though I'm looking at a pair of perfectly identical lines in the file, and could make my edit wherever I choose, I have this idea that one of those lines is the original and the other is the copy. And I don't want to edit the original. In other words, whether I "do it wrong" or "do it right", the end result will be bit-for-bit identical. But one of those edit paths bothers me and the other one doesn't. So in the yanking and pasting process, I'll take the extra time to move my cursor above the copied line, then paste it in so as to preserve the "lineage" of the text. This has nothing to do with version control or any other actual efficiencies. It's just my brain being weird. I don't gain any actual benefit, just a calm mind :) C) Yeah, I was just heading off any nitpicks about my comment.

ccalloway 5y ago

It makes some sense. You don't want to accidentally make some of your edits on one version and some of them on the other version. That would mean that you end up with wrong data, and also have to slowly unwind your changes correctly, if you want to get back the original. So you have to arbitrarily choose one and keep in your mind that that's the one to be edited. You could choose the 'bottom' one. But because object persistence is pervasive, you choose the 'new' one.

samatman 5y ago

This is very closely related to a merge problem git can't solve which pijul can. Bits have a colour, sure, but they have a(t least one) history as well, and that at least can be reasoned about mathematically.

function_seven 5y ago
The irrationality comes from the fact that I end up with exactly the same text file no matter what. My edit path (directed graph of atomic edits that arrive at the new file) can go many ways to the same result, but I find myself hating one path, and liking another. Even in the "good" path results in more keystrokes during editing. When I save my changes to git or svn or whatever, the new file will be the same regardless of edit path taken to create it. But during the editing operations, I had a nagging pull to make sure the characters I changed were from the copy.

mellavora 5y ago

A) why is this irrational, and if so, why is irrational sub-optimal given that the issue involves a non-(fully)-rational system (you)? B) The habit seems very effective, why would you want to 'shake' a very efficient process? C) DRY is an end-state which makes sense for (some) code. It is not at all clear that it makes sense for i.e. yaml config files, where it is expected that numerous items may have many similarities. Sounds to me that by internalizing that bits are colored you have improved your engineering skills.

function_seven 5y ago
A, B) I'm not sure I did a good job illustrating with my example. But there are times when the new text needs to appear above the text I copied. In that case, I'll take extra effort to paste the section to edit above the existing, to make sure I'm editing the "new" text. Even if it takes a bit more effort to position my cursor above the copied text. So in vim, I might yank an entire line and paste it immediately ("yyp"). This automatically pastes below the yanked line and positions the cursor on the new line. But let's say I want to make the edit above the existing. This situation is wrong. The new line was just pasted below the existing. Even though I'm looking at a pair of perfectly identical lines in the file, and could make my edit wherever I choose, I have this idea that one of those lines is the original and the other is the copy. And I don't want to edit the original. In other words, whether I "do it wrong" or "do it right", the end result will be bit-for-bit identical. But one of those edit paths bothers me and the other one doesn't. So in the yanking and pasting process, I'll take the extra time to move my cursor above the copied line, then paste it in so as to preserve the "lineage" of the text. This has nothing to do with version control or any other actual efficiencies. It's just my brain being weird. I don't gain any actual benefit, just a calm mind :) C) Yeah, I was just heading off any nitpicks about my comment.