Live data from Hacker News

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

web.eecs.utk.edu

231–240 of 424 posts

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

#231

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 for that piece of code that isn’t working and doing that every few minutes to preserve intermediate state is a nightmare for my productivity.

It can and should be done automatically by the IDE to enhance developper productivity by getting out of its mind. There is no reason why I should be thinking about that, isn’t that all the point of using IDE and tools to develop ? Seems like using git for that is still re-inventing the wheel

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

#232
post #111

Earlier quoted context omitted.

Likewise. This whole thread is totally bizarre. The closest imaginable thing I might do is wrapping some block of code in an if(false) {..} or #ifdef it out, when I'm refactoring and feeling unsure about my changes. But is that even the same thing that we're talking about here?

Hello from the bizarro universe of people who do this all the time and can't imagine the opposite. Do you never rewrite some code only to realize it didn't precisely capture all the edge cases of the thing you rewrote? In those cases I use the git gutter in VSCode to view what the old code looked like and compare and contrast to the new version to see what I missed. It seems to me that that's the same as what these e…

you cant do it on a first go. i write a draft of what has to happen. often i draw drafts of the solution on a4 sheets of paper(my own blackboard, the best tool i know to make software). i do research and update the drafts to a point where i type in the code. code is the last thing i do. i laught that i make coloring books and not coding :) i am quite fast and i have little problems with switching contexts. the code is much better as i "see" the whole solution. i have much better abstractions. in a recent task i have found with this way of coding, many places with bad code and made them better as they didnt fit the cleanliness of the soulution. they just stand out like the eifel tower in paris.

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

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

Eclipse has the same thing.

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

#234

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.

Scheme has #; which comments out a single expression. This covers most but not all use-cases. (It doesn’t help for commenting-out subsequences, like if you wanted to remove the top half of a begin block.)

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

#235
post #197

My school’s JS IDE [1](“JavaScript without the bad parts”) has a history feature that is just a scrolling list of thumbnails of the code at every change. The IDE doesn’t have many features overall, but the history is actually very nice and natural and feels like it should be standard in any IDE. [1] https://www.ocelot-ide.org/

I'm curious, does it actually use the local machine to compile files? Or is the compilation done on some remote instance?

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

#236

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.

Sometimes I do stuff like

   // FIXME try new way mm/dd/yy
   if(1)
   {
     ... new way ...
   }
   else
   {
      ... old way ...
   }

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

#237
NetBeans have something very similar to this. You can get a diff on all changes to a file, both from your commits and from just a timeline. You can click to transfer old code to the new version blockwise as needed. No need for copy-pasting.

It's set to delete history after 7 days but can be changed to never. Haven't realy used it much last few years though so don't know if it's still there.

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

#238
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…

> Emacs similarly doesn't lose changes in this scenario, but instead of making a tree, it has a ring and undo is an action that can be undone.

Emacs default undo system is really, really bad. Like worse than the "standard" one. But after installing the emacs undotree it becomes sane.

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

#239
post #237

NetBeans have something very similar to this. You can get a diff on all changes to a file, both from your commits and from just a timeline. You can click to transfer old code to the new version blockwise as needed. No need for copy-pasting. It's set to delete history after 7 days but can be changed to never. Haven't realy used it much last few years though so don't know if it's still there.

The same feature is available in IntelliJ IDEA and likely in the other JetBrains IDEs.

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

#240
post #213

Earlier quoted context omitted.

This is the one thing above all else which has kept me off Go. Tentatively comment out a line or two and the whole compilation process may come crashing down because now you have a declared but unused variable, and mere warnings apparently aren't Gestapo enough in this particular universe. You then find and comment out the offending declaration, only for the compilation to die in flames again because now you referenc…

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.

Even worse if you include something that isn't used, that's also a fatal error.
Post reply on HN