Live data from Hacker News

Why is it so hard to see code from 5 minutes ago?

web.eecs.utk.edu

151–160 of 424 posts

Re: Why is it so hard to see code from 5 minutes ago?

#151

When making changes to a block of code or block of text, I frequently just comment out the code and rewrite it anew. I might copy-paste existing code (just to avoid stupid transcription errors). If its too large to see both what I'm writing, and the old code, at the same time, I just use two windows on the same file. This is relevant to writing fiction or non-fiction as well. For example, I didn't like this, so I com…

I do the same - both commenting out and viewing the file in parallel at different spots - vim vertical splits are great for that. In fact, one of my colleagues remarked that he never thought to view the same file alongside itself when he saw me do that when we were pairing.

As an aside, I think I wouldn't mind if a programming language would include two commenting syntaxes, one for ordinary comments, and another for commenting out. These are two very different use-cases, and distinguishing them syntactically might facilitate certain kinds of work-flows.

Re: Why is it so hard to see code from 5 minutes ago?

#152
Netbeans has had this feature for about a decade and I use it all the time for exactly the reasons suggested. I was pleased to see that IntelliJ has the same feature. The resolution doesn't need to be more than a couple of minutes. Netbeans will keep a couple of weeks of local history and prunes the old history down to one or two snapshots a day. It can get a little confusing if you are checking out vastly different versions of the same file from different branches since it doesn't record what branch you were working on at the time, but it nonetheless very useful.

Re: Why is it so hard to see code from 5 minutes ago?

#153
Sad to see so much judgement in this thread from developers who can't fathom why others would need this. "Sounds like trial an error." "Develop a better memory."

Programming is not black and white, there is no right or wrong way to do it. OP discovered a problem they had and wrote a solution for it, believing that others might need to solve the same problem. Clearly they were correct based on plenty of others chiming in with their own anecdotes, or tools they've discovered that help alleviate the same issue in other ways.

If you've never had to UNDO/REDO a block of code to revisit a previous state before moving forward again, kudos. But suggesting those that do are somehow going about programming in the wrong way is not constructive.

Re: Why is it so hard to see code from 5 minutes ago?

#154

Netbeans has had this feature for about a decade and I use it all the time for exactly the reasons suggested. I was pleased to see that IntelliJ has the same feature. The resolution doesn't need to be more than a couple of minutes. Netbeans will keep a couple of weeks of local history and prunes the old history down to one or two snapshots a day. It can get a little confusing if you are checking out vastly different…

> It can get a little confusing if you are checking out vastly different versions of the same file from different branches

I see that as a feature, not a bug. I’ve been saved countless times when I accidentally messed up my git or local state.

Re: Why is it so hard to see code from 5 minutes ago?

#156

When making changes to a block of code or block of text, I frequently just comment out the code and rewrite it anew. I might copy-paste existing code (just to avoid stupid transcription errors). If its too large to see both what I'm writing, and the old code, at the same time, I just use two windows on the same file. This is relevant to writing fiction or non-fiction as well. For example, I didn't like this, so I com…

I do the same - both commenting out and viewing the file in parallel at different spots - vim vertical splits are great for that. In fact, one of my colleagues remarked that he never thought to view the same file alongside itself when he saw me do that when we were pairing.

> one of my colleagues remarked that he never thought to view the same file alongside itself

I do this all the time in Emacs, usually to see two parts of the file that normally are too far apart to be visible at the same time. Collapsible sections can do similar, but to me it's quicker, more natural and more flexible to just split the window.

Re: Why is it so hard to see code from 5 minutes ago?

#157

Does anyone know if there’s a good way to do this in VS Code? I often hold cmd-z until I get to some version and copy code from it. Ideally I’d like to have a separate window where I can see a previous version without affecting the current file/view. Before anyone comments, git doesn’t cut it for this because no one commits after every -+1

Commit early, Commit often!

That's still way more overhead compared to undo/redo

Re: Why is it so hard to see code from 5 minutes ago?

#158

Earlier quoted context omitted.

I do the same - both commenting out and viewing the file in parallel at different spots - vim vertical splits are great for that. In fact, one of my colleagues remarked that he never thought to view the same file alongside itself when he saw me do that when we were pairing.

As an aside, I think I wouldn't mind if a programming language would include two commenting syntaxes, one for ordinary comments, and another for commenting out. These are two very different use-cases, and distinguishing them syntactically might facilitate certain kinds of work-flows.

Yes! Just today I was wishing that I could have syntax highlighting on commented code that I was refactoring. Just dim it a bit instead of turning it all grey.

Re: Why is it so hard to see code from 5 minutes ago?

#159

Earlier quoted context omitted.

I do the same - both commenting out and viewing the file in parallel at different spots - vim vertical splits are great for that. In fact, one of my colleagues remarked that he never thought to view the same file alongside itself when he saw me do that when we were pairing.

As an aside, I think I wouldn't mind if a programming language would include two commenting syntaxes, one for ordinary comments, and another for commenting out. These are two very different use-cases, and distinguishing them syntactically might facilitate certain kinds of work-flows.

Perl and Ruby have this. In Perl it's kind of an abuse of the perldoc system, like this:

    print "foo"
    =pod
    print "won't run"
    =cut
Ruby basically copied it, although I don't think these have documentation uses:

    puts "foo"
    =begin
    puts "won't run"
    =end
When I get to choose, I prefer sticking to // in C code so that I can use /* ... */ for hiding large blocks of code . . . although #if false ... #endif work too.

Re: Why is it so hard to see code from 5 minutes ago?

#160

When making changes to a block of code or block of text, I frequently just comment out the code and rewrite it anew. I might copy-paste existing code (just to avoid stupid transcription errors). If its too large to see both what I'm writing, and the old code, at the same time, I just use two windows on the same file. This is relevant to writing fiction or non-fiction as well. For example, I didn't like this, so I com…

Shouldn't it be "had he looked."? Also the second rendition makes doesn't include what the rest of the joggers are doing, yet the first one does. Not sure if intentional.

At first I gasped at your practice, because I never do that, but I see the point now. Mastery of language.

Post reply on HN