[ufmace]

Upvoted for a number of interesting and unconventional opinions.

Rolling your own JSON, XML, etc parsers raises some eyebrows. I guess it's sort of okay if you expect to only be reading your local config files versus arbitrary web content. Maybe then it's okay to trade off raw speed for not handing a ton of formatting and syntax edge cases.

Writing GUI apps against the native framework. Yup, it'll be a major pain to ever port to another platform. But if you don't care to do that, nothing's as fast and clean both to develop and for the end-user to use as every platform's native framework.

Unit tests are sometimes overrated. IMO, they're much more suited to building apps in dynamic languages. Unit tests are a lot less important if you have a good type system and compiler checking things already. I've heard it described before that half of the benefit of unit testing in these languages is forcing yourself to structure code in testable modules with clean interfaces. But if you can just do that anyways, the actual tests are less important.

[jstimpfle]

I think writing a JSON parser should be perfectly fine, it's quite a simple format (while imperfect and probably way overused). I would say 50 lines of header + 500 lines of .cpp file should be plenty to write a solid reusable implementation that parses to a generic tree (dicts, lists, float/string/bool literals). Should be doable in an afternoon.

But if you disagree, you should try a particular, very popular JSON library for C++ (removed the mention of the name here, you can figure it out on your own if you want).

Last I checked, a git clone of this library downloaded 260 Megabytes of data. The project consists of many many files, but most notably it is a C++ header-only library consisting of 24000 lines of header files to be included into every (transitively) dependent .cpp file.

When you run "g++ -E" on it (to do the preprocessing step only) those 24000 lines will unfold to about 84000 lines.

Just write a short test.cpp with #include <THIS JSON LIBRARY.h> in it and add a int main() { printf("Hello, world\n"); }. Compiling this with "g++ -c" takes about 1 sec on my laptop.

Add a tiny amount of code that "parses" the string literal "3" (which I think is not valid JSON actually. But anyway) and compile + link. Takes 2 secs on my laptop. With -O2, I'm at 3.5 seconds.

Imagine writing a larger project with many many .cpp file that include a header file that publishes such a dependency. Or just imagine compiling a project where multiple .cpp files directly include this thing.

It's a truly sad time to be a programmer.

[hoseja]

I don't think full size of the git clone is relevant information. You can always do a shallow clone.

[jstimpfle]

I think your statement that it doesn't matter is kind of making my point.

[arthur2e5]

Regarding the XML thing the author did mention later how complex a compliant parser is, so presumably tests have been… done. The “HTML/” before the XML is what really raised my eyebrows with the stuff, since not many people besides browsers implement the optional tag and tag soup recovery right. (At least it’s standardized in the spec now.)

Alright, looks like the self-brewed parser is explicitly for CHM HTML4 and EPUB XHTML only, with the more serious stuff in muPDF. I could still mess with it by self-packing CHM (HTML4 has optional tags for ergonomics too), but that sounds very boring.