TCL is a fun language, which seemed to get orphaned ahead of it's time. Like FORTH a lot of the joy of using TCL comes from updating the language itself, rewriting how it works. The downside of that is that you're never sure what is "real" TCL, and what is your in-house addon.
Still TCL is a fun language to implement, and I guess a lot of people have implemented both FORTH and TCL, in addition to the more typical LISP systems.
I remember a time when it was an honestly-debated question whether it would be TCL or Scheme that would become the universally adopted extension language for all software, particularly for this new interesting technology known as the World Wide Web.
> I did some Tcl and that went fine, but I never did enough to really have an informed opinion. I know some people really hate it though.
As someone in the opposite direction, having done lots of Tcl, I love it. It is one of my favorite languages to use. I use it for simple little things on a regular basis.
To be honest, I wish Tcl had won out over Javascript. Somehow Tcl is less of a mindfuck for me (no offense intended to JS lovers, just a personal proclivity / preference).
I don’t recall exactly where I heard (perhaps #tcl on Freenode back in the day) that Tcl dodged a bullet by not becoming the standard, because it was left free to experiment without the responsibility of backward compatibility for the web…
No major browser ever shipped with a Tcl interpreter as far as I can remember. By major I mean Netscape and IE. All of them had a JavaScript interpreter. It was a battle that never happened because it couldn't be fought. Maybe there was a chance in server side software, where JavaScript has not been an option until Node.js. Java and PHP won the server post 1995 and Perl did it before them. Desktop side, the browser + HTML + JavaScript won the desktop, served from either Java or PHP or ASP, then from one of the other post 2005 stacks.
Not with the browser, but there was a TCL runtime you could download to run TCLets from web servers. I had a few contracts for that; some intranets made heavy use of it.
There is/was a plugin for client side Tcl, the Tcl/Tk Tclet Plugin, originally released during the 1990s. It filled the same role as Javascript; but never really gained popularity.
Do you sometimes feel like you're living in the darkest timeline (Community Reference) or in the Star Trek timeline where the Terran Empire reigns instead of the Federation? I joke of course, but getting JavaScript instead of Scheme just seems like a let down.
Strange New Worlds has hinted that the timeline we’re on is shifted because Khan was supposed to conquer Earth in the 90s, but now it’s the 2030s due to various temporal shenanigans.
I feel like if I were more coherent I could write an epic rant about how we are definitely in a bad timeline because of our technological choices. How we built the Internet "wrong" at so many little choices and now we have *waves arms about wildly* this nonsense, but I would be shouting into the wind, I think.
During the dot com boom days, there was a company called Vignette, that was hiring devs to work in Tcl on web app. Might have been work using AOLServer, a web server by AOL, that could be programmed in Tcl.
I remember this because I saw their job ad in a newspaper at the time.
Ex-CEO (later chairman) became a millionaire. Excerpt from above page:
[
In June 1998, Garber hired Greg Peters to succeed him as CEO, and Garber became chairman of the board.[12]
In July 1998, the company launched StoryServer 4, which featured strong support of XML technology.
By December 1998, the company raised an additional $27.5 million in venture capital.[4]
The number of the company's customers rose from 130 in 1998[5] to 700 in 2000.[3]
On February 19, 1999, during the dot-com bubble, the company became a public company via an initial public offering. On the first day of trading, the stock price rose 152%, from $19 to $47.[13]
On February 22, 1999, the company release Vignette Syndication Server.
After the IPO, in 1999, Garber, worth $200 million at the age of 33, sold most of his stock and left the company.[14]
]
I really like Tcl for scripting. It integrates better and any other language I know with the shell and making a simple quick gui that runs some cli script or command based on some (also gui) inputs is fantastic! (using Tk)
I wrote a little silver for wordle in Tcl, but that’s a funny statement because it was mostly using ripgrep calling /usr/share/dict/words but I think that’s part of it charm, it get out of the way and let use you whatever tools and integrates them beautifully!
I've never liked it. I tried it when it was getting some traction (which must have been in the 90s, I guess?), in particular because of Tk (initially I thought Tcl/Tk was the name), and I found it a horrible experience. Its "everything is a string, even this line of code" was way too hacky for me. It was too easy to make errors, and I suspect that sql injection pales in comparison to what careless string manipulation in tcl can do.
I believe that the fact that tcl integrates so well with UNIX is exactly the reason why industry doesn't like it. They want to invest in languages and technologies that can work seamlessly in commercial OSs like Windows and macOS.
No it wasn't, Bell Labs was forbidden to use it for commercial purposes.
The lawsuit against BSD and prohibition of the Lion's commentary book, came shortly after US goverment allowed AT&T to profit from UNIX.
Had UNIX been commercial from its early days, at the same price as comparable OSes of its time, most likely UNIX and C would never have taken over the server room and kernel systems programming.
30+ years later Tcl/Tk is still in active use. In space industry (maybe more on the old side of the old/new space dichotomy) it is used everyday to command and control satellites (both simulators and flatsats on ground and actual satellites in space).
Tcl, Fossil and SQLite share an interesting history. SQLite started as a Tcl extension and the SQLite maintain Dr Richard Hipp is part of the Tcl Core Team as well. Fossil started out as a version control for SQLite development by Dr Richard Hipp as well, and might have influenced the Tcl development as well.
I did (along with the help of several other people finding, building, and testing tools) the migration of Tcl from CVS to Fossil during the great Sourceforge outage. We looked at many options for migrating to such as Darcs, Git, Bzr, and Mercurial -- Larry McVoy (bitkeeper author and Tcl contributor and supporter, also on HN) offered Bitkeeper support as well. The core team liked Fossil the best at the time though -- some people do not view this as the right decision to this day.
Unfortunately. It's not too bad for interactive use (it's somewhere between Bash and Python in terms of sanity; maybe closer to Bash). The problem is people end up writing huge scripts and workflows all TCL which is just way beyond its wheelhouse. Often with a bit of Make and Bash thrown in to make it especially awful.
Sadly there is no end in sight because all of the proprietary tools use it and you can't really do anything about that.
They did add a bytecode runner in one version of TCL and I experimented with making a new language that would compile to TCL bytecode, but unfortunately one of our tools (PowerArtist I think) still bundled TCL from 2005 or so and didn't support it.
I also experimented with a WASM to TCL transpiler, and got it to work a little, but the WASM spec is actually quite big and the TCL code you get out is huge so I don't think that is the right way really.
The only good thing about TCL is that it's value based, not reference based. Value based languages are much more intuitive and easy to reason about, but unfortunately most languages are reference based.
In JavaScript, Java, C#, Dart, Python, etc. it will print 3 because a and b are references to values.
In C++, Rust and TCL, (and maybe Go? I don't remember) it will print 1 because a and b are values.
In value based languages you need explicit syntax to make references and dereference.
In reference-based languages you need explicit syntax to copy values. Often this is omitted entirely which is quite annoying. Until very recently the standard solution to copy a variable was to serialise it to JSON and back again!!
Also worth noting that for immutable values (i.e. all values in Haskell, strings in JavaScript, etc.) there's no observable difference between the two.
The two dominate EDA companies are Cadence and Synopsys. All of the digital design tools for synthesis, place and route, and static timing analysis use the Tcl language as the built in scripting language. These tools have literally thousands of built in commands.
You can look up some of the tools like Cadence Innovus that I use every day. A single license has a list price of over $1 million. We get big discounts because we have about 800 licenses.
https://www.cadence.com/en_US/home/tools/digital-design-and-...
Then you write more Tcl code to script things within the tool. A standard thing is building a power grid. You need to write a for loop to build a metal 1 stripe every 5 microns. That's done in Tcl.
You have a list of clocks you need to define with names and frequencies. Use a Tcl array and a for loop.
Our CAD flow is literally tens of thousands of lines of Tcl code to take Verilog and go through all the steps until we get a GDS file with mask data to manufacture.
The confusion here stems from an acronym collision between Exploratory Data Analysis (where R and related packages like ggplot are popular) and Electronic Design Automation.
LOL, I just thought the person I responded to was confused.
There are so many TLA (Three Letter Acronyms) that are the same across industries with completely different meanings. I was on the ECE subreddit which is for Electrical and Computer Engineering. Someone posted a rant about how annoying these children were, how the pay was bad, and the parents were awful. There were some funny comments about how some engineers acted like children and others about the new grads. Finally someone pointed out that ECE was also Early Childhood Education and pointed them to a different subreddit.
The "ecosystem" would just be, e.g. the suite of ASIC place and route tools, or FPGA synthesis tools, provided by each company. They pretty much all have TCL built in, for to help script them all together.
Each individual script is typically very ad-hoc, to address a specific shortcoming in a tool, or to get a particular mix-and-match of tools from various vendors integrated into a design pipeline.
That being said, it is an ancient and venerable tradition, dating back to the creation of tcl itself, and as long as we're making chip from Silicon it will be the duct tape holding it all together.
Not really. Most of the tcl that gets written is very straightforward and business-logic. The framework you're using is pretty much just the host tool. Trying to integrate other libraries is often difficult if the tcl runtime is missing some features (looking at you, xilinx...)
It can but that's working against the design. How you are "supposed to" do it is write reusable standalone objects in C (think the old CORBA way of doing things) and then write a TCL script as the main skeleton of your program that calls them when needed.
And now that I think of it I think the really orthodox way to do it was to write your whole program in TCL, then profile it and if you needed performance improvements use C to implement some of your more expensive blocks. The TCL library for C let you compile a shared library that the TCL interpreter would load and add the functions you wrote in C as new commands to the language.
There really isn't an ecosystem. It's mostly just used for driving the tools and describing the configuration. For example, if you needed to generate power straps for an ASIC, you'd add a line to your place-and-route tcl script to generate them.
I used Tcl in anger during 1999 - 2003, on our own version of a application server with a similar design approach as AOLServer.
It was Rails before DHH ever came up with the idea, but on a tiny startup in Lisbon that the world never cared about.
Handling automatic generation of database bindings based on parsing SQL92 DDL generated from modeling tools, running across all major UNIX and Windows NT/2000, across DB2, Oracle, Informix, Sybase SQL Server, MS SQL Server, and even Access, just because we could.
While it was a great experience, having to constantly rewrite Tcl code into C for performance reasons, is why afterwards I never used a language for production deployment that didn't had a JIT or AOT toolchain on their reference implementation.
To this day I don't bother with Python and Ruby for anything beyond UNIX scripting.
The founders of that startup also shared the same point of view, building OutSystems on top of .NET, based on our ups and downs delivering that Tcl based application server into several kinds of production workloads.
Thanks to donal fellows and miller puckette for having helped guide me through the tcl world. Having used it so much, tcl has been as indispensable for me as it has been obligatory.
Odd timing, I was just digging through .tcl scripts for SCID (open source chess database software) as I was trying to figure out how to fix a corrupted SCID .si5 database. One of the games got bunk data in the name field and it is corrupted now. Apparently SCID vs. PC has a magic button to fix this stuff but I did not try.
Before there was javascript for UI, embedding Tcl in an application to control a C/Motif GUI seemed like a powerful thing in the mid 1990s, but that project went away and never came back. In retrospect I wish I had kept a Tcl layer for use with each of the dozen or so GUI frameworks that came and went over the next 20 years.
I did Tcl, but in the Storyserver world and hated it. Ok, we got things done, but it was slow. I believe Tcl wasn't to blame, but that was my only experience with it so I couldn't compare it with and without Storyserver.
I forget about those days until something like this comes up.
I like this idea. TCL's major strength is combining up a practical lispy-ness with 'everything is a string'. I bet that would fit well with LLM-land prompting, especially in a hacking sort of environment.
I haven't coded TCL in something like 20 years; at the time Unicode support in TCL was non-existent; a quick review of modern TCL forums looks like UTF-8 support is not wart-free, and UTF-16 support is not on the table.
I used TCL on top of AOLServer, and at its best, it really did give that "you have superpowers" feeling Lisp can give an engineer. I bet it would make a very comfortable environment for experimenting. So much of modern LLM experimentation could be seen as creating DSLs for different tasks: TCL excels at this.
It's been a while, but my recollection is that the Tcl interpreter stores strings as fixed-width code points, and uses 16 bit characters by default, so it's effectively UCS-2 (hence being limited to the first 65536 characters).
This is configurable, though -- I recall it was a preprocessor define in the C code, and you can change it to 32 bits per character, making it UTF-32. Of course, this won't help a Tcl script run somewhere else, but it means you _can_ build a Tcl interpreter that transparently works with "all unicode", at the cost of doubling memory consumption for every string.
All this is concerning the internal string format, not what it accepts as input/output.
The next major release Tcl 9.0 will support the full expanded unicode range, so you can properly manipulate strings containing Sanskrit, Arabic and Pile-of-Poo! Beta release coming "Real Soon Now" :-)
http://antirez.com/articoli/tclmisunderstood.html
TCL is a fun language, which seemed to get orphaned ahead of it's time. Like FORTH a lot of the joy of using TCL comes from updating the language itself, rewriting how it works. The downside of that is that you're never sure what is "real" TCL, and what is your in-house addon.
Still TCL is a fun language to implement, and I guess a lot of people have implemented both FORTH and TCL, in addition to the more typical LISP systems.