Hacker News Reader

Comment by throwaway81523 | Hacker News Reader

I never liked tcl but the implementation was definitely small, which mattered more back then than it does now. Does anyone still care about it?

These days what we really need is an easily embeddable Python. Guile is very nice if you want a somewhat fancy Scheme system, but it got out of control if all you wanted was something light and embeddable.

View on HN

Lots of people care about it, and it's alive and kicking in-industry and being developed (Tcl 9 is imminent[0]).

I've had fun w Guile over the years (though actually never considered its "heaviness"); fun.

I'm constantly amazed at the professional love for Python; its got it's network effect in full-effect: lots of people, lots of software - there's just no denying that. But for Joy of Development, Tcl (and C) is still my go-to.

You probably know this, but speaking of embeddable Python and Tcl, Tcl is indeed embedded in Python if you're running Tkinter[1].

And Larry Wall thought routers were weird places to be ported to[2].

[0] https://sourceforge.net/projects/tcl/postdownload

[1] https://docs.python.org/3/library/tkinter.html

[2] https://libquotes.com/larry-wall/quote/lbh5n5p

I believe lua is often used in this role these days. I've gotten the impression that it is light and easy to integrate, but I haven't tried it myself.

Yes, Lua is quite easy to embed and is popular in game development for that reason. It appears in a few other applications like Redis as well. But, in the big picture, it's a weird language that is not very popular. People want Python and/or Javascript, and JS is awful, so that leaves Python ;).

I do bot understand the downvotes. Maybe because of wording “weird”. Give me a break, I think it has a point: much more people can do Python as Lua.

I do like Lua, but if I just try to use it in my work, I would be paria.

I had figured people didn't like the dig at JS. Unfortunately the WAT video is no longer on youtube. It might be on destroyallsoftware.com.

I guess Lua remains the chief goto for light embedded scripting environment, doesn't it?

If only it had given us dict/apply/lmap earlier, embraced its prefix-ness more (no ugly expr nor https://core.tcl-lang.org/tips/doc/trunk/tip/676.md when we already can do Lisp-style arithmetic via `namespace path {::tcl::mathop ::tcl::mathfunc}`) and had better tools for metaprogramming (string based templating is suboptimal, let us say)...

It still was my gateway into Common Lisp and remains a very cool scripting language with builtin event loop, good Unicode handling and very practical/"batteries included" stdlib.

To this day, TCL is still my go-to for internal scripting languages or, quite often, creating a simple configuration DSL (or an internal linter for configuration files).

Of course, I also do most of my scripting in TCL, so I'm a wee bit biased.

>> what we really need is an easily embeddable Python. Guile is very nice if you want a somewhat fancy Scheme system, but it got out of control if all you wanted was something light and embeddable.

In my experience what goes out of control are python scripts, with many dependencies.

Also the changes in the language tend to be much more intrusive and often than in scheme.

A huge bummer about Guile (and that is frankly shocking for a language designed to be embeddable) is that it relies on a bunch of global state, which means that you can't embed multiple interpreters a single process. This totally kills it as a embedded scripting language for many applications, and it's also just bad practice in general. Even Python, far less easily embeddable, supports multiple interpreters, though before Python 3.13 (I think) they all shared the GIL.

Aside from this issue, the Guile API is pretty good, but the best one by far is Lua's C API, which is just a thing of beauty. I'm curious to try it with Tcl.

Tcl makes it very easy to use multiple interpreters in the same process. It is one of its strengths.

What I like about JO is that he acknowledges the deep flaws of Tcl. And there never developed an inward looking bubble of Tcl/Tk advocates - the users were largely driven by pragmatism; it just got the job done.

This contrasted with Larry Wall and ethos/self-delusion of the Perl community - anyone critical of the language or its design was disregarded as simply lacking the intellect to appreciate the "poetry" of Perl - and the the language warts (better described as big pus-weeping boils) were actually features.

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!

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

> 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

yes, i agree. this is one of many ways lua is exceptional

Yeah it is the de facto scripting language for EDA tools (everything about designing and manufacturing ASICs and FPGAs).

It's pretty terrible but honestly Python would be pretty bad too. What these tools really need is a proper API that you can hook into and then use any language you want.

Reply on news.ycombinator.com