the implementation of tcl is not small; it's 1.9 megabytes stripped, 8.5 times the size of lua 5.2, which is a very popular embeddable scripting language:
: ~; ls -l /lib/x86_64-linux-gnu/libtcl8.6.so /lib/x86_64-linux-gnu/liblua5.2.so.0.0.0
-rw-r--r-- 1 root root 216960 Dec 10 2022 /lib/x86_64-linux-gnu/liblua5.2.so.0.0.0
-rw-r--r-- 1 root root 1852968 Feb 1 2023 /lib/x86_64-linux-gnu/libtcl8.6.so
even guile is smaller:
: bin; ls -l /lib/x86_64-linux-gnu/libguile-3.0.so.1.5.0
-rw-r--r-- 1 root root 1303112 Mar 5 2022 /lib/x86_64-linux-gnu/libguile-3.0.so.1.5.0
a small scripting language might be the 7th edition bourne shell or the 7th edition awk:
: bin; ls -l sh awk
-rwxr-xr-x 1 user user 46126 May 11 1979 awk
-rwxr-xr-x 1 user user 17310 May 5 1979 sh
admittedly tcl is still not as bloated as perl or cpython:
: bin; ls -l /lib/x86_64-linux-gnu/libpython3.11.so.1.0 /lib/x86_64-linux-gnu/libperl.so.5.36.0
-rw-r--r-- 1 root root 3823936 Nov 25 2023 /lib/x86_64-linux-gnu/libperl.so.5.36.0
-rw-r--r-- 1 root root 7732544 May 2 08:59 /lib/x86_64-linux-gnu/libpython3.11.so.1.0
and, at 47 megabytes, javascript makes even cpython look slim:
: Downloads; ls -l /usr/lib/x86_64-linux-gnu/libnode.so.108
-rw-r--r-- 1 root root 47166144 Jun 22 09:21 /usr/lib/x86_64-linux-gnu/libnode.so.108
which is almost as big as java's 187 megs:
: ~; du -sk /usr/lib/jvm/java-17-openjdk-amd64/lib/
187208 /usr/lib/jvm/java-17-openjdk-amd64/lib/
a small embeddable lisp might be xlisp or siod. or, in modern times, tinyscheme, which is a 103-kilobyte executable:
: Downloads; ls -l /usr/bin/tinyscheme
-rwxr-xr-x 1 root root 102648 Jun 8 2020 /usr/bin/tinyscheme
though to be perfectly fair we ought to include its standard library:
: Downloads; ls -l /usr/lib/tinyscheme/init.scm
-rw-r--r-- 1 root root 23806 Jun 8 2020 /usr/lib/tinyscheme/init.scm
which brings the total for tinyscheme up to 125k. siod and xlisp are easy to embed, but i haven't tried embedding tinyscheme in a c program, so maybe it's more of a pain than i imagine it would be
really small would be a forth. forth is basically a scripting layer for assembly language with an interactive shell and ide, and there are plenty of full-featured forths that will run in 16k of ram. unfortunately forth code is hard to read and easy to crash
garbage-collected pointer-graph languages like lisp, python, js, and perl5 tend to use a lot more runtime memory for a given amount of functionality; in tcl (or the bourne shell) a list of 10 numbers like {8 2020 23806 102 7 3 11 5 36 86} is stored as a string which might occupy 31 bytes, plus an allocation header of probably another 16 bytes on a 64-bit system, for a total of maybe 48 or 64 bytes. by contrast, in a lisp system each list item occupies a 16-byte cons cell, so you end up paying 160 bytes; and storage is not reclaimed promptly, so you typically have another multiplier of 1½–3 to keep from spending all your time in the garbage collector. lua is the same; perl and python are different in detail (usually reclaiming storage more promptly due to reference counting, but wasting space on reference-count fields, boxing integers in python's case, and bloated svs in perl's case) but broadly similar in outline
tracing garbage collection (as opposed to the much slower reference counting used by perl and cpython) tends to diminish easy embeddability, both because it's very tricky to do in standard c, and because it kind of wants to own your program's entire memory space
this stuff still matters a lot due to things like icache misses, embedded systems, and standalone executable size. people complain about the size of golang and rust binaries but they don't hold a candle to the cpython interpreter. but it mattered a lot more in the 90s!
> tracing garbage collection (as opposed to the much slower reference counting used by perl and cpython) tends to diminish easy embeddability, both because it's very tricky to do in standard c, and because it kind of wants to own your program's entire memory space
Lua is living proof of the opposite: small, easily embeddable, with a tracing GC
i cloned https://github.com/rsdoiel/xlisp and it turns out that, although the original ast-walking xlisp was for the z80 under cp/m, this version is an r3rs scheme. the stripped executable is 303.6 kilobytes. historical versions of xlisp were easy to embed, and api.doc indicates that this is a priority for this version as well
amusingly, this xlisp package includes a tk interface—by embedding tcl
an earlier xlisp, i think for cp/m-86, is http://www.cpm.z80.de/download/xlisp.zip. it is written in c, about 2800 lines of c, which i haven't tried to compile, but i think the executable is under 64k. this might give the flavor of the language thus implemented:
; ::::::::::::
; :: Turtle ::
; ::::::::::::
; Define "Turtle" class
(setq Turtle (Class 'new))
; Define instance variables
(Turtle 'ivars '(xpos ypos char))
; Answer "isnew" by initing a position and char and displaying.
(Turtle 'answer 'isnew '() '(
(setq xpos (setq newx (+ newx 1)))
(setq ypos 12)
(setq char "*")
(self 'display)
self))
https://www.softwarepreservation.org/projects/LISP/picolisp/... purports to be a lisp interpreter in an 8-kibibyte executable. for cp/m. it looks like it's cp/m-80, since objdump -D -b binary -m i386 -M i8086,intel --adjust-vma=0x100 8kl.com produces gibberish. dz80 from the d52 package produces a reasonable-looking disassembly, but it's 6000 lines long, and i don't have a cp/m or cp/mish emulation environment set up at the moment, so i can't verify that it actually works. all the source code is included
still, it seems like pretty strong evidence that you can do an ergonomic embedded scripting language in 8 kilobytes or so, not 1900 kilobytes
really small would be a forth. forth is basically a scripting layer for assembly language with an interactive shell and ide, and there are plenty of full-featured forths that will run in 16k of ram. unfortunately forth code is hard to read and easy to crash
garbage-collected pointer-graph languages like lisp, python, js, and perl5 tend to use a lot more runtime memory for a given amount of functionality; in tcl (or the bourne shell) a list of 10 numbers like {8 2020 23806 102 7 3 11 5 36 86} is stored as a string which might occupy 31 bytes, plus an allocation header of probably another 16 bytes on a 64-bit system, for a total of maybe 48 or 64 bytes. by contrast, in a lisp system each list item occupies a 16-byte cons cell, so you end up paying 160 bytes; and storage is not reclaimed promptly, so you typically have another multiplier of 1½–3 to keep from spending all your time in the garbage collector. lua is the same; perl and python are different in detail (usually reclaiming storage more promptly due to reference counting, but wasting space on reference-count fields, boxing integers in python's case, and bloated svs in perl's case) but broadly similar in outline
tracing garbage collection (as opposed to the much slower reference counting used by perl and cpython) tends to diminish easy embeddability, both because it's very tricky to do in standard c, and because it kind of wants to own your program's entire memory space
this stuff still matters a lot due to things like icache misses, embedded systems, and standalone executable size. people complain about the size of golang and rust binaries but they don't hold a candle to the cpython interpreter. but it mattered a lot more in the 90s!