Actually, if I had it to do over again I still wouldn't use JSON

When I started with my current employer they asked me to do a "story-board version" of a tool they were pitching to a customer by way of a warm up project. When the customer picked it up they kept me on as the lead designer and coder.¹ This was the first time I'd ever been put in charge of the basic decision making for a shared effort or of something intended as "a product", so unsurprisingly, I made some mistakes. There are facts about the codebase that I am not proud of.² In a couple of cases I cringe inside when I have to explain them to newcomers.

Interchange format

We run a significant amount of computation in separate OS processes.³ Honestly, to an old Unix hand like me that feels completely natural and it's not much harder than threads except for one thing: you can't just hand the worker a binary config object, but have to invoke some kind of interprocess communication. I choose to pass a serialied config object.

Now, a wise developer would have picked an existing serialization library. Obviously. But I didn't understand any of the existing options and saw only obstacles, so I rolled my own.⁴

After all, I had very simple needs, so I had it done in an afternoon. Tests included. Then time passed, requirements changed, and the format grew more elaborate. The code got longer and spawed more templates and more specializations. Writing the tests got harder. We began using it for a save-current-configuration format. I learned how to use the type_traits header badly. Then better. That heloped with the tests, but only a little. Still more requirements loomed and the code became a no-go area for everyone but myself and my best junior dev (now really a mid-career dev).

For several years I've been telling people that if I had it to do over again we'd be using JSON.

Little did I know.

Careful what you wish for

A couple of months ago we found out that a subset of the tool is being used as a component in a multi-step chain by a different division at the customer's organization. Last month we got funding to support that effort. This month they asked us to replace the custom interchange format with JSON.

We picked a library and went to town. Progress is being made, but it's not quite all sunshine and butterflies.

Why JSON is a really bad choice for this application

The thing to understand up-front is that this is an application in physical modeling. We compute an approximation to the behavior of the real world in a highly specialized domain and we do it fast and with a friendly front end. We don't need "just so" fidelity, but it does need to be reality based.

That means numbers. Almost always in floating point representations.

Nearly all modern platforms support IEEE-754 floating point numbers, which I have mentioned before. A feature of that standard is the ability to represent several special cases without demanding extra space. The available special cases go by three names: "infinity", "negative infinity", and "not-a-number" (AKA NaN). The infnities are generated when you do things like divide a finite value by zero or take the logarithm of zero (which you'd expect from real math) but also when you do things "close" to the real ones like dividing a big enough number by a small enough one. NaNs come out of weird operations like dividing zero by zero, or taking the arcsine of two.

Programmers have limited control over the users and what kind of input they generate so these kind of values pop up from time to time, and we have to decide how to deal with them. It's one of the annoyances of the job. Sometimes you want to do one thing with infinities something else with NaNs.

My custom serialization format handles those values gracefully, but JSON does not:⁵ it serializes all of them as null.

Not only is this ambiguous, but readers are allowed to simply fail when they encounter null where they were expecting a number. In particular, the library we'd started using throws an exception in this case. Really. This may or may not be reasonable in some domains but it is clearly on error in scientific computing.

Now what?

The thing is, it's not going to get fixed. You'd have to add new tokens to the grammar which would break many (probably billions) of deploy instances. When one of the selling points of the format has been stability. Total nonstarter.

I'd been planning on deprecating the old interchange format: stop generating it (maybe even remove the generation code) but keep the reading code around for a while. Becuase of the save files, naturally.

Now I'm not sure I want to switch. Maybe I just want to support JSON as an alternative. And support extra code for the foreseeable future. Sigh. Or I can live with not being able to pass well defined specials from component to component. Bigger sigh.

---

¹ Actually, at first (and from time to time since then) I was the only person on the project. But still.

² And some I am proud of. And a couple I'm ambivalent about because they may be necessary, but they are complex and hard for newbs to wrap their heads around. Well, they were hard to figure out in the first place, too. At least I wrote design documents for the features, so I have an answer when they sak "What were you thinking?"

³ A legacy library we rely on for one of the main computationally bound features of the application is single-threaded and not re-entrant; to let our customers take advantage of their beefy, many-cored, analytic workstations we have to get the OS to isolate instances.

⁴ Seems to be a habit, doesn't it? Though, in my defnense the logger has been a success. It has ridden out expanding needs with minimal maintenance and without growing out of hand.

⁵ Interestingly, JSON is a strict subset of JavaScript which does support the specials. To judge from the few things I've seen from the creator, it's likely they were sacrificed on the alter of simplicity. Perhaps a lamb too far, that.

Yeah, why doesn't she?

One of my habits¹ is singing along to whatver music is playing in the car. Today I was belting out The Warning's² When I'm Alone while driving my daughter to gymnastics. She's usually heads-down over her tablet in the car, so I have to make my own entertainment.

As the song wrapped up she asked me what the singer meant by the "hole in [her] soul".

These are the kinds of moments that make parenting a minefield, but also so worth it.

The song is about maintaining outward calm in the face of inner turmoil in a inescapable situation,³ but I don't think⁴ my seven year old really has a reference for that. So I tried to explain that in this case "soul" means how you're really feeling inside and told her somthing like "The whole song is about making the people around you think you're OK, while you're really, really sad on the inside". That seemed to satisfy her at first.

Then, after a few moments of quiet, she asked me "Why doesn't she just tell them?"

Stonkered for the second time in as many minutes. Alas, I suppose that she will understand some day.

---

¹ Good? Bad? Fine when I'm alone but annoying otherwise?

² I'll try to keep the pathetic fan-boying to a minimum here, but if have any interest in rock and don't know this band it's worth a little of your time to check them out. In addition to the song noted above consider Choke, Evolve, Disciple, or Hell you call a Dream as introducers.

³ Written by a homesick fifteen year-old and a better expression of that state of being than I've managed in more than fifty years of being at least a little messed up. Go figure.

⁴ Hard to know with absolute certainty: once you send them to school you don't know everything about what's going on in their life unless someone tells you. I feel pretty confident that either the child or a teacher would have clued us in but there is still room, however small, for doubt.

Header-implementation duality?

While, in principle,¹ C++20 marks the beginning of the end of our long, collective, inclusion nightmare the painful truth is that many C++ developers are going to be dealing with header files for years to come. And I've heard of no plans to bring a modules system to plain C at all.

But at least we have decades of experience from which to derive best practices and better tools to automate or enforce those practices. Right?

Some of the best practices:

1. Every header should have include guards.²
2. Don't #include files unless you need declarations or definitions found therein. Where possible prefer forward declarations or forward declaring headers (like iosfwd).
3. Explicitly include headers to cover everything you need. Do not rely on transitive includes.

None of this is particularly controversial (leaving out the holy war over how to protect files from multiple inclusion), but I find that I have a minor interpretational difference with include-what-you-use (AKA IWYU: one of the leading tools for automating these rules). You see IWYU asks me to include in my implementation file things I already included in my the associated header file. Now, that is a strict interpretation of rule (3), so why does it bother me? Apparently I think of the header and implementation as two parts of a single logical unit rather than two independent things. I mean, those things should be maintained together so the danger of relying on the transitive inclusion is mitigated.

Of course, if I was implementing the tool I'd at the very least start with the current behavior. Simply because it's going to be very hard for the tool to know that this header really and truly does go with that implementation. I mean usual if they have the same stem that's a good clue, and in project where headers and implementations can sit in the same directories that is also helpful. But some layouts separate the interface files, so then what?

---

¹ By now a non-trivial fraction of C++ coders are able to use the 2020 standard, but that doesn't mean that they are able to use modules. Support has been pretty slow even in compilers and build tools maintainers are stuggling with some real problems inherent in the pure flexibility of the module standard in C++.

² Yes, I know, in the Windows world many people strongly advocate for #pragma once instead, and avoiding the possibility of name collisions is a big advantage in my book. But it remains non-standard which is why some major style guides and the core guideline still insist on classic approach.

I think the Stones left that bit out

I had occasion to exchange a moment of shared culture with a cashier over the Rolling Stones' You can't always get what you want, and my daugter wanted to know if we'd learned it at school like she did

So, later, I played her the song. And she wanted to know when they would sing the "you get what you get and don't throw a fit" part.

Irony writ large

This is a rant that's been bugging me for a long time and has just recently boiled over.

My work computer runs Windows. I wouldn't have chosen that, but there are good reasons for it. I'm told. Whatever. I'm a technology pro, and I take my daily dose of copium so I can deal. But there is a fact of life about my working environment that amuses and frustrates me in equal measure: certain applications are just really bad at window placement on returning from sleep mode.

Now, this is actually a hard problem for three reasons. First, I work for a contracting firm so I actually sit at three sites (home, company office, and client facility) and due to hot-desking at the client site maybe seven different desks.¹ Second, I'm a programmer and I prefer to work with multiple monitors. Five of those seats supply an external monitor to pair with my laptop's screen, one of them gives my two externals, and then there is the "sad" seat. Finally, I'm an older programmer and modern displays have lots-n-lots (tm) of itty-bitty-teeny-weeny pixels, so I use auto scaling to make everything easier to read.

The good news is that modern external display buses give the OS enough information that it can "remember" setups and restore all your settings. Yeah! But still, my machine is repeatedly going to sleep with one setup and waking up to find itself connected to another. How operating systems applications should respond to a changing display environment like that is far from trivial, but I feel like things have finally settled out a bit in recent years.

Still not every application is good at this, and my work environment features a few regular offenders.

In third place is that dancing-to-a-different-drummer perennial, Emacs. Particularly Emacs running from a WSL Linux (running from msys it seems to be fine). Every time you wake the computer at a new display location you can expect WSL Emacs windows to migrate to the virtual desktop that was active when you put the machine to sleep. And sometime to unnecessarily switch to the main display as well. Sigh.

Second place goes to Microsoft Teams which seems to jump virtual desktops on an intermittent basis. Often when you've missed an appointment. Maybe? But it also occasional does that when you're just working normally, so it's not clear that it relates to sleeping or to changing display environments at all.

And the biggest irony is Microsoft Edge. Which just can't seem to recall where it was or how big it was. More or less ever. At all. I mean, I re-size and reposition this POS a dozen times a day. What the #&|!, Microsoft?!? Honestly, if a major Microsoft product team can't figure out Microsoft's own interfaces for this stuff why would you expect anyone to get it right? And what does it say that many other application do a pretty good job none-the-less?

---

¹ At least it's just one physical computer, which limits the issue of file synchronization to the usual domains of software repositories and shared drives.

Deepseek-R1 and a few more thoughts on LLMs

Not so long ago Deepseek-R1 dropped to much wittering and gnashing of teeth.

Im my desultory way, I eventually got around to downloading several of the medium scale models to run locally. The 70B parameter model achieves a token or two a second on my framework laptop which is good enough for testing even if I wouldn't try to use it in a productive work flow. My comments here are based mostly on local interactions with that model, though I have poked at it's slightly small cousins. I haven't interacted with the 600B+ parameter variant at all.

My methodology (if you can will accept such a formal sounding word) continues to be pretty ad hoc: I repeatedly fire up the model in ollama, present the model with a single prompt or a short series of related prompts, read the answers then shut down the model before going onto the next prompt(set). As before my prompts are mostly intended to probe the edges of what I expect these models to do well on by choosing subject where I expect one of the following to apply:

• The topic is sparesly represented on the internet.
• The topic is a combination of two or more well covered ideas, but the combination is sparsely represented.
• The topic is a highly specific example taken from a very broad field.

I have added another movie related query that I expect models to do well on. I ask them to explain how the rooftop confrontation in Blade Runner makes Roy Batty a sympathetic and human figure; this is ground that many a fawning essay has covered in detail, and large enough models often write very well on the subject.

But the idea is mostly to stress the generation process by one way or anther.

Something I'd noticed even before I began playing with deepseek, but hadn't mentioned yet is that these models seem to be very bad at keeping track or what was in specific sources (say a single paper I asked about) and what they only found in the halo of secondary-source words written about the thing I asked after. This shows up consistently in how they handle the questions about physics paper with most models drawing in material that was probably written to explain the essays to less technical audiences and attributing it to the paper itself.

Thoughts on Deepseek-R1

At least in the models I've been working with it's good (even for the size), but it's not great. It's really, pointedly not great.

It has a reasoning model, which gets it partly over a hurdle I saw in my earlier post. It was able to actually do something with the weight and volume limits I suggested for my day-hike survival kit. It can math. Yeah!

Mind you, the inputs it was using for the math were still values it picked out of it's training set without any obvious understanding of the context. Like several other models, it keeps insisting that the first-aid kit I should carry will be just a few ounces, which isn't a bad number for something to put in your purse or satchel, but the one I actually pack for a hike is the best part of a pound because it is meant to cover a wider and more serious set of problems.

It's writing style is clunky and repetitive, and it takes great pains to show off the presence of that reasoning model, often sounding like a under-prepared student trying desperately to stretch a cursory understanding into an assigned page target.¹ This stands in contrast to the slow but notable progress I've been seeing as new models come out from the established players. Lamma3.3, for instance, produces much more fluent and readable text for a lot of prompts.

Is the alarmed response justified

Well, OpenAI's annoyance is mostly amusing. To the extent that it is not amusing it's a warning that [ spunky up-n-comers | tendrils of evil, acquisitive foreign powers ] don't always play be the rules that [ their staid elders | the defenders truth freedom and unrestrained capitalism ] proclaim.²

Leaving that aside, the claimed cost and speed of this work is impressive and should probably worry the big players. I mean they still have a better product, but the price-performance situation means that the new guy probably looks really attractive for a lot of applications.

---

¹ Particularly annoying with the slow production speed. I keep wanting to shout "You said that already, think of something new or give it a rest!".

² As a minor irony, I'll note that the young United States was criticized by various European powers for failing to respect even the weak international intellectual property regime then extant. This is a thing with historical precedents even if we don't like it.

Little Surprises #9: too helpful edition

In Qt5, this #include <QString> #include <algorithm> #include <vector> int main() { std::vector<int> v{0, 1, 1, 2, 3, 5, 8}; QString qs("target"); // Search the vector for the string std::find(v.begin(), v.end(), qs); } will build (compile and link). There are very few circumstances where you mean what it will actually do (in this case it's a very expensive no-op), but it is valid code.

This works because of a chain of "helpful" features:

• You can construct a QChar from an int: QChar(int rc) noexcept
.
• There is a equality test between QChar and QString: bool operator==(QChar lhs, const QString &rhs) noexcept
.
• The find template uses operator== between the contents of the vector and the target.

Each of the behaviors is desireable in isolation, so we don't want to remove any of these options entirely. What causes the surprise is the implicit nature of the type conversion.¹ Core guidelines C46 and C164 discuss the uses of explicit annotation to prevent this kind of thing.

BTW: the above code will not compile in QT6 which is a small but significant improvement.

---

¹ Shout out to all the strong typing fans out there.

When I grow up I want to be...

... organized, detail-oriented, and thorough.

I imagine that will be happening ::checks watch:: any day now. Right? Right?!?

Dates are important

If you're putting a technical article on the web please, please make sure it has an easy to find date of production assocaiated with it. Seriously, technical stuff changes and sometimes changes fast. I need to know if your advice is a few years old because that might be enough to make it comprehensively wrong.

That is all.