> Look at the wiki for example. It should really be an actual wiki à la Wikipedia not some sort of strange Wikipedia discussion page masquerading as documentation.

You can complain about it looking "old" if you want, but it's hardly fair to complain that it's not an "actual wiki". It follows the style of the original WikiWikiWeb which predates Wikipedia by a number of years.

Expectations change. Scotsmen change.

But where else would you find gems like this?

https://wiki.tcl.tk/9832

FINALLY, someone actually defined -- in practice -- what "(E)nterprise ready" means.

Best definition yet, that I've seen.

On a related note, if you love Tcl but want a different syntax there's Little, which is driven by Tcl, but has a C/Perl/awk syntax:

http://www.little-lang.org/

Do you think it's an actually good language though? I only tinkered around with Tcl (long ago when writing eggdrop bots and more recently while messing around with FPGA and ASIC build scripts) and while it's serviceable it never struck me as a particularly interesting or elegant scripting language. When given the choice I'll always pick Python or Perl over Tcl. Am I wrong? What did I miss?

I think Tcl is incredibly elegant. It's got a set of very simple syntax rules that compose together to govern everything. You can use Tcl to create your own keywords that are used exactly like the built-in ones and your caller won't ever tell the difference (well, unless they inspect an error backtrace). For example, a try/catch syntax was proposed as TIP 89¹. And many many years ago, as part of the MacPorts project, I implemented the entirety of TIP 89 in pure Tcl. The TIP was proposing actual Tcl keywords, but I implemented exactly the proposed syntax and semantics without a single keyword. I have no idea if that code exists in any form anymore (I haven't been involved with the project in something like a decade), but I'm pretty sure the only observable difference between that and TIP 89 is error backtraces² that cross a frame involving try/catch.

Also, virtually every type³ in Tcl can be expressed as a string, and so you can model the entire language mentally as if every value was in fact a string. If you wanted to write your own Tcl interpreter it would be pretty easy to actually implement it this way, though obviously performance would suffer quite a lot.

¹Later superseded by TIP 329 in response to the error options dictionary in Tcl 8.5.

²And FWIW I believe there's no actual spec for what error backtraces look like anyway, I think it's implementation-defined, though don't quote me on that.

³The only type I know of offhand that can't be expressed this way is an array (which is distinct from a list, that is a fundamental building block of Tcl and can absolutely be expressed as a string)

anyone interested in starting to play around with languages would do well to write out the 'everything is a string' version. its very short and understandable.

plus the result is really amenable to inclusion in another program as an extension language (tcl is too, but it has a much bigger footprint)

I think it's a good language. It has simple syntax (only 13 syntax rules), great documentation for the API, the language, core commands, and all the packages shipped with the core release. It's very flexible so it can be used in a lot of situations: Embedded into a program as a domain-specific language (DSL), scripting engine in its own right with very complex software written in many different styles, evaluating untrusted code (with Tcl Safe Interpreters).

Really the only reason to pick Python over Tcl is that more people have picked Python over Tcl in the past.

I don't think Tcl is in competition with Python or Perl. It is in competition with bash, PowerShell, etc. Its syntax is quicker to type which is good for interactive (REPL) use.

Sometimes I'm thinking about a simple build system which is very much like Make but uses Tcl to be cross-platform and scales better to advanced uses.

Tcl could also work well in Jupyter notebooks.

Once you think about functions, classes, and modules, you better use Python.

You can help improve adoption by using Tcl in your next project -- there's no reason not to, right ? :-)

P.S. We just setup a Slack interface to the Tcl'ers Chat, so now all you Slackers can join in to the hundreds of other Tcl'ers.

https://slack.tcl-lang.org/

I like the quirky feel of Tcl'ers wiki. It gives it an unique playful character. I would like it to stay that way.

For general style improvements to the Wiki there's progress on moving the Wiki to "Nikit":

https://nikit.tcl-lang.org/