Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why is Git Autocorrect too fast for Formula One drivers?

blog.gitbutler.com

Post reply on HN
Print view View original

121–130 of 248 posts

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

#121

Post by llm_trw »

ekidd wrote: post #98
nikau wrote: post #78

Earlier quoted context omitted.

How wasteful, ed uses just ? for all errors, a 3x saving

Ed also uses "?" for "Are you sure?" If you're sure, you can type the last command a second time to confirm. The story goes that ed was designed for running over a slow remote connection where output was printed on paper, and the keyboard required very firm presses to generate a signal. Whether this is true or folklore, it would explain a lot. GNU Ed actually has optional error messages for humans, because why not.

So much of computer conventions evolved for very good reasons because of physical limitations.

When each line of code was it's own punch card having a { stand alone on a line was somewhere between stupid and pointless. Also explains the reason why lisps were so hated for so long.

By the same token today you can tell which projects use an IDE as the only way to code them because of the terrible documentation. It is after all not the end of the world to have to read a small function when you can just tab to see it. Which is true enough until you end up having those small functions calling other small functions and you're in a stack 30 deep trying to figure out where the option you passed at the top went.

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

#122

Post by Dylan16807 »

stouset wrote: post #120
Dylan16807 wrote: post #84

Earlier quoted context omitted.

I'd say the new addition is more of a special case of rounding than it is messing up types.

1 was also accepted as a Boolean true in this context, and it still is in other contexts.

> 1 was also accepted as a Boolean true in this context, and it still is in other contexts.

Is "was" before the change described at the end of the article, or after it?

Before the change, any positive number implied that the feature is on, because that's the only thing that makes sense.

After the change, you could say that 1 stops being treated as a number, but it's simpler to say it's still being treated as a number and is getting rounded down. The interpretation of various types is still messy, but it didn't get more messy.

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

#124

Post by zxvkhkxvdvbdxz »

schacon wrote: post #32
a3w wrote: post #29

Earlier quoted context omitted.

deci is 1/10, deca is 10/1. So decisecond is correct.

I understand, I meant I tried to say the word “decisecond” out loud and we debated if that was a real word or if I was attempting to say “deca” which was understandable.

It's very standardized (SI), meaning 1/10:th. Althought not so commonly used with seconds.

You might be more familiar with decimeters, deciliters, decibels or the base-10 (decimal) numbering system.

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

#125

Post by egypturnash »

chuckadams wrote: post #113
vunderba wrote: post #100

Earlier quoted context omitted.

> EH? I feel like that would also make a good response from the text parser in an old-school interactive fiction game. Slightly related, but I remember some older variants of BASIC using "?" to represent the PRINT statement - though I think it was less about memory and more just to save time for the programmer typing in the REPL.

It was about saving memory by tokenizing keywords: '?' is how PRINT actually was stored in program memory, it just rendered as 'PRINT'. Most other tokens were typically the first two characters, the first lowercase, the second uppercase: I remember LOAD was 'lO' and DATA was 'dA', though on the C64's default character glyphs they usually looked like L and D . All this being on a C64 of course, but I suspect most vers…

C64 basic was tokenized into one byte, with the most significant bit set: https://www.c64-wiki.com/wiki/BASIC_token

Each command could be typed in two ways: the full name, or the first two letters, with the second capitalized. Plus a few exceptions like "?" turning into the PRINT token ($99, nowhere near the PETSCII value for ?) and π becoming $FF.

The tokens were expanded into full text strings when you would LIST the program. Which was always amusing if you had a very dense multi-statement line that expanded as longer than the 80 characters the c64's tokenizer routine could handle, you'd have to go back and replace some or all commands with the short form before you could edit it.

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

#126

Post by fragmede »

chuckadams wrote: post #113
vunderba wrote: post #100

Earlier quoted context omitted.

> EH? I feel like that would also make a good response from the text parser in an old-school interactive fiction game. Slightly related, but I remember some older variants of BASIC using "?" to represent the PRINT statement - though I think it was less about memory and more just to save time for the programmer typing in the REPL.

It was about saving memory by tokenizing keywords: '?' is how PRINT actually was stored in program memory, it just rendered as 'PRINT'. Most other tokens were typically the first two characters, the first lowercase, the second uppercase: I remember LOAD was 'lO' and DATA was 'dA', though on the C64's default character glyphs they usually looked like L and D . All this being on a C64 of course, but I suspect most vers…

D♠

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

#127

Post by bmicraft »

physicles wrote: post #89

The root cause here is poorly named settings. If the original setting had been named something bool-y like `help.autocorrect_enabled`, then the request to accept an int (deciseconds) would've made no sense. Another setting `help.autocorrect_accept_after_dsec` would've been required. And `dsec` is so oddball that anyone who uses it would've had to look up. I insist on this all the time in code reviews. Variables must…

> Variables must have units in their names if there's any ambiguity

Then you end up with something where you can write "TimoutSec=60" as well as "TimeoutSec=1min" in the case of systemd :)

I'd argue they'd been better of not putting the unit there. But yes, aside from that particular weirdness I fully agree.

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

#128

Post by scubbo »

cardamomo wrote: post #26

Reading this post, the term "software archeology" and "programmer archeologist" come to mind. (Thank you, Vernor Vinge, for the latter concept.)

Grrrr, this is such a bugbear for me. I was so excited to read "A Fire Upon The Deep" because hackers talked up the concept of "software archeology" that the book apparently introduced.

The concept is briefly alluded to in the prologue, and then...nada, not relevant to the rest of the plot at all (the _effects_ of the archeology are, but "software archeologists" are not meaningful characters in the narrative). I felt bait-and-switched.

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

#129

Post by bmicraft »

jonas21 wrote: post #93
cobbal wrote: post #80

Earlier quoted context omitted.

It's a decent, if uncommon, unit for human reactions. The difference between 0 and 1 seconds is a noticeably long time to wait for something, but the difference between n and n+1 milliseconds is too fine to be useful.

Milliseconds are a commonly-used unit. It doesn't really matter if 1 ms is too fine a granularity -- you'll just have to write "autocorrect = 500" in your config file instead of "autocorrect = 5", but who cares?

If you're going to store that unit in one byte (possible even signed) suddenly deci-seconds start making a lot of sense

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

#130

Post by fragmede »

zxvkhkxvdvbdxz wrote: post #118
jonas21 wrote: post #93

Earlier quoted context omitted.

Milliseconds are a commonly-used unit. It doesn't really matter if 1 ms is too fine a granularity -- you'll just have to write "autocorrect = 500" in your config file instead of "autocorrect = 5", but who cares?

Sure, yes. But for human consumption, decisecond is something one can relate to. I mean, you probably cannot sense the difference in duration between 20 and 30 ms without special equipment. But you can possibly sense the difference between 2 and 3 deciseconds (200 ms and 300 ms) after some practice. I think the issue in this case was rather the retrofitting a boolean setting into a numerical setting.

The difference between 20 ms and 30ms is the difference between 33 fps and 50 fps which is entirely noticable on a 1080p60hz screen.
Post reply on HN