Tcl's C API is very nice, and makes it easy to either integrate Tcl into a larger C app, or write bits and pieces of C as Tcl commands.

I helped work on the 2nd edition of this book, which I think is still fairly relevant: https://amzn.to/2IB9OyR

Writing Tcl extensions was one of the few times I actually enjoyed using C.

It is probably one of the best languages to extend. Sadly it is also one of the slowest.

Really, it flies compared to Ruby...

Is that right ? I have never used Ruby. I should have my expectations on running time in check in case I do try Ruby out -- I have been meaning to.

I don’t dislike Ruby - you can do some very clever things in very little code with it. But it is far from high-performance!

Early Tcl was slow - but it was being compared to pure C. Recent Tcl is as snappy as any HLL.

Not really. I did some prime number crunching and it's the slowest of them all. Maybe for simple scripts working with strings, but otherwise I'd pick Lua any day. LuaJIT just runs circles around other dynamic languages, only compiled stuff is able to beat it.

Tcl - or Ruby, Python without NumPy (which is an extension) or most scripting languages are not the right tool for the job for number crunching.

I personally think that might depend on what you mean by "slow". Tcl/Tk programs can be very light and memory-efficient -- you can pack a lot of features into a program that only takes 10 megabytes or less at runtime and that starts up and responds to input near-instantly. The event loop abstraction which is well-integrated in Tcl makes it easy to handle sockets, files, timers, and gui events all on one loop which done right can keep your program very responsive without needing to worry about multithreading.

In terms of pure runtime performance (CPU efficiency I guess), do you know of any reasonable benchmarks comparing TCL to say, Python and Ruby? I wonder if they might all be in the same ballpark?

Isn't TCL almost as fast as C for certain things, like strings, but slow in other ways, like recursion? I haven't tried to do any performance optimizations yet really.

Not when you are trying to build a server on top of it.

It can be fairly fast for many use cases (specially because of async processing) and it was the basis one of the original scalable web servers that implemented multi-threading https://en.wikipedia.org/wiki/AOLserver

AOLServer was the one we were measuring ourselves against, see other responses.

You had a web server faster than AOLServer, and you went out of business.

Hm.

Time to consider that your experience may be outdated. Wub, to take one example, is a pure-Tcl web server whose performance is comparable to Apache. Network latency in handling socket I/O swamps any differences in code execution speed.

I'm not a C programmer but I spent some time analysing major parts of C code for a SAP integration library that I maintained to get a better understanding of the SAP RFC interfaces. Never had an issue with the C code and TCL side of the integrations very easy to reason and maintain whilst covering massive amounts of integrations to SAP.

More often then not, the problems I was involved with resolving on emergency escalation (line down) calls was on the SAP side of the world and never in the integration code in TCL and C.

The biggest drawback with the TCL implementation from our application vendor was that they did not implement multi threading for TCL and instead implemented a node.js like event loop. As SAP calls were locking, this did cause locks for all other TCL calls.

Tcl is one of those rock-solid things that have been around for a while, where extrapolating from other projects of the same age you'd expect to find a somewhat muted community, and that's not the case at all.

Dormancy and stagnation can have many causes: author hiatus, the code clearing some threshold feature-complete, obsolescence by competing tech that solves similar problems. And it seems Tcl has managed to stay relevant through a combination of usefulness (like its standard lib, or Tk) sufficient paradigm difference to tech that came later, in some cases future tech building on top of it instead of replacing it wholesale, willingness to fix common gripes in the core (numbers, unicode, binary), and a developer-focused (instead of consumer-focused) approach to packaging. It's probably helped by being a captive scripting language on some embedded platforms too.

Languages that became big and popular in later years faced demands around the distribution of third-party packages. Perl became an early pioneer with a community repository, but later languages had to cope with the expectation of using a language-specific package manager that would download from the official repository, and automagically make packages available globally. Tcl encouraged user contributions in a less formal way [1] -- develop programs (code that uses builtin commands) or extensions (code that defines new commands) for your own use, and make them available if you so wish. This minor difference in attitude creates an ecosystem that feels different from a language package repo, where thousands of packages of varying quality sit, the long tail of them effectively unvetted.

[1] http://wiki.tcl.tk/2352

Does Tcl actually have any sort of package manager? I've started writing Tcl scripts again lately after a decade of not touching the language, and and I'm thankful that so far macOS has seemed to include every extension I wanted to use in the Tcl it ships with, but I'm waiting the day I hit a missing extension and have no idea how to install it.

Activestate put teapot on github. I don't use it though, so I don't know how it works yet. > https://github.com/ActiveState/teapot

aside: Everything tcl just worked for you on macOS? Mac having 8.4 rather than 8.6 drove me nuts.

A couple of ideas that Tcl pioneered were:

(I) design for size, ease of extensibiliy and embedding, and (II) doing threads right.

(I) became a feature offered by many other languages, but I think Tcl was the one that popularized it. This crown belongs to Lua now.

(II) was not adopted as much as it should have been. I am looking at you Python. Interpreter as a library with interpreter state fully contained in an object, no globals or statics -- simplifies threads immensely. Run different interpreters in different threads, no need for global lock, no need for serialization-deserialization to talk to other interpreters in the same address space.

For some time John Ousterhout was part of Sun Labs and Sun invested quite a bit of resources in it and bridges between Tcl and Java. The original idea was that Java was going to be the universal systems language and Tcl the universal scripting language. That was scrapped at some point because the messaging was too complex and it ended up being "Java for everything". Arguably we would have been better off with Java + Tcl than we ended up with Java + Javascript.

When that happened JO went to found Scriptics, but it never got the traction it should (not helped being branded as "parasites" by Stallman)

In one of those "could have been" moments, back in c.1994 I wrote a simple web browser which used SafeTcl (a sandboxed Tcl) to render. I got a few things wrong in hindsight - there was no static markup at all, the whole page was rendered by Tcl although there was a simple Tcl function to render blocks of text and TeX-like markup in Tcl strings.

Tcl is more pleasant than Javascript, but still has some horrible parts like poor support for structs, nothing really equivalent to a pointer, clumsy escaping, and (at the time) no support for dynamically linked extensions.

Why did RMS called them parasites?

Why you should not use Tcl

https://wiki.tcl.tk/16730

Java was going to be the universal systems language

My heart stopped here for a while [0]. Are there any papers on Java as system language? I'd love to read more - as embedded developer, this really is out of my scope.

[0]: don't worry it does it 60 times per minute

Yes, Sun played with idea of putting a JVM on the Solaris kernel.

https://www.researchgate.net/publication/220938922_Writing_S...

They also created SunSPOT before RasperryPI, Arduino were even ideas, where beyond a basic layer written in native code, everything else was Java based.

http://www.sunspotdev.org/

Also Java is actually used as systems language in some scenarios, just not on your desktop.

When it is compiled AOT to be deployed on bare-metal scenarios such like the SDKs being sold by PTC and Aicas (just two examples, there are other companies)

https://www.ptc.com/en/products/developer-tools/perc

https://www.aicas.com/cms/

When it is used on Android Things to write user space drivers.

https://developer.android.com/things/sdk/drivers/

Even 16 or so years earlier in 1990, Sun played with the idea of putting a PostScript interpreter in the SunOS kernel.

Like NeWS was the Network extensible Window System, so NeFS was the Network extensible File System, or NFS 3.0.

It was actually a great idea, just a wee bit before its time, and very poorly named and positioned!

For example: If you want to make a copy of a file on the server, you can send a PostScript program that runs in the kernel and copies the file locally on the server in the kernel with ZERO context switches, instead of sending it over the net to the client, then back from the client to the server. Even if you rsh'ed the user command "cp" on the server, it would still incur context switching, but if your copy loop was running in the kernel then it didn't need to switch in and out and in and out for every block it copied.

There are more examples of why it's a great idea in the paper.

This comparison of NeWS to AJAX also applies NeFS, which is like kernel NeWS with file operations instead of a graphics library -- it also saves you lots of user/kernel context switches even if you're not doing any networking:

https://en.wikipedia.org/wiki/NeWS

NeWS was architecturally similar to what is now called AJAX, except that NeWS coherently:

- used PostScript code instead of JavaScript for programming.

- used PostScript graphics instead of DHTML and CSS for rendering.

- used PostScript data instead of XML and JSON for data representation.

It didn't go over very well because the unenlightened philistines of the time couldn't get their head around an API to the file system that wasn't compatible with creat open close read write and ioctl.

http://donhopkins.com/home/nfs3_0.pdf

Network Extensible File System Protocol Specification

1.0 Introduction

The Network Extensible File System protocol (NeFS) provides transparent remote access to shared file systems over networks. The NeFS protocol is designed to be machine, operating system, network architecture, and transport protocol independent. This document is the draft specification for the protocol. It will remain in draft form during a period of public review. Italicized comments in the document are intended to present the rationale behind elements of the design and to raise questions where there are doubts. Comments and suggestions on this draft specification are most welcome.

[...]

Example: Copy a File

Make a copy of file (foo) called (bar). Both files exist in the same directory dfh. The request starts by looking up the filehandle for the file to be copied and creates a filehandle for the copy. The loop operator executes a procedure that copies the file using 1K reads and writes. It maintains a running count of the number of bytes yet to be copied.

    % Copy a file
    %
    dfh (foo) lookup /foofh exch def % get filehandle for (foo)
    dfh (bar) create /barfh exch def % create filehandle for (bar)
    /bytes foofh getattr /fsize get def % get size of (foo) so we know how much to copy
    /offset 0 def % initialize offset for (bar)
    {
        /data foofh offset 1024 read def % read up to 1K from (foo)
        barfh offset data write % write up to 1K to (bar)
        /bytes bytes 1024 sub def % decrement byte count by 1024
        bytes 0 le { exit } if % if it’s < 0 then we’re done
        /offset offset 1024 add def % increment offset by 1024
    }
    loop
    barfh getattr 1 encodereply sendreply % return the attributes of the new file to client.

When that happened JO went to found Scriptics, but it never got the traction it should (not helped being branded as "parasites" by Stallman)

The primary issue is that Tcl was a language designed on the wrong side of the memory cost divide. Many of the languages designed with "memory and CPU are expensive" got swept aside because newer languages that didn't make that assumption had a lot more features.

What is sad is that Tcl didn't STAY SMALL. In an era of 32K ROM/4K RAM microcontrollers, we don't really have a well-featured scripting language that works down there.

It also didn't help that Tcl went into a period of instability right as the Dot Com Boom/Crash went full tilt whereas Python, for example, was stable from 1997-2000 (A LOT of people standardized on 1.5 for a loong time)

And, as smart as he is, John Ousterhout was one of the big coding problems and getting him out of the codebase helped Tcl dramatically.

In an era of 32K ROM/4K RAM microcontrollers, we don't really have a well-featured scripting language that works down there.

What about Forth? http://www.forth.org/

Just ... no. I'm trying to solve a problem, not play intellectual games for how to create stack threaded code.

I had really high hopes for Lua. But 1-based indexing when you're interfacing to C is just not flying. Apparently I'm not alone as Lua comes in at #9 on the "Dreaded" languages list:

https://insights.stackoverflow.com/survey/2017#technology-mo...