I've sometimes wondered what their plan for this is wrt. people. Richard Hipp is 64, and I don't think he plans to continue working on SQLite until he's 90. I know two other people work on SQLite, but AFAIK he owns the company(?)
That said, I think the future of SQLite is basically guaranteed on account of being open source (as much as anything in this world can be guaranteed anyway). Look at Rust: it's done fine since Mozilla stopped sponsoring it. Go will be fine when/if Google stops sponsoring it. etc.
> the future of SQLite is basically guaranteed on account of being open source
I am not concerned with whether it has a future. But I do fear that the absolute manic focus on code quality, testing and support may take a dive when other programmers take the helm. I am not claiming that there are no developers who are equally careful and/or skilled, but whether the culture of SQLite will persist is, to me, still an open question.
> I've sometimes wondered what their plan for this is wrt.
I'm also curious about this for other projects such as Shakti/k9 [1]. Apologies if not referred to correctly as I'm not familiar with these tools, so consider this a question as much as a comment:
A seemingly obscure implementation of a complex tool with a relatively high learning curve and just three maintainers that is supposedly a key component in a number of domains using high-frequency timeseries data (finance, etc.)?
What's the cost/complexity ratio in incorporating technology like this into your system? Or is it much less than the impression I get as someone that's jsut a curious passer-by?
"Hipp, Wyrick & Company, Inc., or "Hwaci" for short, is a small North Carolina company providing knowledge services to clients around the world since 1992. Hwaci is an S-Corporation owned by the husband and wife team of Richard Hipp and Ginger Wyrick."
Companies are a standard mechanism to provide continuity past the lifetime of a single person. A corporation, if it truly adheres to the laws and bylaws, has enough formalisms to ensure such an organization and its products continue to be supported past a lifetime.
There is a FOMO especially around younger developers who wants to use latest, newest and upgrade all frameworks the moment they pop out on Microsoft website.
Older developers (like me) have opposite problem and I have been fighting for months to not upgrade .NET4.8 to .NET8 due to compatibility with our current deployment chains etc. In the end I had to admit that using .NET8 for everything is going to work too and is going to give us access to better tools and new tech either through some teething problems.
There is no such community push but like anywhere else, you'll see folks get excited about new toys and then try to force them in to try them. It's not any worse for C# than anything else.
> Like engineers in that community look down on not using the latest features?
Yes. Engineers use the latest features heavily to demonstrate that their skills are current.
One of the worst such features is "var". Some tools even flag your code for not using var when you could. Inappropriate use of "var" makes code harder to read (and even MS documentation says this) and makes code slightly less reliable too.
You are right, SomeMethod().Fire() has the problem too. But typically you write
Employee e = SomeMethod();
e.Fire();
This does NOT have the same problem as var. When you use var you reduce the opportunities for the compiler to catch your bug. So the best practice is to explicitly state the type when possible. It makes the code more readable too.
Microsoft recommendation is reasonable. I don't think var should be used as much Rider recommends. But var is perfectly fine in itself. The problem you illustrated occurs independently from var. You assert that one "typically" writes code a certain way but I've seen plenty of both. Further, sometimes you need var. Sometimes the target type can't be spelled like with anonymous types.
Sorry for being unclear. Var is perfectly fine in many cases. Sometimes there are better tools. Screwdrivers are fine tools but they are not appropriate for driving nails.
from your sibling comment:
> "var" also makes your code less reliable as seen in this example
I disagree with this too, I think your example is a classic case of preprocessor directives making it difficult to know what your code is doing because the build system is going to conditionally change your code. Var or not, you can't even know what's being compiled just by looking at the file, and that's a larger problem than the use of var
Use of preprocessor in the example is incidental. The problem with var is that you're not completely stating your intent, leaving it to the compiler to infer your intent. This can lead to trouble in some cases.
I have seen code that sorts numbers as strings, because nowhere in the code was the intent stated that the array is supposed to hold numbers. As a result, if the programmer forgot to convert strings to integers at input time, the bug is never caught.
Funny. I don’t need to work hard for that at all. It comes naturally to me. It obviously has its pros and cons, but to me, a shiny new tech has to prove itself first in order to deserve my attention.
There are, occasionally, the “wow, I got to have that” moments and those are great, but rare.
I stopped using C# 10+ years ago, but I remember wanting to update the framework and use the latest thing (linq to objects) because it made code a lot more concise.
I can see someone defending Ruby as concise (having the ability to chain different transformations) and simple to write in (low verbosity). Lisp? Define a class and do some map/filter/reduce. Lisp is verbose. Sometimes even worse than Java21 these days.
Just put the equivalent code side by side and look. You would be surprised at how much verbosity you choose to ignore.
This is a gold standard for documenting source code, in my experience. It doesn’t entirely solve the “bus” problem, but reduces the barrier to entry for new maintainers or project resuscitators substantially by making it easy to understand what’s going on and why decisions were made.
Admittedly, my own code is also in that 35% range for commenting, so I’m inherently biased towards that threshold specifically. YMMV.
I don't aim for any specific value, but I find that my code is decidedly bimodal — any give file is either close to zero comments or in that 30-50% by lines range. More specifically: I try to structure my code such that the "30-50% comments" code is what enables me to write the zero-comment code.
I worked that way at first, but found that I had difficulty parsing my own zero-comment code to myself years after I wrote it. Nowadays I preface every file/snippet I write with a README block to summarize what the intent of the code was, and I redress my pseudocode into comments once the actual code is written out.
This naturally gets me close to the 1/3rd mark, I find, without really trying. When that code is shared with others, they typically report back that it’s very easy to read quickly and make adjustments.
But again, that’s my entirely subjective experience.
The percentage of comments in line counts doesn't measure the quality of the comments, nor the quality of the codebase.
It's rather easy to get over 50% by putting a comment above each line of code, containing the output of an LLM that's asked "what does this line do" and supplied with exactly that line of code. It's much harder to make sure the comments make sense and actually add value.
"The SQLite source code is over 35% comment. Not boiler-plate comments, but useful comments that explain the meaning of variables and objects and the intent of methods and procedures. The code is designed to be accessible to new programmers and maintainable over a span of decades. "
got me thinking that it would be interesting to remove all comments that cant be reproduced by llm on code base with comments stripped out.
If the llm can produce similar enough comment from scratch, would it be better to just have an IDE that dynamically injects comments when you need as opposed to them being in version control?
One of the stated goals is to have long-term support and maintainability. Adding in a dependency like an IDE is already a large step away from that goal, and to include a dependency on a LLM's non-auditable output actively steps away from that.
Comments in source code are always going to meet the maintainer's intention and will much more likely cover the use cases that comments are meant to cover - unintuitive cases or decisions, unclear algorithms, general usage to point maintainers in the right direction, and so on. More importantly, comments in the source code require no additional tools or other dependencies and as such are more dependable.
Why would I want comments produced by a roll of the dice rather the human who was in the thick of it?
I would instead be willing to consider some kind of QC assessment. Where does AI think the comment does not match the code because something has fallen out of sync.
Is that by line count or by character count? (So I know whether I should instruct my LLM to either write haikus or verbose/hippopotomonstrosesquipedaliophilic comments.)
Can recommend this podcast [1] with Richard Hipp, primary author of SQLite, talking about, among other things, about the origins of SQLite and how they tested it for use in aviation.
Completely off topic, but I think it's a fun quirk of English that sometimes the choice of a/an will tell you how a person pronounces a word. You can spot whether someone has an American or British/Australian accent by whether they write "a historian" or "an historian", for example, even if you've never heard them speak.
Love it. There should be more longevity in software. I've worked at too many projects that was "just" a rewrite of something else, usually due to legacy issues / dropped support (e.g. no support for Flex on iOS, libraries/frameworks no longer being maintained, etc).
I'm a big fan of the Go programming language because of this, but also by extension of "boring technology" (https://mcfunley.com/choose-boring-technology). It's hard to be able to make an impact in this regard in the B2C projects I usually have though.
> Aviation-grade testing → Every machine-code branch instruction is tested in both directions.
It sounds really cool. And even if in the end everyone benefit from that, I wonder who requested that (if someone did)... I mean, it's expensive to test up to that level...
Keep in mind that though it is often claimed that SQLite is DO-178B certified, they do not claim that themselves, they merely say DO-178B-inspired: https://www.sqlite.org/hirely.html
And while Airbus confirmed they are using SQLite, they did not claim they are using it in safety critical parts, which D. Richard Hipp confirms here: https://news.ycombinator.com/item?id=18039303
I believe it was requested by some commercial company. What I find much more astonishing is that this all managed to happen for a public domain product.
Thank you for posting this, now I know about the Recommended Formats Statement from the Library of Congress. Pretty interesting stuff, and unexpectedly detailed!
> Old school → Nobody is completely immune to trends and fads, but the SQLite developers work hard to avoid being sucked into the latest programming fashion. Our aim is to produce timeless code that will be readable, understandable, and maintainable by programmers who have not yet been born.
Not to disagree entirely, but the first stable Rust release is over ten years old. It qualifies as "the latest programming fashion" less and less with each passing day.
I've sometimes wondered what their plan for this is wrt. people. Richard Hipp is 64, and I don't think he plans to continue working on SQLite until he's 90. I know two other people work on SQLite, but AFAIK he owns the company(?)
That said, I think the future of SQLite is basically guaranteed on account of being open source (as much as anything in this world can be guaranteed anyway). Look at Rust: it's done fine since Mozilla stopped sponsoring it. Go will be fine when/if Google stops sponsoring it. etc.
> the future of SQLite is basically guaranteed on account of being open source
I am not concerned with whether it has a future. But I do fear that the absolute manic focus on code quality, testing and support may take a dive when other programmers take the helm. I am not claiming that there are no developers who are equally careful and/or skilled, but whether the culture of SQLite will persist is, to me, still an open question.
Considering the way things are going, I think this is a valid concern for software in general.
> I've sometimes wondered what their plan for this is wrt.
I'm also curious about this for other projects such as Shakti/k9 [1]. Apologies if not referred to correctly as I'm not familiar with these tools, so consider this a question as much as a comment:
A seemingly obscure implementation of a complex tool with a relatively high learning curve and just three maintainers that is supposedly a key component in a number of domains using high-frequency timeseries data (finance, etc.)?
What's the cost/complexity ratio in incorporating technology like this into your system? Or is it much less than the impression I get as someone that's jsut a curious passer-by?
[1] https://shakti.com/
https://hwaci.com/
"Hipp, Wyrick & Company, Inc., or "Hwaci" for short, is a small North Carolina company providing knowledge services to clients around the world since 1992. Hwaci is an S-Corporation owned by the husband and wife team of Richard Hipp and Ginger Wyrick."
Companies are a standard mechanism to provide continuity past the lifetime of a single person. A corporation, if it truly adheres to the laws and bylaws, has enough formalisms to ensure such an organization and its products continue to be supported past a lifetime.
> Nobody is completely immune to trends and fads, but the SQLite developers work hard to avoid being sucked into the latest programming fashion.
So good to see this. I have seen so many developers use the latest C# features heavily, to avoid looking weak.
The second sentence is also very good to see:
> Our aim is to produce timeless code that will be readable, understandable, and maintainable by programmers who have not yet been born.
What do you mean by avoid looking weak? Like engineers in that community look down on not using the latest features?
There is a FOMO especially around younger developers who wants to use latest, newest and upgrade all frameworks the moment they pop out on Microsoft website.
Older developers (like me) have opposite problem and I have been fighting for months to not upgrade .NET4.8 to .NET8 due to compatibility with our current deployment chains etc. In the end I had to admit that using .NET8 for everything is going to work too and is going to give us access to better tools and new tech either through some teething problems.
It could be because this is the easier way to build up resume and be competitive on the market.
[dead]
I think the parent is mostly sour grapes.
There is no such community push but like anywhere else, you'll see folks get excited about new toys and then try to force them in to try them. It's not any worse for C# than anything else.
> Like engineers in that community look down on not using the latest features?
Yes. Engineers use the latest features heavily to demonstrate that their skills are current.
One of the worst such features is "var". Some tools even flag your code for not using var when you could. Inappropriate use of "var" makes code harder to read (and even MS documentation says this) and makes code slightly less reliable too.
Ok but var has been around since C# 3.0 in 2007. Love it or hate it, using that keyword in 2025 signals nothing about how current your skills are.
https://en.wikipedia.org/wiki/C_Sharp_3.0#Local_variable_typ...
You are right about this not being a new feature. But if you don't use it, it seems like you haven't updated your skills in a while.
Besides making the code harder to read, "var" also makes your code less reliable as seen in this example: https://circles.page/567f44465c28b00bf8ed6cf9/Csharp-Type-In...
SomeMethod().Fire(); has the same "problem". var e = new Employee(); does not.
The problem you see is independent from var.
You are right, SomeMethod().Fire() has the problem too. But typically you write
This does NOT have the same problem as var. When you use var you reduce the opportunities for the compiler to catch your bug. So the best practice is to explicitly state the type when possible. It makes the code more readable too.What's more, Microsoft recommends using implicit typing for local variables only when the type of the variable is obvious from the right side of the assignment. See: https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals...
But that's not what the community is doing, and some tools (JetBrains Rider) recommend using var whenever possible.
Microsoft recommendation is reasonable. I don't think var should be used as much Rider recommends. But var is perfectly fine in itself. The problem you illustrated occurs independently from var. You assert that one "typically" writes code a certain way but I've seen plenty of both. Further, sometimes you need var. Sometimes the target type can't be spelled like with anonymous types.
You are contradicting yourself... var is perfectly fine... but it shouldn't be used as much...
Sorry for being unclear. Var is perfectly fine in many cases. Sometimes there are better tools. Screwdrivers are fine tools but they are not appropriate for driving nails.
from your sibling comment: > "var" also makes your code less reliable as seen in this example
I disagree with this too, I think your example is a classic case of preprocessor directives making it difficult to know what your code is doing because the build system is going to conditionally change your code. Var or not, you can't even know what's being compiled just by looking at the file, and that's a larger problem than the use of var
https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...
Use of preprocessor in the example is incidental. The problem with var is that you're not completely stating your intent, leaving it to the compiler to infer your intent. This can lead to trouble in some cases.
I have seen code that sorts numbers as strings, because nowhere in the code was the intent stated that the array is supposed to hold numbers. As a result, if the programmer forgot to convert strings to integers at input time, the bug is never caught.
See: https://circles.page/567f44465c28b00bf8ed6cf9/Csharp-type-in...
Funny. I don’t need to work hard for that at all. It comes naturally to me. It obviously has its pros and cons, but to me, a shiny new tech has to prove itself first in order to deserve my attention.
There are, occasionally, the “wow, I got to have that” moments and those are great, but rare.
I stopped using C# 10+ years ago, but I remember wanting to update the framework and use the latest thing (linq to objects) because it made code a lot more concise.
I have an observation about this: everybody wants a small upgrade that makes it easy for them to make their code a little more concise;
But somehow, almost no one wants a language that is already super-terse in the first place (like Lisp or APL- family).
And yes, that requires a paradigm change to make the most of it - but so does e.g. LINQ.
It’s about the journey, not about the destination.
I can see someone defending Ruby as concise (having the ability to chain different transformations) and simple to write in (low verbosity). Lisp? Define a class and do some map/filter/reduce. Lisp is verbose. Sometimes even worse than Java21 these days.
Just put the equivalent code side by side and look. You would be surprised at how much verbosity you choose to ignore.
Originally written in 2016 [1] so they're already 9/34th of the way there.
[1] https://web.archive.org/web/20161021183035/https://www.sqlit...
9/34 ≈ 26%
> The SQLite source code is over 35% comment.
This is a gold standard for documenting source code, in my experience. It doesn’t entirely solve the “bus” problem, but reduces the barrier to entry for new maintainers or project resuscitators substantially by making it easy to understand what’s going on and why decisions were made.
Admittedly, my own code is also in that 35% range for commenting, so I’m inherently biased towards that threshold specifically. YMMV.
I don't aim for any specific value, but I find that my code is decidedly bimodal — any give file is either close to zero comments or in that 30-50% by lines range. More specifically: I try to structure my code such that the "30-50% comments" code is what enables me to write the zero-comment code.
I worked that way at first, but found that I had difficulty parsing my own zero-comment code to myself years after I wrote it. Nowadays I preface every file/snippet I write with a README block to summarize what the intent of the code was, and I redress my pseudocode into comments once the actual code is written out.
This naturally gets me close to the 1/3rd mark, I find, without really trying. When that code is shared with others, they typically report back that it’s very easy to read quickly and make adjustments.
But again, that’s my entirely subjective experience.
The percentage of comments in line counts doesn't measure the quality of the comments, nor the quality of the codebase.
It's rather easy to get over 50% by putting a comment above each line of code, containing the output of an LLM that's asked "what does this line do" and supplied with exactly that line of code. It's much harder to make sure the comments make sense and actually add value.
"The SQLite source code is over 35% comment. Not boiler-plate comments, but useful comments that explain the meaning of variables and objects and the intent of methods and procedures. The code is designed to be accessible to new programmers and maintainable over a span of decades. "
They try!
got me thinking that it would be interesting to remove all comments that cant be reproduced by llm on code base with comments stripped out.
If the llm can produce similar enough comment from scratch, would it be better to just have an IDE that dynamically injects comments when you need as opposed to them being in version control?
One of the stated goals is to have long-term support and maintainability. Adding in a dependency like an IDE is already a large step away from that goal, and to include a dependency on a LLM's non-auditable output actively steps away from that.
Comments in source code are always going to meet the maintainer's intention and will much more likely cover the use cases that comments are meant to cover - unintuitive cases or decisions, unclear algorithms, general usage to point maintainers in the right direction, and so on. More importantly, comments in the source code require no additional tools or other dependencies and as such are more dependable.
Why would I want comments produced by a roll of the dice rather the human who was in the thick of it?
I would instead be willing to consider some kind of QC assessment. Where does AI think the comment does not match the code because something has fallen out of sync.
I think people are misreading this. I said
> all comments that cant be reproduced by llm
Not remove all comments.
meaning if your comment is so low quality that an LLM will generate it for you by reading the code, then it doesn't belong in VCS
The problem is the non deterministic part
An LLM can generate many valid reasons for doing X, including the right one, but you can't know which one of those it will give you
Is that by line count or by character count? (So I know whether I should instruct my LLM to either write haikus or verbose/hippopotomonstrosesquipedaliophilic comments.)
AI generated comments are useless unless you fix them up, otherwise the reader can generate AI explanations themselves, you're not adding anything.
Can recommend this podcast [1] with Richard Hipp, primary author of SQLite, talking about, among other things, about the origins of SQLite and how they tested it for use in aviation.
[1]: https://corecursive.com/066-sqlite-with-richard-hipp/
I recall him mentioning ( thought maybe it didn't make the cut ) that he would be supporting sqlite into his 90s.
That he was contractually obligated to do so, and that he kept that in mind, probably effects his attitude towards shipping certain things.
>You can copy an SQLite database file
Completely off topic, but I think it's a fun quirk of English that sometimes the choice of a/an will tell you how a person pronounces a word. You can spot whether someone has an American or British/Australian accent by whether they write "a historian" or "an historian", for example, even if you've never heard them speak.
This is great for reducing maintenance overhead for code. I have code using SQLITE written in 2008 that is still working without issues.
Love it. There should be more longevity in software. I've worked at too many projects that was "just" a rewrite of something else, usually due to legacy issues / dropped support (e.g. no support for Flex on iOS, libraries/frameworks no longer being maintained, etc).
I'm a big fan of the Go programming language because of this, but also by extension of "boring technology" (https://mcfunley.com/choose-boring-technology). It's hard to be able to make an impact in this regard in the B2C projects I usually have though.
> Aviation-grade testing → Every machine-code branch instruction is tested in both directions.
It sounds really cool. And even if in the end everyone benefit from that, I wonder who requested that (if someone did)... I mean, it's expensive to test up to that level...
Keep in mind that though it is often claimed that SQLite is DO-178B certified, they do not claim that themselves, they merely say DO-178B-inspired: https://www.sqlite.org/hirely.html
And while Airbus confirmed they are using SQLite, they did not claim they are using it in safety critical parts, which D. Richard Hipp confirms here: https://news.ycombinator.com/item?id=18039303
I believe it was requested by some commercial company. What I find much more astonishing is that this all managed to happen for a public domain product.
The company in question is Airbus.
Thank you for posting this, now I know about the Recommended Formats Statement from the Library of Congress. Pretty interesting stuff, and unexpectedly detailed!
https://www.loc.gov/preservation/resources/rfs/
> Old school → Nobody is completely immune to trends and fads, but the SQLite developers work hard to avoid being sucked into the latest programming fashion. Our aim is to produce timeless code that will be readable, understandable, and maintainable by programmers who have not yet been born.
Shots fired at the rust community.
Not to disagree entirely, but the first stable Rust release is over ten years old. It qualifies as "the latest programming fashion" less and less with each passing day.
It's cool that the developers have such ambitious plans for years to come. After all, SQLLite is already 25 years old.
I wish most software was developed and supported like this
"You can copy an SQLite database file from one system to another ..."
... and further, you can do it in an open, standard fashion over SSH:
https://www.sqlite.org/rsync.html
>SQLite can survive a continental catastrophe.
But not a global. Unless someone ports it to Collapse OS/Dusk OS, that would be a true LTS plan
https://collapseos.org/
https://duskos.org/