10 ms·

Bram Moolenaar responds to Neovim

221 points by dviola 13y ago

sramsay 13y ago
Perhaps this was mentioned the other day, but Neovim did make me think of this old chestnut from Joel Spolsky: http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000069.html I realize Neovim is being characterized as an "aggressive refactor," but I'm sure that's the way Netscape thought of it as well. tl;dr Things you should never do: rewrite the code from scratch.
- city41 13y ago
  37Signals rewrote Basecamp from scratch and as far as I know it's been very successful.
  - Argorak 13y ago
    They wrote a whole new Basecamp. There is no migration path from Basecamp Classic to current and the feature set is not necessarily the same.
    - city41 13y ago
      Who knows, Neovim may very well drop support for vimscript and the entire ecosystem would have to start over. In the long run that may be a great thing.
  - johnny99 13y ago
    It was rewritten by the same people who wrote the first version--very different from the Vim/Neovim case, and from Netscape 6.0. And who knows--37Signals might well have reused some of the innards.
    - city41 13y ago
      That is true and a fair point. Neovim will likely reuse pieces of Vim as well.
- deleted 13y ago
  [deleted]
- typicalbender 13y ago
  That was a really good article, thanks for sharing!
- Jare 13y ago
  When we started work on Commandos 2, we threw away everything from Commandos 1, and started from scratch. 15 years down the road, all the coders still agree that was the best decision ever.
  - middleclick 13y ago
    Were you on the Commandos team? Mad respect to you. Probably my most favourite game of all times. Thanks for working on it.
    - Jare 13y ago
      Thanks! I was technology/tools lead on 2, and while my role in 1 was... hard to explain, yeah my contribution was important. :)
      - darklajid 13y ago
        Did you write about that somewhere? Could you, even? Pretty please?
    - deleted 13y ago
      [deleted]
  - alecthomas 13y ago
    Man, I loved Commandos 1 back in the day. I recently got a bit nostalgic and bought the whole series on Steam, and they are still great games! But MAN are the controls opaque. Thinking back, I think the game came with a little cardboard sheet with all the controls on it, which would have been easier to deal with. Fantastic game though, thanks :)
  - ramgorur 13y ago
    When I hear "Commandos" it makes me nostalgic :-(, but kudos to you and your team !!
  - oftenwrong 13y ago
    Commandos 2 is one of my favorite games! I wish there were more games with the same mix of stealth and strategy being made.
- dengnan 13y ago
  > Things you should never do: rewrite the code from scratch. I can clearly see the benefit of this old wisdom under context of limited resource and limited time, esp. in a commercial company. However, as an experimental, personal(?), non-profit, free/open-source project, I do think neovim has value in its own right: 1. It won't affect any existing plan of vim, and won't change any existing code in vim. We can still happily use vim as usually. 2. If it succeeded, then we would have another powerful free/open source editor in our community. 3. If it failed, then we as a community have nothing to lose. The author might be unhappy then, but he would at least gain lots of experience. There are so many rewritings happen in this community, and they are definitely good things: - svn is a rewriting of cvs, and git is a totally new one (with more features?) written from scratch. - nginx was written even if there's apache httpd - There's zookeeper, but people wrote etcd - etc.
  - hobs 13y ago
    I came to say this exactly. In a commercial project where time and money are limiting factors, you are almost insane to rewrite from scratch. In an OSS context, money is not always the biggest mover, and doing this might actually succeed, or at least not fail because the company fails. It certainly may be that the people lose interest before it gets anywhere, but who cares! The only reason that I could see is that someone wants to fold all their code changes back into vim's original codebase, and they both seem to have different end goals, so eventually they will drift away from each other. Code evolution.
- haberman 13y ago
  With that thinking we never get Linux (NeoMinix), tmux (NeoScreen), Clang (NeoGCC), WebKit (NeoGecko), Subversion (NeoCVS), or Vim itself (NeoVi/Elvis/Stevie/etc).
  - raverbashing 13y ago
    Huummmmm no Neovim is being sold as a VIM refactor, but apparently with no new functionality Very different from Linux (had an aim of being a playground for new features), tmux is different from screen as Clang is different from GCC, Subversion is a totally different beast from CVS
    - haberman 13y ago
      > Neovim is being sold as a VIM refactor, but apparently with no new functionality Where did you get that idea? When I read the project page (https://github.com/neovim/neovim https://github.com/neovim/neovim), two of the explicit goals are: "Enable the implementation of new/modern user interfaces without any modifications to the core source. "Improve the extensibility power with a new plugin architecture based on coprocesses. Plugins will be written in any programming language without any explicit support from the editor. " It is exactly designed to be a playground for new features, but with the goal of them not having to be in the core.
      - pit 13y ago
        The original mailing list post says: "There's a new project that is called Neovim that seeks to refactor and modernize the codebase."
      - pit 13y ago
        The original mailing list message says: "There's a new project that is called Neovim that seeks to refactor and modernize the codebase"
        zimbatm 13y ago
        That's the necessary step 1 to allow further enhancements
- mjn 13y ago
  > tl;dr Things you should never do: rewrite the code from scratch. Considering vim itself is a from-scratch 'vi' clone, that's interesting advice. :) But in any case, I see this as more of a fork than a rewrite. It's more akin to the XEmacs/GNU Emacs situation, where someone submits significant patches upstream which aren't accepted, and then forks their own version to continue that line of development.
  - TazeTSchnitzel 13y ago
    Clones and rewrites aren't really comparable, though.
    - Pacabel 13y ago
      They're pretty comparable. A "clone" can almost always be considered a subset of a "rewrite". Both involve a new software system that is directly inspired by an existing one. The main difference is that a clone is often written by developers who had no involvement with the development of the original system. But that's not always true, especially for any old or sizable software system, where the original developers may no longer be involved.
      - dhimes 13y ago
        I think you are coming dangerously close to muddy semantics. Let's say: a clone is a clone- git clone, hg clone, etc. A rewrite may start with a clone, but the code is no longer a clone when you start the rewrite. A refactor is a subset of a rewrite. Now we can have meaningful discussions about them.
  - sramsay 13y ago
    I think that's an excellent point. Vim is, after all, "Vi iMproved." nvi is a clone.
- Cederfjard 13y ago
  I'm somewhat confused by your comment, since the GitHub page explicitly says that NeoVim "is not a project to rewrite Vim from scratch". Where's the discrepancy here? Perhaps I'm just too tired right now.
- InclinedPlane 13y ago
  Spolsky is wrong. Rewriting is a significant risk, and rewrites often fail because people don't appreciate that fact. But there are ways to rewrite successfully, and often doing so is the correct course of action. A big problem with rewrites is that it puts a strain on development resources, and it's not possible to maintain both old and new code at the same time. Another big problem is prematurely committing to the rewrite, before it has proven itself. When the inevitable happens and schedules slip, defects arise, and features need to be cut this can prove disastrous for a rewrite that you've foolishly committed to in advance. Also, people often ignore the value of years of productive use which provides testing and validation of immense value. If you have the resources often the best choice is to spin off a new project for a rewrite and have them compete in the open. With luck the rewrite could become mature enough to overtake the original (as has happened with many projects). Alternately, work in phases doing refactoring in steps, perhaps with new features behind feature flags. Many people think that rewriting code is easier than green field development, in reality it's often more difficult. It takes a great deal of skill, and often luck, to manage a good rewrite.
  - Pacabel 13y ago
    A significant problem is that there are a lot of developers today who revere Spolsky as some sort of a god, and absolutely refuse to question or reconsider anything that he has written. This trend is particularly bad with those who've gotten involved with software development since 2005 or so. I chalk it up to a lack of experience with massive, multi-decade software projects. If all a developer has worked with are small, recently-written Ruby on Rails apps, for example, then I don't think they can appreciate situations where rewrites of some degree are the only viable option. Hopefully this attitude regarding Spolsky's writing will change with time, as these people encounter the real-world situations where significant or total rewrites are basically the only possible option.
    - InclinedPlane 13y ago
      An even bigger problem, in my opinion, is the idea (usually only implicit) that any advice can apply to the entire panoply of software development. As though writing Flappy Bird and writing control software for the Falcon 9 weren't as different as banging together some shelving using plywood from home depot and machining custom components from exotic alloys using a lathe. An important part of maturing as a developer is learning to understand that different situations call for different techniques and being able to know what things are truly important with a given project and which aren't.
- benched 13y ago
  There is probably no Spolskyism that I disagree with more. And yet, I don't really disagree with what he said in context. The context is within a business where the opportunity cost could make it not worth it. If the only concern is making the software better, my experience is that rewriting does wonders for old code.
- anon4 13y ago
  What you're missing is that Netscape rewrote their own product from scratch. Neovim is a fork bringing very invasive changes (not rewriting from scratch) to a project by a different developer for the purpose of extending the original project in ways the current maintainer doesn't want to. So it's more like taking the old netscape code and making gecko.
- Someone 13y ago
  What makes you think this is a rewrite? If this is a rewrite from scratch, they are insanely fast coders, considering that they have a full-blown editor in less than a month (first commit is from January, 31) That first commit also shows it is not a rewrite, though, since it has a comment starting with "Import vim from changeset v5628:c9cad40b4181"
  - eru 13y ago
    I wonder why they start with fresh history.
- jey 13y ago
  This isn't a "rewrite the code from scratch", but instead is an incremental but aggressive refactoring. There's at least one wildly successful example of this successfully being done for GCC, which is a project even bigger and more complex than Vim. Around GCC 2.8, it was forked into EGCS where major changes were made. This fork was so successful that it then became the official branch of GCC, and modern versions of GCC are direct descendants of EGCS.
  - GFK_of_xmaspast 13y ago
    As I recall, EGCS happened because GCC development had stagnated, if not stalled entirely.
    - ticviking 13y ago
      You mean like vim development
- kentosi 13y ago
  I think that this is an unfair comparison. Netscape and Borland were business with financial targets, deadlines and (more importantly,) competitors vying for the same market share. These guys don't have these pressures, nor did (as per haberman's comment) Linux, tmux, Clang, WebKit, etc as far as I'm aware.
- mildtrepidation 13y ago
  tl;dr Things you should never do: rewrite the code from scratch. Sentiment like this is not valuable. The experience that it comes from is often informative, but as a conclusion, this explicitly ignores circumstances that sometimes do make rewriting a good, compelling course of action. Truly bad, unmaintainable code exists. It exists on projects that have long intended futures. It exists in all sorts of environments on all sorts of projects for all sorts of reasons. To discount the idea of a rewrite out of hand is a failure to objectively review the specific circumstances around whatever it is you're working on. Often there are better ways, and yes, often a rewrite is a bad idea. But absolutes are so rarely valid, and this one is most certainly not universally true.
- shadowfox 13y ago
  > but I'm sure that's the way Netscape thought of it as well Don't really think so. At least as far Netscape 6 went, they came up with an entirely different framework and moved over to Java (as far as I remember). I have rarely seen that sort of thing characterized as a refactor (even on their mailing lists).
  - hnisnotreddit 13y ago
    The Seamonkey Project [1] is the current state of the Mozilla Application Suite[2], which Netscape 6 and 7 were branched from[3][4]. Written in C++ mostly. Some of us have been using Gecko as their renderer for almost sixteen years now. Seems KHTML(w), the base of both Webkit and Blink[5], is the same age. Seems we've gotten a good run out of the existing codebases. In fact, this means that Gecko (and khtml) have been in use twice as long as NCSA Mosaic, which the first Netscape was based on[6]. Imagine how Spolsky must feel about the Servo rewrite. 1. http://www.seamonkey-project.org/ http://www.seamonkey-project.org/ 2. https://en.wikipedia.orgwiki/Mozilla_Application_Suite#Market_adoption_and_project_end https://en.wikipedia.orgwiki/Mozilla_Application_Suite#Marke... 3. https://en.wikipedia.org/wiki/Netscape_6 https://en.wikipedia.org/wiki/Netscape_6 4. https://en.wikipedia.org/wiki/Netscape_7 https://en.wikipedia.org/wiki/Netscape_7 5. https://en.wikipedia.org/wiki/KHTML#KHTML_and_Apple https://en.wikipedia.org/wiki/KHTML#KHTML_and_Apple 6. https://en.wikipedia.org/wiki/Mosaic_%28web_browser%29 https://en.wikipedia.org/wiki/Mosaic_%28web_browser%29
- fsloth 13y ago
  Joel has lots of right things to say, but I'm afraid that one - "Never rewrite from scratch" - is far too sternly interpreted to the point where it is actually more harmful than beneficial. Of course you can rewrite from scratch. You just should not expect to reach the same feature coverage instantly, and should approach the work methodically. Most of all, you should have a good reason. "This code is spaghetti" is usually not one. "I want to implement feature X and the current codebase does not really support is" could be a good reason. Also, a rewrite is pointless from the point of view of code quality unless you are familiar with similar codebases operating in a similar domain. Main advantages or rewrite are, that when you are a domain expert and implementing and designing core routines, you get constant flashes of intuition "Aha, I should add this interface here because that will enable me to implement Foo and Bar using this instead of writing a FooSubsystem and BarSubsystem" and so on. If you have no experience from the domain, you get those insights only after you've written the code and are actually new proud owner of new heap of semi-maintainable code.
- dasil003 13y ago
  I tend to agree with Joel's thesis here, but the example is bad: Netscape was doomed either way, the rewrite was an act of desperation, and I'd say it succeeded because it led to Firefox which slowly clawed back those first few points of marketshare from Microsoft—enough to finally get them to resume browser development. Even assuming they could have pulled a rabbit out of their hat with the Netscape 4 codebase (which was unlikely considering the history of that codebase, and it's legacy compared to the talent and experience that was being pumped into the greenfield Internet Explorer (yes, ironic I know)), IE was still going to eat their lunch. Netscape was between a rock and a hard place. But hey, at least their code lives on today right?
- egeozcan 13y ago
  A general statement such as "never rewrite" is as good as something like "never grow a beard" - while it may be a good advice for someone working in a traditional corporate environment, it certainly doesn't make sense, let's say, for a freelancer.
- emidln 13y ago
  Teams I've been a part of are 3/4 (3 successes, 1 failure) on total rewrites over my career. The failure was entirely my fault as a developer not knowing my own limits (coding, design, security, devops, business reqs, managing up can't happen (at least for me) in the same 60 hours a week). It still almost succeeded on strength of the design and ability of my amazing coworkers to aggressively simplify and consolidate all the things. Rewrites fall into two categories: essential to business and doomed to fail. If it's essential that the business execute on a rewrite, it will happen or the business will fail. If it's not essential, it very well might be the reason the business fails (siphoning away talent and squandering time when a refactor or benign maintenance would suffice). Precisely because massive rewrites are so risky, they are undertaken by the foolish (myself firmly in this camp). The heuristic under which they might succeed is bare necessity.
- hnisnotreddit 13y ago
  Fun food for thought: NCSA Mosaic started in 1992, and ended in 1997. Netscape 4.0, the last user of this engine, stopped development in 1998. Gecko, the core of Mozilla, started in 1998, and is still in development 16 years later. So, the engine that Spolsky was saying was a mistake has now been in use for twice as long as the engine it was replacing.
bachback 13y ago
well of course. Vi was specifically written by Bill Joy to optimize for every character, see http://www.theregister.co.uk/2003/09/11/bill_joys_greatest_gift/ http://www.theregister.co.uk/2003/09/11/bill_joys_greatest_g... And there is no reason we could ever improve on that 35 years later. we need those optimizations... "It took a long time. It was really hard to do because you've got to remember that I was trying to make it usable over a 300 baud modem. That's also the reason you have all these funny commands. It just barely worked to use a screen editor over a modem. It was just barely fast enough. A 1200 baud modem was an upgrade. 1200 baud now is pretty slow. 9600 baud is faster than you can read. 1200 baud is way slower. So the editor was optimized so that you could edit and feel productive when it was painting slower than you could think. Now that computers are so much faster than you can think, nobody understands this anymore. "
- perlgeek 13y ago
  Whenever I use vim through a lagging SSH connection, I'm very happy that it's still usable (at least more so than other editors).
  - jamestomasino 13y ago
    I feel the same way whenever I have to do work remotely on my phone. It's so precise and focused that I can get away with a few keypresses. I think neovim could be a great project and a major change for vim, but it could just as easily never reach a viable state. I won't suggest they give up, but I'm also not putting a lot of hope into it. Bram's vim is amazing, and even vi is stellar. I don't really see a downside whether they succeed or fail.
  - mst 13y ago
    If you can stand the fact that it's only got the original feature set, ex-vi.sf.net provides a version of the original vi that runs on modern unices. I use it on a daily basis and have found that it copes with conference wireless far better than vim does.
typicalbender 13y ago
That seems like a fair response. I tend to agree that sweeping refactorings tend to take a lot of time and it's better to break off small bite size pieces. That being said I really like some of the proposed improvements into vim. I wonder if a similar approach could be taken as when vi was improved to create vim, or perhaps that's what added all the complexity Neovim is trying to solve.
perlgeek 13y ago
It's very easy to look at code base full of weird special cases and think "this could be such much easier if I started from scratch", but in the end if often turns out that all this cruft is there for a reason. It's essential complexity that you wrongly identified as artificial complexity. And the rewrite ends up being much more work than originally anticipated. I don't think there's a way to learn that except by making the same mistake yourself, possibly more than once.
- CJefferson 13y ago
  That is an overly simplistic viewpoint. Vim is written in an inedibly old style of C which is not taught anymore, or used by most people. The code if fill of typedefs for AMIGA and OS/2. Useful to a small number of people certainly, but making progression harder too. This is not a total rewrite, it is a massive overdue refactoring.
  - perlgeek 13y ago
    > The code if fill of typedefs for AMIGA and OS/2. Useful to a small number of people certainly, but making progression harder too. Sounds like the code of pretty much every non-trivial C program that is meant to run of many platforms, not just the five or ten most popular ones. I'm not saying that this is a good thing, just that I don't know any good alternatives that don't sacrifice compatibility with lots of platforms.
    - kzrdude 13y ago
      It should say ifdefs, not typedefs. Inline ifdef directives everywhere is a real nightmare. The very first commit in neovim includes this log: - Process files through unifdef to remove tons of FEAT_* macros
      - teacup50 13y ago
        Which is exactly the sort of pointless "refactoring" that someone does instead of actual refactoring. It also makes merging back to vim difficult to impossible. Expect to see 'neovim' development dissipate rapidly.
CJefferson 13y ago
To be fair to the authors of neovim, there were patches they wrote and submitted to vim, which added exciting new features I would like, which were rejected. People who basically want him to never change (and that is fine) can be happy with mainline. There are others who would like to see some significant updates, particularly allowing better threading support.
- shmageggy 13y ago
  What were the features they submitted? Stuff that's mentioned on the github page or something else?
  - Tyr42 13y ago
    Multithreading and job control
  - btipling 13y ago
    At Floobits we tried to submit set_timeout/async stuff, and couldn't get anywhere with Bram. Months of work wasted. https://groups.google.com/forum/#!topic/vim_dev/-4pqDJfHCsM%5B1-25-false%5D https://groups.google.com/forum/#!topic/vim_dev/-4pqDJfHCsM%...
    - teacup50 13y ago
      Your patches were broken. People spent plenty of time trying to help you fix them. Your response is to tell the Internet that Vim is wrong for not accepting broken patches?
      - Jasber 13y ago
        Did you read the same thread I did? Floobits addressed all the issues. It came down to a fundamental design decision—and after months of hard work, they got a non-answer.
        ampersandy 13y ago
hglaser 13y ago
Why aren't there other vim committers? Bram's conservatism makes perfect sense for someone who has to maintain this huge, consequential, intimidating codebase. Why hasn't he gotten some help?
- kamaal 13y ago
  Big old code bases, have a lot of what I call as 'tribal knowledge' associated with them. People go out, and do experiments only to burn their hands. Over years, the old maintainers generally accumulate a lot of ideas and 'tribal knowledge' to know why 'pie in the sky' ideas won't work. Nevertheless, people still try. A lot of them fail, a few succeed. The vim code base is around 300K lines of C code. I'm sure its nothing like Java where 90% of the code is get/set methods, high level delegating classes and exception handling code. 300K lines of code which does the actual work is simply too much code. And one should exercise great caution while dealing with it. Regression is just one thing, I'm sure there are a lot of places in the code which can silently break things you can't detect only to pop up in some strange case in the wild.
  - ordinary 13y ago
    The vim code base is around 300K lines of C code. I found this hard to believe, so I ran it through cloc: ---------------------------------------------------- Language files blank comment code ---------------------------------------------------- C 113 33366 61819 285817 vim script 1186 22871 32599 145700 C/C++ Header 63 3175 4626 19735 Slightly more than 300k, but still mightily impressive.
  - chris_wot 13y ago
    I can't speak for vim, but the following smacks of code that needs a refactor: 300K lines of code which does the actual work is simply too much code. And one should exercise great caution while dealing with it. Regression is just one thing, I'm sure there are a lot of places in the code which can silently break things you can't detect only to pop up in some strange case in the wild.
  - 13y ago
tinco 13y ago
Well that does it I'd say. With such a negative attitude, who wants him on the team anyway? What the advantages are? They're clearly laid out in the project. Seriously, screw that guy. edit: Yes I know who 'that guy' is and it's great he's been working on Vim for all these years, but he certainly has his head up his ass if he thinks Vim users would not benefit from some big refactorings, a more accessible code base and some dropped platforms. If all those Amiga programmers love Vim so much, why would they be disappointed with an eternal Vim7.4? It's not too late for Vim to lose the editor wars.
- aeonsky 13y ago
  I still have yet to see these concrete user benefits.
  - svalorzen 13y ago
    The benefit is indirect rather than direct, as in the user benefits from the increased availability of plugins/guis since they would be easier to create. Also vim lacks lots of very simple but essential features of modern code editors simply because it lacks the graphical capabilities to do so (an example would be displaying the documentation of some method you are autocompleting, something which I have never seen in vim and which I actually believe is impossible).
    - psquid 13y ago
      > an example would be displaying the documentation of some method you are autocompleting, something which I have never seen in vim and which I actually believe is impossible For python at least, having 'preview' as part of your completeopt has it display the docstring of what you're completing. And :h completeopt suggests that's intended behaviour for all types of completion (where it makes sense), too.
      - fmoralesc 13y ago
        Yes, but currently retrieving that info is done synchronously, so it might slow down things. Under neovim's model, this can be done more efficiently.
codelap 13y ago
What would you call going from vi to vim? Regardless, anything that fixes the mess that is vimscript gets a thumbs up from me.
chimeracoder 13y ago
He's right. With every project, there's a tradeoff between achieving the goals of the project and maintaining compatibility with existing systems. As a Go programmer, I feel a bit sad/ashamed to be saying this, but look at Plan 9 - it failed to usurp Unix (and its descendants) as the dominant OS, because the latter was "good enough", and was already more widely supported and used. Plan 9 vs. Unix is a very different comparison than Vim vs. Neovim, and there are a lot of other factors at play, but the same principle actually holds. Improving or extending an existing system in a compatible way is a lot easier than trying to establish mindshare with a completely new tool. The tradeoff is that extending existing systems leads to cruft and bloat. So if you can establish mindshare with a new tool, you have an opportunity to make a much more elegant one. But that's a big "if". EDIT: I think a better analogy may be an attempt to refactor the Linux kernel into a microkernel. I'd certainly love it if this magically happened - microkernels are much easier to work with, and much more elegant. But it'd be hard to make the case that that'd be a worthwhile endeavor at this point, given the costs of doing so.
- pcwalton 13y ago
  But isn't Go itself an example of success with a complete rewrite?
  - chimeracoder 13y ago
    Good point. If you view Go as a "rewrite" of C, then perhaps, but I wouldn't. It's a new language altogether. C can be embedded in Go easily, and even if it couldn't, there's no reason that one has to "win out" over the other. There's less direct competition between two languages than there is with a family of OSes. And Go was never intended to replace C completely - it just provides a better alternative for some subset of what C/C++/Java are used for. On the other hand, any given system is going to run only one OS[0]. In any case, as I mentioned, it's a tradeoff. There's no absolute answer, though I think he's right here in that the benefits don't outweigh the costs for this example. Put another way, much as I might like to run a microkernel, I'd have a hard time concluding that it'd be the right move for the Linux project to spend time refactoring the entire codebase into a microkernel! On the other hand, to see an example of a rewrite that was successful, look at Reddit, which rewrote the entire codebase in its early days. GCC could also be considered an example, depending on how you look at it. [0] You can run more than one via virtualization, sure, but a number the benefits of Plan 9 come from having an entire set of computers running the same OS.
TempleOSV2 13y ago
I want all code to stay where it is. VIM is Linux. Come to the temple for new projects, like your hymn offerings. A C64 user's manual showed how to add binary graphics bit values together to make a balloon sprite in BASIC. Today, Bill Gates says, "You can make many fonts in HTML." The Linux people says, You can play with permissions and scripting.... I donno. New code that is like the existing 150 demos and applicatins and hymns is what it's for. I don't really wanty 3rd part libraries. I set a limit of 100,000 lines of code. Think of it like the C64 ROM that lasted unchanged for ten years, and all those modest games were built on top of it. Flappy birds and shit. God says... bring_it_on Burp fight small_talk you_owe_me gluttony do_you_have_a_problem lift astrophysics Yawn smart lighten_up what_would_Jesus_do Ivy_league service_sector Is_that_your_final_answer I'm_not_sure ba_ha lighten_up how_about_those_yankees hopefully ha you're_out_of_your_mind California my_precious tree_hugger eh absetively_posilutely persistence when_hell_freezes_over what_a_mess don't_you_love_me what_part_of_God_do_you_not_understand go_ahead_make_my_day who_are_you_to_judge peace incoming left_field What couldnt_possibly end hilarious I_forgot how_high =============== Let 8-year-olds make the games 8-year-olds play. Gabe is a faggot. Linus is a faggot with a cult. ===== If you are older then 12, make hymns. Games are for kids.
dylnclrk 13y ago
Was Vim a complete rewrite of Vi?
- graywh 13y ago
  Vim started as a Vi clone for the Amiga and later grew to include more features and target more systems.
- maxk42 13y ago
  Lots of things were a complete rewrite of vi. Vi was a complete rewrite of ex. ex was a rewrite of em, which was in turn a rewrite of ed, which was a rewrite of qed. Trying to rewrite vim is the wrong approach. Trying to replace it in a backward-compatible way, the way vim did to vi might received a lot better.
  - Narishma 13y ago
    Good thing then that they aren't rewriting vim.
edanm 13y ago
I get the idea that Bram thinks it's going to be more of a rewrite than I think it's going to be. As in, I assumed that neovim would not be a complete rewrite or something, but more targeted refactorings. Of course, Bram knows the codebase and I don't, and I may well have misunderstood the neovim plan, so I'm not sure which of us understands.
keyle 13y ago
Sorry to point out to the ironic here. But his signature includes the link to a "new programming language". And it reads much like "Neo-C".
tambourine_man 13y ago
The project has already surpassed its requested value in the first 48hs. The enthusiasm reminds me of git-annex. I really love this business model, the developer works on something he is passionate about, we can support the project and influence its future, all while strengthening the community around it.
lukasm 13y ago
Am I the only one thinking why C?
- pstuart 13y ago
  Nope. http://talks.golang.org/2014/go1.3.slide#23 http://talks.golang.org/2014/go1.3.slide#23
kzrdude 13y ago
Vim is not a healthy project. Example: They support transparent encryption for documents, but refuse to address or document the shortcomings of their implementation. It's of course a fully custom implementation of a half-homerolled protocol. Main flaws: Apart from implementation issues, non-authenticated encryption susceptible to bitflipping.
ageofwant 13y ago
My $20 is totally worth the "risk". Here's some dude from Brazil, that has at least some demonstrable skill, willing to take a month and have a go at improving a tool I use every day. For the price of four coffees. As for Bram, he can, and most likely will continue his good work on vim. I am kind of disappointed that he is not more supported of this effort though.
ayosec 13y ago
This reminds me to the origin of Inkscape, as a fork from Sodipodi. The (only) Sodipodi committer didn't want too many patches, and he wanted to stay with C (no C++ code). Some people forked Sodipodi, and created Inkscape. I can remember that one of their first tasks was to make the code compatible with a C++ compiler. Nowadays, Inkscape is a very good tool, and I hope that Neovim has a great success too.
sigzero 13y ago
I won't move off of Vim personally. I don't push it really as I use a pretty stock setup. However, good luck to the neovim devs, it will be cool to watch.
est 13y ago
Total refactoring without regression is rare. Especially in the wild.
huherto 13y ago
> It's going to be an awful lot of work, with the result that not all systems will be supported, new bugs introduced and what's the gain for the end user exactly? That may be a problem for vim but not for neovim. Neovim doesn't have a legacy user base, they can focus on the currently used systems.
jijji 13y ago
1. make kickstarter campaign to "revolutionize" open source project vim. 2. :%s/vim/neovim/g 3. profit!?!?!?!?!?
mekoka 13y ago
Total refactoring is not a solution. To Diego: Prove him wrong. I suspect that Bram has been maintaining the code base for so long, that he might need a bit more than a mere message to warm him up to the idea of a refactoring to the scale that you're undertaking. Also, you might not be the first person to contact him with such a proposal. I wonder how long it took for others before they gave up. Build something tangible and contact him again later with proof of concept, something that would make this more than just a fleeting dream. To people questioning Bram's position: You need to look a bit further than your nose. The fact that you want to create plugins or extensions does not put you in the mainstream as a Vim user. It's an extremely popular editor of almost religious proportion, with lots of existing plugins and extensions. So we know that people use it and making plugins is possible. With all of its annoyances it gets the majority of the job done for most users. One can't just wake up one day and say that they'll change things, not even Bram at this point. The most desirable outcome in my opinion would be to have Neovim be a continuation of Vim (Vim 10.0?) rather than just another fork, and for that, having Bram on board would be a boon. His longevity as a maintainer is impressive.
- gradstudent 13y ago
  Good points but I'm not convinced there exists a compelling reason to fork vim. From a user perspective there are no points of differentiation between NeoVim and vim. As an outsider looking in, it appears to me that NeoVim exists only to scratch the itch of some developers writing vim extensions. Is that reason enough to exist? Maybe. But what's the long-term aim here? Without a strong point of differentiation to attract users and thus developers NeoVim will be left forever playing catchup with Bram's original creation -- constantly rewriting new features to remain relevant and forever fixing both old vim bugs and new NeoVim-specific bugs.
  - weavie 13y ago
    That will depend on which way the extension developers go after that. If they all flock to neoVim then it will soon be the case that you have to use neoVim in order to use the best extensions.
  - 13y ago
jbranchaud 13y ago
As vi was a popular editor amongst programmers and system administrators, there initially was doubt whether Bram's 'improved' version could achieve the quality and fan following of the original. But since its first release for Unix systems in 1992, Vim has effectively eclipsed the original Vi, having won several awards[3] and has been referred to as one of the most popular text editors. - Excerpt from http://en.wikipedia.org/wiki/Bram_Moolenaar http://en.wikipedia.org/wiki/Bram_Moolenaar
z3phyr 13y ago
Abrash wrote in his graphics programming black book, and I quote, Carmack's law -> "I’ll take this opportunity to coin Carmack’s Law, as follows: Fight code entropy. If you have a new fundamental assumption, throw away your old code and rewrite it from scratch. Incremental patching and modifying seems easier at first, and is the normal course of things in software development, but ends up being much harder and producing bulkier, markedly inferior code in the long run, as we’ll see when we discuss the net code for QuakeWorld. It may seem safer to modify working code, but the nastiest bugs arise from unexpected side effects and incorrect assumptions, which almost always arise in patched-over code, not in code designed from the ground up. Do the hard work up front to make your code simple, elegant, great—and just plain right—and it’ll pay off many times over in the long run."
- ksk 13y ago
  If you watch any of Carmack's recent keynotes you'll see hes advocating doing the opposite now. Whats changed is the multi million dollar risk profile associated with modern game releases, the huge increases in the sizes of the teams, the large scale complexity of modern AAA code-bases, etc. And also the fact that most games now are data-dominant rather than being sold entirely on some new game-engine feature(s).
ChuckMcM 13y ago
Every 10 years or so I think some energetic programmers should set about writing God's Own Text Editor. There have been a lot of really useful technologies that have come from those efforts, whether it was EMACs, Gosling EMACs, vi, vim, pfe, visual slick edit, sublime text, or even wordpad. An editor is a fairly complete system, well within the capabilities of a single motivated individual, and like cocktail gowns entirely fashion/taste driven.
general_failure 13y ago
Refactoring is not a big deal. In fact I don't even want total compatible with vim.
thetxef 13y ago
maybe if Bram even commented on the two patches that Thiago had posted, things could have been different. All Thiago got was: being ignored, one of the worst ways of disdain. Not just even a 'thanks but not interested'. Other two guys who tried to provide patches to be merged on the same area also suffered from being mostly ignored (he replied to them but just once I think).
_pmf_ 13y ago
Streamlining and simplifying a code base by introducing JSON-RPC for internal API? Success is practically guaranteed!
chris_wot 13y ago
Refactoring is hard. I'm learning this with delving into the LibreOffice codebase. It's got a lot of issues - about 25 years of accreted code and design decisions that need unpicking, tangled code that needs refactoring, etc. However, it's sure easier to refactor than start from scratch! At least LO has a working product. Best of luck to the Neovim guys :-)
jballanc 13y ago
The old Unix ways are dying... Or, at least, I think that's the best way to summarize the essential miscommunication between these two camps. Vim is, in the spirit of Unix, a single purpose tool: it edits text. Why would it need threading? async? background jobs? You can't type in two places at once, right? NeoVim wants to be something like an IDE-lite. Text editing, yes, but with the ability to do background compilation/syntax checking, a bit of debugging here, some REPL-ish things there. For that you need a better async story, better process control, etc. So, in the end, I don't actually see a problem here. Vim will cater to one audience, NeoVim to another. For my money (or donation to Uganda), I'm happy using tmux splits, sending text between vim windows and REPL windows, and keeping Vim primarily as a text editor with syntax highlighting. I would appreciate if some events could be backgrounded (e.g. syntax check on file save), but I don't think this needs a complete refactor.
- fmoralesc 13y ago
  > You can't type in two places at once, right? You might want to. See https://floobits.com/ https://floobits.com/
- ansible 13y ago
  In some ways, neovim keeps to the Unix spirit better than vim. People already use vim as an IDE, but it doesn't work well in many cases. And the alternate user interfaces are not as good as they could be. If you've got a clean separation between the editing engine and the rest of the IDE suite of processes, that is the Unix way in my view.
farginay 13y ago
Clang v. GCC all over again?
bakul 13y ago
I haven't looked at vim code in ages but if it is really 300K lines of code, I wouldn't refactor it in any major way. If I absolutely wanted to scratch that particular itch, I'd rewrite it from scratch. In another language (not C or C++). And structure it differently.

221 points by dviola 13y ago

Perhaps this was mentioned the other day, but Neovim did make me think of this old chestnut from Joel Spolsky: http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000069.html I realize Neovim is being characterized as an "aggressive refactor," but I'm sure that's the way Netscape thought of it as well. tl;dr Things you should never do: rewrite the code from scratch.

city41 13y ago
37Signals rewrote Basecamp from scratch and as far as I know it's been very successful.
- Argorak 13y ago
  They wrote a whole new Basecamp. There is no migration path from Basecamp Classic to current and the feature set is not necessarily the same.
  - city41 13y ago
    Who knows, Neovim may very well drop support for vimscript and the entire ecosystem would have to start over. In the long run that may be a great thing.
- johnny99 13y ago
  It was rewritten by the same people who wrote the first version--very different from the Vim/Neovim case, and from Netscape 6.0. And who knows--37Signals might well have reused some of the innards.
  - city41 13y ago
    That is true and a fair point. Neovim will likely reuse pieces of Vim as well.
deleted 13y ago
[deleted]
typicalbender 13y ago
That was a really good article, thanks for sharing!
Jare 13y ago
When we started work on Commandos 2, we threw away everything from Commandos 1, and started from scratch. 15 years down the road, all the coders still agree that was the best decision ever.
- middleclick 13y ago
  Were you on the Commandos team? Mad respect to you. Probably my most favourite game of all times. Thanks for working on it.
  - Jare 13y ago
    Thanks! I was technology/tools lead on 2, and while my role in 1 was... hard to explain, yeah my contribution was important. :)
    - darklajid 13y ago
      Did you write about that somewhere? Could you, even? Pretty please?
  - deleted 13y ago
    [deleted]
- alecthomas 13y ago
  Man, I loved Commandos 1 back in the day. I recently got a bit nostalgic and bought the whole series on Steam, and they are still great games! But MAN are the controls opaque. Thinking back, I think the game came with a little cardboard sheet with all the controls on it, which would have been easier to deal with. Fantastic game though, thanks :)
- ramgorur 13y ago
  When I hear "Commandos" it makes me nostalgic :-(, but kudos to you and your team !!
- oftenwrong 13y ago
  Commandos 2 is one of my favorite games! I wish there were more games with the same mix of stealth and strategy being made.
dengnan 13y ago
> Things you should never do: rewrite the code from scratch. I can clearly see the benefit of this old wisdom under context of limited resource and limited time, esp. in a commercial company. However, as an experimental, personal(?), non-profit, free/open-source project, I do think neovim has value in its own right: 1. It won't affect any existing plan of vim, and won't change any existing code in vim. We can still happily use vim as usually. 2. If it succeeded, then we would have another powerful free/open source editor in our community. 3. If it failed, then we as a community have nothing to lose. The author might be unhappy then, but he would at least gain lots of experience. There are so many rewritings happen in this community, and they are definitely good things: - svn is a rewriting of cvs, and git is a totally new one (with more features?) written from scratch. - nginx was written even if there's apache httpd - There's zookeeper, but people wrote etcd - etc.
- hobs 13y ago
  I came to say this exactly. In a commercial project where time and money are limiting factors, you are almost insane to rewrite from scratch. In an OSS context, money is not always the biggest mover, and doing this might actually succeed, or at least not fail because the company fails. It certainly may be that the people lose interest before it gets anywhere, but who cares! The only reason that I could see is that someone wants to fold all their code changes back into vim's original codebase, and they both seem to have different end goals, so eventually they will drift away from each other. Code evolution.
haberman 13y ago
With that thinking we never get Linux (NeoMinix), tmux (NeoScreen), Clang (NeoGCC), WebKit (NeoGecko), Subversion (NeoCVS), or Vim itself (NeoVi/Elvis/Stevie/etc).
- raverbashing 13y ago
  Huummmmm no Neovim is being sold as a VIM refactor, but apparently with no new functionality Very different from Linux (had an aim of being a playground for new features), tmux is different from screen as Clang is different from GCC, Subversion is a totally different beast from CVS
  - haberman 13y ago
    > Neovim is being sold as a VIM refactor, but apparently with no new functionality Where did you get that idea? When I read the project page (https://github.com/neovim/neovim https://github.com/neovim/neovim), two of the explicit goals are: "Enable the implementation of new/modern user interfaces without any modifications to the core source. "Improve the extensibility power with a new plugin architecture based on coprocesses. Plugins will be written in any programming language without any explicit support from the editor. " It is exactly designed to be a playground for new features, but with the goal of them not having to be in the core.
    - pit 13y ago
      The original mailing list post says: "There's a new project that is called Neovim that seeks to refactor and modernize the codebase."
    - pit 13y ago
      The original mailing list message says: "There's a new project that is called Neovim that seeks to refactor and modernize the codebase"
      - zimbatm 13y ago
        That's the necessary step 1 to allow further enhancements
mjn 13y ago
> tl;dr Things you should never do: rewrite the code from scratch. Considering vim itself is a from-scratch 'vi' clone, that's interesting advice. :) But in any case, I see this as more of a fork than a rewrite. It's more akin to the XEmacs/GNU Emacs situation, where someone submits significant patches upstream which aren't accepted, and then forks their own version to continue that line of development.
- TazeTSchnitzel 13y ago
  Clones and rewrites aren't really comparable, though.
  - Pacabel 13y ago
    They're pretty comparable. A "clone" can almost always be considered a subset of a "rewrite". Both involve a new software system that is directly inspired by an existing one. The main difference is that a clone is often written by developers who had no involvement with the development of the original system. But that's not always true, especially for any old or sizable software system, where the original developers may no longer be involved.
    - dhimes 13y ago
      I think you are coming dangerously close to muddy semantics. Let's say: a clone is a clone- git clone, hg clone, etc. A rewrite may start with a clone, but the code is no longer a clone when you start the rewrite. A refactor is a subset of a rewrite. Now we can have meaningful discussions about them.
- sramsay 13y ago
  I think that's an excellent point. Vim is, after all, "Vi iMproved." nvi is a clone.
Cederfjard 13y ago
I'm somewhat confused by your comment, since the GitHub page explicitly says that NeoVim "is not a project to rewrite Vim from scratch". Where's the discrepancy here? Perhaps I'm just too tired right now.
InclinedPlane 13y ago
Spolsky is wrong. Rewriting is a significant risk, and rewrites often fail because people don't appreciate that fact. But there are ways to rewrite successfully, and often doing so is the correct course of action. A big problem with rewrites is that it puts a strain on development resources, and it's not possible to maintain both old and new code at the same time. Another big problem is prematurely committing to the rewrite, before it has proven itself. When the inevitable happens and schedules slip, defects arise, and features need to be cut this can prove disastrous for a rewrite that you've foolishly committed to in advance. Also, people often ignore the value of years of productive use which provides testing and validation of immense value. If you have the resources often the best choice is to spin off a new project for a rewrite and have them compete in the open. With luck the rewrite could become mature enough to overtake the original (as has happened with many projects). Alternately, work in phases doing refactoring in steps, perhaps with new features behind feature flags. Many people think that rewriting code is easier than green field development, in reality it's often more difficult. It takes a great deal of skill, and often luck, to manage a good rewrite.
- Pacabel 13y ago
  A significant problem is that there are a lot of developers today who revere Spolsky as some sort of a god, and absolutely refuse to question or reconsider anything that he has written. This trend is particularly bad with those who've gotten involved with software development since 2005 or so. I chalk it up to a lack of experience with massive, multi-decade software projects. If all a developer has worked with are small, recently-written Ruby on Rails apps, for example, then I don't think they can appreciate situations where rewrites of some degree are the only viable option. Hopefully this attitude regarding Spolsky's writing will change with time, as these people encounter the real-world situations where significant or total rewrites are basically the only possible option.
  - InclinedPlane 13y ago
    An even bigger problem, in my opinion, is the idea (usually only implicit) that any advice can apply to the entire panoply of software development. As though writing Flappy Bird and writing control software for the Falcon 9 weren't as different as banging together some shelving using plywood from home depot and machining custom components from exotic alloys using a lathe. An important part of maturing as a developer is learning to understand that different situations call for different techniques and being able to know what things are truly important with a given project and which aren't.
benched 13y ago
There is probably no Spolskyism that I disagree with more. And yet, I don't really disagree with what he said in context. The context is within a business where the opportunity cost could make it not worth it. If the only concern is making the software better, my experience is that rewriting does wonders for old code.
anon4 13y ago
What you're missing is that Netscape rewrote their own product from scratch. Neovim is a fork bringing very invasive changes (not rewriting from scratch) to a project by a different developer for the purpose of extending the original project in ways the current maintainer doesn't want to. So it's more like taking the old netscape code and making gecko.
Someone 13y ago
What makes you think this is a rewrite? If this is a rewrite from scratch, they are insanely fast coders, considering that they have a full-blown editor in less than a month (first commit is from January, 31) That first commit also shows it is not a rewrite, though, since it has a comment starting with "Import vim from changeset v5628:c9cad40b4181"
- eru 13y ago
  I wonder why they start with fresh history.
jey 13y ago
This isn't a "rewrite the code from scratch", but instead is an incremental but aggressive refactoring. There's at least one wildly successful example of this successfully being done for GCC, which is a project even bigger and more complex than Vim. Around GCC 2.8, it was forked into EGCS where major changes were made. This fork was so successful that it then became the official branch of GCC, and modern versions of GCC are direct descendants of EGCS.
- GFK_of_xmaspast 13y ago
  As I recall, EGCS happened because GCC development had stagnated, if not stalled entirely.
  - ticviking 13y ago
    You mean like vim development
kentosi 13y ago
I think that this is an unfair comparison. Netscape and Borland were business with financial targets, deadlines and (more importantly,) competitors vying for the same market share. These guys don't have these pressures, nor did (as per haberman's comment) Linux, tmux, Clang, WebKit, etc as far as I'm aware.
mildtrepidation 13y ago
tl;dr Things you should never do: rewrite the code from scratch. Sentiment like this is not valuable. The experience that it comes from is often informative, but as a conclusion, this explicitly ignores circumstances that sometimes do make rewriting a good, compelling course of action. Truly bad, unmaintainable code exists. It exists on projects that have long intended futures. It exists in all sorts of environments on all sorts of projects for all sorts of reasons. To discount the idea of a rewrite out of hand is a failure to objectively review the specific circumstances around whatever it is you're working on. Often there are better ways, and yes, often a rewrite is a bad idea. But absolutes are so rarely valid, and this one is most certainly not universally true.
shadowfox 13y ago
> but I'm sure that's the way Netscape thought of it as well Don't really think so. At least as far Netscape 6 went, they came up with an entirely different framework and moved over to Java (as far as I remember). I have rarely seen that sort of thing characterized as a refactor (even on their mailing lists).
- hnisnotreddit 13y ago
  The Seamonkey Project [1] is the current state of the Mozilla Application Suite[2], which Netscape 6 and 7 were branched from[3][4]. Written in C++ mostly. Some of us have been using Gecko as their renderer for almost sixteen years now. Seems KHTML(w), the base of both Webkit and Blink[5], is the same age. Seems we've gotten a good run out of the existing codebases. In fact, this means that Gecko (and khtml) have been in use twice as long as NCSA Mosaic, which the first Netscape was based on[6]. Imagine how Spolsky must feel about the Servo rewrite. 1. http://www.seamonkey-project.org/ http://www.seamonkey-project.org/ 2. https://en.wikipedia.orgwiki/Mozilla_Application_Suite#Market_adoption_and_project_end https://en.wikipedia.orgwiki/Mozilla_Application_Suite#Marke... 3. https://en.wikipedia.org/wiki/Netscape_6 https://en.wikipedia.org/wiki/Netscape_6 4. https://en.wikipedia.org/wiki/Netscape_7 https://en.wikipedia.org/wiki/Netscape_7 5. https://en.wikipedia.org/wiki/KHTML#KHTML_and_Apple https://en.wikipedia.org/wiki/KHTML#KHTML_and_Apple 6. https://en.wikipedia.org/wiki/Mosaic_%28web_browser%29 https://en.wikipedia.org/wiki/Mosaic_%28web_browser%29
fsloth 13y ago
Joel has lots of right things to say, but I'm afraid that one - "Never rewrite from scratch" - is far too sternly interpreted to the point where it is actually more harmful than beneficial. Of course you can rewrite from scratch. You just should not expect to reach the same feature coverage instantly, and should approach the work methodically. Most of all, you should have a good reason. "This code is spaghetti" is usually not one. "I want to implement feature X and the current codebase does not really support is" could be a good reason. Also, a rewrite is pointless from the point of view of code quality unless you are familiar with similar codebases operating in a similar domain. Main advantages or rewrite are, that when you are a domain expert and implementing and designing core routines, you get constant flashes of intuition "Aha, I should add this interface here because that will enable me to implement Foo and Bar using this instead of writing a FooSubsystem and BarSubsystem" and so on. If you have no experience from the domain, you get those insights only after you've written the code and are actually new proud owner of new heap of semi-maintainable code.
dasil003 13y ago
I tend to agree with Joel's thesis here, but the example is bad: Netscape was doomed either way, the rewrite was an act of desperation, and I'd say it succeeded because it led to Firefox which slowly clawed back those first few points of marketshare from Microsoft—enough to finally get them to resume browser development. Even assuming they could have pulled a rabbit out of their hat with the Netscape 4 codebase (which was unlikely considering the history of that codebase, and it's legacy compared to the talent and experience that was being pumped into the greenfield Internet Explorer (yes, ironic I know)), IE was still going to eat their lunch. Netscape was between a rock and a hard place. But hey, at least their code lives on today right?
egeozcan 13y ago
A general statement such as "never rewrite" is as good as something like "never grow a beard" - while it may be a good advice for someone working in a traditional corporate environment, it certainly doesn't make sense, let's say, for a freelancer.
emidln 13y ago
Teams I've been a part of are 3/4 (3 successes, 1 failure) on total rewrites over my career. The failure was entirely my fault as a developer not knowing my own limits (coding, design, security, devops, business reqs, managing up can't happen (at least for me) in the same 60 hours a week). It still almost succeeded on strength of the design and ability of my amazing coworkers to aggressively simplify and consolidate all the things. Rewrites fall into two categories: essential to business and doomed to fail. If it's essential that the business execute on a rewrite, it will happen or the business will fail. If it's not essential, it very well might be the reason the business fails (siphoning away talent and squandering time when a refactor or benign maintenance would suffice). Precisely because massive rewrites are so risky, they are undertaken by the foolish (myself firmly in this camp). The heuristic under which they might succeed is bare necessity.
hnisnotreddit 13y ago
Fun food for thought: NCSA Mosaic started in 1992, and ended in 1997. Netscape 4.0, the last user of this engine, stopped development in 1998. Gecko, the core of Mozilla, started in 1998, and is still in development 16 years later. So, the engine that Spolsky was saying was a mistake has now been in use for twice as long as the engine it was replacing.

bachback 13y ago

well of course. Vi was specifically written by Bill Joy to optimize for every character, see http://www.theregister.co.uk/2003/09/11/bill_joys_greatest_gift/ http://www.theregister.co.uk/2003/09/11/bill_joys_greatest_g... And there is no reason we could ever improve on that 35 years later. we need those optimizations... "It took a long time. It was really hard to do because you've got to remember that I was trying to make it usable over a 300 baud modem. That's also the reason you have all these funny commands. It just barely worked to use a screen editor over a modem. It was just barely fast enough. A 1200 baud modem was an upgrade. 1200 baud now is pretty slow. 9600 baud is faster than you can read. 1200 baud is way slower. So the editor was optimized so that you could edit and feel productive when it was painting slower than you could think. Now that computers are so much faster than you can think, nobody understands this anymore. "

perlgeek 13y ago
Whenever I use vim through a lagging SSH connection, I'm very happy that it's still usable (at least more so than other editors).
- jamestomasino 13y ago
  I feel the same way whenever I have to do work remotely on my phone. It's so precise and focused that I can get away with a few keypresses. I think neovim could be a great project and a major change for vim, but it could just as easily never reach a viable state. I won't suggest they give up, but I'm also not putting a lot of hope into it. Bram's vim is amazing, and even vi is stellar. I don't really see a downside whether they succeed or fail.
- mst 13y ago
  If you can stand the fact that it's only got the original feature set, ex-vi.sf.net provides a version of the original vi that runs on modern unices. I use it on a daily basis and have found that it copes with conference wireless far better than vim does.

typicalbender 13y ago

That seems like a fair response. I tend to agree that sweeping refactorings tend to take a lot of time and it's better to break off small bite size pieces. That being said I really like some of the proposed improvements into vim. I wonder if a similar approach could be taken as when vi was improved to create vim, or perhaps that's what added all the complexity Neovim is trying to solve.

perlgeek 13y ago

It's very easy to look at code base full of weird special cases and think "this could be such much easier if I started from scratch", but in the end if often turns out that all this cruft is there for a reason. It's essential complexity that you wrongly identified as artificial complexity. And the rewrite ends up being much more work than originally anticipated. I don't think there's a way to learn that except by making the same mistake yourself, possibly more than once.

CJefferson 13y ago
That is an overly simplistic viewpoint. Vim is written in an inedibly old style of C which is not taught anymore, or used by most people. The code if fill of typedefs for AMIGA and OS/2. Useful to a small number of people certainly, but making progression harder too. This is not a total rewrite, it is a massive overdue refactoring.
- perlgeek 13y ago
  > The code if fill of typedefs for AMIGA and OS/2. Useful to a small number of people certainly, but making progression harder too. Sounds like the code of pretty much every non-trivial C program that is meant to run of many platforms, not just the five or ten most popular ones. I'm not saying that this is a good thing, just that I don't know any good alternatives that don't sacrifice compatibility with lots of platforms.
  - kzrdude 13y ago
    It should say ifdefs, not typedefs. Inline ifdef directives everywhere is a real nightmare. The very first commit in neovim includes this log: - Process files through unifdef to remove tons of FEAT_* macros
    - teacup50 13y ago
      Which is exactly the sort of pointless "refactoring" that someone does instead of actual refactoring. It also makes merging back to vim difficult to impossible. Expect to see 'neovim' development dissipate rapidly.

CJefferson 13y ago

To be fair to the authors of neovim, there were patches they wrote and submitted to vim, which added exciting new features I would like, which were rejected. People who basically want him to never change (and that is fine) can be happy with mainline. There are others who would like to see some significant updates, particularly allowing better threading support.

shmageggy 13y ago
What were the features they submitted? Stuff that's mentioned on the github page or something else?
- Tyr42 13y ago
  Multithreading and job control
- btipling 13y ago
  At Floobits we tried to submit set_timeout/async stuff, and couldn't get anywhere with Bram. Months of work wasted. https://groups.google.com/forum/#!topic/vim_dev/-4pqDJfHCsM%5B1-25-false%5D https://groups.google.com/forum/#!topic/vim_dev/-4pqDJfHCsM%...
  - teacup50 13y ago
    Your patches were broken. People spent plenty of time trying to help you fix them. Your response is to tell the Internet that Vim is wrong for not accepting broken patches?
    - Jasber 13y ago
      Did you read the same thread I did? Floobits addressed all the issues. It came down to a fundamental design decision—and after months of hard work, they got a non-answer.
      - ampersandy 13y ago

hglaser 13y ago

Why aren't there other vim committers? Bram's conservatism makes perfect sense for someone who has to maintain this huge, consequential, intimidating codebase. Why hasn't he gotten some help?

kamaal 13y ago
Big old code bases, have a lot of what I call as 'tribal knowledge' associated with them. People go out, and do experiments only to burn their hands. Over years, the old maintainers generally accumulate a lot of ideas and 'tribal knowledge' to know why 'pie in the sky' ideas won't work. Nevertheless, people still try. A lot of them fail, a few succeed. The vim code base is around 300K lines of C code. I'm sure its nothing like Java where 90% of the code is get/set methods, high level delegating classes and exception handling code. 300K lines of code which does the actual work is simply too much code. And one should exercise great caution while dealing with it. Regression is just one thing, I'm sure there are a lot of places in the code which can silently break things you can't detect only to pop up in some strange case in the wild.
- ordinary 13y ago
  The vim code base is around 300K lines of C code. I found this hard to believe, so I ran it through cloc: ---------------------------------------------------- Language files blank comment code ---------------------------------------------------- C 113 33366 61819 285817 vim script 1186 22871 32599 145700 C/C++ Header 63 3175 4626 19735 Slightly more than 300k, but still mightily impressive.
- chris_wot 13y ago
  I can't speak for vim, but the following smacks of code that needs a refactor: 300K lines of code which does the actual work is simply too much code. And one should exercise great caution while dealing with it. Regression is just one thing, I'm sure there are a lot of places in the code which can silently break things you can't detect only to pop up in some strange case in the wild.
- 13y ago

tinco 13y ago

Well that does it I'd say. With such a negative attitude, who wants him on the team anyway? What the advantages are? They're clearly laid out in the project. Seriously, screw that guy. edit: Yes I know who 'that guy' is and it's great he's been working on Vim for all these years, but he certainly has his head up his ass if he thinks Vim users would not benefit from some big refactorings, a more accessible code base and some dropped platforms. If all those Amiga programmers love Vim so much, why would they be disappointed with an eternal Vim7.4? It's not too late for Vim to lose the editor wars.

aeonsky 13y ago
I still have yet to see these concrete user benefits.
- svalorzen 13y ago
  The benefit is indirect rather than direct, as in the user benefits from the increased availability of plugins/guis since they would be easier to create. Also vim lacks lots of very simple but essential features of modern code editors simply because it lacks the graphical capabilities to do so (an example would be displaying the documentation of some method you are autocompleting, something which I have never seen in vim and which I actually believe is impossible).
  - psquid 13y ago
    > an example would be displaying the documentation of some method you are autocompleting, something which I have never seen in vim and which I actually believe is impossible For python at least, having 'preview' as part of your completeopt has it display the docstring of what you're completing. And :h completeopt suggests that's intended behaviour for all types of completion (where it makes sense), too.
    - fmoralesc 13y ago
      Yes, but currently retrieving that info is done synchronously, so it might slow down things. Under neovim's model, this can be done more efficiently.

codelap 13y ago

What would you call going from vi to vim? Regardless, anything that fixes the mess that is vimscript gets a thumbs up from me.

chimeracoder 13y ago

He's right. With every project, there's a tradeoff between achieving the goals of the project and maintaining compatibility with existing systems. As a Go programmer, I feel a bit sad/ashamed to be saying this, but look at Plan 9 - it failed to usurp Unix (and its descendants) as the dominant OS, because the latter was "good enough", and was already more widely supported and used. Plan 9 vs. Unix is a very different comparison than Vim vs. Neovim, and there are a lot of other factors at play, but the same principle actually holds. Improving or extending an existing system in a compatible way is a lot easier than trying to establish mindshare with a completely new tool. The tradeoff is that extending existing systems leads to cruft and bloat. So if you can establish mindshare with a new tool, you have an opportunity to make a much more elegant one. But that's a big "if". EDIT: I think a better analogy may be an attempt to refactor the Linux kernel into a microkernel. I'd certainly love it if this magically happened - microkernels are much easier to work with, and much more elegant. But it'd be hard to make the case that that'd be a worthwhile endeavor at this point, given the costs of doing so.

pcwalton 13y ago
But isn't Go itself an example of success with a complete rewrite?
- chimeracoder 13y ago
  Good point. If you view Go as a "rewrite" of C, then perhaps, but I wouldn't. It's a new language altogether. C can be embedded in Go easily, and even if it couldn't, there's no reason that one has to "win out" over the other. There's less direct competition between two languages than there is with a family of OSes. And Go was never intended to replace C completely - it just provides a better alternative for some subset of what C/C++/Java are used for. On the other hand, any given system is going to run only one OS[0]. In any case, as I mentioned, it's a tradeoff. There's no absolute answer, though I think he's right here in that the benefits don't outweigh the costs for this example. Put another way, much as I might like to run a microkernel, I'd have a hard time concluding that it'd be the right move for the Linux project to spend time refactoring the entire codebase into a microkernel! On the other hand, to see an example of a rewrite that was successful, look at Reddit, which rewrote the entire codebase in its early days. GCC could also be considered an example, depending on how you look at it. [0] You can run more than one via virtualization, sure, but a number the benefits of Plan 9 come from having an entire set of computers running the same OS.

TempleOSV2 13y ago

I want all code to stay where it is. VIM is Linux. Come to the temple for new projects, like your hymn offerings. A C64 user's manual showed how to add binary graphics bit values together to make a balloon sprite in BASIC. Today, Bill Gates says, "You can make many fonts in HTML." The Linux people says, You can play with permissions and scripting.... I donno. New code that is like the existing 150 demos and applicatins and hymns is what it's for. I don't really wanty 3rd part libraries. I set a limit of 100,000 lines of code. Think of it like the C64 ROM that lasted unchanged for ten years, and all those modest games were built on top of it. Flappy birds and shit. God says... bring_it_on Burp fight small_talk you_owe_me gluttony do_you_have_a_problem lift astrophysics Yawn smart lighten_up what_would_Jesus_do Ivy_league service_sector Is_that_your_final_answer I'm_not_sure ba_ha lighten_up how_about_those_yankees hopefully ha you're_out_of_your_mind California my_precious tree_hugger eh absetively_posilutely persistence when_hell_freezes_over what_a_mess don't_you_love_me what_part_of_God_do_you_not_understand go_ahead_make_my_day who_are_you_to_judge peace incoming left_field What couldnt_possibly end hilarious I_forgot how_high =============== Let 8-year-olds make the games 8-year-olds play. Gabe is a faggot. Linus is a faggot with a cult. ===== If you are older then 12, make hymns. Games are for kids.

dylnclrk 13y ago

Was Vim a complete rewrite of Vi?

graywh 13y ago
Vim started as a Vi clone for the Amiga and later grew to include more features and target more systems.
maxk42 13y ago
Lots of things were a complete rewrite of vi. Vi was a complete rewrite of ex. ex was a rewrite of em, which was in turn a rewrite of ed, which was a rewrite of qed. Trying to rewrite vim is the wrong approach. Trying to replace it in a backward-compatible way, the way vim did to vi might received a lot better.
- Narishma 13y ago
  Good thing then that they aren't rewriting vim.

edanm 13y ago

I get the idea that Bram thinks it's going to be more of a rewrite than I think it's going to be. As in, I assumed that neovim would not be a complete rewrite or something, but more targeted refactorings. Of course, Bram knows the codebase and I don't, and I may well have misunderstood the neovim plan, so I'm not sure which of us understands.

keyle 13y ago

Sorry to point out to the ironic here. But his signature includes the link to a "new programming language". And it reads much like "Neo-C".

tambourine_man 13y ago

The project has already surpassed its requested value in the first 48hs. The enthusiasm reminds me of git-annex. I really love this business model, the developer works on something he is passionate about, we can support the project and influence its future, all while strengthening the community around it.

lukasm 13y ago

Am I the only one thinking why C?

pstuart 13y ago
Nope. http://talks.golang.org/2014/go1.3.slide#23 http://talks.golang.org/2014/go1.3.slide#23

kzrdude 13y ago

Vim is not a healthy project. Example: They support transparent encryption for documents, but refuse to address or document the shortcomings of their implementation. It's of course a fully custom implementation of a half-homerolled protocol. Main flaws: Apart from implementation issues, non-authenticated encryption susceptible to bitflipping.

ageofwant 13y ago

My $20 is totally worth the "risk". Here's some dude from Brazil, that has at least some demonstrable skill, willing to take a month and have a go at improving a tool I use every day. For the price of four coffees. As for Bram, he can, and most likely will continue his good work on vim. I am kind of disappointed that he is not more supported of this effort though.

ayosec 13y ago

This reminds me to the origin of Inkscape, as a fork from Sodipodi. The (only) Sodipodi committer didn't want too many patches, and he wanted to stay with C (no C++ code). Some people forked Sodipodi, and created Inkscape. I can remember that one of their first tasks was to make the code compatible with a C++ compiler. Nowadays, Inkscape is a very good tool, and I hope that Neovim has a great success too.

sigzero 13y ago

I won't move off of Vim personally. I don't push it really as I use a pretty stock setup. However, good luck to the neovim devs, it will be cool to watch.

est 13y ago

Total refactoring without regression is rare. Especially in the wild.

huherto 13y ago

> It's going to be an awful lot of work, with the result that not all systems will be supported, new bugs introduced and what's the gain for the end user exactly? That may be a problem for vim but not for neovim. Neovim doesn't have a legacy user base, they can focus on the currently used systems.

jijji 13y ago

1. make kickstarter campaign to "revolutionize" open source project vim. 2. :%s/vim/neovim/g 3. profit!?!?!?!?!?

mekoka 13y ago

Total refactoring is not a solution. To Diego: Prove him wrong. I suspect that Bram has been maintaining the code base for so long, that he might need a bit more than a mere message to warm him up to the idea of a refactoring to the scale that you're undertaking. Also, you might not be the first person to contact him with such a proposal. I wonder how long it took for others before they gave up. Build something tangible and contact him again later with proof of concept, something that would make this more than just a fleeting dream. To people questioning Bram's position: You need to look a bit further than your nose. The fact that you want to create plugins or extensions does not put you in the mainstream as a Vim user. It's an extremely popular editor of almost religious proportion, with lots of existing plugins and extensions. So we know that people use it and making plugins is possible. With all of its annoyances it gets the majority of the job done for most users. One can't just wake up one day and say that they'll change things, not even Bram at this point. The most desirable outcome in my opinion would be to have Neovim be a continuation of Vim (Vim 10.0?) rather than just another fork, and for that, having Bram on board would be a boon. His longevity as a maintainer is impressive.

gradstudent 13y ago
Good points but I'm not convinced there exists a compelling reason to fork vim. From a user perspective there are no points of differentiation between NeoVim and vim. As an outsider looking in, it appears to me that NeoVim exists only to scratch the itch of some developers writing vim extensions. Is that reason enough to exist? Maybe. But what's the long-term aim here? Without a strong point of differentiation to attract users and thus developers NeoVim will be left forever playing catchup with Bram's original creation -- constantly rewriting new features to remain relevant and forever fixing both old vim bugs and new NeoVim-specific bugs.
- weavie 13y ago
  That will depend on which way the extension developers go after that. If they all flock to neoVim then it will soon be the case that you have to use neoVim in order to use the best extensions.
- 13y ago

jbranchaud 13y ago

As vi was a popular editor amongst programmers and system administrators, there initially was doubt whether Bram's 'improved' version could achieve the quality and fan following of the original. But since its first release for Unix systems in 1992, Vim has effectively eclipsed the original Vi, having won several awards[3] and has been referred to as one of the most popular text editors. - Excerpt from http://en.wikipedia.org/wiki/Bram_Moolenaar http://en.wikipedia.org/wiki/Bram_Moolenaar

z3phyr 13y ago

Abrash wrote in his graphics programming black book, and I quote, Carmack's law -> "I’ll take this opportunity to coin Carmack’s Law, as follows: Fight code entropy. If you have a new fundamental assumption, throw away your old code and rewrite it from scratch. Incremental patching and modifying seems easier at first, and is the normal course of things in software development, but ends up being much harder and producing bulkier, markedly inferior code in the long run, as we’ll see when we discuss the net code for QuakeWorld. It may seem safer to modify working code, but the nastiest bugs arise from unexpected side effects and incorrect assumptions, which almost always arise in patched-over code, not in code designed from the ground up. Do the hard work up front to make your code simple, elegant, great—and just plain right—and it’ll pay off many times over in the long run."

ksk 13y ago
If you watch any of Carmack's recent keynotes you'll see hes advocating doing the opposite now. Whats changed is the multi million dollar risk profile associated with modern game releases, the huge increases in the sizes of the teams, the large scale complexity of modern AAA code-bases, etc. And also the fact that most games now are data-dominant rather than being sold entirely on some new game-engine feature(s).

ChuckMcM 13y ago

Every 10 years or so I think some energetic programmers should set about writing God's Own Text Editor. There have been a lot of really useful technologies that have come from those efforts, whether it was EMACs, Gosling EMACs, vi, vim, pfe, visual slick edit, sublime text, or even wordpad. An editor is a fairly complete system, well within the capabilities of a single motivated individual, and like cocktail gowns entirely fashion/taste driven.

general_failure 13y ago

Refactoring is not a big deal. In fact I don't even want total compatible with vim.

thetxef 13y ago

maybe if Bram even commented on the two patches that Thiago had posted, things could have been different. All Thiago got was: being ignored, one of the worst ways of disdain. Not just even a 'thanks but not interested'. Other two guys who tried to provide patches to be merged on the same area also suffered from being mostly ignored (he replied to them but just once I think).

_pmf_ 13y ago

Streamlining and simplifying a code base by introducing JSON-RPC for internal API? Success is practically guaranteed!

chris_wot 13y ago

Refactoring is hard. I'm learning this with delving into the LibreOffice codebase. It's got a lot of issues - about 25 years of accreted code and design decisions that need unpicking, tangled code that needs refactoring, etc. However, it's sure easier to refactor than start from scratch! At least LO has a working product. Best of luck to the Neovim guys :-)

jballanc 13y ago

The old Unix ways are dying... Or, at least, I think that's the best way to summarize the essential miscommunication between these two camps. Vim is, in the spirit of Unix, a single purpose tool: it edits text. Why would it need threading? async? background jobs? You can't type in two places at once, right? NeoVim wants to be something like an IDE-lite. Text editing, yes, but with the ability to do background compilation/syntax checking, a bit of debugging here, some REPL-ish things there. For that you need a better async story, better process control, etc. So, in the end, I don't actually see a problem here. Vim will cater to one audience, NeoVim to another. For my money (or donation to Uganda), I'm happy using tmux splits, sending text between vim windows and REPL windows, and keeping Vim primarily as a text editor with syntax highlighting. I would appreciate if some events could be backgrounded (e.g. syntax check on file save), but I don't think this needs a complete refactor.

fmoralesc 13y ago
> You can't type in two places at once, right? You might want to. See https://floobits.com/ https://floobits.com/
ansible 13y ago
In some ways, neovim keeps to the Unix spirit better than vim. People already use vim as an IDE, but it doesn't work well in many cases. And the alternate user interfaces are not as good as they could be. If you've got a clean separation between the editing engine and the rest of the IDE suite of processes, that is the Unix way in my view.

farginay 13y ago

Clang v. GCC all over again?

bakul 13y ago

I haven't looked at vim code in ages but if it is really 300K lines of code, I wouldn't refactor it in any major way. If I absolutely wanted to scratch that particular itch, I'd rewrite it from scratch. In another language (not C or C++). And structure it differently.