On 24 February 2014, Diego Viola <[email protected]> wrote:
> I don't understand, Bram says "It's much better to improve what we
> have." which is good and reasonable to me. I agree with this.
>
> But then we have people like Thiago de Arruda (aka tarruda) who have
> worked very hard on multithreading support for Vim, and his patches
> didn't make it into mainline Vim.
>
> So how can we "improve what we have" when 99% of the patches are
> ignored or rejected according to most developers?
I believe you miss the big picture here. At this point, virtually
nobody aside from Bram understands the code well enough to make "big"
changes. The other "main" developers are just people that know enough
about the code to scratch their own itches. These people post patches
occasionally (and Bram usually includes their patches), but their
interest is generally limited to particular pieces of Vim, and don't
have either the motivation or the resources to look anywhere else.
As a result, what happens when an "outsider" posts something as far
reaching as the recent timeout / async patch, or the multithreading
patch, is that Bram is reluctant to write an in-depth analysis (he has
been at this for 20+ years, he has a job, a life, and he already has his
hands full just from maintaining Vim as it is), and nobody else really
feels qualified to post a meaningful answer. The only somewhat informed
feedback the author receives is then a few vague and / or opinionated
rants that rarely go beyond pointing out the obvious. Then the author
concludes that nobody cares, feels offended, takes it personally, and
posts frustrated calls to arms on YC. There, they manage to receive a
deluge of way more opinionated, way less informed rants about anything
and everything Vim except the actual patch, and things slowly loop back
to the statu quo ante.
On the other hand, most of these far reaching "outsider" patches
are, actually, less than perfect. That's to be expected too, partly
because what they are trying to do is objectively hard (if it weren't,
it would have been done long ago), and partly because the authors don't
read the code end to end before starting to write their patch, to make
sure their changes doesn't interact badly with other parts of Vim.
That's actually the kind of feedback they would expect from the list.
But, as I explained above, this doesn't happen. Rinse and repeat.
> Sorry, I do have great respect for Bram Moolenaar and his work, I just
> don't understand this development model at all.
>
> Perhaps the fork could have been avoided if the development model was
> more reasonable? I don't know.
If you think Bram should just merge all these crowd-acclaimed
patches, no question asked, you'd be wrong too (IMO, of course). See
f.i. what other people have to say about Vim, even without experimental
patches:
https://news.ycombinator.com/item?id=6668453
As I see it (and for what it's still worth), the way forward is
not to lower the standards for accepting patches. It isn't to rewrite
Vim from scratch in Haskell, Javascript, Rust, Go, or whatever other
language of the day. It isn't to refactor it to use libuv, or other
revolutionary library of the day. And it certainly isn't to compile yet
another list of flaws, or another wish list.
In my opinion the way forward is for enough people to start reading
the code, patiently and diligently, in their own rhythm. Once there is
a critical mass of developers who actually understand the code, and see
it as just old, rather than terrible or evil, we might see progress.
/lcd
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
