Dwarf Fortress' creator on how he's 42% towards simulating existence | Hacker News Reader

Dwarf Fortress' creator on how he's 42% towards simulating existence

pcgamer.com

267 pointsphodo129 comments

Quote from Tarn Adams (DF's creator):

I don’t even use version control. If you don’t know what that is then you’re not gonna yell at me. If you even know what version control is you’re gonna be like, ‘You don’t use version control? You don’t use source control? What is wrong with you? How can you even work?’

If you're the sole developer of a project and you have, say, hourly backups, then maybe version control is a waste of effort? I would still use it out of habit, but it seems perfectly reasonable to me that Tarn would choose not to.

I don't think it would be a waste of effort. Unless he's got an amazing mind, uncanny ability not to make mistakes, and doesn't forget anything, getting `$vc blame ...` is worth it on its own. I'd argue it's not reasonable, but it's his choice to make.

But I really hope he's got automatic, offsite backups going.

Not sure if he will ever read this thread, but FWIW, free rsync.net account for life, if he wants one.

Same goes for Terry A. Davis.

For me version control isn't even really about having backups (though that is a nice side effect). Version control is about documenting and annotating the process of creation, and it is uniquely necessary in programming because of how eternally iterative programming is. Code that is not annotated with its history and its motivations suffers to an extreme degree from entropy, becoming more and more difficult to understand.

VC is part of code. Not using it is, to me, like refusing to use verbs.

well vc to me is about merging and managing integration in a sane way, the ability to rollback on snafu is surely welcome, but for my side projects I just use some cloud sync service

Then you lack the history of your code, storing only the latest version. Though for personal projects, this might not matter, it's all a part of discipline in my eyes.

If you see SCM as too time consuming, then I think you need more practise, and as such, should be using as much as you can.

I agree that version control is a fundamental part of software and if you ever have to read code I hope you have access to the versioning and issue discussions. Some people are ok without it for personal projects, but one day someone is going to read your code. Please be nice to them and give them the history behind your decisions.

To me it's a way of creating checkpoints which I can revert to when I've taken a wrong turn. It actually increases productivity for me.

It's also a useful way of managing different experiments, and discarding the ones that didn't work and reverting to last known good, or integrating the ones that do work. That gets increasingly messier as your codebase grows.

Version Control is not really a part of the code, but it's a part of the whole project if you will. There's code, version control, build system, issue tracker.

In some cases these can be very simple, and the simplest cases I can think of are: version control - backups, build system - batch/script file, issue tracker - text file.

Although once you know one of the more complex versions of each system then it's easier to just use that. (Git/SVN/CVS, make/CMake/Premake, etc)

Not using VC is coding with permadeath.

We play Dwarf fortress; Tarn is playing the meta game.

This is the same exact argument against buying renter's insurance (for instance).

Lot's of programmers are creatures of habit. It probably is faster for him to work without version control. Until that one day when it isn't and he wishes he was.

It's the next level on from "I don't need comments, I can remember everything" and "meaningful variable names take too long to type"

> This is the same exact argument against buying renter's insurance...

Eh? I don't buy RI because

* I can cover the replacement cost of everything covered by pretty much every RI policy I've ever seen

* Over the decades I've been living on my own, I've never had a situation where any RI policy would kick in

Therefore, RI policies are nothing but money set ablaze for me. I'd rather make use of that money.

Can you cover the cost of everything at once? If that's the case, good for you, but I pay for insurance to cover those one in a million chances like the house burning down with everything in it. It's entirely possible I'll never claim, but if my house just burnt down I don't want to be worrying about where I'm going to find money for a hotel tonight, and replacing everything I own tomorrow.

Renters insurance isn't just about replacing your belongs, it also is about liability coverage (e.g. someone is injured in your apartment.)

Insurance is state by state. And the $10K I had on my apartment before I dropped it wouldn't pay for a paper cut in the ER anyway. At least it was extremely cheap like $10/yr as some kind of package deal with my car insurance. That was for a masonry and steel and tile apartment building, likely a wood house would be much more expensive.

> Can you cover the cost of everything at once?

Yes. That's why I said that I could cover the replacement cost of everything. :)

My real loss would be the data that doesn't have offsite backups. I'm unaware of any RI policy that will cover highly-competent data recovery services. (And if one exists, I expect that it will be outrageously expensive.)

A good test may be how long you have to be saving the insurance payments to cover everything.

> Over the decades I've been living on my own, I've never had a situation where any RI policy would kick in

That's fairly expected. Given my current RI cost and how much it covers, they're losing money if I make a significant claim more than every 200 years or so.

An overflow from a bathtub on the 9th floor can cause ~40k of damages in under an hour.

Renters caps at 300k and they added that cap becuase you can easily reach that level of damage. Still it's 10$ a month so the odds of that happening are rather low.

My apartment complex requires proof of renter's insurance above 300k for me to even live here. I've nearly gotten in trouble a couple of times when the old proof reached its expiration and I neglected to show them the updated documents.

Popular version control takes natural, insignificant, almost unconscious modifications and turns each into an explicit diff that must be entered into the system and documented forever. If you are a solo developer, version control is literally a waste of time. Just write the damn code and back up it at the end of the day. Leave meticulous documentation to the uberprojects, megacorps, and CS grads that want to pretend that they are doing something meaningful.

I disagree. Version control very much impacts the process of writing code. For example, if I'm going to make a major change to a solo project but I don't know what angle to approach it from, I'll create a branch to test one approach and another to test a different approach. If I'm unhappy, I can always branch from master again. The alternative would be to either attempt to make as few breaking changes as possible or test out exactly one at a time and lose progress when I go from one approach to another. Also, if I need to go back to an older version to fix something broken or remove a part of my code, commit messages document the changes so that I don't have to think of the code as a linear timeline of changes and search for the date, but rather search for commits that include keywords in the names and focus on those.

You can do much of what you described by copying directories around, keeping a text file running sheet and judicious use of winmerge. The key thing is to be managing complexity. git provides good mechanisms for this but it is not the only way. Linus didn't use version control for at least a decade, either. git started out as an automation of an existing manual process he had.

> You can do much of what you described by copying directories around, keeping a text file running sheet and judicious use of winmerge.

Sorry, but can I just check, are you saying this is the alternative as in you SHOULD do this, or are you saying this is the alternative as in you SHOULD NOT do this?

It's just the way you wrote it sounds like you're saying this is the recommended way of developing, which I'm sure is not what you meant.

Also, is winmerge available in .deb/.rpm?

Your post is passive-aggressive from start to end. If you state questions respectfully I'll have a shot at a response.

Winmerge is Windows only. I imagine this means this strategy can't be followed at all unless you use Windows? ;)

The approach is an alternative, as in: you can do it. I used to work that way before I used version control, and I know I'm not the only one. I definitely prefer the workflow with version control, that's for sure, but some seem not to find it especially compelling when working alone and that is their prerogative.

When you're working on your own, any process is fine, if you are comfortable with it. The object of the exercise is to create useful/interesting/etc. products for people to use/enjoy/etc. - and you'd have a hard time arguing that this is a goal Dwarf Fortress has failed to meet.

(Unsurprisingly, I've yet to meet anybody that's preferred working without source control on shared code. But perhaps they do exist.)

This is still version control, just without very many features and easy to mess up.

> If you are a solo developer, version control is literally a waste of time.

Strong disagree. If you're working on things that are sufficiently complex, you'll not-infrequently find yourself in a situation where the thing you were working on has become broken, and you can't remember how or when it broke.

Single-dev version control lets you make frequent checkpoints so that you can compare the current state to a previous one to discover the source of and quickly recover from failures of the mind such as these.

My git history is littered with one or three word commit messages. If I ever go to publish my code (or finish with what I was doing) then I rebase all that shit into a coherent history. But, until that point I don't spend even a microsecond worrying about attaching meaningful messages to my checkpoint commits.

Eh...I find git is actually really bad for this type of thing. It's too in the way. Git is great for "I'm throwing all this out, but want to remember what I did or some of the neat things in it".

But to fix an accident? That's what ~5-min ZFS snapshots are for.

That sounds like a pretty nifty feature - can you point at any docs about how that works/how to set it up?

At university the lab systems had a networked home directory setup, and one of the greatest things was a '/yesterday/' link to your personal homedir, exactly as it was 1 day ago.

I have no idea how they set it up, but something along these lines is plausible.

How are ~5 minute ZFS snapshots significantly better than

  git log --patch

to look at your history, combined with

  git checkout $COMMIT

to get the code to perform any tests required? (Or, if you have a reliable automated test,

  git bisect start HEAD $KNOWN_GOOD_COMMIT -- && git bisect run $TEST

will automatically find the error for you.) [0][1]

And remember that the git checkpoint creation process is -at its most verbose- running

  git commit -m "C"

[0] You can use points-in-time as commit references, like 'master@{30 minutes ago}' or 'HEAD@{2016-01-01}'

[1] And even if you don't have a test, you can easily manually run the bisect machinery.

You can use version control as a domain-specific backup tool. I think it's irrational to not use it if unless you're writing some quick toy code.

Git branches have changed the way I code. Even if I didn't have to maintain stable and development branches of my apps the other benefits are well worth the very small overhead of managing code in Git.

And of course with even one other developer working on the same code base I'd say VC is practically mandatory.

> If you are a solo developer, version control is literally a waste of time.

If and only if you're a solo developer working on a single computer and work on a pretty linear, one feature at a time development.

And if you're a solo dev, you won't need to "waste" a lot of time in version control anyway. All you need is "git init", "git add" and "git commit" and you're already better off than without. Anything on top of that is optional but useful.

Using version control like git kinda forces you to change the way you are developing. You start to think more about building logical pieces and also really think about how the software is coming along.

I would recommend learning git for anyone. Sure, it's a big hassle, because it forces you to rethink your habits. But in the end, learning it has done me nothing but good and using it enforces me to follow good practice at the same time.

Also, just the support of 'git stash' to throw away experiments that didn't work easily is worth it. Tagging versions for release, demos, whatever .. git can help there too.

> Using version control like git kinda forces you to change the way you are developing.

It doesn't. Nothing prevents you from adding/committing several days worth of work with a "changed stuff. fixed some other stuff" commit message.

Ok, using SCM like git _allows_ you to change the way you are developing. You will still need to use the tool correctly.

If people have good reasons for not doing certain things, then fine, but when people are just averse to it because they're lazy, well, that irks me (when I have to deal with them.)

Very true. I knew a lead developer once that with the majority of his commits to TFS would give it some variation on the commit "latest and greatest" (If he didn't want to type that it might be "l&g").

I didn't speak up about it because I was only a contractor at the time, but it made me wince to see a whole history list of his commits with like 20 "latest and greatest" and maybe three commits that actually said what he did.

But most places I've been to, people have been pretty good about explaining what they've committed, when version control was being used.

I use this in an alias:

git log --pretty=oneline --abbrev-commit --graph --stat

Seeing the names of the changed files in each commit gives me a lot more of context than simply the commit description.

And I could double-click any commit and get the 'changeset details' with all the files modified and their diffs, but it's still better to provide an overview of what you're checking in instead of forcing people to interpret your code.

At my current job we have dev tasks associated with the changesets (if applicable), so that helps provide context also.

You make it sound a lot harder than it is.

What it is:

  git commit -am '(what changed)'

Effortless combination of history, backup, and publishing. There’s very little reason not to do it. Up to preference how often it’s done and how detailed messages are.

Even on a solo project, `git bisect` by itself is more than enough reason for me to use source control. I could script something similar that ran against my daily backups, but then I'd have to recursively diff two backups to find out what had changed between them - at which point I'm basically implementing a shoddy subset of what git already does.

My 'backups' may as well be a cronned:

  git add . && git commit -m "Daily snapshot" && git push

Ta-da! You are now 'using' source control.

This or any other automatic backup solution has a big problem though: if the backup happens while you have a syntax error or something in your code then your test suite will fail and any bisect type functionality you have will be useless.

There's nothing 'forever' about this. If you don't like all that cruft in your version control, you can always just start a new 'clean slate' repo. And you don't have to document anything. And it literally takes 2 seconds to commit and push your code from the command line.

You waste more time picking your nose.

> Just write the damn code and back up it at the end of the day.

If you save a copy of your code each day, you are using version control - just an ad-hoc, error-prone sort of version control that wastes space and makes it painful to do any of the things people use version control for.

Although I would not subscribe to the idea that VC as a solo developer is always a waste of time, there are definitely small scope projects where I do not use it.

If you know your project is for sure _personal_ (i.e. not shared) and a small _proof-of-concept_ (i.e. if you go further in that direction you will do a rewrite anyway), I think it is overkill. Your code and data will be in so much flux, that good old copying is faster than dealing with the VC.

Thinking about it, I think it makes sense to add VC to a project, when it delivers its first satisfying result, I would call that the proof-of-concept program. At that point you throw it away/archive it, or you have bigger plans, then you probably add version control knowing you have this working prototype and rewriting stuff.

You do not have the history to that point, but it would not be helpful anyway.

You could just have really short or even empty commit descriptions, if that's your worry.

You are confusing old school CVS and SVN version control with the modern, branch oriented workflow that can be achieved with Git or Mercurial.

Easy branching and merging enable exploratory programming in a way that makes you stop worrying about a whole class of regression bugs forever.

Well, you could use the same logic for comments, namespaces, variable and function names, high-level languages.

All of these are created to mitigate human errors. If you think that you don't make them, why bother? Write the whole thing in hand-crafted optimized assembly, from beginning to the end.

And some people have done just that. In fact tons of mainstream 80s programmers wrote whole games and other apps in optimized assembly from beginning to end. And some still do (MenuetOS, TempleOS, etc).

But obviously, that's a slippery slope. You can do anything in between.

The other end of that BS argument line is that you could use the same logic to depend on ALL available tools -- and refuse to write anything without an IDE, package manager, language features like contract programming, formal proofs, etc.

Agreed. Others have pointed out that one can just commit daily and use git as a backup.

This is true, but there is still a psychological difference: We have become slaves of our window managers and development tools. The fewer tools you use, the more true creativity is unleashed.

The best works of humanity have been written before the existence of version control (and computers for that matter).

I see version control as a necessary evil for multi-developer projects.

Well, if you're developing something, and that isn't your development tools themselves, you are still a slave to your development tools. I really don't buy this argument, and I just think that it's a matter of habit and convenience. You can pick and choose development tools freely until you think that you have a satisfying workflow.

I would argue that for me, personally, using version control "unleashes more true creativity" because I can fire and forget my changes and just branch out or roll back until I find something I like, without thinking too much about where and what to backup. The not actually writing code or designing aspects of development then take less time out of my work.

I have to agree. With SCM, I feel more in control, and worry less about my code and files getting lost, and feel like I am free to do anything.

I tell my developers when they're worried about testing something on code, just create a branch and try it, and if it fails, just move on. You shouldn't ever be worried about losing code, or changing things. This is one of the greatest advantages of SCM -- how many variations of a codebase you can have, and how easy that can be.

Sounds like TA is asking for some Fun!

There's an article with an outrageous title (claiming one's getting towards the goal of simulating existence!) and the top comment is about "he doesn't use version control?!".

That's so HN.

Where does it talk about simulating existence? I tried skimming it

What?

The entire article is about this.

It would be hard to find a paragraph where this isn't explicitly mentioned.

You didn't skim very well.

I read the whole thing and I didn't catch that part either.

To be fair, the title is serious exaggeration. Tom Adams has a large task list of implementation ideas, and they're 42% complete. He then says that these represent the "narratively interesting" parts of existence.

If I made a game that had a day and night, sleep and awake, food, drink, sex and death, I could claim that it simulates 100% of the interesting parts of existence. To cast that as actually simulating existence would be silly, though.

Lisa, I want to play your game.

Version control is a really cheap and really useful time machine with notes for all the periods of a program's life that people want to either travel to or just see. It's really useful whether or not you work in a team. It's also so trivial to set up and use now with git and mercurial, that it makes me scratch my head whenever experienced programmers mention that they don't use it.

No, version control is still advantageous if the project has more than, say, 5000 lines (or however many lines you are still able to fully comprehend as a whole).

- If you're using services like github or bitbucket, you have remote backups of your source in case your HDD breaks.

- You have clear documentation of your progress, the changes, what you implemented when.

- You can always revert to a prior point. If you try to implement a risky feature that might break a lot of things, and if it does, you can revert to an old version with 1 command. If you have hourly backups, or folders with regular full backups, you will scramble to find the right version to revert to (I happen to know from experience!)

- If you take a break from the project, you can quickly pick up from where you left off when you read your last commit message.

Trust me, once you started using VC on solo projects, you can't imagine your life without that convenience. It's so easy to set up and just makes your life easier in many ways.

It's about documenting when and where changes are made so that you can find bugs easier, not for backups.

Oh I hope he has good offsite backups at least. I would hate for the world to lose the future of Dwarf Fortress because he loses his code.

Dwarf Fortress is beautiful art. I feel confident the Tarn brothers will be remembered for centuries for this work. I don't know of any other game, software even, being so laboriously created from the heart.

It is certainly a fun experiment but it's also the poster child of wasted potential. If even a few more developers and artists could work on the game with toady still making 100% of the decisions the game would be much more flexible and much more polished and accessible. It is still a wonderful sandbox that can be experience by a select few but I hope one day the code is released to others and the game can truly blossom.

The project's success is due to the ecosystem they've created. Any introductions of designers/developers could spell entire doom for the project. I can appreciate not bringing in new talent as it is an unnecessary gamble.

That sounds appealing, but it would be something else. There are hundreds or perhaps thousands of polished fun games to play. Dwarf Fortress is different. It's raw. The wretched interface and myriad bugs are part of the whole experience. In a lot of ways, it's like punk rock. Yeah, the musicians could keep better time, and be in tune, but then it would be a different kind of music.

The lunacy of one guy writing so much depth and detail has it's own magic that you can't really get anywhere else. Maybe it is indeed a waste. I think i've spent more for that game than any other, save maybe WoW because of all the expansions.

Except that then he'd be a project manager rather than a programmer.

No need. Plenty of 3rd party tools. Take a look at the Lazy Newbs Pack: http://lazynewbpack.com/

It contains utilities to do just about everything you feel is lacking, save some major interface overhauls. I agree, the interface is byzantine, but at the end of the day, it's basically like emacs or vi....

Tools in the Newbs Pack include 3D fort imager, StoneSense, Dwarf task/military/nobles manager Dwarf Therapist, dozens of pixel art packs to turn your d's and c's into little dogs and chickens. There are even tools to directly modify the game: turn off aquifers, turn off invasions, remove races, turn off vampirism, limit the number of children.

The only wasted potential in Dwarf Fortress is people who maybe can't get into it because it's so freakin' complex. Tarn knows the code's a mess. He's not a programmer. He's a mathematician. He writes code that works, and when it does, he moves on. Nothing in Dwarf Fortress was written to be touched by an outsider. It's a truly personal project for the Adams.

Sargos mentioned 3 benefits that they would expect - flexibility, polish and accessibility.

Sure, maybe we have enough flexibility right now, but Dwarf Fortess definitely isn't a paragon of polish or accessibility.

And it never will be. And that's a good thing.

Also, if you don't think DF has polish, you've never played it. The polish is very subtle, but the game is SUPER polished with tons of details you'll miss if you don't go deep.

> No need. Plenty of 3rd party tools. Take a look at the Lazy Newbs Pack ....

A lot of trouble has been put into making tools such as Dwarf Therapist in the Lazy Newb Pack. They're basically made by snooping the memory of the DF process (unless I'm mistaken here). If DF source code was available (even if it would be immutable), a tremendous amount of effort could have been into better use than practically reverse engineering parts of the core game.

In my opinion, Dwarf Fortress could be much better if the source code was open or at least available.

Or there was some formal API or at least some convention for communicating without hacks

He does talk in the interview about why he doesn't do that, and the reasons aren't completely unreasonable (basically he wants to avoid professionalising the dev process)

That sounds unreasonable to me.

To put a different license and dump the source somewhere, you don't need to change your personal process at all.

You absolutely do. Open sourcing code is not just throwing a tarball over the wall. It's comments, it's documentation, it's changelogs that go a lot deeper than "fewer children are spawned." When people are reading the code, they want to make changes. They want to help. Tarn has no interest in changing his job from one of programmer/designer to one of gatekeeper/manager. I can completely understand why he doesn't want to do this. It'd make a lot more work for him, and people would come to him with complaints, demands, questions about it.

No, you don't need to change anything about comments, documentation, changelogs, anything. You can totally just throw a tarball over the wall. No, you don't need to accept contributions. When it's your project, you do whatever you like, regardless of the license. Whether you occassionally upload a binary or a source snapshot.

I'm all for OSS but that would be a privilege, not a right.

They're keeping it close to their hearts, where it belongs. Call me a purist but I'm more than happy with the way it's progressing.

Not really contradicting you here, but DFHack for the last couple of years has worked as a shim between DF and the SDL library. Substantially simplified the process of changing the game's behaviour, and mostly eliminated the need to poke around memory addresses. DFHack is also essentially the third party modding library for everyone else, with only Dwarf Therapist still poking around memory last I heard.

Kind of uninteresting for most players, but hey; this IS hacker news.

There are other ways that people have contributed, though. Take, for example, the project that led to the solid density values being updated for all sorts of materials.

Saguaro wood density only exists online thanks to Dwarf Fortress, for one example.

Adding graphic would completely change the proccess, because new features to add would have different comparative costs than now.

This would result in completely different game in the end, probably a lot more mainstream.

I'm glad he decided not to pursue that path.

I think you're right here. I read the comments of another link to this article where someone was going on about how DF only runs on a single-core and could benefit from a layer of threading.

Apparently even though it's text only there are points in the game where it slows down to a few frames per second.

The modern iteration is based on SDL graphics, not text (though that is available). The game slows down because you end up with 80+ dwarves, cats, forgotten beasts, Mothmen, kobolds, and more, all trying to pathfind to their next thing, and by that time you have dug down 60+ z-levels and there's rivers and fish and some dwarf really wants a sock from his/her dead friend and it all adds up to an awful lot of computation 100 times a second. The graphics of it all is probably one of the easiest parts.

However, this is a 14 year old, very complex codebase. Tarn has said himself that multithreading is highly improbable at this point, it's not something you can just drop in. It would probably absorb an entire release cycle.

The Sistine chapel roof is such wasted potential. If he'd got a team together and sculpted it before painting it, and used a bigger range of paints, it would have been much better.

"See son? That @ sign there represents God and the - is God's finger. The _ is the hand of Mankind, reaching out, and # is of course Mankind."

The Software Engineering Daily [podcast] interview with Adams is a great listen. It's a great narrative about software development as art and passion.

http://softwareengineeringdaily.com/2015/10/22/dwarf-fortres...

Hmm interesting description there. From the OP article and things I've read previously, I'd say Dwarf Fortress is the epitome of focusing on the ends of the software rather than means of software developement.

I'd say you're both correct. It's not the architecture/engineering details of the program that are a work of art, but what it actually does. In other words, the Adams are passionate about developing a particular piece of software, not passionate about software development.

Yeah that's is what I meant. The end result is definitely art.

Poor Zach Adams (Tarn's brother), not getting any mention in the article (or even this comment thread). Even though he doesn't work on programming the game, he still writes the stories that (as far as I can tell) carry the creation of DF forward.

Even more weirdly, the article calls Tarn Adams just "Adams", as if that name is unambiguous when discussing Dwarf Fortress.

Dwarf fortress is one of my favorite examples of emergent behavior- the maneating carp, cat-explosions, cats getting drunk, etc. Actually, a lot of cat based bugs in general.

Survived 18months of goblin siege, the last 6 of which spent without access to water. Survived the Roc that drove the goblins away.

Fortress became unplayable due to catsplosion. I love this game.

Eat the cats? I never saw a problem with catsplosions because I restrict them to pastures so they don't adopt dorfs.

Why did I never think of that... Gotta run into vermin problems if you're not careful though, right?

One free roaming cat or maybe two are enough to deal with vermin.

just remember to have hens around or other vermin eaters

I would swear all the comments starting here are made up.

I promise you they aren't! It really goes that far. Thanks for the laugh :)

I assumed they would still adopt dwarves. Guess I'm wrong. Still gotta lock up all the cats that have adopted one though.

Causes a spiral of despair if you haven't preempted their adopting of dorfs

"Fortress became unplayable due to catsplosion."

Just put all cats in a cage and leave few males wandering around to deal with vermin. The last time I played (few years ago, don't remember the exact version) this worked flawlessly.

The most epic of Dwarf Fortress epic tales

Room Carnage

This is the link for episode 58, but start from 1

https://www.reddit.com/r/dwarffortress/comments/49iiom/roomc...

This is great. Dwarf Fortress is a huge part of the reason I became a programmer.

Maybe that's why I'm a bit disappointed now that I actually am one, but that's life :p.

The thing that really scares me is that he doesn't use version control. I hope and assume that he has SOME kind of backup approach, but the thought of trying to wrangle that many lines of code without proper VCS, in what is clearly an insanely complex codebase, is just beyond me.

Version control is a must when you're working with other people. When you're the only one writing code it's not so important.

That's debatable. Version control have helped me a lot. It also helps me experiment with new code without risking forgetting something because I can always roll back.

I agree that the topic is debatable.

A few years ago I looked for any studies on the usefulness of a version control system over, say, a versioning filesystem. (Examples of such include the VAX filesystem which auto-versioned every save, Dropbox does the same for at least 30 days, and the Mac Time Machine gives access to previous backup snapshots.)

I wondered if for some projects auto-versioning on save or clock event in a VFS would be more useful than manual versioning with a VCS. For an common scenario, co-authors working on a paper might have a shared Dropbox directory. They can modify the images, Word document, etc. safely without risking forgetting something because there's the option to see older versions of the directory.

Those studies have not been done. I know for myself, for the initial stages of a project, I find it more effective to iterate through multiple directories (eg, "foo", "foo2", "foo3") so I can easily compare different approaches, than to create a new repo, name the branches, and check out each one to get the same effect. I also have hourly backups, so I won't loose much in the way of code.

At least for me version control maps better to how I think about my code than individually versioned files at the OS level.

It's very rare that a change will hit only one file, at the least it's likely to imply changes in the test suite as well, and likely there'll be several objects collaborating. Being able to group those changes together and then annotate them with a commit message is hugely useful to me for a couple of reasons. Firstly I can roll that change set back as a single unit, but more usefully I can look at the history of a given file, of even a given line of code, and then map the changes to the wider context that influenced them. I couldn't tell you how many times I've wondered just why a line is doing something, run git blame, and instantly been given an answer by a past version of me who still has all the details fresh in their head.

Oh, certainly. My comments is to highlight that there's no research that helps identify if these personal beliefs are generally true. Perhaps it's only useful for large (>1M LOC) projects, or 40% of programmers. Perhaps it's worse for spike projects with 1-3 people, <1KLOC, and <1 week of development, as compared to auto-backups of a project directory every 10 minutes and/or vim's "go back in time" history tracking.

We don't really know, beyond personal experience, which is why this is very debatable.

I programmed for a long time (middle school to the end of college) on 1 person or 2 person projects without version control. I'd just manually copy the directory when I'd made significant progress, or wanted to experiment with a different approach. Multi-person collaboration happened by working out who would work on what ahead of time and manually merging the bits back together.

It worked great, and even though I now use git for even personal projects, I'm not sure it's on balance useful, along the lines of your thinking.

Because: VC warps your thinking. You change your work habits and spend time crafting this artifact, the VC commit history, which is secondary to your actual goal. For example, there's a tendency to quickly jump between different areas, or make unrelated changes, because that works against the nice 'commit-per-thing' history that looks nice in VC.

So no VC doesn't seem so crazy to me :)

I never said it's not useful, only that in this circumstance it's not important. It may be that he would eventually gain some efficiency by learning and using version control, but the lack of version control has clearly not prevented him from successfully creating a program, and quite a complicated one at that.

Even huge projects involving large numbers of people can be and have been done without version control, if you have a large enough project management staff. You'd be mad to try to do it that way merely because you can, now that version control has gotten so good, but it's still not a necessity. It's not vital.

If you're the sole developer, copying code to some scrapbook or something works just as well. Probably even better, because you can create a simpler or more comprehensible archival system. And search.

I don't follow how it would work better. Right now I don't need to do any kind of setup or thinking. I could rewrite a huge chunk right now as an experiment and change 1000s of lines of code. Then if I don't like it I can just press "reset" and I'm back to stable.

In fact, I did just that yesterday.

Branches and being able to revisit older code are very important, regardless of the number of people working on the code base.

Branches aren't important. If you ever used pre-git, they were a massive PITA that small teams wouldn't bother with.

And being able to visit old code? I can't remember a single instance in my career where that was important. I can imagine scenarios where it might be, but they've never happened in real life. The other thing I realised is that most source control systems are useless if you change a file's name, you can get to the old file, but you simply can't be bothered. So it's actually easy to effectively 'lose' old code through refactors.

Source control is great for looking up the 'why' of what you did 6 months later and for backups.

And for identifying who broke the build :)

On a single developer project? No need for git, it was me.

The stupid guy that wrote this ugly code was me too.

I still use a VCS, if only for synchronizing code between computers, and for actually erasing dead code without regrets.

Oh, yeah, multiple computer synch is the other reason I use too, and auto-builds.

The fact the CVS or SVN were not capable tools to use branches doesn't mean anything about modern use of branches in Git or Hg.

Otherwise we would be judging all programming languages by the use cases and the pitfalls of COBOL.

I met Tarn at GDC, and his answer to not using version control was using a backup of the source code in labeled CDs

So he's using version control, just pretty poor and manual version control. I have a hard time seeing myself preferring to use "labelled CDs" over Merurial with an off-site copy or two -- but just because a system doesn't mostly consist of (automated) software, doesn't mean it's not a system. It's not as if Mercurial/git (in most setups) works without manual intervention (git commit) -- and arguably having automatic snapshots is worse than having manual commits (eg: if I was more diligent making use of etckeeper for my laptop, it'd contain much more useful information than the now mostly "automatic commit before apt-get upgrade". But at least it gives me some automated rollback options when I forget what I was doing with a certain daemon config or tweaking xorg manually).

Anyone know if/when/where the recording of the talk will be uploaded?

I think he is pulling your leg because he believes that the answer to life the universe and everything is 42.

Is there any chance of him going opensource?

It would be nice to be able to get a better ui which clearly he has no interest in coding himself.

This is mentioned in the article. I think his response is totally understandable.

  > People are still doing this kind of stuff with the game being close
  > and making this amazing stuff. Why not put the code open source?

  > It’s basically a kind of paranoia or prudence about what might happen.
  > Because there’s forking that would just be way easier just to have other
  > projects going out there, people selling it and stuff. And people asking
  > for, say they’ve fixed some of the bugs, and they’re like, ‘Here, could
  > you incorporate this patch?’ I become a project manager, and it brings
  > out some of the [reasons] why I’m not in an industry job, right? I have
  > no experience working with other coders.

Why not put the code open source?

It’s basically a kind of paranoia or prudence about what might happen...

Just what Tarn said that becoming manager is not fun is enough. Managing psychofoans, managing people that want some feature, managing pull requests. If you are not Linus telling bad words to people then you might end up like "Flappy bird" creator.

Reply on news.ycombinator.com