Live data from Hacker News

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

web.eecs.utk.edu

341–350 of 424 posts

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

#341

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…

How do you comment things out in the "English fiction/non-fiction" programming language?

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

#343

Earlier quoted context omitted.

Commiting frequently also has a substantial cost of needing to think of a commit message. If you don't think of a commit message, you'll never be able to find this version again. If you think up a message every 2 minutes, you'll quickly find you spend more time thinking of commit messages than writing code. I wish there was some kind of auto generated commit message. Things like: "Added function xyz()" or "Adjusted c…

> I wish there was some kind of auto generated commit message. Things like: > "Added function xyz()" or "Adjusted constant FOO to 27" or "Made lots of changes in file a.c,, b.c and c.c". I would argue that these are not good commit messages as they do not add information not already provided by the diff itself. Commit messages should communicate the intended effect of a change that has been made, rather than being a…

In which case I want a lossy summary of the diff... And it would be great if a tool could generate those for me...

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

#344

Earlier quoted context omitted.

I do the same. Many people comment about commiting frequently but that doesn't work for me: delete code + commit => I don't see the code anymore and my brain magically forgets about it. I need the quick feedback loop: commented code + uncommented code (all in one screen) => new code is going to look like a mix of both. If I have to use git to see commented code then the feedback loop is broken.

Commiting frequently also has a substantial cost of needing to think of a commit message. If you don't think of a commit message, you'll never be able to find this version again. If you think up a message every 2 minutes, you'll quickly find you spend more time thinking of commit messages than writing code. I wish there was some kind of auto generated commit message. Things like: "Added function xyz()" or "Adjusted c…

> It would be nice for git to have some kind of "commit of commits" which allows a hierarchical representation of commits. Ie. the "Add new printscreen feature" could have as subcommits "Create print renderer" and "Hook up print UI".

These are usually called feature branches.

> "Added function xyz()" or "Adjusted constant FOO to 27" or "Made lots of changes in file a.c,, b.c and c.c".

These are very poor commit messages that don't add anything of value; any diff viewer will tell you the same immediately, so you might as well leave it blank.

> Commiting frequently also has a substantial cost of needing to think of a commit message.

In larger, private feature branches I'll use loads of "asdf" commits that I will later squash together. These are my "ok, so far so good" points to make figuring out where I broke something easier.

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

#345

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…

Huh, I thought your first example was much more poetic. The vaguely run-on sentence does a much better job of evoking what's happening in the scene.

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

#346
post #292

My favorite IntelliJ feature is that it tracks the full history of the files in your project, losslessly and independently from your VCS. You can just go and pull source from Local history, from 5 minutes or 5 days ago (I'm not sure how far back it goes, I've never needed more than a week). Not something I use often but as a last ditch effort to find code that I've spent hours or days on and subsequently lost to a gi…

So does eclipse. The author seems unaware of similar solutions that have existed forever...

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

#347

Earlier quoted context omitted.

I do the same. Many people comment about commiting frequently but that doesn't work for me: delete code + commit => I don't see the code anymore and my brain magically forgets about it. I need the quick feedback loop: commented code + uncommented code (all in one screen) => new code is going to look like a mix of both. If I have to use git to see commented code then the feedback loop is broken.

Commiting frequently also has a substantial cost of needing to think of a commit message. If you don't think of a commit message, you'll never be able to find this version again. If you think up a message every 2 minutes, you'll quickly find you spend more time thinking of commit messages than writing code. I wish there was some kind of auto generated commit message. Things like: "Added function xyz()" or "Adjusted c…

You don't need to think about good commit messages. Just something that works for you and then rebase before pushing. That works for me at least

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

#348

Earlier quoted context omitted.

Newb emacs user here. Heavily reliant on spacemacs and tutorials and copy-paste, but I use it often. The undo-tree terrifies me.

I was too at first, until I learned the shortcut keys (to move to the next branch specifically), then everything was fine.

On this point, C-h m yields a complete list of keybindings for all modes active in whatever buffer you do it in.

More generally, for anyone new to Emacs and struggling as I once did, I can't recommend strongly enough that you learn how to use the help system (C-h C-h) and the built-in manual (M-x info). Emacs can teach you a great deal about itself, and these are the ways it does so.

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

#349

Earlier quoted context omitted.

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.

In C, you can wrap the 'commented' code with #if 0 ... #endif

In languages with multiline comments like /* and single-line comments like //, you can do:

    //*
    old_code();
    /*/
    new_code();
    //*/ 
And remove the first slash from the first line to switch between blocks.

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

#350
I didn't even realize I did this until reading this article.

I think the issue is that the undo/redo concept is inadequate. The author's solution of a persistent, read-only history seems like a step in the right direction, but that seems like it's much too slow of a workflow to beat out CTRL+Z/Y/Shift+Z, which is muscle memory for most.

Maybe we need something like a hyper lightweight git that can be controlled via keystrokes.

It's really disappointing how so many interfaces have been stagnant for so long. It sometimes feels like the only software difference between a computer from 2021 and 2001 is that the graphics and animations look nicer, but otherwise is just more of the same stuff.

Post reply on HN