12 ms·

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 i

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.

dustingetz 11y ago
I wonder why didn't the vim folks write the abstracting library?
- amelius 11y ago
  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.
  - VLM 11y ago
    If they added libvu support, we'd have a post about "VIM's 430 line keyboard input routine" instead of a mere 400. At least for a major release or so before they could flush the legacy code. If they can.
jsprogrammer 11y ago
>There is nothing to be gained. What about easier extensibility? Not many are going to want to look at that code, let alone try to add some additional functionality to it.
chadgeidel 11y ago
I am reminded of the old Joel on Software article "Things you should never do part 1": http://www.joelonsoftware.com/articles/fog0000000069.html 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." EDIT: Joel isn't actually recommending "do nothing" - on the contrary - the article goes into some depth on ways one can improve software without throwing everything away and starting from scratch.
- geofft 11y ago
  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.
  - chadgeidel 11y ago
    You are correct, of course - but back in the old days that this article was written unit testing wasn't as widely adopted as it was today. Joel does recommend solutions to improving code, and I'll bet if he wrote that article today he would include unit testing as a part of the solution.
  - pjmlp 11y ago
    Outside HN like crowds almost no one writes tests. In most enterprises it even has less value than documentation when deadlines approach. The sad reality is that most software is a by product of the main business and as such the quality goals are always pretty low. Edit: typo has => as
    - the_af 11y ago
      I find it odd how many people overlook this fact. I think people reading tech blogs and sites sometimes live in a bubble. I don't know if in most, but in many companies there are no automated tests at all, and very few "best practices" such as automated builds/continuous integration and even decent source control. I don't want to name names, but I'll say this: I know for a fact at least one IT/support department in the local branch of a HUGE multinational energy company (guess a few names and you'll get it) doesn't do automated tests of any kind. They are similarly clueless about most things tech-minded folk would consider best practices of the last decade. This department doesn't work on core software, but instead on inventory/procurement systems, but still...
    - acqq 11y ago
      It's not that the tests can't improve the software produced, it's that often nobody has the incentive to bring these improvements.
nkassis 11y ago
"There is nothing to be gained." Not completely true, you could argue that it would be more maintainable in the future but I don't think that outweigh the risk of making changes here while it's still fully functional and nothing really needs it to change.
- joosters 11y ago
  Yes, maintainability / extensibility is good. But I'd be wary of refactoring code purely for the sake of potential maintainability / extensibility, as it's work for no gain. You're trying to predict the future for the code, and that's a losing game. If someone has a reason to extend the code, then you have the choice of hacking in the new feature, or refactoring the code to make it nicer. Each case really needs to be considered on its merits. But IMO it's almost always better to prefer to keep the code as-is rather than making big rewrites. Tiny refactoring is the way to go.
  - nkassis 11y ago
    I'm OK with that stance, I try to advocate the same myself but you have to be careful of the boiling frog issue of making small incremental refactoring that lead to dead ends. Stepping back and thinking about the long term is valuable. Doesn't mean you have to do the work now for that potential future but thinking of the potential drawbacks of the current design and it's limitation may guide the decision as to when it's appropriate to do a major refactoring. Also this particular example seems like something that will probably rarely need modifications. I'd be interested in seeing how often this code changes. My guess is the effort to refactor this will probably be equivalent cost to the future changes.
samf 11y ago
How do you know it works? Did you test it on every platform? What you would have to gain is maintainability. Maybe it's not worth it; maybe it is. But saying that there is nothing to be gained is just an opinion.
- joosters 11y ago
  I bet that it contains fewer bugs than a rewrite of the code will have! That code represents years of tweaks, fixes and obscure workarounds. There are countless problems that you will re-introduce with a code rewrite, because the subtleties in aged, thoroughly-used code are not immediately obvious.
  - samf 11y ago
    I agree, I just think your initial statement was a bit extreme.
    - joosters 11y ago
      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.
      - ianamartin 11y ago
        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.
        11y ago
serge2k 11y ago
In that best result you also end up with code that is smaller and easier to extend in the future. Considering that Vim is still extremely common that is a win.
ggreer 11y ago
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 clock changes, either from user intervention or ntpd. The correct solution is to use a monotonically-increasing timer, such as Linux's clock_gettime() or OS X’s mach_absolute_time(). Vim's UI is powerful, but its codebase is a nightmare. My blog post explains why in more detail. 1. http://geoff.greer.fm/2015/01/15/why-neovim-is-better-than-vim/ http://geoff.greer.fm/2015/01/15/why-neovim-is-better-than-v...
- Alupis 11y ago
  > The code works, but it's quite buggy Could you elaborate a bit? I've never experienced a bug related to keyboard input while using Vim, at least that I know of.
  - baby 11y ago
    Depends on what machine you are using Vim from
  - cpncrunch 11y ago
    Me neither. I've been using vim for about 20 years and I don't think I've ever spotted a single bug in that time.
    - winternewt 11y ago
      vim crashes or hangs for me about once every month. I've never bothered to find out why since I don't think it's worth the effort. The effort would be lower if the code was cleaner and didn't have so much bloat related to platforms that don't exist. It would definitely be easier to submit a patch if I didn't need to cater to all the platforms I've never seen.
      - 11y ago
haberman 11y ago
> But the code works. The "#ifdef maze" in OpenSSL was criticized by the OpenSSH/OpenBSD guys as a key part of the picture that allowed something like Heartbleed to happen: http://blather.michaelwlucas.com/archives/2071 http://blather.michaelwlucas.com/archives/2071 Tons of ifdefs make it much more difficult to ensure that all permutations of flags are correct, or can even compile. I think I remember reading that OpenSSL wasn't even capable of being compiled with the standard, system malloc(). No one compiled it that way, so that build configuration broke without anyone knowing it.
- kevingadd 11y ago
  Every time I deal with ifdef mazes I regret it. MonoGame is a familiar & nasty example, since it tries to be a portable reimplementation of a game framework (with ~a dozen platform targets/backends) but instead ends up being catastrophically buggy - as an end user or a maintainer you can't tell which functions are even implemented or syntactically valid. I started using a SDL2-only fork of the same library (just one backend! near-0 ifdef count!) and suddenly all those nasty problems went away.
ams6110 11y ago
Yes, I don't think this is a WTF. What it really is, is an example of real-world code, that needs to work everywhere, not just in a specific app on a specific OS running on specific hardware... that of course makes it easy for things to be much more tidy.
deleted 11y ago
[deleted]
jayvanguard 11y ago
Your definition of "works" doesn't include "ability to easily absorb change as the world modernizes". The world of computing is changing each year and any software that works well needs to adapt (or else be trivially small like many unix utils so the world adapts around them or abandons them). I love vim and have looked at contributing a number of times but the sheer amount of cruft creates a huge barrier.
burnte 11y ago
Actually, best case is you'd have code that still works, but faster, with fewer bugs, and less likelyhood of breaking with future changes. Code working is not the only metric by which code is judged. How WELL it works is more important, for example.
masukomi 11y ago
> But the code works. ...is exactly the type of thinking that results is countless of wasted developer time wading through unmaintainable crap, which is never touched because "the code works" and everyone's to damn afraid to change it because it's so excessively complex because no-one bothered to go back and refactor it for readability, maintainability, modern libraries, or anything else. "working" isn't good enough.
smegel 11y ago
> that still works... And is more portable, maintainable etc. And criticizing code is not exactly the same thing as saying it should be re-written, given the time investment and low yield. Yes the code works, but don't write code like this every again.
rtpg 11y ago
unreadable code means the code doesn't work for 1 of its 2 purposes : conveying to the reader what it actually does. So it only accomplishes half its job
anon4 11y ago
Not just that, it's just 400 lines. Has the author ever seen production C++ code? This is high-quality easy-to-maintain code in comparison. Come on.
VeejayRampay 11y ago
What about being inclusive as an open-source code base? If you simplify the code, remove obsolete cruft and start making use of common place modern libraries, then all of a sudden a bunch of people who were not interested in the first place because the code was way too complicated to get into are suddenly an option. And that's huge.

dustingetz 11y ago

I wonder why didn't the vim folks write the abstracting library?

amelius 11y ago
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.
- VLM 11y ago
  If they added libvu support, we'd have a post about "VIM's 430 line keyboard input routine" instead of a mere 400. At least for a major release or so before they could flush the legacy code. If they can.

jsprogrammer 11y ago

>There is nothing to be gained. What about easier extensibility? Not many are going to want to look at that code, let alone try to add some additional functionality to it.

chadgeidel 11y ago

I am reminded of the old Joel on Software article "Things you should never do part 1": http://www.joelonsoftware.com/articles/fog0000000069.html 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." EDIT: Joel isn't actually recommending "do nothing" - on the contrary - the article goes into some depth on ways one can improve software without throwing everything away and starting from scratch.

geofft 11y ago
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.
- chadgeidel 11y ago
  You are correct, of course - but back in the old days that this article was written unit testing wasn't as widely adopted as it was today. Joel does recommend solutions to improving code, and I'll bet if he wrote that article today he would include unit testing as a part of the solution.
- pjmlp 11y ago
  Outside HN like crowds almost no one writes tests. In most enterprises it even has less value than documentation when deadlines approach. The sad reality is that most software is a by product of the main business and as such the quality goals are always pretty low. Edit: typo has => as
  - the_af 11y ago
    I find it odd how many people overlook this fact. I think people reading tech blogs and sites sometimes live in a bubble. I don't know if in most, but in many companies there are no automated tests at all, and very few "best practices" such as automated builds/continuous integration and even decent source control. I don't want to name names, but I'll say this: I know for a fact at least one IT/support department in the local branch of a HUGE multinational energy company (guess a few names and you'll get it) doesn't do automated tests of any kind. They are similarly clueless about most things tech-minded folk would consider best practices of the last decade. This department doesn't work on core software, but instead on inventory/procurement systems, but still...
  - acqq 11y ago
    It's not that the tests can't improve the software produced, it's that often nobody has the incentive to bring these improvements.

nkassis 11y ago

"There is nothing to be gained." Not completely true, you could argue that it would be more maintainable in the future but I don't think that outweigh the risk of making changes here while it's still fully functional and nothing really needs it to change.

joosters 11y ago
Yes, maintainability / extensibility is good. But I'd be wary of refactoring code purely for the sake of potential maintainability / extensibility, as it's work for no gain. You're trying to predict the future for the code, and that's a losing game. If someone has a reason to extend the code, then you have the choice of hacking in the new feature, or refactoring the code to make it nicer. Each case really needs to be considered on its merits. But IMO it's almost always better to prefer to keep the code as-is rather than making big rewrites. Tiny refactoring is the way to go.
- nkassis 11y ago
  I'm OK with that stance, I try to advocate the same myself but you have to be careful of the boiling frog issue of making small incremental refactoring that lead to dead ends. Stepping back and thinking about the long term is valuable. Doesn't mean you have to do the work now for that potential future but thinking of the potential drawbacks of the current design and it's limitation may guide the decision as to when it's appropriate to do a major refactoring. Also this particular example seems like something that will probably rarely need modifications. I'd be interested in seeing how often this code changes. My guess is the effort to refactor this will probably be equivalent cost to the future changes.

samf 11y ago

How do you know it works? Did you test it on every platform? What you would have to gain is maintainability. Maybe it's not worth it; maybe it is. But saying that there is nothing to be gained is just an opinion.

joosters 11y ago
I bet that it contains fewer bugs than a rewrite of the code will have! That code represents years of tweaks, fixes and obscure workarounds. There are countless problems that you will re-introduce with a code rewrite, because the subtleties in aged, thoroughly-used code are not immediately obvious.
- samf 11y ago
  I agree, I just think your initial statement was a bit extreme.
  - joosters 11y ago
    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.
    - ianamartin 11y ago
      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.
      - 11y ago

serge2k 11y ago

In that best result you also end up with code that is smaller and easier to extend in the future. Considering that Vim is still extremely common that is a win.

ggreer 11y ago

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 clock changes, either from user intervention or ntpd. The correct solution is to use a monotonically-increasing timer, such as Linux's clock_gettime() or OS X’s mach_absolute_time(). Vim's UI is powerful, but its codebase is a nightmare. My blog post explains why in more detail. 1. http://geoff.greer.fm/2015/01/15/why-neovim-is-better-than-vim/ http://geoff.greer.fm/2015/01/15/why-neovim-is-better-than-v...

Alupis 11y ago
> The code works, but it's quite buggy Could you elaborate a bit? I've never experienced a bug related to keyboard input while using Vim, at least that I know of.
- baby 11y ago
  Depends on what machine you are using Vim from
- cpncrunch 11y ago
  Me neither. I've been using vim for about 20 years and I don't think I've ever spotted a single bug in that time.
  - winternewt 11y ago
    vim crashes or hangs for me about once every month. I've never bothered to find out why since I don't think it's worth the effort. The effort would be lower if the code was cleaner and didn't have so much bloat related to platforms that don't exist. It would definitely be easier to submit a patch if I didn't need to cater to all the platforms I've never seen.
    - 11y ago

haberman 11y ago

> But the code works. The "#ifdef maze" in OpenSSL was criticized by the OpenSSH/OpenBSD guys as a key part of the picture that allowed something like Heartbleed to happen: http://blather.michaelwlucas.com/archives/2071 http://blather.michaelwlucas.com/archives/2071 Tons of ifdefs make it much more difficult to ensure that all permutations of flags are correct, or can even compile. I think I remember reading that OpenSSL wasn't even capable of being compiled with the standard, system malloc(). No one compiled it that way, so that build configuration broke without anyone knowing it.

kevingadd 11y ago
Every time I deal with ifdef mazes I regret it. MonoGame is a familiar & nasty example, since it tries to be a portable reimplementation of a game framework (with ~a dozen platform targets/backends) but instead ends up being catastrophically buggy - as an end user or a maintainer you can't tell which functions are even implemented or syntactically valid. I started using a SDL2-only fork of the same library (just one backend! near-0 ifdef count!) and suddenly all those nasty problems went away.

ams6110 11y ago

Yes, I don't think this is a WTF. What it really is, is an example of real-world code, that needs to work everywhere, not just in a specific app on a specific OS running on specific hardware... that of course makes it easy for things to be much more tidy.

deleted 11y ago

[deleted]

jayvanguard 11y ago

Your definition of "works" doesn't include "ability to easily absorb change as the world modernizes". The world of computing is changing each year and any software that works well needs to adapt (or else be trivially small like many unix utils so the world adapts around them or abandons them). I love vim and have looked at contributing a number of times but the sheer amount of cruft creates a huge barrier.

burnte 11y ago

Actually, best case is you'd have code that still works, but faster, with fewer bugs, and less likelyhood of breaking with future changes. Code working is not the only metric by which code is judged. How WELL it works is more important, for example.

masukomi 11y ago

> But the code works. ...is exactly the type of thinking that results is countless of wasted developer time wading through unmaintainable crap, which is never touched because "the code works" and everyone's to damn afraid to change it because it's so excessively complex because no-one bothered to go back and refactor it for readability, maintainability, modern libraries, or anything else. "working" isn't good enough.

smegel 11y ago

> that still works... And is more portable, maintainable etc. And criticizing code is not exactly the same thing as saying it should be re-written, given the time investment and low yield. Yes the code works, but don't write code like this every again.

rtpg 11y ago

unreadable code means the code doesn't work for 1 of its 2 purposes : conveying to the reader what it actually does. So it only accomplishes half its job

anon4 11y ago

Not just that, it's just 400 lines. Has the author ever seen production C++ code? This is high-quality easy-to-maintain code in comparison. Come on.

VeejayRampay 11y ago

What about being inclusive as an open-source code base? If you simplify the code, remove obsolete cruft and start making use of common place modern libraries, then all of a sudden a bunch of people who were not interested in the first place because the code was way too complicated to get into are suddenly an option. And that's huge.