Live data from Hacker News

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

web.eecs.utk.edu

31–40 of 424 posts

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

#31

For anyone that uses emacs, there is an excellent plugin "undo-tree" that solves this problem in a slightly different way. Everytime you undo a series of actions and then perform a new action, it creates a branch in the "tree". You can then visualize the tree and move through it quickly your entire buffer history.

This was my first thought. A timeline is nice, but the problem with a linear undo history is that if you undo and then edit, you lose access to the state before you undid. A tree is clearly the right structure for undo history.

You could just append a new state to the end of the timeline when you “undo”, so you never lose history. This is how undo works in Emacs by default.

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

#32
If looking at a source browser of a previous version of your code is not adequate to understanding how it worked, such that you wish to "rewind" to that version and run it, then your code is very poorly written.

It is indeed difficult sometimes to understand our own code some time after it is written, but by following good practices (ideally functional, with mostly pure functions), it should be readable.

I will venture a (biased) guess that one of the biggest challenges to understanding the code was the mutation of objects in the process. This is the #1 reason why functional programming is superior. With FP, you can grok what a function does and then comfortably forget about how it does it. It takes input, it produces output. Period. As long as you agree with the transformation algorithm, you can reduce that complexity to a one-line description.

Even in non-FP-first languages, you can usually write pure functions. Some scenarios have enough performance demands that you must mutate things, but probably most situations can be approached with FP styling.

All this rewinding and undoing is a distraction from the real problem. The real problem is that "it smells". It smells like a level of complexity that should not be.

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

#33
post #27

Earlier quoted context omitted.

This is excellent... for Vim users. A lot of developers either are not willing or haven't gotten around to learning the complexities of Vim, and use other IDEs like JetBrains or Eclipse. This workflow won't work for them.

JetBrains' various apps can do this as well with a feature called "Show Local History". I'm not sure where it is in the menus but you can hit shift twice and type it in. It automatically commits after every change since the IDE was opened, and can easily be diffed and reverted as needed. Reverting saves another entry, so you can revert back to the future as well.

It's in the context menu for files/classes at least.

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

#34
post #12
post #2

jetbrains IDEs have a local history feature that seems to do this

Yeah and it’s actually decent. That being said I don’t mind committing often. If I have a slew of small commits I squash them. Since I will need to commit at some point, I rather do it incrementally.

Committing removes the diff view in PyCharm, and I can't lose that.

By "diff view" I mean I can see all the changes I've done from the main branch.

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

#35
post #32

If looking at a source browser of a previous version of your code is not adequate to understanding how it worked, such that you wish to "rewind" to that version and run it, then your code is very poorly written. It is indeed difficult sometimes to understand our own code some time after it is written, but by following good practices (ideally functional, with mostly pure functions), it should be readable. I will ventu…

Nope. Sometimes I’m rewriting something and I just want to see what the old code looked like before I changed it. There’s nothing smelly about that.

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

#36
post #32

If looking at a source browser of a previous version of your code is not adequate to understanding how it worked, such that you wish to "rewind" to that version and run it, then your code is very poorly written. It is indeed difficult sometimes to understand our own code some time after it is written, but by following good practices (ideally functional, with mostly pure functions), it should be readable. I will ventu…

Are you certain the requirements can always be met without complexity?

Have you ever had to build an os kernel, a database, an mmorpg server, a realtime 3d game engine, a production compiler, jit, or garbage collector?

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

#37

I just searched and couldn't find a plugin for Atom called Yestercode. If there was one, I'd definitely use it.

It isn’t public [yet]. You should check out our plug-in CodeRibbon though! Available for Atom.

https://utk-se.github.io/CodeRibbon/

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

#39
post #15

I've gotten in the habbit of just commiting very frequently. I have a git alias "git cam" that just commits everything with the message "nt". Then once I've got something working, I use GitUp (which makes it very easy to merge/split/rearrange commits) to collapse all the nt commits into one or two coherent "real" commits. Maybe a little clunky, but works well for me.

Basically same deal here, though using 'magit' and 'wip' instead of 'nt'. ('No text', one assumes?)

Doesn't help with IDE settings and such, but that's such a niche situation that it doesn't matter at all for me.

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

#40
post #16

> Why is it so hard to see code from 5 minutes ago while in the middle of a change? In vim you can do: :earlier 5m to see the code you had 5 minutes ago. > (1) If you go to a prior state and then make a new change, you can no longer redo and all those changes are lost. Vim makes a tree, so that doesn't happen with it. When you undo and make a new change, you're just making a new branch. u/Ctrl-r goes from leaf to tru…

This is excellent... for Vim users. A lot of developers either are not willing or haven't gotten around to learning the complexities of Vim, and use other IDEs like JetBrains or Eclipse. This workflow won't work for them.

I am one of those "not willing" people. I encounter the same issue discussed here without even thinking about it, and solve it as such:

1. Realize I need to check how my new code looked like 5 min back. 2. Copy full file into clipboard, undo by a few steps 3. Do a temp commit on GitHub desktop 4. Paste the new code back and look at the diff on GitHub desktop, and if needed undo the temp commit from above.

Is this more clicks than the vin shortcut? Sure. But I don't have to go learn the internal tree structure representation of my text editor and spend my time in that universe. I have found a way to do what I need to with the tools I have in hand.

This is the same way how the majority of finance runs on excel when they could do better with better programing. In the end whether you get the job done in fields where you're not billed by the second is not dependent on how well you use your tools necessarily.

The other analogy is cars - for most people it's something that gets them places, for others it's a way of life if not at least a more involved proposition.

Post reply on HN