
The return of the Tcl browser plugin - blacksqr
https://fossil.e-lehmann.de/tclplugin/index
======
kragen
This is great! I remember the slide rule I wrote in Tcl/Tk in 1997 was able to
run in the browser plugin: [http://canonical.org/~kragen/slide-
rule.tcl](http://canonical.org/~kragen/slide-rule.tcl). I wonder if it still
does!

The Tcl plugin could have been an awesome alternative to Java applets. Too bad
they abandoned it.

Unlike others here, I don't think Tcl is "extremely enjoyable to code in",
largely due to its lack of first-class aggregate data structures, but it makes
doing simple things very simple.

~~~
bch
I don't know when you last worked with Tcl, but it's got lists (as always),
dictionaries, and integrated first-class object system (after years of various
extensions). Also, if it's an option, punting structures to C can be nice to
organize data.

Re: abandoned applets - some see that as dodging a bullet. If it became a Big
Deal in the browser, it arguably could have cemented itself into the form it
had at that time, because of maintaining compatibility for that audience. It's
a thought exercise I haven't completely thought through, to be honest, which
just occurred to me because Tcl has done a tremendous job being true to itself
anyway, and has a great amount of compatibility with historic versions of
itself.

Anyway, now I'm off to look at slide rules ;)

~~~
davidw
> punting structures to C can be nice to organize data

I'm a Tcl fan, but the above is actually somewhat problematic, because to hold
a reference to the C struct, you have to then manually free it later, losing
some of the benefits of a language with automatic memory management.

Real dicts, and the new object stuff are big improvements though.

~~~
blacksqr
FlightAware has released the SpeedTables package for Tcl, which basically
creates C structures on the fly, as well as C-based accessor routines:

"Speed tables reads a structure definition and emits C code to create and
manipulate tables of rows of that structure. This allows operations to be
performed on the table at native code speeds, using a custom extension that
manages rows of fields as native C structs and emit subroutines for
manipulating those rows in an efficient manner."

FlightAware.com deals with extremely high-volume data throughput, and they
manage the whole process with Tcl.

[https://github.com/flightaware/speedtables](https://github.com/flightaware/speedtables)

~~~
davidw
Cool! They run [https://tcl.apache.org/rivet/](https://tcl.apache.org/rivet/)
too, which I played a part in building.

------
favadi
Any HN reader still uses Tcl in production system? Is it still relevant in
2015?

~~~
bch
Here. Extremely enjoyable to code in and easy to integrate with C which makes
integrating with arbitrary libraries and syscalls simple. The language rules
are strict, but there are few of them, and they allow for surprising
customizability (read: DSL). In a nutshell (for me), as competent as any
language, and more enjoyable than most.

This describes explicit use, outside of cases where you may be using it
directly or indirectly and not realize, like Expect, or in your network
routers like your F5 iRules, etc.

My work is currently specifically Tcl-focused, at ActiveState, but see my
other comments for years of enthusiastic Tcl experience from "general"
development and operations gigs. I use it where I can, and I can use it in a
lot of places.

~~~
cartoonfoxes
> Here. Extremely enjoyable to code in and easy to integrate with C which
> makes integrating with arbitrary libraries and syscalls simple.

This is definitely a sweet-spot for TCL. It's not surprising that TCL doesn't
get more attention when this use case has been so stable for so long.

~~~
tptacek
Perhaps because Lua is a better language and, like Tcl, was custom-built for
that sweet spot.

~~~
mzs
I've not done any Lua but my oldest son has and he showed me. It really did
not stand-out in my mind compared to say python. I guess it's pretty simple,
embeddable, interoperable with C. It really was a great first language for him
really but so would have js really.

Tcl is pretty neat though. It has this feel like lisp and very simple rules
plus everything can be a string, which is prefect for gluing text output
together between tools.

~~~
tptacek
I've done a lot of Tcl work; two successive companies I worked at used it as
their embedded language. It has its charms, but I would have a hard time
working at another company that in 2015 chose Tcl over Lua.

Issues I have with Tcl:

* The syntax is as idiosyncratic as a Lisp, but has few of the advantages that Lisps get for homoiconicity.

* uplevel/upvar is a janky way to get metaprogramming. Compare metaprogramming in Tcl to that of Japanese Tcl errr Ruby.

* The Tcl runtime is outmoded.

I could probably think of others.

There's also the fact that Tcl's vaunted integration with C code has pretty
much become par for the course in high level languages. I didn't find writing
Ruby extensions to be any more painful than writing Tcl extensions. Modern
high level languages also expose full-featured FFIs, so you often don't even
need bindings.

Tcl was ahead of its time! It was a good embedded high level language before
virtually every large project recognized the need for embedded languages. And
the event-based model that Tk forced on it turned out to be pretty useful for
network servers. It was a _great_ choice in the late 1990s.

~~~
mzs
Good points, I'd moved to python for embedding and shimming myself and then
got bit cause SWIG had forced Cpython when there were other options later. I
do still very much like the simple syntax though.

~~~
tptacek
I like it sometimes more and sometimes less. For instance, the "everything's a
string" parsing rules mean comments can cause parse errors.

~~~
mzs
Ha, that's the very reason I used it at first!

    
    
      #!/bin/sh
      # the next line restarts using tcl \
      exec tcl "$0" "$@"
      ...
    

I just go _so_ annoyed with is it /usr/bin/perl or /usr/local/bin/perl or ...
And is it awk or nawk or ... And somebody told me this trick with Tcl and I
was like, "I'll just use it for this simple script and be done with it."

------
kevinwalzer
Tcl is an awesome language for developing cross-platform desktop apps in, and
Tk bindings are everywhere. I use Tk as the foundation for Mac (and soon
Windows) apps written in Python and Perl as well as Tcl.

------
gwbas1c
Would be nice if there was some kind of walkthrough. Nothing shows what kind
of tags are needed in HTML, what kind of files are uploaded to the web server,
how to interact with the DOM, ect, ect.

------
xiaq
It might be much more useful to develop a Tcl-to-JavaScript compiler instead
of a browser plugin...

~~~
blacksqr
You mean like EmTcl?

[http://aidanhs.github.io/emtcl/](http://aidanhs.github.io/emtcl/)

~~~
eleh
Interresting project :). Every project in this direction is thriving and fun,
no doubt. I am happy to see these developments, hopefully they go on!

The browser plugin on the other side is mature and fits in where EmTcl, NaTcl
etc. leave off: when it comes to use the _full_ feature set of Tcl and its
huge extension library, including Tk windows, in the browser and in production
code. Intranet web applications maybe, e.g for the use cases I mentioned
above. Therefore it still has its niche, I think.

But maybe it will be possible to do things like sockets on arbitrary ports
with arbitrary protocols, or driving external hardware, with EmTcl in the
future? That would be great :-)!

