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

Vim's 400 line function to wait for keyboard input

geoff.greer.fm

Post reply on HN
Print view View original

111–120 of 239 posts

Re: Vim's 400 line function to wait for keyboard input

#111

Post by zhiyuany »

chadgeidel wrote: post #36
nkassis wrote: post #29

Earlier quoted context omitted.

If I remember correctly Joel wasn't opposed to refactoring old code. That article seemed to be mainly against wholesale rewrites which I agree in a most cases. He is now paying the price for taking this rule to the extreme. I think sometimes rewrites are unavoidable as tech on which the old code is based dies and the current code needs to continue to be extended. In Joel's company case they slowly ended up having to…

Exactly - I (incorrectly) assumed most folks had previously read the article. Mea culpa.

May I know which article? (I mean, the article about joel's paying the price.

Re: Vim's 400 line function to wait for keyboard input

#112

Post by eridius »

ggreer wrote: post #48
joosters wrote: post #13

But the code works. It supports lots of platforms through choice. Yes, you could make the code prettier if you dropped some platforms. Yes, you could refactor it to use some abstracting libraries that now exist. But the code works . If you rewrote the code, the best result you could end up with is the same functionality that still works. All other possible results are bad. There is nothing to be gained.

I made the page as a companion piece to a blog post[1]. The code works, but it's quite buggy. Also, it is almost certainly broken on outdated OSes. It's just that nobody uses the latest Vim on IRIX or VMS, so no bug reports get filed. A quick glance shows some obvious errors in RealWaitForChar(). For example: with typical preprocessor defines, it uses gettimeofday() in a select() loop. This will break if the system c…

Your blog post recommends using NeoVim today. I've considered looking at it several times, but the home page[1] still says

Is it ready to download and run now with all the features?

No. Although some features are a work in progress, Neovim isn't at a stable point. Using Neovim should be done with caution as things may change.

This warning is why I haven't yet tried switching over. Are they just being overly-cautious?

[1]: http://neovim.io

Re: Vim's 400 line function to wait for keyboard input

#113

Post by geofft »

SonicSoul wrote: post #33
geofft wrote: post #23

Earlier quoted context omitted.

And your old code doesn't have a test suite you can run on the new code? Well there's your problem. Testless code doesn't acquire bugs by just sitting around on your hard drive, but it doesn't lose any bugs that way, either, and without a test suite you can't afford to do anything but leave it sitting around.

You're assuming that old code doesn't have tests, or that tests can't be written for it, or that it can't be patched without a rewrite?

I'm assuming that if it doesn't have regression tests, the old code is untouchable / legacy code, because you can't add features to it without risking breaking something. If it does have regression tests, then you can rewrite it and only switch to the rewrite once it passes all tests. Joel's argument goes away, because the regression tests document exactly what obscure edge cases you wouldn't have thought of.

Re: Vim's 400 line function to wait for keyboard input

#114

Post by knodi123 »

brudgers wrote: post #71
stinos wrote: post #42

Earlier quoted context omitted.

It doesn't acquire bugs just by sitting around on your hard drive. Except when sometimes it does. That is, external factors reveal old bugs or introduce new ones. Like when you use it after installing a new package/driver/OS and it blows up. Or after years you give it to a new crazy user which somehow succeeds it hitting 20 keys at a time and your code doesn't handle that. I'm not saying occasions like those require…

There are also latent bugs which are inconceivable at design time and only become possible after several cycles of Moore's law. http://googleresearch.blogspot.com/2006/06/extra-extra-read-...

I remember I once went to great trouble to use a succession of old computers to copy my favorite DOS game off of a 5 1/4" floppy into a 3 1/2" floppy, and then from there onto a network, and then onto my laptop, so I could take it to school with me. And in the end, I learned that the game ran so fast on my laptop that your character would move at light speed and then die as soon as you pressed a button, because my laptop was too fast.

There was nothing wrong with the program, it just didn't expect to still be in use 17 years later.

Re: Vim's 400 line function to wait for keyboard input

#115

Post by zyztem »

harmil wrote: post #101
solutionyogi wrote: post #87

Earlier quoted context omitted.

He covers in the blog post: http://geoff.greer.fm/2015/01/15/why-neovim-is-better-than-v... From the blog post: That if statement’s conditions span 17 lines and 4 different #ifdefs. All to call gettimeofday(). Amusingly, even the body of that statement has a bug: times returned by gettimeofday() are not guaranteed to increase. User intervention or ntpd can cause the system clock to go back in time. The correct soluti…

ntpd guarantees (under the default settings now, though that's new... you can ask it to shoot you in the head, but I don't recommend that you use firearms in this way) that the clock will never go backwards. You're thinking of nptdate, a utility provided with ntpd, but which is only ever supposed to run at system initialization time to get the time close enough for ntpd to take over. If ntpd finds that the clock is a…

With Linux/NTP there was two times 23:59:59 UTC not long ago: https://access.redhat.com/articles/15145

Re: Vim's 400 line function to wait for keyboard input

#116

Post by nwmcsween »

omegaham wrote: post #53
x0x0 wrote: post #37

Earlier quoted context omitted.

A previous employer had a codebase that generated, on a full compilation, at least 10k warnings. That same codebase powered $200mm/year in revenue.

And if your developer time is better spent on producing more features than cleaning up your previously made code, you'll end up with 10.5k warnings. I'm sure that someone will freak out and cry, but as long as you can keep extending it and working with it, why fix it? Of course, technical debt builds up, and eventually you're badly locked in until you refactor, so it's a balancing act.

You're only looking at it from a sort of incompetent manager perspective. Those 10k warnings will produce exploits, they also make reasoning about the code much much harder costing time and money or even worse nobody understands it.

Re: Vim's 400 line function to wait for keyboard input

#117

Post by rootbear »

glass- wrote: post #92
rootbear wrote: post #65

I assume portability is why the function declaration is old K&R style and not ANSI prototype style. I'm always surprised when I see K&R style in modern(ish) code. I do miss the ability to declare multiple parameters of the same type without repeating the type name, though. Oddly, several modern languages (like D) seem to think that's a feature.

Check vim's style guide (:help style-example in vim), you'll find a note that says: > NOTE: Don't use ANSI style function declarations. A few people still have to use a compiler that doesn't support it.

Amazing. I wonder what platforms those are.

Re: Vim's 400 line function to wait for keyboard input

#118

Post by bjourne »

chadgeidel wrote: post #18
joosters wrote: post #13

But the code works. It supports lots of platforms through choice. Yes, you could make the code prettier if you dropped some platforms. Yes, you could refactor it to use some abstracting libraries that now exist. But the code works . If you rewrote the code, the best result you could end up with is the same functionality that still works. All other possible results are bad. There is nothing to be gained.

I am reminded of the old Joel on Software article "Things you should never do part 1": http://www.joelonsoftware.com/articles/fog0000000069.html From the article: "The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they've been fixed. There's nothing wrong with it. It doesn't acquire bugs just by sitting around on your hard drive…

He is talking about commercial software where the only thing that counts is money in and money out. That a free software developer should never clone and rewrite another developers software is false. Lots of successful projects are rewrites or clones of existing software, like QMail over Sendmail and vim itself over vi.

Re: Vim's 400 line function to wait for keyboard input

#119

Post by ianamartin »

joosters wrote: post #64
samf wrote: post #62

Earlier quoted context omitted.

I agree, I just think your initial statement was a bit extreme.

Yeah, on a re-read, my comment is too sure of itself. Never say never! But while there are always edge cases, IMO code rewriting is something that is almost never worth it. Especially a maintainability rewrite just for the sake of maintainability.

I'm so sick of hearing this tripe. Rewriting code is almost always a good idea because after you re-write it, you have some snowball's chance in hell of understanding it.

Oh, but Jeff Attwood said . . . Whatever. And then Jeff Atwood said something very different.

Blah, blah, blah.

If the engineer that wrote the code isn't at the company anymore, and no one really gets it now, rewrite it. At least you will have some chance of understanding the new bugs instead of failing to understand the old bugs (and there are bugs in that old code that you, for whatever reason can't read.)

Rewrite. Always.

Re: Vim's 400 line function to wait for keyboard input

#120

Post by tyho »

wspeirs wrote: post #90
ggreer wrote: post #48

Earlier quoted context omitted.

I made the page as a companion piece to a blog post[1]. The code works, but it's quite buggy. Also, it is almost certainly broken on outdated OSes. It's just that nobody uses the latest Vim on IRIX or VMS, so no bug reports get filed. A quick glance shows some obvious errors in RealWaitForChar(). For example: with typical preprocessor defines, it uses gettimeofday() in a select() loop. This will break if the system c…

Many companies (FactSet for example) still use VMS, and vim on those systems... I think folks would be surprised how many legacy systems are still out there.

How likely are these companies to upgrade to the latest vim though? It is not like these companies running VMS are following the latest version, if vim dropped crufty old OS's, then the code would be simpler and the old OS's would not notice.
Post reply on HN