The article doesn't discuss how Sun turned away from Tcl and embraced Java instead (understandable since it focuses on Tcl).
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.
I was the VP of Engineering of Ousterhout's spinout company, Scriptics, and worked for him. I don't know the story of how Sun made the decision but John has a longer History of Tcl here: https://web.stanford.edu/~ouster/cgi-bin/tclHistory.php
"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.
I got exposed to TCL/TK while working for a National Lab a long time ago. At the time I was a hardcore C++ developer and after a week or two with TCL/Tk I was almost dying laughing about how easy it was to build really cool applications. I truly miss working with that platform.
Argonne National leaned heavily on Tcl relatively recently for a petascale super-computer project of theirs[0] (I was introduced to it by Justin Wozniak of Argonne at a Tcl conference in Manassas).
In his google talk on the philosophy of software design, he said that the hires who worked out best for him were the ones where he just really enjoyed the conversations with them during the interviews [1]
There's definitely a reality split between developers who accept early in their careers that they need to learn SQL and regular expressions and developers who cling to the hope that if they hold on just a few more years they won't be important skills any more.
I was at Sun Labs at that time - Ousterhout's group was internally regarded as one of the top groups there. I was in a different group.
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.
In the 90's Java did have technical merit because the Tcl of that era didn't have a bytecode interpreter. It wouldn't have been practical for the sort of low level embedded devices Sun was aiming to support with Java processors. The resources needed for dynamism is also a handicap for such platforms.
I only watched this from the outside, but my impression was that it was an overreaction. Sun had a nice research operating system based on Java called SpringOS, but when clients heard about that they revolted. The transition from SunOS to Solaris had been traumatic and they threatened to jump ship if there would be any more changes ahead.
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.
They didn't do it in a smart way. Part of the Self group joined forces with some other researchers to create a company called Animorphic which would build the world's "fastest Smalltalk" using the Self technology. It was called StrongTalk and had other interesting features like optional type declaration and extensive use of traits and mixins.
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.
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:
>[...] 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. [...]
Interesting to read how Expect came so soon out of TCL (TCL: 1988, Expect: 1990)
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.
Aw man I love Expect. We have a bunch of legacy stuff and Tcl/Expect powers most of it. Every few years people try to replace it with python and pexpect, there was a nodejs implementation, and perl. They sorta worked, but anytime you had to something more complicated than a single session or simple parsing they fell apart.
now I have it wrapped in a starpack and just dont tell them the language unless they ask lol
Expect has had remarkable longevity, though I'd say the greatest impact of Tcl has been though *sqlite* which started as a Tcl extension and still uses Tcl in its development. Sqlite is used so very widely, hard to find any major software that doesn't incorporate it. I guess Tcl is nearly everywhere, under the hood anyway.
Furthermore, I've been wanting to give our embedded app's CLI some smarts, add some control-flow features, and I can think of no better way to do implement that than make it a TCL shell.
I think expect is a result of having no programatic interface for command line tools. I ofter wonder how much more useful these command line tools, and how many hundreds of man years would have been saved with buggy text parsers, if there was a programatic stdin/stdout, in addition to the one for humans, from the beginning.
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.
I like Tcl a lot. The design is simple, extremely easy to learn, and yet the code is still maintainable (((looking at you LISP))). Among the scripting languages I've used, I probably liked Tcl the most. I wish it didn't fall out of favor.
Same here! Tcl/tk is a lovely little language and much under appreciated by many! Interesting software started in tcl, such as redis, expect and sqlite. Still use some tcl through environment-modules, in my personal work setup.
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.
I think a lot of programmers as they are first learning their first language go through a phase of trying to count brackets and parentheses and failing miserably (those bugs are horrible to hunt down) before finding editors that help match them for you. Even then, many editors don't do a great job of this so coders develop a certain aversion to using many parentheses or brackets of any type. This is also rooted in the conventional C philosophies that more than two levels of indentation are a bad thing.
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.
In my very humble opinion, the parens in lisps are one of the most redeeming qualities as it makes IDE manipulation so much easier and macros are much easier to write. I did enjoy Ruby a lot too though, and you can definitely see some of the clean-syntax similarities.
I was a big Tcl user between 1999 and 2002, our startup was an heavy user, however the experience of slowly replacing Tcl with C code, made me never choose languages without either JIT or AOT compiler ever again, other than for scripting tasks.
I've been evaluating different languages for writing plugins and TCL really seems tempting. Unfortunately, I've been leaning towards Lua just due to its pervasiveness (today). I also vaguely remember one of the top contenders having some more esoteric parts that concerned me. I can't remember how much of that was TCL, Lua, or both.
Indeed as sibling comment mentions there are Tcl fans out there. The guy who created redis has good things to say[0]. With a little evangelism it could maybe stage a comeback.
Fellow tcl lover here. When I left my tcl job I felt like I was approaching some next level of productivity that I've never quite found with other languages
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.
I adore Tcl, and always have. Funny that you mention Lisp, because I've always considered Tcl a kind of "close cousin" of Lisp; both in it's code structure and the ability to build new control structures and the like. It feels more Lisp-y to me than it does C-y.
My only lisp experience was trying to teach myself AutoLISP in notepad in the mid 90s - I remember the parentheses trauma well. This was before I knew any CS or what a functional language was.
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 used Tcl extensively over many years. It's a tremendously flexible tool that can be shaped to accomplish many tasks. Tcl was never the most widely used scripting language but it's alive and well, and its development continues with new versions on the horizon. There still is a lot to like about Tcl.
Off-topic, but you should be aware that the (((triple parentheses))) are apparently an anti-semitic thing. Just so you know it can be misinterpreted in some contexts x)
When anti-semites or alt-right people or other hate groups decide to adopt an arbitrary, commonly used sign (like, the "ok" symbol [1]), is the correct reaction to stop using that sign, basically giving it to them, or is the correct reaction to use it as much as possible in non-racist/x-ist contexts, to dilute the intended co-option? Honestly I don't really know the answer. I completely understand avoiding it to not have your comment or action taken out of context, as the risk of personal damage is high, but on the other hand I don't feel that society should just "give away" common symbology just because some hate group decides to take it. How can this be fought?
I am curious as to what most westerners react when they see a Hindu swastika? Is it common knowledge that there's a Hindu/Buddhist swastika or is it percieved as Nazi swastika?
It was a Native American symbol also. It was on the insignia of the 45th Division, a National Guard unit from the American southwest; but as WW II approached, it was swapped for a thunderbird.
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?
You probably already are aware of it but there's an effort to create an open source successor to Rebol. See the Red Programming Language site [0].
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.
I know about Red. Unfortunately it requires 32-bit libraries, whereas Rebol 3 does not. I could not get Red to work as easily and nicely as I did get Rebol 3. :/
> 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.
Thanks, didn't know about the Rebol3 version in the link. I'll have to look into it. AFAIK the Red developers goal is to extend the Rebol philosophy to a modern, open source tool that can serve a number of high and low level purposes. Red is coming along but slowly. Not surprising given the lofty ambitions of the project. I too hope they succeed.
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.
Yup. I have no experience AT ALL with Amiga OS. I really love Rebol though. Perhaps I would love Amiga OS as well. I should read up on it. Any interesting writings on its philosophy and whatnot? Similar to what could be found about Plan 9, for example.
Rebol is seriously cool and criminally overlooked on HN. Unlike TCL, it didn't survive to the same extent. There is the whole Red effort (very cool), but I'm not sure if they'll get there. I wish them the best of luck though.
Yeah, so do I. I mentioned in my other comment that I do not use it because of lack of 64-bit support and whatnot. If they do get there, and I could replace my Rebol 3 programs with Red, then I will switch to it. As for Rebol 3, I use https://github.com/Oldes/Rebol3.
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.
So I just dived in to the Rebol cookbook myself, and I came across Rebol 3 implementations of some of the goodies from there that are originally written in Rebol. For example I stumbled upon https://zolk3ri.name/cgit/rebol-cr-auth/ and https://gist.github.com/gchiu/5288312. They are both quite cool. It truly does make me love Rebol even more!
Tcl is insane. The language is straight out of The Book (Anathem). By that I mean, the semantics are not just wrong, they're so wrong they risk warping your brain. But the language somehow remains useful, powerful, and flexible. And there is still no faster way to get from zero to working GUI in the 2020s on a conventional computing environment (Windows or some Unix). So it's fantastic for prototyping at the very least.
1) I realize that Tcl isn't technically stringly typed on the inside anymore, but extensionally it still appears so.
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 just guess there are two kinds of people in the world. I think scope leakage across logical boundaries is dangerous and really hurts maintainability and code readability, and I think Tcl's tight restriction of variable scope by default is one of its most valuable properties.
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?
I don't think that downward capture of bindings from an enclosing scope counts as "leakage" and I've never seen it lead to the maintainability issues you describe. In Perl and JavaScript, under certain conditions variable scope can leak upward, and that opens up its own can of fresh hell.
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.
I was thinking exactly in the eldritch horror direction. Thanks for writing that, you have saved me the unpleasantness of finding out exactly what it was that made me loathe Tcl.
Having used Tcl extensively I think scoping rules aren't really too complicated, but there are some apparent inconsistencies. A main one is global variables aren't visible inside procedures unless declared as "global", whereas procedures are global no matter where created (in the global namespace). However referring to variables and procedures using fully qualified namespaces is always correct and unambiguous.
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.
Ah, so Tcl's rules are dynamic scoping with extra steps. No wonder they're so mind-boggling.
Lexical scoping is the most straightforward, least surprising scoping strategy I've seen. With lexical closures it allows for some tremendously powerful constructs.
True, lexical scoping is dominant in current programming languages and it is easier to reason about.
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'
If it was truly dynamic (or more correctly indefinite) scope, we'd see '2' printed because 'b' would be readable in procedure w, but instead we get an error. However if inside the procs '::b' was used instead of 'b', then 2 is printed consistent with dynamic scope. ('::b' is 'b' in the global namespace.)
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...
25 years ago, I worked on a team that built a full online retail brokerage in Tcl (including web page generation). It made me love the language as a developer, but the runtime performance on late 1990s hardware (especially pre-Tcl8) was pretty poor.
I've since reached for Tcl several times per year and enjoy it each time.
My first industry job was almost on Aolserver: https://github.com/aolserver/aolserver#readme but I didn't have the discipline at the time to make it through the tech screen. In retrospect, I dodged a bullet, but I'm still glad I tried it cause it was for sure horizon-broadening
I really like Tcl the language and some of the tooling, but certainly not all of it.
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.
TCL has a feature which to me qualifies as a total "What the hell were they thinking?", not unlike the COME FROM command from Brainfuck, except, in a real language.
That statement is upvar [1]. Read its description and despair.
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.)
As a fan of immutability (edit: I suppose I should say rather referential transparency is more relevant here), that horrifies me, but at the same time I have to commend the ingenuity.
A lot of semiconductor EDA / CAD tools use Tcl as the built in scripting language. Our CAD flows are thousands of lines of Tcl code that are both wrappers around the tools and scripts for the tools to execute that set options and run various commands generate reports
OpenCASCADE, the C++ CAD library used by FreeCAD and others, has official bindings available in Tcl. (Bindings, for example, in Python, are available from 3rd parties.)
> The Tcl Conference is also one of the world's premier events for upper body wear: each year there are 5-10 different T-shirt designs given away to recognize various extensions, events, etc.
That's funny. Is there a gallery collecting these?
I collected many of the T-shirts and other items. I published a list w/ photos, including a few photos others sent me. All done in glorious bare-bones 1990's HTML, photos taken on 35mm and scanned with a cheap scanner.
It may be something of a specialised tool now, but in the 90s it’s hard to express how far ahead of the curve the TCL ecosystem was from anyone else. I remember people looking offended at how fast you could slap together a UI compared to the C/C++ nonsense they were used to. Expect redefined the game for all sorts of scripting.
I'm a long time user of Tcl. For me, the biggest strength of Tcl is it's C API. It's quite straightforward to implement extensions. That, and the people that were involved in the language early on are incredibly smart and creative.
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!
My first job was writing Tcl code to orchestrate various little c++ apps that were used for data processing to create various terrains for a flight sim training app. Love the language. But that was a long time ago.
I love Tcl. I haven't used it in a while as my job scope has changed. I used to write all sort of utilities and throw a little UI on top with Tk. I still keep watch on what happens in that space.
Anyone know if there is a good visual IDE for TK (like VB6 style)? I researched it a long time ago and they were all glitchy and problematic (considering the numerous TK options and managers). I still develop little applets in the console every few years but its a pain in the ass when you do it so rarely since you forget everything you learned the last time.
If I remember correctly, Tcl was the first language I coded in. That was in late 90s, I asked my dad to pay some hosting company so I could have IRC bots. I don't think I ever understood how thinhs really worked, but I remember I was able to type "commands" in IRC channels and my bots would do stuff, like send private messages, join channels, etc.
I wonder in what context the language comes up for others. I remember having to use it to accomplish something maybe once over the last 25 years(?) and it was so long ago I don’t even remember what it was.
It pops up in a bunch of different areas. If you used the Orbix Corba ORB, it was there. It's the scripting language for F5 load balancers. A one-time popular monitoring tool called NetCool/Omnibus used it for script extensions. It's also in a few different Electronics Design Automation (EDA) tools. It was also in a few different tools that dealth with Healthcare-specific IT, like HL7 protocol bridging. Just the ones I ran into. Prior to lua it was really the only dead-easy way to link a known, mainstream-ish, scripting language into an existing tool.
We're using it now (2022) to run some high volume transaction websites.
We are not writing new apps in it, but a lot of existing code still uses it,
and is actively modified.
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.