Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linus Torvalds: “I'm happily hacking on a new save format using ‘libgit2’”

plus.google.com

Post reply on HN
Print view View original

121–130 of 265 posts

Re: Linus Torvalds: “I'm happily hacking on a new save format using ‘libgit2’”

#121

Post by icebraining »

bananas wrote: post #115
sanderjd wrote: post #100

Earlier quoted context omitted.

What is that massive semantic difference? If you want the number represented by 1e999 as the value for salary, at some point, something has to take "1e999", whether you call it a string or a something-with-no-type, and turn it into a number. Your deserializer has to know to do that in either case.

As follows. It's more how the abstraction works. XML: ->[byte stream]->[deserializer]->[bignum] JSON: ->[byte stream]->[json reader]->[string]->[deserializer]->[bignum] The latter is, well, wrong.

Multiple JSON deserializers have that mapping integrating, eliminating those steps. See, for example, the ContextualDeserializer in Jackson.

Re: Linus Torvalds: “I'm happily hacking on a new save format using ‘libgit2’”

#122

Post by mattgreenrocks »

mrcharles wrote: post #94

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. 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…

Preach it. My favorite persistence code: stuff that has nothing to do with SQL/NoSQL.

I leaned heavily on Python's pickle module for serializing a few thousand entities to disk a few years ago. By streaming them to the application at startup time, it remained plenty fast for all datasets it'd encounter. I intended to replace it with SQLite one day, but I never had to. I could just keep them all in memory.

I'd probably choose something a bit safer now, but it was hard to beat the simplicity.

Re: Linus Torvalds: “I'm happily hacking on a new save format using ‘libgit2’”

#123

Post by shawnz »

andor wrote: post #72
halflings wrote: post #53

Earlier quoted context omitted.

JSON's semantics is that you represent numbers by their decimal representation. In this particular case, you're giving a different representation, so of course you an pass it as a string.

His point was that this number is too large to store it in a Javascript Number variable (which is a IEEE 754 double).

OK, so the provided number format is not sufficient for the kind of numbers he is trying to deal with. So instead you would represent it as a string and handle the encoding/decoding of that number yourself. How is that different from the XML way where there is no provided number format to begin with, and everything is a string?

Re: Linus Torvalds: “I'm happily hacking on a new save format using ‘libgit2’”

#124

Post by bct »

eponeponepon wrote: post #50
oneeyedpigeon wrote: post #4

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 re…

Document markup is the one place XML is a no-brainer - more specifically, long-form, highly structured documents (i.e., essentially books). Without it, publishing would be stuck in a morass of nebulous, ill-documented proprietary messes, and a great deal of current learning would be at risk of being lost to posterity. The fact that there are associated open standards such as XSLT with which to transform it is just th…

Yeah, we're still well in the backlash phase of XML's hype cycle.

I just hope that opinion of it as a markup language can be rehabilitated before someone reinvents it and kicks off a new hype cycle.

Re: Linus Torvalds: “I'm happily hacking on a new save format using ‘libgit2’”

#125

Post by draegtun »

k__ wrote: post #89
rbehrends wrote: post #43

Earlier quoted context omitted.

XML is unnecessarily verbose, for the supposed sake of human readability. But used as a serialization format, it isn't really readable or editable by humans (except in the sense that a Turing machine is programmable): remember that the ML in XML stands for "markup language", and SGML, its predecessor, was designed as a way of marking up normal text, not littering data with angular brackets and identifiers. (XML/SGML…

> the problem is that XML has prevented the adoption of something better What would be better?

I think S-expressions would have been better.

Alternatively Carl Sassenrath was pushing Rebol in the past. See his blog post "Was XML Flawed from the Start?" - http://www.rebol.com/article/0108.html

Update: Just posted the above blog link to HN: https://news.ycombinator.com/item?id=7361260

Re: Linus Torvalds: “I'm happily hacking on a new save format using ‘libgit2’”

#126

Post by TheEzEzz »

mrcharles wrote: post #94

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. 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…

I did this with C# in my last game. All the map/object editors output C# code on save, which was then included in the compiled code on the next build. The beauty is that your "data" files get automatically updated when you refactor your regular code! On top of that loading is faster, because you don't need to worry about fetching a file and parsing it, the whole thing is just compiled code embedded in your executable.

Re: Linus Torvalds: “I'm happily hacking on a new save format using ‘libgit2’”

#127

Post by vidarh »

saurik wrote: post #102
lmm wrote: post #24

Earlier quoted context omitted.

If used sensibly XML isn't too bad. But there's a whole lot of cruft in the standard that seems to do nothing except make it harder to use. Part of this is a problem with popular libraries rather than inherent to the format, but we judge a thing by its ecosystem rather than in isolation. So: namespaces are a pain, making it much harder than it should be to just make my xpath work. DTDs are annoying, especially when a…

> So: namespaces are a pain, making it much harder than it should be to just make my xpath work. Namespaces exist to solve a real-world problem that happens in real-world use cases (SVG embedded in HTML, HTML embedded in RSS). While it would be nice to look at things that are complex and say "it would be less complex for these trivial cases without this feature", in reality there are then common use cases that become…

The biggest caveat with namespaces is that most people have never bothered figuring out how they work. The number of applications I've seen that have hardcoded namespace names instead of looking up the namespace uri for example, is horrifying.

Re: Linus Torvalds: “I'm happily hacking on a new save format using ‘libgit2’”

#128

Post by jethro_tell »

Touche wrote: post #111
mrcharles wrote: post #94

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. 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…

That's how people are going to cheat at your game.

Plot twist, It's actually a 'teach yourself lua game'

Re: Linus Torvalds: “I'm happily hacking on a new save format using ‘libgit2’”

#129

Post by 3pt14159 »

mattgreenrocks wrote: post #122
mrcharles wrote: post #94

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. 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…

Preach it. My favorite persistence code: stuff that has nothing to do with SQL/NoSQL. I leaned heavily on Python's pickle module for serializing a few thousand entities to disk a few years ago. By streaming them to the application at startup time, it remained plenty fast for all datasets it'd encounter. I intended to replace it with SQLite one day, but I never had to. I could just keep them all in memory. I'd probabl…

I used to do that, but pickle bit me once. I think it changes between versioning or something. I had to start the statistical model from scratch.

Re: Linus Torvalds: “I'm happily hacking on a new save format using ‘libgit2’”

#130

Post by pierrebai »

bananas wrote: post #32
Sharlin wrote: post #16

Earlier quoted context omitted.

The issue is probably that 99.999% of all XML use cases don't use (or need) the verification aspect. For all of those, XML is overkill. Besides, surely it would be possible to design a verification layer on top of JSON, for instance - the fact that one does not currently exist does not mean that XML (and abuse of XML!) should not be criticized.

One of the core aspects of XML that is really important is that no typing is inferred by the structure of the file unlike JSON. JSON is by nature tied to the JavaScript type system which is sparse and inaccurate. For example, if you look at the following: { "name": "bob", "salary": 1e999 } Ah crap! Deserializer blew (in most cases silently converting the number to null) bob 1e999 No problem. The consumer can throw th…

Either to author of the serialized data realized that the numbers could overflow a float or didn't. This is independent of serialization format.

In your contrived example, somehow, the user of JSON didn't realize the salary could overflow a float. (OTOH, he succeeded in serializing it, mysteriously.) All the while, the XML user was magically forward thinking and deserialized the value into a big decimal. Your argument simply hinges on making one programmer smarter than the other. If one knows that a value will not fit a float, the memory representation won't be a float and the serialization format won't use a float representation. It has nothing to do with JSON vs XML.

Post reply on HN