This is from the SQLite creator D. Richard Hipp who is always worth reading, but, I'd like to recommend reading what TCL's creator John Ousterhout has to say.
His article on threads from 1995 was highly influential on me, and I remember it to this day. More recently (2018, revised and expanded in 2021), he published a book on software engineering practices called A Philosophy of Software Design which is, in my opinion, the best in its category.
show comments
graemep
> Early versions of SQLite (prior to 2004) operated on the classic TCL principal that "everything is a string". Beginning with SQLite3 (2004-06-18), SQLite also supports binary data.
> However, types are still very flexible in SQLite, just as they are in TCL. SQLite treats the datatypes on column names in a CREATE TABLE statement as suggestions rather than hard requirements
This is something I do not much like. Its not compulsory (you can create "strict" tables). It works well in TCL which is an entire language designed around the idea. Less so in SQL.
One of the advantages of RDBMSes is that not accepting obviously wrong data makes life easier for developers. You can debug an issue that happens on inserting the data, not when you find the wrong type or other bad much later on.
show comments
zvr
Back in the day, the Tcl conferences (and the EuroTcl in Europe) were great sources of information. Only about half of the presentations were for Tcl internals and extensions. The rest were about other projects that were using Tcl in some way or other, and it was fascinating to learn about completely different areas of software.
I was looking for this because Figure 1 (Breakdown Of SQLite Source Code By Language) is missing, and archive.org doesn't seem to have it. That chart can be found near 11:56 of the video above.
1vuio0pswjnm7
"The sqlite3.c and sqlite3.h source files are build products, and the source tree used to build those files is over 50% TCL code."
Always feels silly to have to install Tcl to compile sqlite3,
I use the --disable-tcl configuration option before compiling. After "make" I have a one-liner to statically-link the sqlite3 binary. It takes a relatively long time to link; sqlite3.c is a whopping 8.7M. I end up with a 1.7M sqlite3 binary.
I never do "make install". I do not want to install all the Tcl stuff.
smitty1e
> For example, the byte-code engine used to evaluate SQL statements inside of SQLite is implemented as a large "switch" statement inside a "for" loop, with a separate "case" for each opcode, all in the "vdbe.c" source file.
I wonder -- if they were to restart from scratch today, would they do the same thing? If not, which stack would they choose?
show comments
novoreorx
I wonder is it possible to use Tcl as a testing tool for modern languages such as Python and JavaScript, the way SQLite use Tcl to do testing looks really promising
This is from the SQLite creator D. Richard Hipp who is always worth reading, but, I'd like to recommend reading what TCL's creator John Ousterhout has to say.
His article on threads from 1995 was highly influential on me, and I remember it to this day. More recently (2018, revised and expanded in 2021), he published a book on software engineering practices called A Philosophy of Software Design which is, in my opinion, the best in its category.
> Early versions of SQLite (prior to 2004) operated on the classic TCL principal that "everything is a string". Beginning with SQLite3 (2004-06-18), SQLite also supports binary data.
TCL can handle binary data. It is just not a separate type: https://wiki.tcl-lang.org/page/Working+with+binary+data
SQLite also always had a null type, surely?
> However, types are still very flexible in SQLite, just as they are in TCL. SQLite treats the datatypes on column names in a CREATE TABLE statement as suggestions rather than hard requirements
This is something I do not much like. Its not compulsory (you can create "strict" tables). It works well in TCL which is an entire language designed around the idea. Less so in SQL.
One of the advantages of RDBMSes is that not accepting obviously wrong data makes life easier for developers. You can debug an issue that happens on inserting the data, not when you find the wrong type or other bad much later on.
Back in the day, the Tcl conferences (and the EuroTcl in Europe) were great sources of information. Only about half of the presentations were for Tcl internals and extensions. The rest were about other projects that were using Tcl in some way or other, and it was fascinating to learn about completely different areas of software.
There is also a video recording of this talk:
https://youtu.be/kHmwv3I1Kxk?si=CrZW_VVnA_UqcXCU
I was looking for this because Figure 1 (Breakdown Of SQLite Source Code By Language) is missing, and archive.org doesn't seem to have it. That chart can be found near 11:56 of the video above.
"The sqlite3.c and sqlite3.h source files are build products, and the source tree used to build those files is over 50% TCL code."
Always feels silly to have to install Tcl to compile sqlite3,
I use the --disable-tcl configuration option before compiling. After "make" I have a one-liner to statically-link the sqlite3 binary. It takes a relatively long time to link; sqlite3.c is a whopping 8.7M. I end up with a 1.7M sqlite3 binary.
I never do "make install". I do not want to install all the Tcl stuff.
> For example, the byte-code engine used to evaluate SQL statements inside of SQLite is implemented as a large "switch" statement inside a "for" loop, with a separate "case" for each opcode, all in the "vdbe.c" source file.
Duff's Device[1] for the win!
[1] https://en.m.wikipedia.org/wiki/Duff's_device
I wonder -- if they were to restart from scratch today, would they do the same thing? If not, which stack would they choose?
I wonder is it possible to use Tcl as a testing tool for modern languages such as Python and JavaScript, the way SQLite use Tcl to do testing looks really promising
Anyone has used the mysterious "e" editor?