Live data from Hacker News

Why is Git Autocorrect too fast for Formula One drivers?

blog.gitbutler.com

201–210 of 248 posts

Re: Why is Git Autocorrect too fast for Formula One drivers?

#201
post #153

Earlier quoted context omitted.

> I insist on this all the time in code reviews. Variables must have units in their names if there's any ambiguity. For example, `int timeout` becomes `int timeout_msec`. Same here. I'm still torn when this gets pushed into the type system, but my general rule of thumb in C++ context is: void FooBar(std::chrono::milliseconds timeout); is OK, because that's a function signature and you'll see the type when you're look…

One of my favorite features of std::chrono (which can be a pain to use, but this part is pretty sweet) is that you don't have to specify the exact time unit, just a generic duration. So, combined with chrono literals, both of these work just like expected: std::this_thread::sleep_for(10ms); // sleep for 10 milliseconds std::this_thread::sleep_for(1s); // sleep for one second std::this_thread::sleep_for(50); // does n…

I do something similar in Java by taking a java.time.Duration in any method dealing with time. We don't have the snazzy literal syntax, but that means users have to write:

  someMethodDealingWithTime(Duration.ofMillis(10));
  someMethodDealingWithTime(Duration.ofSeconds(1));
  someMethodDealingWithTime(50); // does not compile
Since these often come from config, i also have a method parseDuration which accepts a variety of simple but unambiguous string formats for these, like "10ms", "1s", "2h30m", "1m100us", "0", "inf", etc. So in config we can write:

  galactus.requestTimeout=30s
No need to bake the unit into the name, but also less possibility of error.

Re: Why is Git Autocorrect too fast for Formula One drivers?

#202

Earlier quoted context omitted.

100 ms is an insanely short window. I would say usually even 1000ms would be too short for me to recognize and kill the command, even if I realized immediately that I had done something wrong.

It's much too short to read an output, interpret it and realize you have to interrupt But often you type something, realize it's wrong while you are typing but not fast enough to stop your hand from pressing [Enter] That is one of the only situation 100ms would be enough to safe you That being said, the reason in the article for 100ms is just confused commander. Why would anyone: 1) encode a Boolean value as 0/1 in a…

Absolutely. When I'm booting up an unfamiliar system and trying to catch the BIOS prompt for something non-normal, even 5 seconds is often too short. For me to notice that the prompt has been given, read "PRESS DEL KEY TO ENTER SETUP, F11 FOR BOOT OPTIONS, F12 FOR PXE BOOT" (or whatever), understand it, look for the F11 key on the possibly unfamilar keyboard on my crash cart, and press it, can often take me more than 5 seconds. Especially if it's not a single key required but a control sequence. Maybe I'm slow. I always change these prompts to 10 seconds if they are configurable. Or I'll make a label with the options and stick it on the case so I can be prepared in advance.

Re: Why is Git Autocorrect too fast for Formula One drivers?

#203
post #148

Earlier quoted context omitted.

Maybe worth noting here that 100ms is well under the human reaction time. For context, professional sprinters have been measured to have a reaction time in the ballpark of 160ms, for pretty much everyone else it's higher. And this is only for the reaction, you still need to move your hand, press the keys, etc.

There are different ways to measure reaction time. Circumstance is important. Reaction to unreasonable, unexpected events will be very slow due to processing and trying to understand what happens and how to respond. Examples, you are a racecar driver, participating in a race, you're driving your car on a racetrack in a peaceful country. An armed attack: Slow reaction time, identifying the situation will take a long t…

I also want to add in the context of human sprinters & F1 drivers, their reaction time is measured via leg actuation, which for a creature evolved to be an object-throwing endurance hunter is going to have worse neural & muscular latency than, say, your forearm. That is why using your finger to trigger a response in a conventional computer time tester can get such high speeds, cause we're essentially evolved for it.

Re: Why is Git Autocorrect too fast for Formula One drivers?

#204

Earlier quoted context omitted.

Git has notoriously bad CLI (as other commenters here noted). Your snarky comment provides no value to this discussion.

On the contrary, it offers a little levity and humour, and possibly even the chance for some self-reflection as you consider why you thought it was appropriate to insult the folk who manage Git. I'm sure you can manage at least one of those?

Your comment isn't funny, just snarky. I suggest you read again HN guidelines and do some reflection yourself.

Also, if you see it as insult, that's your mistake. It is just a simple empirical observation. I'm not saying it's an original thought - feel free to Google more about this topic.

I won't waste any more time since you obviously aren't interested in discussion.

Re: Why is Git Autocorrect too fast for Formula One drivers?

#205
post #117

Earlier quoted context omitted.

I have a very hard time relating to everyone else complaining about ~~lack of units~~ being unable to read/remember API docs. But using `chunk_time_ms` where ms is MICROseconds?! That's unforgivable, and I hope for all our sakes, you don't have to use that lib anymore! :D

The sheer number of APIs of modern coding is exhausting, I can't imagine either trying to keep all the stuff I'm using in my head or having to go back to the docs every time instead of being able to just read the code.

do you primarily write rust, or js?

Re: Why is Git Autocorrect too fast for Formula One drivers?

#206

For reference, Valtteri Bottas supposedly recorded a 40ms!!! reaction time at the 2019 Japanese Grand Prix. https://www.formula1.com/en/video/valtteri-bottas-flying-fin...

Is there a random time between the red lights and the green lights, or is it always the same? Because that feels more like learning the timings than reacting to something

No green lights, when the reds go out it is race start but there is a random delay after all reds lighting up and then going off.

Re: Why is Git Autocorrect too fast for Formula One drivers?

#207
post #18

I think it makes sense, if I typed something wrong, I often feel it before I can read it, but if I already pushed enter, being able to ctrl+c within 100 ms is enough to save me. I'm pretty sure I've also aborted git pushes before they touched anything before I put this on, but this makes it more reliable.

You are talking about an anticipatory response. Human response have been studied extensively and it is broadly accepted that ~100ms is the minimum for physiological processing and motor response to stimuli. If you feel you go faster you are anticipating your reaction.

Re: Why is Git Autocorrect too fast for Formula One drivers?

#208

Earlier quoted context omitted.

In this case the reaction starts before you hit enter, as you're typing the command So, you type `git pshu ` and realise you made a typo before you've finished typing. You can't react fast enough to stop hitting enter but you can absolutely ctrl+c before 100 more ms are up

I'm still pretty skeptical of this claim. If you type 60 wpm, which is faster than an average human, but regular for people who type as professionals, you spend on average 200ms on a keystroke. 60 standard words per minute means 300 chars per minute [0], so 5 chars per second which is 200ms per char. Many people type faster than this, yes, but it's all still very much pushing it just to even meet the 100ms limit, and…

Typing is not string of reactions to stimuli.

Re: Why is Git Autocorrect too fast for Formula One drivers?

#210

Earlier quoted context omitted.

https://www.gnu.org/fun/jokes/ed-msg.en.html "Note the consistent user interface and error reportage. Ed is generous enough to flag errors, yet prudent enough not to overwhelm the novice with verbosity."

> not to overwhelm the novice with verbosity that doesn't make complete sense, in unixland it's old-timers who understand the beauty of silence and brevity, while novices scan the screen/page around the new prompt for evidence that something happened

Ed helps induce novices into the way of the old-timers because it loves them and wants them to be happy.
Post reply on HN