Dr. Hipp occasionally gets on a soapbox and extolls the virtue of sqlite databases for use as an application file format. He also preaches about the superiority of Fossil over Git. His arguments generally make sense. I tolerate his sermons because he is one of the truly great software developers of our time, and a personal hero of mine.
These are thought-experiments to help better understand how SQLite works.
This is exactly how supporting documentation should be written so that others read it.
The problem is that better is not an abstract measure. It is better at what, for what purpose, in what context? I like fossil in the abstract, but it isn’t integrated well into any of my tools; there is only one hosting service I know of; and they took away the wysiwyg option from the build in wiki (a preference of mine). So it isn’t better for me
Your better will be measured against different criteria, etc.
This seems like a rather superficial discussion of a very interesting question. It doesn't discuss factors such as price or custom configurations of MacBooks, for example. Perhaps someone at Ars Technica could give us a better analysis.
The author completely misses the point that the term "systems programming" is an abbreviation for "operating systems programming". His entire argument seems based on this misunderstanding. Time for a re-write.
I seem to recall that "systems programming" was initially penned meant what we now call "application development" [1]. I realize that these days, the two tasks are considered very different, but as far as I understand, that's "just" because we now have access to high-level APIs, the likes of which didn't exist when the name was invented.
In my book, it's "system programming" when you are writing an application and you need to reach to lower-levels than what your language/stdlib/framework typically allows. So the authors of the DeepSeek training mechanism were doing system programming when optimizing communication between cores, but also anybody who sets out to optimize a Python-based app by writing a Rust module, or a Rust developer when they're calling directly into libc, or a C developer when they're writing assembly or performing syscalls, etc. Of course, by this definition, there's no such thing as a "systems programming language", but there are languages that can serve for system programming of other languages.
[1] Which seems to be confirmed by the article, in fact.
> "systems programming" is an abbreviation for "operating systems programming"
I don't think this is right. Systems programming is a broader term that can include embedded systems, compilers, virtual machines, game engines, etc. At least that's my perception based on how it's commonly used.
