I remember we had users at a chip foundry who were super deep into TCL. Is it still used anywhere else? Would you use it for a new project if you for instance already knew Python or Lua?
Antirez (the author of this interpreter) uses it for the Redis test suite.
Personally, I know Lua and Python very well but I still used TCL a few years ago for something very specific: using ODBC on Windows. I gave more details on the Lua mailing list here: http://lua-users.org/lists/lua-l/2021-01/msg00067.html
That was interesting to read. So in your case it came down to ecosystem depth, especially on Windows - where there was a TCL solution to talk ODBC, but the equivalent Lua functionality had issues on Windows.
Tcl/Tk to this day is the best tool to make GUI frontends for CLI applications. Besides that, in the past I used it in production for intranet database entry applications. It has since been replaced by Flask. In my opinion the higher complexity of the Flask version is no way justified and we should have kept the much simpler ~2k LOC Tcl/Tk solution.
best thing about TCL is easy syntax and that everything is a string :) Unique and simple and easy language with very slow changes.
Something like Python in good old days of 2.x before young internet javasceipt devs started pouring A LOT of new features to the language (feature creep).
Nowadays Python is so complex and flooded with ex C, C++, Java, JavaScript, Haskell programmers adding so many features, so fast that it's impossible to follow and understand them :(
Languages should not evolve on that rate. No time to master it :(
There's certainly something to be said for stable, uncomplicated and minimalist tooling that wont evolve out from under you and leave you with something that won't just-work five years from now.
I guess that's why Tcl is so popular in the EDA arena. I can stick some custom JTAG tooling in a Cyclone II design and talk to it by Tcl-scripting the 15-year-old software - and be confident that the same code (both in the FPGA and on the host computer) would work with the latest software and a current device.
Having said that, Tcl's not entirely free of compatibility and fragmentation frustrations: I sometimes wish that OpenOCD used full-fat Tcl rather than JimTcl, just so that I could make use of Tk. Being able to plot a histogram of data collected from the FPGA or make clickable buttons to trigger events is very useful.
Sadly it seems the blog post that was released in the past is no longer available, but the wayback machine has a copy
https://web.archive.org/web/20220303135439/https://oldblog.a...
That provides background about the constraints/limitations in this code.
Related: https://github.com/antirez/aocla
I remember we had users at a chip foundry who were super deep into TCL. Is it still used anywhere else? Would you use it for a new project if you for instance already knew Python or Lua?
It is at the core of the SQLite test suite and also a first-class citizen in interfacing to it.
I'm looking to use TCL for an embedded platform, as the scripting shell. Its simplicity and small size is key, as is its easy integration with C.
It is still used for operations procedures in, at least, European space industry. E.g., in mission control systems from Terma (CCS5 and TSC).
Antirez (the author of this interpreter) uses it for the Redis test suite.
Personally, I know Lua and Python very well but I still used TCL a few years ago for something very specific: using ODBC on Windows. I gave more details on the Lua mailing list here: http://lua-users.org/lists/lua-l/2021-01/msg00067.html
That was interesting to read. So in your case it came down to ecosystem depth, especially on Windows - where there was a TCL solution to talk ODBC, but the equivalent Lua functionality had issues on Windows.
We've got Check Point Firewalls at work, and during updates I see lots of .tcl in the web UI.
Tcl/Tk to this day is the best tool to make GUI frontends for CLI applications. Besides that, in the past I used it in production for intranet database entry applications. It has since been replaced by Flask. In my opinion the higher complexity of the Flask version is no way justified and we should have kept the much simpler ~2k LOC Tcl/Tk solution.
It's still the lingua-franca of ASIC/FPGA/Simulation, especially for scripting the tools.
I think it's slowly being replaced there by Python, but it's very slow.
best thing about TCL is easy syntax and that everything is a string :) Unique and simple and easy language with very slow changes.
Something like Python in good old days of 2.x before young internet javasceipt devs started pouring A LOT of new features to the language (feature creep).
Nowadays Python is so complex and flooded with ex C, C++, Java, JavaScript, Haskell programmers adding so many features, so fast that it's impossible to follow and understand them :(
Languages should not evolve on that rate. No time to master it :(
/rant
There's certainly something to be said for stable, uncomplicated and minimalist tooling that wont evolve out from under you and leave you with something that won't just-work five years from now.
I guess that's why Tcl is so popular in the EDA arena. I can stick some custom JTAG tooling in a Cyclone II design and talk to it by Tcl-scripting the 15-year-old software - and be confident that the same code (both in the FPGA and on the host computer) would work with the latest software and a current device.
Having said that, Tcl's not entirely free of compatibility and fragmentation frustrations: I sometimes wish that OpenOCD used full-fat Tcl rather than JimTcl, just so that I could make use of Tk. Being able to plot a histogram of data collected from the FPGA or make clickable buttons to trigger events is very useful.
I agree, so much for the benevolent dictator idea.
That's certainly a take...
> best thing about TCL is easy syntax and that everything is a string :)
What? That's the worst thing about TCL.
I love it. Living proof that languages doesn't need forced types.
Data is Data. It's kinda object programming as visioned in the 70".
So easy and trivial language.
JimTCL has more features and it's almost as small.
You probably know but others might not: they have the same author.
haha golden comment
Yep, but Jim has been maintainer over and expanded.
Altough the SDL2 bindings are very alpha.