This is from 2019, prior to the finalization of modules in the standard. I'd be interested in how many of these issues were unaddressed in the final version shipped.
There isn't much of a final version shipped. It's pretty well understood that modules are underspecified and their implementation across MSVC, clang, and GCC is mostly just ad-hoc based on an informal understanding among the people involved in their implementation. Even ignoring the usual complexity and ambiguity of the C++ standard, modules are on a whole different level in terms of lacking a suitable formal specification that could be used to come close to independently implementing the feature.
And this is ignoring the fact that none of GCC, clang, or MSVC have a remotely good implementation of modules that would be worth using for anything outside of a hobby project.
I agree with the other commenter who said modules are a failure of a feature, the only question left is whether the standards committee will learn from this mistake and refrain from ever standardizing a feature without a solid proof of concept and tangible use cases.
You learned nothing because the extent of your knowledge tends to be rather superficial when it comes to C++.
Office does not use C++ modules, what Office did was make use of a non-standard MSVC feature [1] which reinterprets #include preprocessor directives as header units. Absolutely no changes to source code is needed to make use of this compiler feature.
This is not the same as using C++20 modules which would require an absolutely astronomical amount of effort to do.
In the future, read more than just the headline of a blog post if you wish to actually understand a topic well enough to converse in it.
Are you sure?
I've been confidently wrong about stuff before. Embarrassing, but it happens..
And I've been working with many people who are sometimes wrong about stuff too.
With LLMs you call that "hallucinating" and with people we just call it "lapse in memory", "error in judgment", or "being distracted", or plain "a mistake".
Yeah, for the most part. But I've even had a few instance in which someone was very sure about something and still wrong. Usually not about APIs but rather about stuff that is more work to verify or not quite as timeless.
Cache optimization issue or suitability of certain algorithms for some problems even.
The world is changing a lot and sometimes people don't notice and stick to stuff that was state-of-the-art a decade ago.
But I think the point of the article is that you should have measure in place which make hallucinations not matter because it will be noticed in CI and tests.
For the most part, yes. Because people usually read docs and test it on their own.
But I remember a few people long ago telling me confidently how to do this or that in e.g. "git" only to find out during testing that it didn't quite work like that.
Or telling me about how some subsystem could be tested. When it didn't work like that at all.
Because they operated from memory instead of checking. Or confused one tool/system for another.
LLMs can and should verify their assumptions too. The blog article is about that. That should keep most hallucinations and mistakes people make from doing any real harm.
If you let an LLM do that it won't be much of a problem either.
I usually link an LLM to an online source for an API I want to use or tell it just look it up so it is less likely to make such mistakes. It helps.
I do agree. I still think that the article articulates a very interesting thought... the better the input for a problem, the better the output. This applies both to LLMs but also for colleagues.
I remember how computer enthusiasts had hard time explaining to “regular” people what personal computers were good for. They would often mention things like cooking recipes and balancing checkbooks which really was not convincing at all…
> The first TRS-80 ad was similarly scattershot, promising to be everything to everyone: “[p]rogram it to handle your personal finances, small business accounting, teaching functions, kitchen computations, innumerable games
Innumerable games sounds very compelling (though the Apple II was more solidly in the video game system business with support for color graphics and game controllers; but Apple's Mac later yielded many nice black-and-white games, aided by the Mac's sharp, though tiny, display.)
Nice article though showing a spreadsheet (two versions of VisiCalc), two word processors (Electric Pencil and WordStar - of George R.R. Martin fame), and not just games (MicroChess) but a rather interesting, if primitive, abstract animation program (Electric Paintbrush).
Digital art/creativity is I think an underappreciated application area for computers, though programs like {Mac,MS,Deluxe}Paint etc. and Photoshop were milestones, and demoscene software formed its own art practice and culture. Processing is perhaps a modern heir to Electric Paintbrush.
Ugh. I know all that and I am still sick of hearing about memory safety. My teammates spend way more time fixing security issues in “safe” languages than C/C++/whatever. It simply doesn’t matter…
It's hard to compare the two. A low-level memory safety issue can intersect with security. So can a flaw in logic that touches on security, but is reproducible and not undefined in any way.
The latter can often be more easily exploited than the former, but the former can remain undetected longer, affect more components and installations, and be harder to reproduce in order to identify and resolve.
As an exmaple of "more easily exploited". Say that you have a web application that generates session cookies that are easy to forge, leading to session hijack. Not much skill is needed to do that, compared to exploiting a memory safety problem (particuarly if the platform has some layers defenses against it: scrambled address space, non-executable stacks, and whatnot).
Perhaps he's talking about risk compensation (https://en.wikipedia.org/wiki/Risk_compensation) --- e.g. maybe safe languages structurally excluding memory corruption and concurrency problems tempts developers to let their guard down with respect to correctness generally and produce security vulnerabilities that wouldn't occur in a language with C's need for rigor.
Doubtlessly, there is some of that going on. I doubt the risk compensation erases the benefit of memory safety, but let's not kid ourselves.
Joy is probably an improvement on slog, but one person's joy is another's hell. I've inherited a lot of joyful projects that were an awful fit for continued maintenance because joyful meant using new, unproven, and unstable technologies.
I have experienced many identical situations. Some people just love to tinker and over-engineer for the sake of stretching a muscle. It's unfortunate when that sneaks into a prod system that has to be maintained by others.
I've never met Raymond but based on his posts, I have a fantasy that Microsoft would make him "Benevolent Dictator For Life" of Windows desktop OS. At this point, it's the only thing that might save Windows 11 as a daily desktop operating system for power users.
I recently learned of him because of a service that he seems to be affiliated with. This is a service that seems to search for webinars or meetings and surreptitiously records them. It is an interesting concept, but it has definitely baffled some Zoom users. This is a Reddit thread I saw where it seems to be him who is responding to some of the comments: https://old.reddit.com/r/Zoom/comments/1lpvv06/webinartv_ste...
reply