On Thursday, February 22, 2018 07:24:30 aberba via Digitalmars-d wrote: > On Tuesday, 20 February 2018 at 21:53:59 UTC, Jonathan M Davis > > wrote: > > On Tuesday, February 20, 2018 15:08:04 aberba via Digitalmars-d > > > > wrote: > >> [...] > > > > Well, ideally, std.json would be replaced with something > > better, but it does work, and there's always going to be stuff > > outside of the standard library. Pretty much no matter what > > you're doing, at some point, you're either going to have to use > > a third party library for something that you need or write it > > yourself (usually, some combination of both). And there are > > plenty of standard libraries that don't have any kind of JSON > > support. > > > > [...] > > Out of curiosity, do you work on serverside related stuff at work > or something. I noticed you were using Java.
I did use Java in previous jobs, but I don't curently use it. In recent years, I've done far more with C++ and D, and my current job mostly involves D. And I would almost certainly turn down a job that involved much in the way of Java unless I were desperate. It's just too primitive to be a pleasant language to program in. Most of the code that I've done in my career has been server side, assuming that there is any client or server involved at all. In particular, I have done _very_ little with browser-based technologies like javascript. The closest that I've really done to something that would be client-side would be a client that viewed video that it pulled from an NVR over the LAN in a video security system, and that was a desktop application written in C++. In any project that involved a browser, I've always been working on the server side of things. > Why you developed dxml XML makes a lot of sense for several projects that I have. I wanted to have a good XML parser for those projects, and it was clear that that wasn't going to materialize on its own. For instance, one project that I have that I'd like to get back to is creating wrappers for Qt5 so that it can be used from D. That would be far too error-prone and time-consuming to do by hand, so it involves code generation, and my solution for that was to create description files for the Qt headers so that the necessary C/C++ and D code could be generated from them. Any improvements to the code would therefore involve improving the code generation rather than having to edit a ton of code by hand (Daniel Murphy also suggested that I parse the C++ code like he did when porting dmd from C++ to D, so I'll probably automate the generation of the description files later, but I wouldn't want parsing C++ code to be part of building the library, and at least some manual tweaks of the description files may be required). I had originally thought to do those description files in JSON, but they would have been incredibly verbose and ugly that way in comparison to what I could do in XML, because XML is far more free-form, whereas everything in JSON pretty much has to be a value, an array, or an associative array. Initially, I'd used std_experimental_xml, and it worked, but I had to work around bugs in it and make changes to my local copy that never made it into the upstream repo, because it wasn't maintained. So, there was no way that I could release anything that way, and I needed an XML parser that was actually maintained and worked without local fixes. And for better or worse, that meant writing my own XML parser, which also delays any projects requiring an XML parser, but sometimes, you have to spend time on one project in order to have the tools you need to complete another. Heck, even the Qt5 wrappers are in that boat. I'm doing them, because there are a couple of applications that I'd like to write that need Qt, not just because I like the idea of being able to use Qt from D. Also, while I would have preferred to spend my time on projects other than an XML parser, I do actually like writing parsers. - Jonathan M Davis
