Vim's 400 line function to wait for keyboard input • Hacker News Board

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

#31

Post by amelius » Wed, Jul 15, 2015, 6:39 PM UTC

dustingetz wrote: post #15

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 wonder why didn't the vim folks write the abstracting library?

Simple. Just imagine how this code evolved. First, they started with a simple 1-liner, that took at most 5 minutes to come up with. Then another platform was added, this took another 5 minutes, etc.

Abstracting, however, would take perhaps a day of work. A full library such as libuv would have taken maybe a couple of weeks to develop.

So there you are. QED.

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

#32

Post by MBlume » Wed, Jul 15, 2015, 6:40 PM UTC

I'd like to see what the code looks like after it's been through the preprocessor in a modern Linux environment -- I'm guessing a hell of a lot shorter?

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

#33

Post by SonicSoul » Wed, Jul 15, 2015, 6:40 PM UTC

geofft wrote: post #23

chadgeidel wrote: post #18

Earlier quoted context omitted.

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…

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?

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

#34

Post by mkagenius » Wed, Jul 15, 2015, 6:41 PM UTC

Can't believe people are going mad over a code snippet when they don't know under what coditions they were written and under what coditions the code base is being maintained.

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

#35

Post by gjkood » Wed, Jul 15, 2015, 6:42 PM UTC

bpicolo wrote: post #25

gjkood wrote: post #9

Does this have a noticeable performance impact for a typical vim end user, using it in an interactive file editing workflow? On any modern hardware? I suppose there may be some negative performance impact if we need to use it for an automated/batch workflow (I can't think of many where something like 'sed' won't be better suited).

Doubtful, ifdefs are compile-time

Agreed. I am in my 'Ready > Fire > Aim' mode today.

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

#36

Post by chadgeidel » Wed, Jul 15, 2015, 6:46 PM UTC

nkassis wrote: post #29

chadgeidel wrote: post #18

Earlier quoted context omitted.

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…

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.

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

#37

Post by x0x0 » Wed, Jul 15, 2015, 6:46 PM UTC

ProAm wrote: post #11

erikb wrote: post #6

To answer most questions here: Yes, nowadays there are cross-platform libraries you can use instead of implementing that yourself. And yes code that has grown for centuries and contains unnecessary things or patterns that aren't used nowadays can be refactored. Or at least that's how I'd interpret the article.

I really dislike the code review witch hunts you see on HN (or anywhere). On one side of the coin you have startups that merely want to get something thrown together with duct tape, working and ship so they can refactor later and clean things up. On the other hand you have people writing blogs posts to humble brag their code reading and blogging ability. No one knows the circumstances that created this original code.…

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

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

#38

Post by cat_dev_null » Wed, Jul 15, 2015, 6:49 PM UTC

If you are all such experts, why don't you "fix it" and then pull request it in.

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

#39

Post by x0x0 » Wed, Jul 15, 2015, 6:49 PM UTC

geofft wrote: post #5

pkaye wrote: post #2

The question is do you think it could have been done better given that they support multiple OS/UI, etc...

You can refactor it into multiple functions (#ifdefs around a line containing just "||"? seriously??), some of which are no-ops on some platforms / configurations, and let the compiler deal with inlining the functions that exist and optimizing out those that don't. (Not that you would have noticed the overhead anyway, probably.)

Probably with heavy code duplication though, as eg X clipboard management and X session management appear to be cross-cutting concerns. I mean, if you bury the ugly in just one function, I don't see how everyone is calling this horrid engineering.

edit: I read this [1] and maybe the ugly isn't localized =P

edit2: since you're reading this, thank you for ag. I use it every day.

[1] http://geoff.greer.fm/2015/01/15/why-neovim-is-better-than-v...

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

#40

Post by joshstrange » Wed, Jul 15, 2015, 6:50 PM UTC

zecho wrote: post #22

jandrese wrote: post #8

This is a classic case of why legacy code is a nightmare to maintain. It's the OpenSSL situation all over again, and one can definitely see the appeal of going through there and ripping out all of the functionality that nobody uses anymore just to make maintenance less of a nightmare. Luckily vim doesn't run suid root on any sane system, so all of this legacy cruft is not as huge of a threat surface on the machine.

Yep. There's nothing worse that maintaining code that doesn't change, or rarely changes. All that doing nothing because the code works, or works well enough, to avoid anybody noticing it. Yes, that's the classic example of why legacy code is a nightmare to maintain. When I think of maintenance, I think of constantly refactoring things that work.

While I see your point you are missing the point that Parent hits on: Maintenance. Sure if everything was working you wouldn't touch it but if you do need to make changes or add features at some point then having refactored it into something sane and readable makes a lot of sense. I doubt the Parent is suggesting we re-write everything just because it is old.