Live data from Hacker News

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

web.eecs.utk.edu

251–260 of 424 posts

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

#251
post #59

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.

Came here to post this. Tho most times my undo tree are single characters.

You should work on you long-term memory for the language's keywords, or on your variable naming ;-)

EDIT: Or are you programming in APL?

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

#252

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.

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.

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

#253
post #243
post #213

Earlier quoted context omitted.

Are unused variables really compiler errors in Go? That does seem very harsh, and very counter productive while developing. -Werror is all well and good, but while I’m in the middle of writing the code, it’s a bit much.

The theory is that given enough code, any antipattern that compiles will make its way into real use, and therefore the only way to make people stop using an antipattern is to refuse to compile it. Go trades inconvenience in the short term for removing an entire class of bugs and raising the readability floor of bad code.

That's an insane approach, eslint solves this just fine and is fully configurable for almost any style preference.

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

#255

For me "Local History" feature in WebStorm solves the issue. https://www.jetbrains.com/help/webstorm/local-history.html

Indeed it’s one of the reasons why I’m staying with JetBrains products. It’s really efficient, we can compare side by side the local history to understand where it went wrong all while keeping the git history clean. Because while I could do the same manually with git, when I’m in the flow thinking about/building/debugging a particular piece of code, moving out to select files to add to git and then filling a message…

It has also been in stock Eclipse since at least around 2010, when I started using it.

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

#257
post #228

Earlier quoted context omitted.

> the wrong way is not constructive. Well, open minded people can try other ways. Mine is sitting back and thinking instead of racing the keyboard to try out stuff until it works. Both ways (as I compare to my exclusively younger colleagues) reap results in about the same timespan, but I hardly type more than the actual code I need to type while my colleagues write and delete books ('iterate fast') in that time. It b…

> productivity of an employee by keystrokes, screen changes and # of commits. Aaargh, that's the most quality destroying metric possible.

The most easily gamed as well... I have no idea how these people thinking about introducing a metric to measure others don't realise that whenever that happens it just becomes another game.

It really isn't that hard to know that through experience and a little bit of forethought.

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

#258

For me "Local History" feature in WebStorm solves the issue. https://www.jetbrains.com/help/webstorm/local-history.html

I've found Local History on these JetBrains IDEs to be really helpful too. Particularly when combined with "Put Label" command (which I assign to a keyboard shortcut). This lets you insert a descriptive label info the stream of your local history snapshots (such as before you attempt something), so you can go straight to one of those labels and diff against current. Useful when you're trying out an approach with parts that may be discarded, as it's handy for reverting lines of current or overwriting and inserting blocks back from the snapshots. You automatically get a label after certain events, like a test fail or VCS commit. I think there's a snapshot after every save too, and you can configure autosave to happen whenever the editor pane loses focus of you want to.

The only things to watch out for with local history in these IDEs is that the snapshots are deleted after five days by default, and all are wiped if you need to delete your IDE cache for any reason.

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

#259
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.

If writing text more than 4 hours / day is what you do for a living, and you have at least 10 more years left of doing that, not learning Vim is just lazy. Vim gives you back enough time to think about what you're writing.

Also, if you go cold turkey, you'll be productive in less than a month, and arrive at a good workflow that fits you in less than six months, flow that you will improve over the years in amazing ways.

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

#260

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…

I actually think this is part of the problem- there is excellent tooling for making programming much, much easier, but many programmers are unaware of how to use them.

When I was an undergrad, I wrote code in a text editor without syntax highlighting, I debugged using log statements, and I manually tested every change by running my program manually with different inputs.

Of course those are all fixed by pretty basic things, but you would be surprised how many programmers literally don’t know how to use the tools they have, or are unaware of them. And some tools are downright hard to grok- git is definitely one of those.

Post reply on HN