
Tcl.js: robust, high-performance Tcl in JavaScript - blacksqr
https://github.com/cyanogilvie/Tcl.js
======
xantronix
Tcl's pretty mindbendingly cool. Don't ever let anybody convince you
otherwise. It may not do all the things on earth you'd want it to do, but by
Lady Circe the things it does offer are solid as a bank vault made of Volvos.
Asynchronous programming baked into the core since time immemorial and
possibilities of metaprogramming that would make any Lisp blush? Traits to be
admired, indeed.

~~~
amelius
See also "Tcl the Misunderstood" [1]

An interesting discussion here: [2]

[1]
[http://antirez.com/articoli/tclmisunderstood.html](http://antirez.com/articoli/tclmisunderstood.html)

[2] [http://lambda-the-ultimate.org/node/3891](http://lambda-the-
ultimate.org/node/3891)

------
aidanhs
Writing such a thing from scratch is pretty impressive - the twelve rules of
Tcl syntax are readable
([http://www.tcl.tk/man/tcl/TclCmd/Tcl.htm](http://www.tcl.tk/man/tcl/TclCmd/Tcl.htm)),
but it's up to you to figure out the edge cases!

As a different take on the same problem, I compiled Tcl to JS with Emscripten
- [http://aidanhs.github.io/emtcl/](http://aidanhs.github.io/emtcl/). I also
wrote a toy DOM library
([https://github.com/aidanhs/emtcl/blob/master/opt/dom.c](https://github.com/aidanhs/emtcl/blob/master/opt/dom.c))
which plugs into it which you can see demonstrated on the page.

One of the nice things about EmTcl is that you can include arbitrary C
extensions by also compiling them with Emscripten, which is how the DOM
library above works. As a more comprehensive demonstration, have a look at
TclDis ([http://aidanhs.github.io/tcldis/](http://aidanhs.github.io/tcldis/)).
That has Tcl, a Tcl C extension I wrote for Tcl <-> Python communication, a
Python interpreter and the Python script I wrote for performing Tcl
decompilation all in the same page! (it probably won't work well on a mobile
browser)

Emscripten truly is incredible.

~~~
fuck_dang
Do you think TCL has a future in embedded domains the same way that Lua does?
It seems to me (not that I know anything) that a lot of folks are stuck on TCL
as that thing they had to write to make Tk applications. GNOCL exists now, and
there's TCL.js here now that could bring TCL to an even larger audience.

I mean, TCL with js-extensions could be a game-changer.

~~~
Frondo
No, I don't think it would be. I spent several years writing a lot of Tcl, and
there are too many show-stopper problems in the language and community for it
to be involved in any kind of game-changer.

The language looks good on paper. It's also used widely enough to hold onto
"legacy but useful" status for a long, long, long time (think cobol or fortran
--there are still people writing new code in these languages, but only in very
narrow niches, very little general-interest code).

There's a ton of weird gotchas, though, once you start writing in it that will
drive you mad. Like the bracing rules that make sense until they don't, and
then you have to make a really careful re-read of the so-simple 12 rules:

    
    
        proc a {} {
            puts "}"
        }
    

"extra characters after close-brace" ???

The regexes are also weird. Not a week goes by I don't have to wrestle with
one of my legacy tcl scripts (getting close to replacing them all, after
enough of this weirdness).

And don't expect Tk apps to look good _anywhere_ at this point.

BUT....you get used to that stuff eventually. The real problem, though, is
that there's just no one left to actually address any of the problems in the
language. The core team is there, but they're mostly just keeping things
chugging along. Very little in the way of new ideas going around.

It has a very small and shrinking community, though, which leads to a vicious
circle of, almost no one uses it for cool new things, almost no one blogs or
writes about it in a promotional way, so there's almost no pull for new people
to start writing in Tcl. There's no "killer app" and no one doing the leg work
about it to introduce anyone new. The community keeps shrinking by attrition.

The online faces of Tcl, the main site and the wiki, have also suffered from
probably the worst bikeshedding and, for lack of a better turn of phrase, old
fogeyism I've ever seen in any kind of project. Landing on a wiki page and
finding 15 year old discussions about long-gone aspects of the language, the
place is like a ghost town. Also not going to bring in a lot of new people
that way.

Aaaaand...why does any of this matter? Because the standard library is small
and missing a lot of useful modern stuff for the generalist. It's often not
well-documented, and you won't find any example code on a blog anywhere, so
you're on your own. You're going to implement a lot of stuff that, if you'd
started your project anywhere else, someone else has already done and posted
to Github.

I think it's admirable how the handful of remaining core maintainers have
brought the language kicking and screaming into the 2010s. They're squeezing a
little more life out of the ecosystem and I commend them.

~~~
progman
> And don't expect Tk apps to look good anywhere at this point.

A JS version of Tk could be a game changer (using CSS).

~~~
Frondo
I don't think so. Tk was simple when a lot of GUI programming was complex.
That's what it brought to the table.

HTML and CSS is already simple. QML is simple and beautiful. Tk-style layout
design wouldn't bring anything to the table in 2016 that other people aren't
already doing, and doing pretty well.

~~~
luckydude
Tk doesn't have to look bad. Check this out:

[http://www.mcvoy.com/lm/bitmover/lm/gui-
config/gui.html](http://www.mcvoy.com/lm/bitmover/lm/gui-config/gui.html)

I had to stare at that to be sure which was firefox and which was tk. I agree
the defaults sort of suck but you can tweak them and make it look pretty
decent.

~~~
Frondo
If Tk was all I had, I'd probably sink the time (and it would be a _lot_ of
time) into learning how to fiddle with xrdb (for tk) and ttk's styling engine.

The lack of documentation, opaqueness, and complexity, all that stuff adds so
much challenge, just to get to "pretty decent".

There are better options in 2016, both from a visual perspective (looks good
out of the box) and a programmer-tweakable perspective (can I make changes?).

I said this elsewhere, but Tk brought something to the table a long time ago,
when GUI programming was complicated. GUI programming just isn't hard, the way
it used to be.

Hey, if you're used to it, great, I certainly don't want to take the option
away from anyone, but it's misleading to offer it as competitive in any way
with the other contemporary toolkits.

~~~
luckydude
Which toolkits? In particular, cross platform, has similar high level
functionality, looks better.

------
SFjulie1
Tcl/Tk interpreter and C libs are way more portable than js. It is actually
stupid.

If we revamped the tk default look and coded directly in tcl/tk "apps" would
more secure by default, less costly and doing the job a tad more correctly.

Instead of using UDP like stream over HTTP (webosckets) we could even use UDP
or RTP or whatever native protocol that does the job. Even TCP. We could
actually do the application without frameworks, without all these stacks, and
with far less interoperability headaches (like testing for all browsers) and
less vulnerabilities.

Not to say js is insane.

What is the competitive advantage for the web stack nowadays compared to
tcl/tk after all?

~~~
jnbiche
> What is the competitive advantage for the web stack nowadays compared to
> tcl/tk after all?

Unlike TCL/TK, web stack already installed on 99% of computers, ready to use
with no explicit installation steps other than loading a page.

That counts for a lot.

~~~
blacksqr
Regrettably, that counts for everything. I wonder what the answer would be if
"competitive" were changed to "engineering"?

~~~
scotty79
"Engineering" advantage of webstack over Tcl is that it's actually running
various, daily used apps on those 99% (or more) computers so lots of kinks
were ironed out.

~~~
SFjulie1
So you are a lemming suffering a Stockholm syndrome?

Go on. I am no lemming I will watch you with all the other unicorned lemmings
experience the explosion of the IT bubble while I can still adapt with 20 yo
technologies.

------
KasianFranks
Good to see Tcl here. I use it in depth for AI algos.

~~~
blacksqr
More information please!

~~~
KasianFranks
[http://summarai.com/summarai/](http://summarai.com/summarai/)

~~~
xantronix
Wow. So I popped in the first seven paragraphs of the text of Wizard People,
Dear Reader:

[http://www.erikkennedy.com/wizardpeopledearreaders.html](http://www.erikkennedy.com/wizardpeopledearreaders.html)

...And out popped a bloody good summary I couldn't have written better myself.
I second blacksqr's sentiment and would love to see more of the guts of this
dashing, dangerous beast of a thing you have unleashed upon this planet.

------
ilostmykeys
Tcl meets Javascript: a match made in heaven.

(Interpret as you will)

~~~
icedchai
One crappy language meets another...

~~~
sigzero
Tcl is far from crappy.

~~~
icedchai
If you say so. I can't think of any reason I'd use it these days.

------
esailija
> Pedantically correct syntax parsing (list, script and expressions), to the
> extent possible in Javascript.

What does that mean? If it's possible to write x86 that runs linux in
JavaScript, why is it not possible to write a parser?

~~~
williadc
Because Tcl allows things like this:

set foo set

$foo bar baz

~~~
sokoloff
esailija was making the point that a greater extent is _possible_ , by
emulating x86, booting Linux into it, and running full-blown tcl in that.
(It's technically correct, the best kind of correct.)

------
denniskane
I also have a sandboxed interpreter in my site... I use JS to parse strings of
shell/bash text. The site is a full-scale desktop environment in a browser:
[https://linuxontheweb.appspot.com](https://linuxontheweb.appspot.com)

It is Chrome only as it relies on access to a local filesystem, and using
Native Client plugins.

------
sdegutis
Tcl's got a pretty bad rap. But you know what? It probably deserves it.
Anyway, well done, it's nice to see things ported to JS since JS has overtaken
both math and love as the universal language.

~~~
ktRolster
If you're going to insult a language, you should at least say WHY you don't
like it.

~~~
keepitsmall
Ousterhout designed Tcl as a general replacement for the kind of small crappy
one-off interpreters he found himself adding to larger systems over and over
again. At one point he decided that enough was enough and we was going to
write an embeddable interpreter with the flavor of a simple shell like bash.

Tcl is great for simple scripting and automated testing. It's also great when
you want to represent small bits of data as code. Perspecta Presents[1], one
of Ousterhout's first commercial ventures, used Tcl scripts as the file format
for its presentations[2].

But Tcl was never intended for large programs. Ousterhout expected large
programs to be written in another language with compilers, linkers, linters
and other tools. Once a Tcl program gets past a certain size it becomes
effectively unmaintable. Tracking down a variable name typo bug in a 100,000
line Tcl program is a hell I refuse to visit again.

1- [http://wiki.tcl.tk/4191](http://wiki.tcl.tk/4191) 2-
[http://www.rpi.edu/dept/rcs/packages/ppres/1.10/common/sampl...](http://www.rpi.edu/dept/rcs/packages/ppres/1.10/common/samples/eggs.ppr)

~~~
ArkyBeagle
Tcl requires a certain level of stylistic discipline and rigor. You are not
wrong about tracking down a typo but that's a problem anywhere.

That Perspecta file is not pretty to look at.

