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.
Tcl was the first language that I really grokked. Before that, I had tried learning C, C++, and Perl in my spare time. Progress was made, but not enough that I was able to write anything that was actually useful on the command line, let alone a GUI.
Then someone suggested that I try Tcl/Tk. Literally within 2 hours of first hearing of the language I had a reasonably functional application running on my computer.
I do most things in Python these days since it is simply far and away more capable than Tcl but I still think it's an excellent language for a lot of things.
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.
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.
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):
I do wish the main documentation site would focus more on Tk and less on Tcl/Tk, you get the impression that the two are joined at the hip. For those of us that don't like Tcl it seems like Tk is still quite usable but working out how is left as an excercise for the reader.
Except that it has zero accessibility support, e.g. for blind users with screen readers. Please don't use it for any non-toy application, unless it's something inherently visual.
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.
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.
You mentioned AWK. I'm somewhat surprised the C extension capability of gawk never took off. AWK could have competed with Perl in its heyday. There are extensions that add select(), sleep(), sockets, serialization, xmllib, and other C ABI based stuff that helped Perl. Too little, too late, I guess.
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!
Oh wow, AndroWish looks amazing! I didn't know about it because it's not on F-Droid. I bet I can run the slide-rule app I wrote in 1997 on my hand computer now!
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.
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!"
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.
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.)
I haven't looked in ages - is AOLserver still the best Tcl web-app platform? Tcl is an amazingly direct programming language, which makes things easy to do, and with the significant advantage of crystal-clear readability, and less error-prone code. (A friend of mine maintains Tcl is really short for "try coding less"...)
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.
> 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.
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.
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].
> here 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.
I love the way you put this. My team is in the middle of an IMO largely pointless port of working code from Scala to JS, because some senior people think Scala is icky...
(Even though my team is a JS team, I don't think JS is a better language than Scala. To the objection I get: "we can't find Scala engineers" I point out that JS engineers on my team have had to learn to read Scala in order to port the code, so they're halfway there already...)
Is there such a thing as a PL engineer? I thought it was software engineer, and the particular language matters less than general software principles and practices. Plus, any new employee is going to have to learn the code base regardless of whether they start out knowing the language.
Any software engineer should be able to learn a new language. The idea that you have to higher engineers who already know the language, particularly a high level general purpose one, seems suspect. It's not like they're writing some low level Rust or C code.
It seems like a poor reason to port a code base, but I guess it happens often enough.
> Any software engineer should be able to learn a new language. The idea that you have to higher engineers who already know the language, particularly a high level general purpose one, seems suspect. It's not like they're writing some low level Rust or C code.
Yeah, I agree. And I'm doubtful that the time it would take for one or two competent people to come up to speed in Scala is less than the time we're spending to port the entire thing over to JS. It's months of engineering time. That time could have been spent improving the existing codebase rather than the much riskier option of porting to a new language. And then that team would have the Scala engineers it needs, for ongoing work. Or at least a shared resource to help out.
Most developers aren’t software engineers, they are coders who just jump on the hottest JS trend or are utterly content with Enterprise Java mediocrity. Their entire lens is warped by a narrow view of “coding” and are incapable of programming anything beyond that frame.
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.
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).
Of course that didn't end up happening, but it's interesting to think about what might have been different if it had.
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.
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.
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.
I'm in a similar boat of TCL dislike. But that probably has a lot to do with my first introduction was through installing a program and having all types of difficulties doing so.
Being exposed to a language at first by trying to understand what it is doing in installing software is probably not a great introduction. I did get the software installed but my dislike remained
This was probably further increased by the fact that post that I had bad experiences with my supervisor that just soured everything about it. Even to this day where it would benefit me to use TCL, I try to avoid it in favor of languages like Python.
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".
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.
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.
Tcl/Tk was my first love in programming. I've spent years wishing that i could find other environments as easy and capable as Tcl.
The only other GUI development environment I've come across that I've found to be similarly easy to develop in (and cross-platform) is Free Pascal / Lazarus. I assume the commercial Delphi offerings might be similar, but I don't have any experience with them.
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).
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.
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).
> 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.
"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.
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}
You can use proc command in Tcl to replace existing commands and procedures, which gives you the possibility to implement different behaviour.
An example that shows this:
~$ tclsh
% rename while origwhile
% proc while {args} {
puts stderr "Debug: invoked while with arguments $args"
# do anything you want here
uplevel 1 origwhile $args
}
% set i 0
% while {$i < 5} {puts $i; incr i}
Debug: invoked while with arguments {$i < 5} {puts $i; incr i}
0
1
2
3
4
%
And in Forth the dictionary is searched backwards for a word (starting with the most recent definitions), so you can similarly override words. Powerful!
In Forth, not just new words - everything (except the stacks, I think) - as if in C you could redefine not only every reserved word but every symbol - (, ), +, *, ->, %, &, [,],{,},# = etc etc. Also there are 'defining words' (akin to typedef, struct, enum etc) and you can define new defining words... And so turn Forth into any other language you wanted, if you were crazy enough..
Putting on words instead of code, since my last Tcl was about 20 years ago.
Semantically Tcl is a bit like Lisp with Algol syntax, and you get to execute expressions on upper stack levels, and can also evaluate parameter blocks (aka lambdas).
So you just need to create a function for your control structure, that will take the required parameters for the control structure body, and then eval it on the upper call level.
It is very rough as description, but maybe I was still able to convey the idea.
For our in-house app server, all our configuration DSLs were just Tcl scripts that we sourced (loaded) on application start.
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.
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.
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!
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.
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".
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.
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).
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.
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.
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.
Tcl's syntax is sufficiently simple that you can write something that parses it in Tcl, and there's examples of doing that to do more complex metaprogramming all over the wiki.
Plus things like uplevel let you jam a lot of meta trickery into commands without needing AST manipulation.
So, yeah, you do get both capabilities, it's just done atop the very simple baseline system, if that makes sense.
(look at e.g. 'snit', a pure Tcl OO system, as an example of what can be done with just Tcl itself)
Yes. And Tcl does expose list-parsing functions, so you can pretend the strings are lists. Also, current versions of Tcl have optimizations around that.
I think the keys are a) uplevel (which might be very difficult to do in a compilable language?) and b) having a syntax that's a bit more traditional. It's not the fact that you're manipulating strings - indeed I'd very much like a TCL that allowed you to metaprogram with a more structured representation.
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.
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.
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.
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/
For a while, I know that https://flightaware.com/ used it fairly heavily. Indeed, their careers page still shows an interest in Tcl skills.
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/).
The Java rewrite also still exists (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.
AOL Server has been replaced with naviserver. Which is just as excellent. I've been creating a webApp in TCL with the help of navi. It's just so simple to get it done.
Setup a GET method to a TCL procedure and then return the HTML of that procedure.
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.
Having written at least one tool in Tcl/IncrTcl, widely used within our company for chip-level verification, I would tend to disagree with you.
Using a standard Tool Command Language to control your EDA Tools, is a wonderful concept. Tcl's numerical handling leaves something to be desired ([expr 1 + 1]), but in other aspects, such as node/list processing, it is stellar.
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.
I'm not that guy, but here's my interpretation: tcl is used as the embedded scripting language in the vast majority of EDA tools. In some ways it performs this job quite well, with tool companies providing functions which parse their arguments like inputs to a shell script. For example, you can call
report_timing -from ... -to ...
When the commands have 50 optional parameters, this method of calling is convenient.
However, the problem is that it has been pushed to its absolute limit. Massive automated design flows consisting of tens to hundreds of thousands of lines of often highly unstructured tcl are present at most semiconductor companies. All of this code is written by VLSI engineers who have not much software training. These engineers take advantage of the highly dynamic nature of tcl to solve their problems quickly... and the result is often an unmaintainable mess of code. As an example, I've almost never seen anyone use tcls module system, instead its just scripts using the `source` function to load other scripts.
Since the language is not mainstream among software engineers, there is very little material on best practices, and semiconductor companies are extremely locked down meaning there is no open source tooling to speak of. So VLSI engineers continue producing spaghetti code to handle all of the implementation.
Obviously I am speaking in very broad strokes, so there may be companies out there that do it right.
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.
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...
I take your comment to mean that the damage is caused by the choice of embedded scripting language being Tcl, rather than the fact that EDA engineers aren't software engineers and don't build testable, maintainable, reliable code bases.
What would have been a better choice? Lisp, as in AutoCad? Something else?
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.