I learned to hate TCL with a passion.

That said, in EDA in general it works well for the most part.

Python was effectively completely stable through all this and gained a critical mass following.

I don’t know what you mean “shot itself in the foot“ here. Some examples?

> Python was effectively completely stable through all this and gained a critical mass following.

I don’t know how much more “effectively stable” Python was than Tcl. Can you expand on this?

I personally see this largely as “luck of the draw”. It seems to me there’s a lot to complain about with Python - the low-fruit classic is the GIL. Despite that huge impediment, it came to be a scientific computing go-to language. Who would have guessed that? We can see things now and say “popular languages are popular”, and that’s about it.

Not luck of the draw, it was because of the OOP craze in the late 1990s and early 2000s. In undergraduate school I took some introductory programming classes for an easy A, as I was already working as a web developer (like many in my generational cohort) for living expenses. (My degree program was entirely unrelated.) In one of those classes I just ended up as something of a [very poor] TA for the professor. At some point he told me that his department was looking to reorganize their curriculum to emphasize OOP and asked what I thought about Java and Python. I had never programmed in either, mostly working with Perl, JavaScript, PHP and ColdFusion. But I told him that Python was becoming popular in the open source space, and the simplicity of the language, including dynamic typing, and freely available tooling would likely make it more accessible.

I don't know if he took my advice, but in any event as I remember things Python eventually overtook Perl partly, if not largely, by riding the OOP wave. People like to say that it was because Python was simpler and more consistent (TOOWTDI instead of TMTOWTDI), but it was really only simpler and more consistent in the context of OOP programming. For quick, top-to-bottom procedural programming tasks Perl has always been simpler, IMO.

Sure, but Tcl also had/has a well-regarded OO system, and Ruby was on the scene, so Python doesn’t actually stand out singularly.

Ruby didn't have very much mindshare in the U.S. during the relevant period. Which is a real shame. There's always been a significant amount of great work coming out of Japan that never gets popular attention elsewhere. Ruby is one of the notable exceptions, though it's break-out success came belatedly. (Wikipedia says the first English language Ruby mailing-list was created in 1999. AFAICT, O'Reilly's first Ruby book was "Ruby on Rails", published 2006. O'Reilly's "The Ruby Programming Language" wasn't published until 2008. All of these are indicative of an exceptionally late popular introduction to the English language programming community.)

I don't mean to imply that luck had nothing to do with Python's success. It's just that if you look at the contenders at the time and the qualities that people were (rightly or wrongly) looking for in a programming language, it's not at all surprising why Python gained popularity. To the degree luck had anything to do with it, it was largely the timing of those nexus of factors.

O'Reilly published Matz's Ruby in a Nutshell in 2001, but it didn't sell very well. When I worked there, I encouraged more Ruby publishing but only after I published the "Rolling with Ruby on Rails" articles (January 2005) did that argument get much traction.

The Pragmatic Programmers released their first Ruby programming book in 2000, by way of comparison (and Dave introduced me to DHH in 2004, which is how I decided to seek out the Rails articles).

Tcl made the crucial (in retrospect wrong) decision not to support a central extension package repository or well-stocked releases and chose to focus on the core. This forced users to scrounge the web for extensions and hope they compiled on their platforms, and depend on sketchy support from individual authors.

The OOP craze played a significant role as well I think. I recall that in the late 1990s Tcl was part of something of a renaissance of varied programming paradigms escaping academia and getting applied in the wild (partly in the form of clever Tcl extensions). But Java/OOP and WWW/server-client killed that movement dead.

Python, on the other hand, felt like it was at version 1.5.2 absolutely forever.

> It seems to me there’s a lot to complain about with Python - the low-fruit classic is the GIL.

Except that, in the late-1990s/early-2000s, it didn't matter. Scripting languages were slow relative to compiled languages. Multiple-threads effectively didn't exist. Hyperthreading didn't hit until 2003--after the DotBomb.

> Despite that huge impediment, it came to be a scientific computing go-to language. Who would have guessed that?

Gee, who could have guessed that a whole lot of scientists and engineers kinda liked Matlab the program but hated Mathworks the company and that providing somewhere for them to jump ship to would be popular? Like ... absolutely everybody?

Of course, just the idea isn't enough. The alternative has to be sufficiently capable.

Thus ... Enthought. Enthought personnel put in a lot of elbow grease and work to make Python a scientific computing go-to language.

As always, the best way to predict the future is to make it.

The release notes[0] for Tcl 8 seem to list minor-ish annoyances, but perhaps you did have to support something across the 7-8 divide; I won’t argue against your experience in that case.

> As always, the best way to predict the future is to make it

Truth.

[0] https://www.tcl.tk/software/tcltk/8.0.html#incompatibilities