21–30 of 265 posts
why do you need to view filesystem and make it readable for humans, you would interact it via commands "ls" or some gui git as the basis of filesystem is interesting, hope we don't need to manually make branches and commits to use it
I think this title is wrong. 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. 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. You now end up with the following problems: locking, synchronising filesyste…
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.
People seem to prefer JSON, but I don't find it any better to hand-write/hand-edit than XML. If anything it's slightly worse, because it has more syntax edge cases.
Edit: clarification as HN won't let me reply any more.
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. 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? Doing hierarchical data in SQL is a bitch and if you wan…
Is XML schema really so much better than e.g. JSON schema?
To me it feels like there's an impedance mismatch between the kind of structures XML lends itself to and the kind of structures programs are good at dealing with. So for program-to-program communications with a certain level of validation I find Protocol Buffers is a much better fit. Conversely in cases where human readability is really important, XML isn't good enough compared to JSON.
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.
People seem to prefer JSON, but I don't find it any better to hand-write/hand-edit than XML. If anything it's slightly worse, because it has more syntax edge cases.
It's just meant to be human readable.
If you want human editable "json", use Yaml: http://www.yaml.org/ (it's a superset of Json that adds comments, linking etc.)
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".
Earlier quoted context omitted.
People seem to prefer JSON, but I don't find it any better to hand-write/hand-edit than XML. If anything it's slightly worse, because it has more syntax edge cases.
JSON is explicitly not designed to be hand-editable. Hence, for example, no comments. It's just meant to be human readable. If you want human editable "json", use Yaml: http://www.yaml.org/ (it's a superset of Json that adds comments, linking etc.)
Earlier quoted context omitted.
People seem to prefer JSON, but I don't find it any better to hand-write/hand-edit than XML. If anything it's slightly worse, because it has more syntax edge cases.
And it doesn't support the multitude of accurate numeric types that XML does implicitly. XML data is not just "strings", it's a sequence of characters. The deserializer determines what sort of type it is based on either the structure or the language's capabilities. With XML, you can define these policies. With JSON you're stuck with JavaScript being the semantic standard and type definitions which ties you to floats…
This I like. The race away from the waterfall straw man has also stripped us of the advantages of BDUF.
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.
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 ;)
Earlier quoted context omitted.
JSON is explicitly not designed to be hand-editable. Hence, for example, no comments. It's just meant to be human readable. If you want human editable "json", use Yaml: http://www.yaml.org/ (it's a superset of Json that adds comments, linking etc.)
How is YAML a superset of JSON? Do you mean 'conceptually'?