Tcl was accused of being a scripting language that is more suitable for simple scripts, so I went and took a look at the Wikipedia article to see if it too presented a similar view. To quote: "It is commonly used embedded into C applications,[9] for rapid prototyping, scripted applications, GUIs, and testing.[10]"

Is wikipedia also doing a fud attack on Tcl (as it naturally could be the case), or is RMS post simply a less diplomatic and less friendly way to say that Tcl don't have the same purpose and use case as languages like c and c++? Any turning complete language can of course be used for anything, but looking at how something is used often give a good hint on where its strengths are.

At the time, Tcl was being used for fairly large apps (and it still is, e.g. in WaveSurfer). As for large scale suitability, I would guess that both Tcl and guile nowadays are eclipsed by Lua for embedded scripting, which to me would suggest that "simple" won out over "powerful".

What is not mentioned in that thread (at least not in RMS' original message) is that what triggered his edict was that somebody extended gdb with Tcl as the extension language. This was an absolutely reasonable use case for Tcl - the lightweight syntax makes it perfect as an interactive, embedded scripting language.

This discussion led to the creation of Guile, the withering of Tcl support in gdb, and eventually the introduction of a gdb that used Guile as its extension language — in 2014, 20 years after RMS decided that the Tcl extension (which I believe pretty much worked already) was unacceptable.

Of course, as astute readers will already have guessed, Tcl was BSD licensed...

Your narrative omits that gdb added Python scripting support in 2009.

Of course, as astute readers will already have guessed, Python is permissively licensed.

Both true, but I did not want to further digress. I would argue that the fact that it took 15 years for scripting support to show up again is evidence that the original policy was counter-productive.

It's been 6 years since Guile 2.0, when Guile went from being an interpreter only to having a VM and AOT compiler.

You mean a jit compiler. There is still not AOT compiler for GNU Guile AFAIK. Except janneke work.

There is an AOT compiler from source to bytecode, and then there is a bytecode interpreter. Wingo is considering the possibility of having a bytecode-to-native JIT or a source-to-native compiler.

Guile uses an ahead of time (AOT) compiler. Someone wrote an experimental tracing JIT recently [0] but that's not part of Guile itself.

[0] https://github.com/8c6794b6/guile-tjit

I believe in theory it also uses Lightning[1], but I can no longer get Lightning to build since GCC 6 or so, so I can't verify that.

[1]: https://www.gnu.org/software/lightning/

that's fantastic context; thanks for pointing this out.