
Extending Tcl - blacksqr
http://wiki.tcl.tk/6276
======
srean
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.

~~~
ridruejo
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)

~~~
alfanick
> 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

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

[https://www.researchgate.net/publication/220938922_Writing_S...](https://www.researchgate.net/publication/220938922_Writing_Solaris_device_drivers_in_Java)

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/](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.ptc.com/en/products/developer-tools/perc)

[https://www.aicas.com/cms/](https://www.aicas.com/cms/)

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

[https://developer.android.com/things/sdk/drivers/](https://developer.android.com/things/sdk/drivers/)

~~~
DonHopkins
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](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](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.

~~~
pjmlp
Many thanks for the overview, NeWS had lots of great ideas, pity we got stuck
with X11 on UNIX systems.

------
niftich
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](http://wiki.tcl.tk/2352)

~~~
eridius
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.

~~~
monetus
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](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.

~~~
eridius
macOS has 8.5 (at least as of macOS 10.12), though that's still not 8.6. And I
discovered the TclTLS package it ships with is old and doesn't even support
TLSv1.2. But besides that it's been serviceable.

------
davidw
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](https://amzn.to/2IB9OyR)

~~~
pjmlp
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.

~~~
gaius
Really, it flies compared to Ruby...

~~~
petre
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.

~~~
davidw
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.

~~~
ptrott2017
As DavidW points out Out of the box Tcl (like most scripting languages) was
never designed for numeric processing. If you want to do numerics and number
crunching in Tcl use one of the extensions such as Vectcl or the Mathemtcl.
Tcl's C APi makes writing extensions (or wrapping existing libs) pretty
straight forward too.

------
KasianFranks
ANNOUNCE: Digital Trader - java/tcl/tk web agent (1997)
[https://groups.google.com/forum/#!msg/comp.lang.tcl/5-KIZWGY...](https://groups.google.com/forum/#!msg/comp.lang.tcl/5-KIZWGYLMI/fU-
ZAIF8ZYMJ)

