On the game I'm currently working on, it's built very heavily around Lua. So for the save system, we simply fill a large Lua table, and then write that to disk, as Lua code. The 'save' file then simply becomes a Lua file that can be read directly into Lua.<p>This is absolutely amazing for debugging purposes. Also you never have to worry about corrupt save files or anything of it's ilk. Development is easier, diagnosing problems is easier, and using a programmatic data structure on the backend means that you can pretty much keep things clean and forward compatible with ease.<p>(Oh, also being able to debug by altering the save file in any way you want is a godsend).
What's with all the XML hate? Of course, doing everything in XML is a stupid idea (e.g. XSLT and Ant) and thanks heaven that hype is over.<p>But if I want something that is able to express data structures customized by myself, usually with hierarchical data that can be verified for validity and syntax (XML Schemas or old-school DTD), what other options are there?<p>Doing hierarchical data in SQL is a bitch and if you want to transfer it, well good luck with a SQL dump. JSON and other lightweight markup languages fail the verification requirement.
I think this title is wrong.<p>Firstly some clarification - this appears to just be about the persistence format for his dive log. It was XML, now it's git based with plain text.<p>As someone who had to manage a system which worked with plain text files structured in a filesystem for a number of years in the 1990s, this is done to death already.<p>You now end up with the following problems: locking, synchronising filesystem state with the program, inode usage, file handles to manage galore and concurrency. All sorts.<p>Basically this is a "look I've discovered maildir and stuffed it in a git repo".<p>Not saying there is a better solution but this isn't a magic bullet. It's just a different set of pain.
Back in the bad old DOS days, instead of creating a file format for saving/loading the configuration of the text editor, I simply wrote out the image in memory of the executable to the executable file. (The configuration was written to static global variables.)<p>Running the new executable then loaded the new configuration. This worked like a champ, up until the Age of Antivirus Software, which always had much grief over writing to executable files.<p>It's a trick I learned from the original Fortran version of ADVENT.
What I like is the "I dont start prototyping till I have a good mental picture"<p>I am currently stuck on a project I want to start becasue I cannot get it to fit right in my (future) head. And I am glad I am not an idiot for not being able to knock out my next great project in between lattes.<p>(Ok, in direct comparison terms I am an idiot, but at least its not compounded)
I don't quite get Linus' problem with XML for document markup (for anything else - config files, build scripts - sure, XML is horrible). Does anyone know any more details about what his specific gripe is? For me, asciidoc (which looks very similar, conceptually, to markdown) suffers from one huge problem: it's incomplete. Substituting symbols for words results in a more limited vocabulary, if that vocabulary is to remain at all memorable.<p>Sure, XML <i>can</i> be nasty, but thats very much a function of the care taken to a) format the file sensibly b) use appropriate structure (i.e. be as specific as necessary, and no more).
<a href="https://github.com/torvalds/subsurface" rel="nofollow">https://github.com/torvalds/subsurface</a><p>I didn't really know what he was talking about but I think this is it.<p>The title does need changing though as it is definitely file formats under discussion not file systems.
What is it with HN commenters and their demented ability to send topics completely of track? I would have thought someone might have examined the code or what Linus is trying to implement and comment about it.<p>But here we have threads about Lua, why people hate XML and love JSON and all kinds if irrelevant issues which have been well hashed elsewhere ad nauseam. Why not restrict to an analysis of whatever it is Linus developing?<p>HN is getting truly annoying and sucky, if it isn't so already.
> "I actually want to have a good mental picture of what I'm doing before I start prototyping. And while I had a high-level notion of what I wanted, I didn't have enough of a idea of the details to really start coding."<p>This I like. The race away from the waterfall straw man has also stripped us of the advantages of BDUF.<p>While rigid phase-driven project management helps nobody, I think there's still room for speccing as much as we can upfront within iterative processes.<p>Or you could run to the IDE and start ramming design pattern boilerplate down its throat the second you're out of the first meeting ;)
I don't really understand what he's talking about here (my ignorance, not his fault.) Is it something like <a href="https://camlistore.org/" rel="nofollow">https://camlistore.org/</a> that is a content addressable (the git part) datastore?
>>So I've been thinking about this for basically months, but the way I work, I actually want to have a good mental picture of what I'm doing before I start prototyping. And while I had a high-level notion of what I wanted, I didn't have enough of a idea of the details to really start coding.<p>This might be a tangential discussion. Earlier, I used to have a similar approach. Can't code until I have the complete picture. But, it's tough to do in a commercial world and you have deliverables. So, nowadays, I start with what I know and scramble my way until I get a better picture. There are times when that approach works. But, there have been days where I was like - "wish I had spent some more time thinking about this".<p>I am curious how folks on HN handle this "coding block".
This is what Linus does. He has strong opinions and he throws them around. You can't let that get to you. Both XML and JSON are just fine if used properly.
And the actual description is here: <a href="http://lists.hohndel.org/pipermail/subsurface/2014-March/010592.html" rel="nofollow">http://lists.hohndel.org/pipermail/subsurface/2014-March/010...</a>
Why reinvent on-disk data formats when you can just make a file of protocol buffers? <a href="https://code.google.com/p/protobuf/" rel="nofollow">https://code.google.com/p/protobuf/</a>
Current title that I see "Linus Torvalds on implementation of human-readable file system" is off. It's about file formats, not file systems.
why do you need to view filesystem and make it readable for humans, you would interact it via commands "ls" or some gui<p>git as the basis of filesystem is interesting, hope we don't need to manually make branches and commits to use it
Worked on a project a few years ago where we needed distributed sync capability. Using git (or bazaar or mercurial) was one of the options - store everything in it versus a database. Interesting to see the same thought "coming back".
Why not sqlite or sexpressions? Linus states that databases can't hold previous state but that's not really true...<p>I'm not sure why git is the best tool for the job in this case, even after reading the post & some of the contents.
erik-naggum's most excellent xml rant: <a href="http://www.schnada.de/grapt/eriknaggum-xmlrant.html" rel="nofollow">http://www.schnada.de/grapt/eriknaggum-xmlrant.html</a>