On Mon, Apr 29, 2019 at 11:49 AM Richard Hipp <d...@sqlite.org> wrote:
> On 4/29/19, Russ Cox <r...@golang.org> wrote: > > > > That page's section 1.1 Philosophy of Assert describes the SQLite > project's > > philosophy about three different kinds of assertions - assert, ALWAYS, > and > > NEVER - which I found very helpful and principled and would consider > > pointing other developers at when the topic arises. > > > > But then it inexplicably shifts into a critique of the Go language. > > Thanks for your kind reply, Russ. I have rewritten the paragraph in > question to try to better capture the point I was attempting to make, > and to be less snarky. Please reread and let me know if you think the > new paragraph is acceptable or if it needs further revision. The current analogy still doesn't seem like it represents the Go project's position accurately: It is true that assert() can be misused. Antibiotics can be misused too, but that does not mean we should ban all antibiotics. This is an interesting analogy, because of course widespread misuse (overuse) of antibiotics is a real problem, and the solution is to make doctors think more carefully about when to use them and not, rather than "just prescribe the antibiotics to be safe". Avoiding misuse by encouraging that kind of careful decision is exactly why Go does not provide an assert builtin that would make it trivial to "just add an assert to be safe". Instead, we leave it to users to write the specific trivial assertion function they want (SQLite assert, SQLite ALWAYS, or something else entirely), forcing them to decide explicitly what action should happen when the condition is false. We hope this will make programmers think a little more about consequences and make programs better overall. There's no ban on writing such a function, only an effort to make people think carefully about which meaning they really want. At this point we are not likely to add anything new along those lines, but if I were designing a new language, the question of adding all three - invariant(x), always(x), and never(x) - as a collective replacement for assert(x) would be an interesting thing to consider. Honestly, it still seems to me like this page is not the place to have this debate at all, and it would be improved by dropping all mention of Go. But if you want to draw a contrast, I think it would be accurate to say: Because assert() can be and is commonly misused, some programming language theorists and designers look with disfavor on the whole idea of assert(). For example, the Go programming language omits a built-in assert, to eliminate its frequent misuse to mean ALWAYS. SQLite avoids this misuse by reserving assert only for provable invariants and otherwise using ALWAYS or NEVER. Best, Russ _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
