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

191–200 of 239 posts

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

#191

Post by roghummal »

akkartik wrote: post #107
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…

I too have followed the vim mailing list for many years, and tried and failed to submit a patch to it. I mostly use neovim now, and have successfully submitted a patch to it. Based on these experiences I found your blog post unnecessarily incendiary. The thread of your patch submission ( https://groups.google.com/d/msg/vim_dev/-4pqDJfHCsM/LkYNCpZj... ) was actually quite civil. It didn't do what you want, but let's b…

Someday 'vi' might symlink to 'nvim' instead of 'vim'. 'VI Improved Improved'!

Mr. Greer's post was necessarily incendiary; He's building his brand. Wasting space on the front page of HN is a feather in his cap.

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

#192

Post by jsmeaton »

steve_b wrote: post #187
smt88 wrote: post #178

Earlier quoted context omitted.

The best-engineered technology is rarely the most popular. I'd be interested to see a list of well-written code bases that are also popular. The interesting thing about PHP (the program) is that, in my experience, the code doesn't suck because it was hastily written or because it was written a long time. It sucks because the people who write it and work on it have bizarre, nonsensical philosophies about writing code.…

do you have any links to these talks? thanks!

Need an excuse to buy a new monitor by any chance? :)

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

#193

Post by andrewflnr »

smt88 wrote: post #178
tsuyoshi wrote: post #171

Earlier quoted context omitted.

"Vim is, without question, the worst C codebase I have seen." From the example you give, I agree it must be bad. But if you want to see something worse, check out PHP. No, not the billions of programs written in the PHP language (which are, indeed, almost all terrible), but the C source to the PHP interpreter. Obviously PHP was invented by someone who just doesn't care about creating a decent programming language. Ev…

The best-engineered technology is rarely the most popular. I'd be interested to see a list of well-written code bases that are also popular. The interesting thing about PHP (the program) is that, in my experience, the code doesn't suck because it was hastily written or because it was written a long time. It sucks because the people who write it and work on it have bizarre, nonsensical philosophies about writing code.…

llvm and redis have good reputations. sqlite, I think. Lua. llvm in particular seems to owe its popularity to good structure, though it does seem to be an exception that highlights the common case.

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

#194

Post by msravi »

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…

Right. So you recommend neovim, which is good, except that it won't install -- not on some unused OS, but on OS X 10.6.8 (Snow Leopard). Now I know that's a little behind, but really? Beautiful code that won't work on a 2010 OS is just awesome.

As an aside, I think it's a growing problem that the formulae in Homebrew are not updated to support 10.6.8.

And Vim? It just works. Maybe it's all those #ifdefs that make the code look ugly...

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

#196

Post by rtpg »

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.

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

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

#198

Post by yoklov »

breadbox wrote: post #55

There is nothing wrong with supporting lots of platforms, but those #ifdefs need to be encapsulated in wrappers functions (or macros). This is a classic example of premature optimization, actually. You use one or two #ifdefs directly because you hate to pay the cost of function overhead just to make the code easier to read. (Even though there's practically no point in tiny optimizations just before the code is going…

I don't think this was done for the purpose of optimization. Usually this happens when you want to add support for one small change, and its easier to get a small patch in vs a big one.

Its not really the classic case of premature optimization either. At least not in my experience. That's more like 'I know I need a spatial partition here, time to research all the ways they can be implemented and their performance tradoffs, and implement a really good one" when you should have just used a hash table and done the other stuff if spatial lookups even show up when profiling.

Stuff like this is way more damaging for both codebase complexity and productivity then anything else. The golden rule is to only do enough optimization to make it easy to do the optimizations you might need to do later, but no more.

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

#199

Post by anon4 »

roghummal wrote: post #191
akkartik wrote: post #107

Earlier quoted context omitted.

I too have followed the vim mailing list for many years, and tried and failed to submit a patch to it. I mostly use neovim now, and have successfully submitted a patch to it. Based on these experiences I found your blog post unnecessarily incendiary. The thread of your patch submission ( https://groups.google.com/d/msg/vim_dev/-4pqDJfHCsM/LkYNCpZj... ) was actually quite civil. It didn't do what you want, but let's b…

Someday 'vi' might symlink to 'nvim' instead of 'vim'. 'VI Improved Improved'! Mr. Greer's post was necessarily incendiary; He's building his brand. Wasting space on the front page of HN is a feather in his cap.

I'm really sad neovim didn't call themselves vi improved improved, or vii. It doesn't just carry the naming tradition of vim, but is also one more than vi.

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

#200

Post by anon4 »

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.

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.
Post reply on HN