The Birth of Tcl
tcl.tk
tcl.tk
It's interesting because Sun had the same goals for Tcl as they did for Java (or vice-versa!): "evolve Tcl into a universal scripting language for the Internet", "allows untrusted scripts to be evaluated safely", "Tcl plugin, so that Tcl scripts can be evaluated in a Web browser".
Ousterhout spun Tcl out of Sun in late 1997, which feels like the timeline when Sun was turning to Java.
Is there insider history available anywhere on how and why that transition happened? I can certainly imagine that performance and expressivity were a concern.
"At the same time, it became clear that Sun needed to focus its language evangelism around Java, which was released shortly after I arrived at Sun and had become hugely popular. Though Java and Tcl are very different languages, used for very different purposes, it would have been too hard for Sun to evangelize both of them simultaneously. I came to the conclusion that, overall, Java offered more benefits for Sun than Tcl did."
John was a great person to work for. He hired me despite the fact that in the interview with him I told him I'd never used Tcl and when he extolled its virtues he told me that it was "easy to learn and had powerful regular expressions" and I said "Don't those two things contradict each other?" He stopped talking and had a rather surprised expression on his face. I thought I'd blown it. Actually, I'd done the most important thing I could possibly have done: made him think something new.
[0] https://www.mcs.anl.gov/~wozniak/papers/Swift_Tcl_2015.pdf
My recollection is that the concerns were not around technical merit: a. Tcl and Java were positioned as competitors, b. Sun saw Java as a critical weapon in its fight against Microsoft, c. Java won the internal battle, which led to Tcl/Scriptics spin out.
Sun's reaction was to adopt "only Sparc, only Solaris, only Java forever and ever" as their roadmap, publicly killing SpringOS, Tcl, Self (programming language) and so on. That did make the clients happy.
Given the buzz around Java they did a quick demo showing that language running on top of their technology, and in 1997 Sun bought them to use that HotSpot technology in their main Java implementation. So they paid a lot for what they previously already had but ignored.
https://news.ycombinator.com/item?id=12025218
https://vanderburg.org/old_pages/Tcl/war/
https://news.ycombinator.com/item?id=17060181
pwg on May 13, 2018 | parent | context | favorite | on: Extending Tcl
Why you should not use Tcl
DonHopkins on May 14, 2018 [–]
And with that diplomatically worded message, RMS kicked of The Infamous TCL War.
That was Stallman's response to Sun bombastically pushing TCL as the official scripting language of the web, BEFORE Live Oak / Java was a widely known (or evangelized) thing.
At the point anybody started talking about a Java/TCL bridge, it was already all over for TCL becoming the "ubiquitous scripting language of the Internet".
Sun's unilateral anointment of TCL as the official Internet scripting language trigged RMS's "Why you should not use Tcl" message, which triggered the TCL War, which triggered Sun to switch to Java.
After the TCL war finally subsided, Sun quietly pushed TCL aside and loudly evangelize Java instead. The TCL community was quite flustered and disappointed after first winning the title "ubiquitous scripting language of the Internet" and then having the title yanked away and given to Java.
Any talk of bridges were just table scraps for TCL, the redheaded bastard stepchild sitting outside on the back porch in the rain, smoking a cigarette and commiserating with NeWS and Self.
Tom Lord's description of what happened is insightful and accurate:
https://web.archive.org/web/20110102015130/http://basiscraft...
>The Infamous Tcl War
>[...] Mr. Ousterhout had, a few years prior, developed Tcl while on the faculty of UC Berkeley - mainly, I think, to have a handy tool for other research and only secondarily as an experiment in language design. And he topped it off with Tk. Tcl/Tk took off in a huge way. It was easy to understand. The source code, written in Mr. Ousterhout's methodical and lucid style, was a joy to read. At the time, about the most convenient option for developing a GUI to run on a unix system was to write C code against the Motif toolkit - an ugly, expensive, and frequently disappointing process. With Tcl/Tk in hand, people started handing out new "mini-GUIs" for this and that, like candy. Tcl/Tk started to find application in some rather intense areas, like, for example, the "control station" software for some oil rigs. It was a smash hit.
>Meanwhile, I don't think I'm letting too many cats out of the bag here, the informal Silicon Valley social network of well placed hackers were quietly and unofficially circulating some very interesting confidential whitepapers from Sun Microsystems. One of their researchers, a fellow called Mr. Gosling, had dusted off a language he'd once led the design of called "Oak". Oak was originally intended for use in embedded systems. Its basic premise was that devices ought to be Turing complete and hackable, whenever possible. Oak's approach to statically verifiable byte-code comes from that origin. Mr. Gosling came out of Carnegie Mellon University and the attiude behind Oak was popular there. As one grad student had quipped a few years earlier: "If a light switch isn't Turing Complete I don't even want to touch it."
>In light of the rising star of web browsers, the folks at Sun conceived the notion of offering up a derivative of Oak to serve as the extension language for browsers. (It is probably worth mentioning here that Mr. Gosling was earlier well known for making one of the very first unix versions of Emacs.) Oak was re-named "Java" and the rest of its history is fairly well known.
>I've read, since then, that up to around that point Brendan Eich had been working on a Scheme-based extension language for Netscape Navigator. Such was the power of the hegemony of the high level folks at Sun that the word came down on Mr. Eich: "Get it done. And make it look like Java." Staying true to his sense of Self, he quickly knocked out the first implementation of Mocha, later renamed Javascript. This phenomenon of Sun's hegemony influencing other firms turns out to be a small pattern, as you'll see.
>Mr. Ousterhout was hired by Sun (later he would spin off a Tcl-centric start-up). The R&D; team there developed a vision:
>Java would be the heavy-lifting extension language for browsers. The earliest notions of the "browser as platform" and "browser as Microsoft-killer" date back to this time. Tcl, Sun announced, was to become the "ubiquitous scripting language of the Internet". Yes, they really pimped that vision for a while. And it was "the buzz" in the Valley. It was that pronouncement from the then-intimidating Sun that led to the Tcl wars.
>Mr. Eich, bless his soul, brute-forced passed them, abandoning Scheme and inventing Javascript. [...]
I think there was internal politicking at Sun going on too, where JOs departure wasn’t necessarily “coincidentally” when Sun was turning to Java.
Expect remains an essential tool for dealing with interactive (but not TUI) terminal application, and in usage really fits its TCL roots perfectly. In contrast, I've found the Perl and Python ports of Expect to be somewhat awkward, not fitting those languages paradigms as well.
In the 2020s, I still think Expect is TCL's killer app.
But, with the reality we live in, expect helped me many times in the past. These days, I use python's pexpect for the same use cases.
now I have it wrapped in a starpack and just dont tell them the language unless they ask lol
Good thing cgit caches, eh?
On site with a customer, the question of creating a GUI interface came up. A few engineers left and, after a bit of time in another room, came back with a proposal already demo'd in tcl/tk.
[1]: https://edition.cnn.com/2019/09/26/us/adl-new-hate-symbols/i...
Kipling used a Hindu swastika on his books. He also, I believe, discontinued this with the rise of the Nazis. Don't those arms point counter-clockwise, though?
Maybe now is a good time to re-examine those assumptions and re-evaluate those priorities.
At a time when Electron is the cross platform UI toolkit of choice, Tcl/Tk seriously deserves a second look.
Have to say that lisps are very nice too, in my opinion. Started learning a little common lisp recently and was surprised by its elegance. I think lisps can be very maintainable, when care is taken. It's easy to write unreadable programs, but this also holds for tcl. With great power comes great responsibility.
At least that was how I used to see things, prior to getting familiar with Lisp and emacs. Now I find myself using all kinds of parentheses in every language so as to make order-of-operations more explicit at a quick glance. I even learned to count parentheses and almost enjoy it.
I think learning Python's complete-opposite approach of getting rid of brackets in most cases and using indentation-only also clarified my thinking on the matter. I find that this brings back the old problem of mismatched-bracket bug hunting, but worse because indentation levels can get shifted and then there's no amount of paren-matching that will help sort things out.
In essence, I think everyone should learn Python and Lisp, then see which philosophy they like better.
I did come away impressed though with how it could map to CAD concepts. It reminded me of the RPN stack when programming my HP42 calculator. I could sense there was an underlying elegance I wasn't fully grasping.
I've played around with Red and it's pretty interesting. Though rather different from Tcl. Red compiles to native code out of the box which is an advantage. Currently Red is limited to 32-bit output. When they get 64-bit working along with self-hosting compiler I think the language could become a major success.
> When they get 64-bit working along with self-hosting compiler I think the language could become a major success.
I agree. I will most likely switch to it (though I have not dig'd deeper, hopefully it follows the philosophy of Rebol). I will check if my Rebol 3 programs work with it, or without much modification. I suppose as long as it supports 64-bit, has libraries for SHA512 (`system/catalog/checksums/sha512` in Rebol 3), along with `random/secure` and `random/seed now/precise`, I suppose it should be fine.
In any case, it is a deal-breaker for me. I really want them to get 64-bit working and have a self-hosted compiler. I wish them the best.
For the people who are interested: when I say Rebol 3, I am referring to https://github.com/Oldes/Rebol3. There is a decent and detailed post on SO about these implementations and their differences. I found Oldes' one to be the most ideal.
It was very easy to get Oldes' Rebol 3 up and running. It works. There are many extensions as well. My only problem is the lack of GUI (a huge problem, to be honest, because I want to contrast it to Tcl/Tk which I love as well), or at least I have not found the way to make it work. I might be doing something wrong though, or I might be missing something. I have not had enough time to search it up and get it to work.
Anyone who knows how to get GUI to work with Oldes' Rebol 3 please, let me know, it would be much appreciated. Any recent (and decent) Rebol (or Rebol 3) may suffice, as long as it is 64-bit.
[1] I believe it to be a major reason for Rebol not being used much. We need a proper, working Rebol! One working, actively maintained implementation, not hundreds of half-assed ones. :( I really hope Red makes it.
For what it is worth, people ought to check out the Rebol cookbook. It is full of amazing stuff. So easy to implement somewhat complicated things. I am seriously wondering why it is not more popular. I would say a lot has to do with the fact that it has been open sourced too late (should have been open to begin with, IMO), and that there are too many different, but somewhat alike implementations[1]. It is confusing to a newcomer. They do not know what to use, why, and if it actually is under active development and will continue to be.
[1] https://stackoverflow.com/questions/31510930/rebol3-what-is-...
After he left Commodore he wrote Amiga Logo.
2) Attempting to understand how variable scoping works in Tcl is like attempting to stare into the maw of some eldritch horror, deeper than the earth itself by some trick of other-space, and lined with infinite rows of writhing, fang-tipped cilia. The central tenet of lexical scoping -- that bindings visible outside a set of braces should also be visible inside unless overridden with a specified inner binding, didn't occur to Ousterhout when he designed Tcl and Tcl has to deal with the implications of that. 'upvar' sometimes works, but sometimes doesn't, and in some cases you have to reason through when your code is being called and what's visible then.
I'm so old I remember many conversations among perl and JavaScript programmers talking about the bug that drove them craziest, and it always seemed to come down to unexpected scope leakage and variable name collisions. Then there would be a lot of laughing and back-slapping and calls of 'been there bro!' I just can't wrap my head around that viewpoint. Better IMO to allow scope to cross function point boundaries only at well-defined points.
I've been programming in Tcl for over 20 years and the times when use of upvar was called for have been very few. Meanwhile, how much of your code that you wrote 20 years ago still runs just fine on the latest tool stack?
Lexical scope also allows the lambda calculus to work, and with it powerful constructs like parameterized functions over values, and fine-grained restriction of variable access through lexical closures. An eager young Scheme programmer can write a module or object system for Scheme in an afternoon.
Tcl allows those things to be written, but they're a bit more involved. And you have to exercise caution, as which bindings are live when a particular Tcl script gets executed is not clear from the program text. (I believe Tcl with upvar actually has dynamic scope semantics which, yet again, can of hell.) But hey, it's a wonderful thing that Tcl admits as much metaprogramming as it does, that puts it well ahead of many popular languages.
The thing with upvar (and uplevel) is that by default upvar refers to variables in the caller of the current proc. But when a proc is called indirectly (e.g., a callback proc) then the variable upvar is intended to reference may be 2 or more frames above. Using something like "upvar #2 refvar var" works as expected. It's analogous to deferencing pointers in C when there are >1 levels of indirection.
Is there any programming language that doesn't have some confusing rules? If a language is going to be useful the answer is bound to be "no". It's a curious how we get used to a particular (or even peculiar) syntax. When used long enough it begins to feel "natural" and obvious, and find it amazing how anyone would have difficulty understanding how it works.
Lexical scoping is the most straightforward, least surprising scoping strategy I've seen. With lexical closures it allows for some tremendously powerful constructs.
Alas Tcl is more complicated. It's sort of dynamic but not quite depending on how variables are accessed. For one thing a proc definition provides a separate scope from the global variable scope. If we define:
set b 5 ;# global
proc w {a} {
# upvar 1 b b
+ $a $b ;# "can't read 'b': no such variable"
}
proc x {} {
set b 2 ;# local
w 0
}
x ;# error re: no such variable 'b'
Of course the call to w in x doesn't operate under lexical scope since procedures are global and can't access variables inside another procedure's scope.
It is possible under some conditions to mimic lexical scope using the upvar command. In the case of proc w, uncommenting the upvar call would reference var b in the calling proc (or stack frame).
Wow, written out that is kinda "mind-boggling"! But in practice it's not a problem keeping it straight, at least most of the time...
puts "for real" ;# orly?
and there's some weird business about backslashes in comment characters, which IIRC "modern" tcl-ists use for ployglot launch scripts
#!/bin/sh
# this hides *both* lines from tclsh \
exec "tclsh" "$0" "$@"
puts "and now, moar tcl"I don't use end of line comments myself so that never bugged me.
I've since reached for Tcl several times per year and enjoy it each time.
I kind of wish there was a single reputable website that I could go to for all versions. I don't want something from Source Forge or ActiveState or some random person's website. I'm sure they're all fine, but I'm a lot less sketched out with running Anaconda Python or Java than Tcl. Funny enough, some Python systems include Tcl for the Tk GUI, but I haven't been able to get some of the libraries I'm interested in to work with that version.
That statement is upvar [1]. Read its description and despair.
upvar and uplevel seem scary/strange when you read about them, but once you start using them in code, they feel perfectly suited for the task.
Think of it as similar to "passing value by reference", for example when you pass the address of a variable in C/C++.
I once did a web search to see whether there was an equivalent in PHP. I found a thread in at PHP forum, which told a poster that he was a bad person for wanting such a thing. (This was a long time ago, so perhaps I exaggerate. But they did say that PHP was just fine without it.)
That's funny. Is there a gallery collecting these?
I had the good fortune of working with Michael McLennan and George Howlett for a while (both mentioned in the referenced history).
Michael's "Effective Tcl/Tk Programming" is a fantastically written programming reference. He was a prolific creator of interesting applications and toolkits. I recall him creating a GUI for our boring corporate bug database where he added a points system to make fixing bugs "more fun".
George managed to avoid incrementing the version number on his BLT toolkit by appending letters of the alphabet to releases. I never did learn why. I just checked and I see he made it all the way to 2.4z!
And the hosting provider was called Dungeons something.. Very dodgy looking website, dad needed a little convincing to give them his CC info