VectorStorm Blog

I mentioned a few weeks back that I’ve switched to using Vim as my main editor, and couldn’t be happier.  A lot of that was due to my personal dislike for features which are becoming increasingly common and difficult to disable in popular IDEs, and which I can completely disable within Vim.  But to be honest, most third-party editors would work just as well;  Vim just works for me.  Others can (and do!) prefer Notepad+, Emacs, TextEdit, SublimeEdit, and others.  The key point I wanted to make to other programmers is that it’s worth experimenting with text editors — there’s no need to lock yourself to the one that came with your IDE!

Anyhow.  At a similar time to when I started using vim, I started experimenting with using git, rather than subversion, for source control.  This wasn’t for any special reason, just that I’d been learning a little git (since it’s very popular amongst vim users), and wanted to make a lightweight repository for tracking changes to my Vim preferences.  And then for fun, I imported the MMORPG Tycoon 2 history into git

For me, the best feature of git, compared against subversion, is the ease with which it handles branching and merging, which were always at least mildly painful under subversion.  With git, though, it’s so easy to maintain separate streams of development that suddenly, I’m finding that I can work on several features at once, each separately from each other.  The screenshot above shows a graphical view of the current MMORPG Tycoon 2 codebase.  Right now, I have four different feature branches running, some for core features (“context” is for figuring out how to handle the context actions which I’ve previously shown in a “context matrix”), and some experimental (“duothreadman”, which is doing comparitive performance testing by maintaining two separate pools of threads, so that a glut of low-priority tasks can’t clog up the task queue).  If a feature branch works out well, I can merge it back into the master branch.  If not, I can just delete it and it doesn’t clutter up my repository any more.

Under git, it takes a fraction of a second to create a new feature branch, or to switch from one to another.  These operations would have taken several minutes each under subversion, and been major undertakings which had to be carefully considered and executed.  But they’re trivial now;  not even worth spending time thinking about.  Just make the branch, and delete it later if it turns out to have been a bad idea.

This sort of flexibility means that when I’m feeling blocked on one task, I can easily set it aside and work on a different task, without having to struggle to keep the two sets of changes distinct from each other.  And that’s tremendously freeing.

So it’s Vim‘s twentieth birthday today.  Or yesterday, depending on where you stand vis-a-vis the international dateline.  (screenshot above is MacVim displaying a snippet of the current MMORPG Tycoon 2 codebase)

For those with other backgrounds, vim is a free text editor.  It’s basically an improved version of vi, the original visual text editor.  (vi was the first program which would display your text at the same time that you were editing it)  Another popular old text editor which is still in modern use is emacs.  And the flame wars between vi users and emacs users are one of those eternal debates amongst IT people who have nothing better to do with their time, right up there with tabs vs. spaces (tabs), tabstops (4), little-endian vs. big-endian (big), and Coke vs. Dr. Pepper (just some tea, please, and a little bit of milk would be lovely, thanks).

Functionally, vim is just a text editor.  But it’s a text editor that’s designed around being used exclusively by the keyboard;  once you really know what you’re doing, you never have to touch the mouse at all.  Or even move your fingers away from the home row.  (Don’t touch your arrow keys!)  Once you get used to it, it’s actually substantially faster and easier to get around a text file — or a whole project — this way.  But it does take a bit of practice and research to reach the point where it becomes effortless.

Oddly enough, my first experience with vim was with its first appearance anywhere;  on Fish Disk #591, for my Amiga 500 computer.  Admittedly, it completely baffled me at the time, and I quickly threw it aside to spend more attention on the various games which were (let’s be honest) the main reason I acquired and kept those disks of freeware software.  And it wasn’t until a decade later that I’d re-encounter vim, as I started to play with Linux, where it was one of several “vi-like” editors available (though it seemed to be gaining acceptance as the best of the lot).  I still didn’t use it much, but I at least learned enough to use it as my default Unix editor.  And during my time at Atari Melbourne House, I wrote a few server programs and a lot of perl scripts, all using vim as my source code editor.

But it wasn’t until very recently, when I started poking with Xcode 4, with its major revamp of Mac and iOS coding features, where I finally decided that I really wanted a more consistent interface for writing code, something that would work the same across multiple platforms, and would remain responsive and not inexplicably freeze up the way that most IDEs will occasionally do.  Other people talked about how great the Mac-exclusive text editor TextMate is, and I considered it, but I really wanted something that I could use on any platform.  So my mind went back to vim, and I really dove into all the details that I had only skimmed before.

I would estimate that it took me about two weeks of full-time development using vim to get back to my usual development speed.  And after another two weeks, I was substantially faster in vim than in other editors.  (Of course, I was already familiar with many of the core vim concepts;  others have estimated 1-2 months to become proficient, for someone who’s jumping in cold)

Anyhow.  I just wanted to mention.  Just because it’s made coding so much less painful, again.  Any coders out there, I’d definitely recommend experimenting with other text editors, and see if there’s one that works well for you personally.  Don’t just always use the one that’s built straight into your IDE by default, the way that most of us do.  There are far better tools available out there, if you’ll only look!

Just got back from Freeplay.  I think my talk went relatively well;  had a painfully dry throat until some event organiser kindly brought me a bottle of water, and it took the audience a little while to warm up, but we eventually got there.  I got through all the topics I wanted to cover, and I don’t think I made myself look too silly in the process.  :)

Paul Callaghan’s crowd-sourced “unKeynote” concept seemed to be a huge success.  I’d like to be the first one to call for its return in future Freeplays, even if funding is available to bring in a more traditional keynote speaker.

Anyhow, I’ll be back at FreePlay again tomorrow, just listening to sessions.  And tonight?  Tonight I’ll probably play some Bastion, before getting some early sleep.

For anybody in or near the Melbourne area, just a quick side-note that I’ll be speaking at FreePlay next weekend, discussing my favourite subject:  how code can affect player perceptions of a game.  There’ll be some re-covering of stuff from VGKnowHow, and a lot of new stuff as well.  My session goes from 14:45 – 15:45 on Saturday, August 20th, at the State Library of Victoria.  There are further details, for anyone interested.

Tickets to FreePlay are $35 for access to the conferences and workshops.

If you’re in the vicinity, drop by and say ‘hi’!

We’re now up and running on the new server.  I think that everything has been moved across successfully, but please let me know if you spot anything that’s not working the way that it used to be working.  (Yes, the ‘forum’ link is temporarily disabled.  Let me know if you notice any other broken links, though!)