
Who Says Tcl Rules? - blacksqr
https://wiki.tcl-lang.org/page/Who+says+Tcl+rules...?V=56
======
yesenadam
A few years ago I installed XCode on my Mac, started learning it (looked 1000x
more complicated than my previous IDE.."Hello world" auto-creates dozens of
files and folders..) and read hundreds of pages of docs, started learning
Objective-C, to try to draw pixels on the screen. Found out that was
impossible! Ok, so basic graphics. Shapes.. I never bothered doing much at
all. Too much hassle.

Discovered Tcl/Tk a lil while later. They were already on my Mac. With a half-
dozen-line program in 1 minute I'd made a window on my screen with text.
Graphics not much harder. I couldn't believe I'd gone through all that! haha.
Had no idea GUIs could be so simple to write on a Mac. Noone told me. I wrote
a couple of games in a few days. Tcl is a kinda weird language, unique, but
very easy to get the hang of and be very productive in, a joy. I loved it.

~~~
bachmeier
This is all true. Tk is a great way to make a GUI on Mac or Windows. Linux,
not so much, as it's so ugly and outdated that it's basically unusable. Maybe
things have changed in recent years, but a 1995-style GUI just doesn't cut it.

~~~
bluedays
The tk framework has had some improvements in 8.5 when ttk was added that
modernize the framework. You can make really attractive Windows now with ttk
on Linux now that wasn’t possible before.

~~~
acqq
Exactly, Tk looks good on all platforms at latest since 8.5 and the new
engine. The relevant tutorial:

[https://tkdocs.com/tutorial/intro.html](https://tkdocs.com/tutorial/intro.html)

Which exists since 2008.

Here's the minimal example for Tcl, Perl, Python and Ruby (note -- Tk doesn't
have to be used only in Tcl!) with the pictures of the native looking
interfaces on Mac OS X, Windows and Linux (all three):

[https://tkdocs.com/tutorial/firstexample.html](https://tkdocs.com/tutorial/firstexample.html)

------
Zenst
TCL was/is a wonderful glue language and by that I mean it is great for
connecting diverse things together. Company I worked at in the late 90's, used
to to control a few hundred modems hanging some RS/6000's taking customer
terminal orders. This was all handled by TCL and even had a lovely X11 control
interface thanks to TK. These then got sent upto the mainfrom for processing.
Was also used to provide an assured file transfer to an AS/400 over FTP. At
the time you had shell, peal, or was looking at C and the likes of java still
being defined and in need of optimisation (saw some nice stuff in java, but
would need 10x resources to run compared to alternatives, moore's law helped
that within a few years afterwards).

But it was robust and great at interacting with whatever you wanted and
enabling you to do it in a controlled way.

It reminds me how it is perceived in much the same way AWK was and still is,
it's a hidden gem that many never bothered with but if you spend a bit of time
to learn it, you start to think, why didn't I look into this more earlier.

Though python has in so many ways, usurped it and indeed AWK for their niche
uses, they still have their places.

[EDIT X11, not Z11 typo]

~~~
AlexMax
> Though python has in so many ways, usurped it

Funny you should mention that. Python's standard GUI system is still based on
tk, and from a quick look at the docs you can even run a tcl script from
inside Python.

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

------
silasdb
Tcl cross-platform feature is astonishing. With Androwish [1] it steps even
further.

I have a bunch of private tools for personal organization (time tracker, todo
list, notepad-like app) that I've written in Tcl. Over the years, I used
Android smartphones more and more and I just wanted all those small apps for
Android too, but never had time to learn mobile development.

With Androwish I can just run them in my Android almost unmodified! And I can
also make use of Android features like notifications. I sync the files between
devices with Syncthing [2] or another tool and, voilà! I can use the same apps
in both Android and Unix!

[1] [http://androwish.org/](http://androwish.org/)

[2] [https://syncthing.net/](https://syncthing.net/)

EDIT: syntax

~~~
blacksqr
Some of us would love it if you would share your apps!

~~~
silasdb
They started as quick-and-dirty apps because I didn't find anything that
suited my needs so I decided to write my own. They are still quick-and-dirty
(and ugly) but I intend to publish them next months after I clean the code up.
Maybe I show them in "Show HN" :-)

I still need to discover how I overcome some Androwish limitations. Tk is
great but the integration with the system (like copy-n-paste) is still
something I need to discover how to deal with.

------
kragen
The best hagiography of St. Tcl is by Yosef Kreinin:
[https://yosefk.com/blog/i-cant-believe-im-praising-
tcl.html](https://yosefk.com/blog/i-cant-believe-im-praising-tcl.html)

I wowed some students in my operations research class a couple of months ago
by writing a few lines of code in the Python interpreter and popping up a
window with a button in it with Tkinter. "You keep doing magic!"

~~~
braythwayt
I recall Philip Greenspun’s (of the “tenth rule” fame) book about web
development. In it, he explained how he was G$D with TCL and AOLServer while
others around him were still arguing about how high to pile the Java towers of
abstraction.

[http://philip.greenspun.com/panda/](http://philip.greenspun.com/panda/)

~~~
yesenadam
That link is to _Philip and Alex 's Guide to Web Publishing_. I'd looked at a
_lot_ of pages on that site before a while ago, but didn't read that book,
thinking maybe it's out of date and not worth reading. Boy I was wrong, it's
gold.

Looking at it just now, I couldn't help thinking his style of illustrating
with photos was an influence on your own books?! I guess so. (I've only read
the 2 coffee-themed JS books, which I _really_ loved. Thank you! p.s. The most
sophisticated JS program I wrote was "JavaScript REPL with allong.es" hehe.)

------
digitalsushi
I think it is a testament to just how far good design choices can outweigh the
decision of which language. Two lifetimes ago, I worked at a company that
sells testing software for CPE devices (consumer grade routers, et cetera).
The entire core of that product is written in pure TCL - a fully tunable TCP
stack with a knob for adjusting every metric, and a fully state driven
architecture composed of TCL primitives that can emulate an entire ISP and a
corporate LAN. There are so many languages that would be obvious better
choices, but part of what allows a legacy of sledge hammered test cases to
evolve is respecting the garden they are grown in - generally when you
transplant a tree, you're going to kill it. Instead, a careful analysis of the
existing implementation has allowed that product to continue, and grow, for
many, many years.

~~~
bch
> good design choices can outweigh the decision of which language

It sounds like you’re saying the project succeeded by good design despite Tcl
(fair - I don’t know your project), but I’d argue Tcl itself _is_ a fine
example of good design. With a small amount of study you’ll be able to
effectively reason about it. It’s extremely regular, composable, and
interfaces well be it text manipulation, networking, filesystems, GUIs, ...,
or indeed, itself - it’s well-established and takes compatibility seriously. I
think I’m into it nigh 15 years, and it’s still a proper first-goto tool for
me.

~~~
tyingq
It has evolved some. Initially, TCL used C strings, and there was no way at
all to use any binary data with a null in it. No copying binary files, no non-
trival sockets work, etc. And lists being runtime parsed strings of "{blah
{blah}} {\\{blah}" remains slow and cumbersome. In the 90's, I switched to
Perl to get past some of these things.

Don't get me wrong, I love it too, but it has warts just like any other
language.

Ousterhout is clearly an outlier thinker though. Not just the father of TCL
and TK but log structured filesystems, RAFT consensus, and more. I'd be
excited if he jumped back into a new language project based on his reflective
experience. I imagine a more pragmatic Perl 6 or similar.

~~~
bch
You’re right re: it’s early internals, and we probably both know people who
still (mistakenly) complain about that. _Conceptually_ the “everything is a
string”(EIAS) model still holds though, even though it’s supported by dual-
ported “objects” w native representation, and the running is often byte-
compiled instead of string parsing. We’ve got early smart fans who saw the
vision and possibilities like Karl Lehenbauer, Don Libes, Richard Hipp, and
the current core team like Kevin Kenny, Don Porter, Donal Fellows, etc who
deeply understand What Tcl Is, and strictly maintain it, even while pushing it
ahead (TclObj, finally an in-core blessed object system, native database
framework, Miguel Sopher’s(RIP) work on the stackless non-recursive engine
(NRE) and coroutines that fell out of that work...

Back to Ousterhout though, you might dig his “Philosophy of Software
Design”[0] book, or talks associated with it[1].

Lots to like in this space...

[0] [https://www.amazon.com/Philosophy-Software-Design-John-
Ouste...](https://www.amazon.com/Philosophy-Software-Design-John-
Ousterhout/dp/1732102201)

[1] [https://youtu.be/bmSAYlu0NcY](https://youtu.be/bmSAYlu0NcY)

~~~
tyingq
Just bought the book. Thanks for replying with some valuable insights!

------
mhd
I think it's interesting to look at Tcl's pedigree and compare it with Perl.
Both definitely have a strong Unix heritage. Perl's initial use case was
scripting where you went beyond both awk and the shell, and regarding syntax
stuck to the former. The target audience certainly was supposed to know a bit
about programming, but shouldn't

Tcl on the other hand is more shell-like in its core syntax, trying to
simplify that. Not really because it's supposed to supplant shell scripts, but
because it has a similar target audience, people looking to automate things
(or customize them).

At least that's the beginning, and if it would've stayed that way, nobody
would lament either language's passing, as they'd be good in their niche. To
truly fall, one must rise first. Perl did that with early web programming
(CGI), Tcl with UI programming.

I like both a lot. I've had a lot of fun programming with Tcl, and it was
interesting how your workflow changes if a UI is really, really close to hand
(sorry, TKinter doesn't come close to me, the only other language I'd nominate
for that would be Rebol). Programming with BASIC I always asked for input,
programming with Perl/Python I always pass command line parameters, with Tcl I
often popped up small Windows.

~~~
smacktoward
There was a period in the early-Web days when Tcl looked like a serious
contender to take the lead in Web programming too, thanks to its use as the
main scripting language in the influential AOLServer (see
[https://en.wikipedia.org/wiki/AOLserver](https://en.wikipedia.org/wiki/AOLserver)).

Of course that didn't end up happening, but it's interesting to think about
what might have been different if it had.

~~~
bch
It was also embedded in browsers[0]. It “could have been javascript”.

Sort of a bitter-sweet scenario - I think some were excited that Tcl could
have been out there more, in people’s face, but others think Tcl dodged a
bullet, as mass adoption would have laid a tough burden of backward
compatibility and a bit of ossification that the core team is happy to not
have mandated on them.

[0]
[https://books.google.ca/books?id=GQIMAgAAQBAJ&pg=PA4&lpg=PA4...](https://books.google.ca/books?id=GQIMAgAAQBAJ&pg=PA4&lpg=PA4&dq=%22tcl%22+web+browser+ncsa&source=bl&ots=P7j7qSO1FQ&sig=ACfU3U0mC1wybigQnPqzpl_FOByVZecLEw&hl=en&sa=X&ved=2ahUKEwi_lrbWyarnAhVaHDQIHQmYDGEQ6AEwAHoECAQQAQ#v=onepage&q=%22tcl%22%20web%20browser%20ncsa&f=false)

------
rakoo
A longer love letter from antirez (Salvatore Sanfilippo) to TCL:
[http://antirez.com/articoli/tclmisunderstood.html](http://antirez.com/articoli/tclmisunderstood.html)

------
PaulHoule
Tcl is very similar to LISP where the "list" is a delimiter-separated string
instead of the car-cdr thing.

It's a clever language but it has the kind of sloppiness that Python has for
better and for worse. In particular (in both languages) you can look up the
stack and see and influence more than most people think you should.

I've come to appreciate the module system in Javascript which is static enough
to allow tree shaking. You could not do that reliably for Tcl or Python -- you
can't even do it in Java because almost all Java code does something with
passing strings to the Classloader, even if it is just the standard library
looking things up in resource files.

Many people who like Tcl have moved on to Lua for various reasons.

------
ghettoimp
Not to be mean about it or anything, but I really dislike TCL.

Granted, you could do much worse. Unlike shell scripts you at least have
access to sensible data structures like lists, dictionaries, and so on. And
unlike shell scripts or Makefiles, you can actually handle spaces in your
data, so that's at least not horrible.

But when everything is a string, there is no type safety anywhere. So many
things that should just be compile errors blow up on you at run-time instead.
God help you if you're using code that other people are updating and silently
changing.

The syntax is also pretty annoying at times. For instance, you can use
unbalanced {} characters within comments, but not if those comments are within
a proc. You can nicely write long lists over many lines with {...}, but you
can't put comments in those.

Anyway, haters gonna hate. I hope other folks like it more than I do.

~~~
sedatk
Lack of strong-typing isn't something specific to TCL or rare at all. Python
and JavaScript are weakly typed too.

~~~
gugagore
but not everything is a string in Python and JavaScript.

It's possible your parent didn't mean literally "strong typing" or even
"static typing", but instead more generally "notions of types, whether at
runtime or before".

~~~
ghettoimp
Yes exactly. TCL is somehow even more weakly typed than conventional
dynamically typed languages. For instance, in Python, len(3) is an error, but
in TCL, llength 3 is 1.

------
Bendingo
No-one yet mentioned expect [0][1], which is the most amazing, general-purpose
automation tool I've ever used.

IMHO it's creator Don Libes [2] is an original-thinker/innovator in the same
league as Ousterhout.

[0]
[https://en.wikipedia.org/wiki/Expect](https://en.wikipedia.org/wiki/Expect)?

[1]
[https://www.tcl.tk/man/expect5.31/expect.1.html](https://www.tcl.tk/man/expect5.31/expect.1.html)?

[2]
[https://en.wikipedia.org/wiki/Don_Libes](https://en.wikipedia.org/wiki/Don_Libes)

------
bitwize
I still don't know of a faster way to go from zero to functional GUI than to
use Tcl/Tk. Not Visual Basic (too much rat wrestling). Certainly not
JavaScript with a browser, which requires either authoring considerable HTML
alongside your code, using a heavyweight framework, or both (React!). With
Tcl/Tk you just write a few lines to throw some controls up and wire them to
send appropriate commands to your back end. It's amazing.

~~~
7thaccount
Rebol's View DSL has similar power to TCL/Tk. You can write all sorts of apps
in only a few lines of code.

~~~
9214
View is not a DSL, it's a graphical engine (based on Anti-Grain Geometry in
case of Rebol and native in case of Red). What you are talking about is a
combination of View and VID (Visual Interface Dialect).

~~~
7thaccount
Sorry you're right and thanks for correcting my error.

I guess I was just trying to say Rebol/Red have something similar to TCL/Tk in
that you can trivially build powerful GUIs.

------
andoma
TCL have an interesting feature where user defined functions (or commands as
it's called) can return TCL_RETURN, TCL_BREAK, or TCL_CONTINUE (in addition to
TCL_OK and TCL_ERROR as you would expect) which directly affects control flow
in the calling functions.

~~~
nrclark
That's some crazy shit right there, thanks for telling us about it!

For those interested, here's a link that discusses it:
[https://www.tcl.tk/man/tcl8.6/TclCmd/return.htm](https://www.tcl.tk/man/tcl8.6/TclCmd/return.htm)

------
AceJohnny2
One system I work with exposes a CLI. The whole system is written in C, and
the CLI is basically just a frontend for a bunch of commands that take in [int
argc, char __argv]. It is, to misquote Greenspun 's tenth, an ad-hoc,
informally-specified, bug-ridden, slow implementation of a proper REPL.

My secret wish is to replace it with an embedded TCL REPL. TCL isn't perfect,
but it's pretty easy to interface with C, and it fits on small targets. My
main problem (aside from lack of time) is that I'd actually need a tiny
version that would fit within dozens of kilobytes of code. Closest I've found
is Jim [1], which is 100-200kB (depending on features). Compare that with Lua,
which fits under 100kB (though excluding its standard library).

[1]
[http://jim.tcl.tk/index.html/doc/www/www/index.html](http://jim.tcl.tk/index.html/doc/www/www/index.html)

~~~
kbr2000
I might have some time this summer, feel free to contact and explain ;)

~~~
AceJohnny2
I wish I could, but it's all for stupid-secret projects :(

------
yesenadam
"The programmer is free to reinvent the language, write new control
structures, and so on."

I don't remember that about Tcl.. How far can you do that? And how do you do
that? (an example would be great). Thanks.

I've been getting into Forth lately, where you can redefine absolutely
everything[0], and make your own anything, to a ridiculous degree. Not sure
what this quote means. I'll be pleasantly surprised if it's true.

[0] Well, you are stuck with the stack(s) I guess. But that's about it.

edit: Thank you all for the great answers!

~~~
davidw
Here's a starting point: [https://wiki.tcl-
lang.org/page/New+Control+Structures](https://wiki.tcl-
lang.org/page/New+Control+Structures)

~~~
blacksqr
tl;dr Tcl has an "uplevel" command that lets you execute code in the variable
scope level of the procedure that called it. The classic example is a "do"
loop, which Tcl doesn't include out of the box:

    
    
      proc do {body condition} {
        while 1 {
            uplevel $body
            if {![uplevel [list expr $condition]]} break
        }
      }
    
      set i 10
      do {puts $i ; incr i -1} {$i > 0}
    

output:

    
    
      10
      9
      8
      7
      6
      5
      4
      3
      2
      1

------
ainar-g
I wrote one of my term papers in Tcl/Tk back in the days. It was a version of
the Towers of Hanoi, IIRC. Still the best desktop UI programming experience of
my life (although arguably I haven't had a lot since then). Tcl is a very
_nice_ language for small scripts. Kind of like a LISP for mere mortals.

By the way, does anybody know if anyone ever attempted to add a kind of static
typing to Tcl? It would be very interesting to see how a stringly-typed
language would go about that.

------
topspin
So someone cited my HN comment[1] about Tcl from yesterday on this page.
That's fine. I recall one issue I had with Tcl was lack of support for
monotonic clocks (on Linux anyhow.) So a sleep might take a long time to
expire if the system time changed to the past. I wonder if that ever got
addressed.

[1]
[https://news.ycombinator.com/reply?id=22174228](https://news.ycombinator.com/reply?id=22174228)

~~~
rkeene2
TIP 302 has been open to fix this in Tcl 8.7+, and there is atleast one
implementation of the fix.

I looked at addressing TIP 302, but it was complicated since Tcl virtualizes
the clock (like it does the filesystem).

------
nicbarth
Aha Tcl/Tk makes writing desktop apps fun! In my system admin days I used it
for little UI's to interface with my bash scripts. Running scripts or little
visualization tools on remote servers with X forwarding was pretty nifty too!

------
stkni
My first experience of Tcl/Tk was circa 2000. The finance house I worked at
had used it to implement a real-time order management system.

Even better was the ability to attach to the running ui or server (yes we had
both), replace some of the code on-the-fly, and disconnect. Perhaps not so
amazing these days, but it was way ahead of anything else I'd seen upto that
point and pretty mind-bending for a C/C++ coder.

------
Uhhrrr
Those first quotes are attributed to "deepchip.com", but that's just the
archive of the E-mail Synopsys Users Group (ESNUG). For many years it was the
main watering hole for talking about EDA ("electronic design automation" ->
hardware design) software. Synopsys was only one of three big EDA companies,
but because there were so many tools in the chain, and they were (sometimes)
interoperable, all the different products from the different vendors would get
discussed, sometimes mercilessly.

Someone who wanted to play folk historian could probably have a lot of fun
going through the archive, assuming their eyes wouldn't glaze over at terms
like "cycle accuracy" or "serial loopback".

------
yellowapple
The only thing stopping me from using Tcl/Tk for literally every desktop
application I write is the lack of a good web view (which is unfortunately a
hard requirement for a lot of projects nowadays). If I can find (or develop) a
WebKit or WebEngine or Gecko or Servo or whatever widget for Tk that actually
works reasonably well, then I'd drop Python and Qt5 for that niche in a
heartbeat.

~~~
cmacleod4
Take a look at
[http://www.androwish.org/index.html/wiki?name=jsmpeg+SDL+Vid...](http://www.androwish.org/index.html/wiki?name=jsmpeg+SDL+Video+Driver)
for an experimental approach to displaying Tcl/Tk applications in a web
browser.

------
doublerabbit
I code perl and I code TCL. I like both.

Perl has the magic and TCL has the voodoo. Add both together you get voodoo
magic which is quite fascinating.

~~~
forinti
The thing I like the most about Tcl is Tk and Tk works nicely with Perl.

I've used Tcl in various cases in which I needed to provide the client with
and executable. Freewrap gives you a reasonably sized executable (it's a lot
better than having your end-user install Java or even Perl).

~~~
mst
Note also that while Perl's Tk.pm is based on an ancient fork of Tk, if you
use Tcl.pm + Tkx.pm then perl embeds your "real" Tcl/Tk and talks to that so
you get properly modern functionality.

This is how the tkdocs.com examples in Perl maintain parity.

------
gugagore
If I understood correctly, Tcl's metaprogramming capabilities are based on
manipulating strings and not a syntax tree (e.g. lisp). Is that a key
component of making it usable by "mere mortals"?

I think ideally I'd like both capabilities, which seems possible if you just
expose the language's parser as a function.

~~~
geoelectric
The other comment mentions it in passing, but the ability to uplevel (operate
within the scope of your caller instead of your own) means the difference
between statements and function calls is blurred.

That, along with the ability to pass code block literals, lets you redefine
the language into your own DSL with new control flow statements. You can
define a “while loop” function, for example.

Before heavy use of closures and callbacks in dynamic languages
(Array.forEach, for example) became the thing this was pretty huge, and it’s
still nicer syntax sugar than you get defining control structures with that
route.

I used TCL with Squish for Qt-based UI test automation for a couple of years.
For stuff like that where you really do want a set of domain-specific
imperatives you can string together, it was really cool to work with. Biggest
downside was you could get too fancy and find yourself alone off in the weeds
of your own DSL.

------
nobleach
My immediate answer to this question is/was, "The Samba team!". Messing around
with Samba 3 beta and OpenLDAP back in the day was the reason I bought and
read "Sams Teach Yourself TCL/Tk". I really enjoyed how easy it was to get
results. All of my GUI programming until that point had been Borland Delphi
and Visual Basic. So this felt so fresh and close to the metal. (No dragging
and dropping and having 300 lines of code being generated behind the scenes) I
have no idea when or why I stopped playing with it.

------
matt_the_bass
I used Tcl today as part of some Xilinx fpga work. Interesting to learn there
is such an ecosystem/community for tcl. I’ll look into adding TK functionality
to my Xilinx tools.

------
DictumMortuum
Working in a betting company. The most important applications are still
written in TcL.

I think it's a lovely language. If it had a debugger it'd be awesome.

~~~
blacksqr
[https://github.com/flightaware/TclProDebug](https://github.com/flightaware/TclProDebug)

~~~
DictumMortuum
Thanks! I'll definitely check it out.

------
pjmlp
I enjoyed using it back in the .com days for our own AOL Server like app
server, at the startup I was working on.

Nowadays not sure if it still has viable market.

~~~
commandlinefan
About 20 years or so ago, I was hired at a large online travel site to assist
in porting the entire codebase from a mix of TCL and C++ to (then new,
popular, exciting) Java. I had a strong background in both C++ and Java at the
time but had never even heard of TCL. When I first started looking at some of
the code, I could see why it was a natural choice for building websites: the
TCL syntax seemed to just flowed naturally into HTML. When I, as the “new Java
guy” inevitably got blamed for the shortcomings of Java against the old TCL
codebase, I was hard-pressed to defend JSP against it. I never really worked
with TCL much, but even 10 years later, long after the migration was complete,
the old hands still missed it.

~~~
davidw
It was a perfect language for the web in a lot of ways. With some other guys,
I made an Apache module that let you do PHP type scripts, back in the day:
[https://tcl.apache.org/rivet/](https://tcl.apache.org/rivet/)

For a while, I know that [https://flightaware.com/](https://flightaware.com/)
used it fairly heavily. Indeed, their careers page still shows an interest in
Tcl skills.

~~~
rwmj
Famously Ars Digita, founded by Philip Greenspun, started out using AOLserver
and Tcl to design websites. The company wrote what I suppose would now be
called a "middleware stack".

After he sold the company to Red Hat I worked there really briefly. Apparently
half the sales fell through because Tcl wasn't regarded as "enterprisey"
enough for customers (note the customers themselves would probably never write
a line of code). There was an attempt to rewrite the entire engine in Java —
it being 2002 — which limped along for a while before the project died.

But there's more! The original Tcl stack was open sourced and continues to
this day as OpenACS ([https://openacs.org/](https://openacs.org/)).

The Java rewrite also still exists
([https://svnlegacy.ow2.org/byline/](https://svnlegacy.ow2.org/byline/)) but
has been dead 15+ years, and just digging into those 7 level deep directories
rekindles a feeling of dread in me.

~~~
shanemhansen
I learned web development using openacs around 2005. I got alot of value out
of the experience.

ad_proc and online documentation was awesome.

I also had to figure many things out from first principles because
documentation was all for PHP and Apache, not aolserver and tcl.

------
7thaccount
I bought Ashok Nadkarni's TCL book recently and TCL has a lot going on in a
very small amount of code. It is seriously underrated!

------
_pmf_
My favorite piece of TCL/Tk code is the official gitk git UI that comes with
git and works on Linux and Windows; it's the single file here:
[https://github.com/git/git/blob/master/gitk-
git/gitk](https://github.com/git/git/blob/master/gitk-git/gitk)

------
ohithereyou
It's amusing to see Mike Doyle, founder of noted patent troll Eolas[0] being
cited on this page.

[0]
[https://en.m.wikipedia.org/wiki/Eolas](https://en.m.wikipedia.org/wiki/Eolas)

------
dana321
uplevel and upvar..

Kinda strange how scope is restricted to the current level.

[https://en.wikipedia.org/wiki/Tcl](https://en.wikipedia.org/wiki/Tcl)

------
tus88
If they exist, you are guaranteed to find them on HN.

------
JohnFen
I do!

TCL is perhaps my favorite scripting language of all time.

------
munk-a
This is beside the main point, but my eyes bugged out a bit seeing block-quote
style divs (or maybe code style) used to capture the author information but
not the quote itself - I suppose someone dumped this into the website from a
text file and didn't adjust it for markdown, but it is really bugging me.

------
sigzero
I love the Tcl language (it's fun). I love the Tcl community as well.

------
agumonkey
any good tcl recipe book ? I'm curious on what non trivia tcl code should be
organized

~~~
anthk
\- TCL TK 8.5 Programming Cookbook

\- TCL 8.5 Network Programming

Yes, we are in 8.6, but except OOP almost nothing changed.

~~~
agumonkey
Thanks a ton

------
typon
Tcl is single handedly responsible for billions of dollars of damage in the
EDA industry

~~~
gugagore
I wonder if you mean Tcl is bad, or that the damage is caused by Tcl being
powerful and obviating the need for version upgrades of special-purpose
software. Or something else.

~~~
seabird
Tcl itself isn't really the problem. EDA tooling is generally a dumpster fire
(queue horror stories about checking bitstream files into VCS because there's
no guarantee the compiler will ever spit the same one out again, even if
nothing changed), and Tcl is used to make patchwork fixes to glaring tooling
issues.

This is all fine and good, but when a vendor can no longer change or fix
tooling without running the risk of breaking a large customer's Tcl
abomination, the flexibility that it provided is now a problem that's dragging
everybody down with it. All of this goes without mentioning that electrical
engineers that often get saddled with this aren't very good programmers.

People are excited about SymbiFlow for a reason. The hype in spite of how
unlikely it is that it will ever match vendor tooling is a testament to the
situation.

~~~
dublin
The simple fact is that the vast majority of the people writing programs
aren't very good programmers, even if they've been trained to be. We need more
languages like Tcl and Lua that are quick and easy for beginners to pick up
and become productive with. Add easy interfaces to AWS services for back-end
programming, and a Tk-like interface that dumps out JS code for web app front-
end programming, and you'd have a real winner...

~~~
blacksqr
I'll quote another comment on this discussion:

Take a look at
[http://www.androwish.org/index.html/wiki?name=jsmpeg+SDL+Vid...](http://www.androwish.org/index.html/wiki?name=jsmpeg+SDL+Video+Driver)
for an experimental approach to displaying Tcl/Tk applications in a web
browser.

