I spent a lot of time with Tcl, first at company some friends and I started in the late '90s, and then at Arbor Networks, where I dragged it into their service provider product.
In a Lisp, code is trivially parsed because everything is a tree of conses, and the language derives tremendous power from that.
In Tcl, code is trivially parsed because everything is a string, and the language is hamstrung by it; it's a little like trying to code a major project in Bourne shell.
For a time, Tcl had the best C integration story of the scripting languages, with a thoughtfully designed extension interface that was easy to use. But every major scripting language has that now.
Tcl was early to what I guess I'll call mainstream metaprogramming (obviously, Lisp got there first) with "upvar" and "uplevel" and [incr tcl]. But Ruby --- which bears a lot of similarities to Tcl --- did all that stuff much better and more cleanly.
> a thoughtfully designed extension interface that was easy to use. But every major scripting language has that now.
OP> Easily embeddable/extendable.
Easily embeddable language implementations have regrettably remained more uncommon. Sure, extending has gotten relatively easy, but it's still in that "we own the world - you are welcome to visit, as long as you fully respect our partially-documented memory, stack, io, threading, whimsy, and other disciplines" kind of way. And "feature: we're embeddable! (sort of, if you're careful, sometimes, maybe)" toxic hairballs of surprise are still a thing.
Exactly. Tcl competes with Lua, not Python or Ruby. And Tcl and Lua both have their respective advantages and disadvantages.
- Lua has better support for handling non-trivial data structures, but Tcl interop is a lot less cumbersome, as the host language only needs to know how to pass strings back and forth, basically.
- Tcl is more suitable for writing DSLs due to its homoiconicity, but Lua's more conventional syntax is more suitable for traditional programming.
- Tcl's command-oriented syntax makes it fairly easy to write an expressive shell-like interface for your application (debugging, state inspection, expert interface).
I'll note that via JimTcl [1], Tcl also has an additional niche for bootstrapping software as a much saner replacement for /bin/sh programming, such as in autosetup [2].
Article feels like a blast from the past. I think Tk was the best of it. By 2001 I had ditched Tcl and was using Perl/Tk instead to fit simple UIs on in-house tools. Maybe we had some lingering expect(1) scripts for a few years after that.
Things are a little bit more nuanced than 'everything is a string', since you can create types that are other things. I think this comment gets at that in a fairly accurate way:
> But Ruby [...] did all that stuff much better and more cleanly.
But it's taken Ruby a lot of years to get there. And even now, I'd suggest Ruby's `refinements` need more maturing for it to be clear. "uplevel" was wonderfully powerful for creating DSLs, even if rather sharp-edged to develop with.
I thought the time TCL went wrong was back in 1994, when Sun unilaterally announced that TCL was going to be the official scripting language of World Wide Web browsers, prompting RMS to kick off the TCL War by writing "Why You Should Not Use TCL". [1] And then Sun changed their mind and decided that Java was going to be the official scripting language of World Wide Web browsers. And we all know how that turned out.
Type checked, C like, structs, perlisms like if (buf =~ /re/), compiles to tcl byte codes so that L can call tcl and tcl can call L, open source, liberal license.
Yeah, John likes it but he's not sure if it will take off or not. We haven't merged to tip with the tcl tree and we have some issues to resolve:
- not thread safe, it assumes one tcl thread
- we stole a bit from the ref count integer to implement "undef" and the tcl core isn't thrilled with that
- we default to pcre (but have the old stuff for compat, you can switch at run time)
- we broke a bunch of tests (mostly pcre related)
As a long-time Tcl/Tk user it seems where some might think Tcl went "wrong" was combining its Lisp-like semantics with C-style syntax. The "hybrid" was confusing to many programmers, especially those coming from C and similar tools.
The article mainly examines the corporate and marketing aspects of Tcl's history, and not so much the technical merits of the language. True enough, Tcl lost out to Java and other languages on that account but as the article acknowledges Tcl still has quite a large community keeping it going.
On the technical side, the commentary about "everything is a string" has been extensive discussed and IMO has been shown to be more than not a red herring. In any case many of the "warts" that were prominent in 2010 have been at least partially addressed. Notably in recent years Tcl as acquired many Scheme-like features, an official OOP facility, and coroutines among other "modern" features.
Tcl remains incredibly flexible and adaptable to diverse problem domains. I wouldn't try to write a hardware driver in Tcl, but for many problems it's the most productive tool in the toolbox.
Tcl had been a pretty good way to create things like embedded command shells for C-based programs, and this was great as long as people operated in fairly sequential ways like “command1, command2, command3”.
The problems with Tcl start to show up when invariably somebody decides they want something more logically complex than a sequence of commands. Debugging Tcl is extremely difficult, which makes it a huge maintenance liability. For example, a “line number” isn’t much help if the “line” refers to 90% of the file and Tcl thinks all of that is essentially one statement (no matter how many braces are in it). As another example, there are tons of places where a variable is referenced both like "$this" and "this"; that is just a whole series of accidents waiting to happen, especially when you consider that many functions depend on argument order and they don’t necessarily produce obvious malfunctions when variables are misused.
> For example, a “line number” isn’t much help if the “line” refers to 90% of the file and Tcl thinks all of that is essentially one statement
I think this may have improved since you last looked:
$ cat j
#!/usr/bin/env tclsh
puts [ set a [ expr { 9 + [set x]}]]
$./j
can't read "x": no such variable
while executing
"set x"
invoked from within
"expr { 9 + [set x]}"
invoked from within
"set a [ expr { 9 + [set x]}]"
invoked from within
"puts [ set a [ expr { 9 + [set x]}]]"
(file "./j" line 3)
> there are tons of places where a variable is referenced both like "$this" and "this"
$this is essentially [ set this ], returning its value, or deferencing the value, if you will. The entire set of rules that Tcl abides by are contained entirely in a small document (here [0], with commentary). It's really not difficult to figure out.
That trace is not as bad as I remember but if you write that in a nice long multi-line series of if-statements (say) it’ll still print out the whole mess and only tell you one useless line number. If there’s a "proc" it’s a little better but it can only show the bad line number relative to the "proc", requiring you to do some manual work to find the function within the file and then the offending statement line.
Also, I have no problem with the logical "$x" syntax; rather, the fundamental flaw is that the string "x" could be used to change the variable "x" without any clue in the syntax that this may happen (e.g. no "&x" like in C, no "\$x" like in Perl; just "x", or worse "$y" that resolves to "x"). And don’t even get me started on multi-level "upvar". This whole thing is a minefield, especially if people use simple variable names that can’t be searched in a code base. If you’re really unlucky, you accidentally swap the order of parameters and it just so happens that your "$x" value is almost plausible so you never notice the disaster you just created. It’s simply a “write once, modify never” coding style: it saves the programmer 10 seconds and creates the most brittle of code. I would never recommend it to anyone.
Not David, but I think Tcl popularity was already going down way before GitHub became as popular as now. Around 2005 most projects were on SVN, and Tcl was already more or less "the language that you have to use together with Tk".
Between BitchX and Eggdrop development, I'd say that TCL was my most-used language circa 1998-1999. Had totally forgotten about it until seeing this post (for better or for worse!)
I'm not a programmer by any stretch, but back in the early 2000s I used Tcl/Tk to create my own little scripts and utilities in Slackware, my everyday OS of the time. It's simple to learn and use for the layman, but powerful enough to do real tasks and automate workflows.
I have no real need for it these days, but I'm happy to see it is still in use even if it's not as popular as it once was.
I'm having a look at Tcl at work due to legacy code and it's no language that I find easily accessible. Especially when having not that much time and having a large codebase.
The interpretation and the braces in braces parts are annoying. Not very readable.
Modularization is not easy and other files can't be imported as fast as with Python or ES2015.
Resources and tutorials are not readily available, there is no community I ran into to ask stuff compared to the rest of the language world.
Finding a test framework or linting mechanisms is not easy either.
I'm no friend of Tcl at the moment, I'm not sure if that will change.
>Resources and tutorials are not readily available
I think I know all the major web resources for the language, and I agree. In terms of learning material available online Tcl is simply very much behind Perl, Python, and Ruby. If you're learning Tcl from scratch today, I'd recommend to start by following https://learnxinyminutes.com/docs/tcl/ (ignore the broken syntax highlighting) and then https://www.tcl.tk/man/tcl8.5/tutorial/tcltutorial.html, and playing with the REPL extenstively (I am a fan of using http://homepages.laas.fr/mallet/soft/shell/eltclsh as your REPL for how it does completion). If you want a book, there are quite a few, but most of them outdated. While I haven't read it myself, I have heard good things about the most recent, The Tcl Programming Language, and I enjoyed its author's other writing on Tcl. The man pages that Tcl comes with are a high quality reference for its commands. The Tcler's Wiki (https://tcl.wiki/) is also indispensable as a reference and a starting point for research.
>there is no community I ran into to ask stuff
I highly recommend the "tcl" tag on StackOverflow and #tcl on Freenode. The former has some seriously dedicated people answering StackOverflow-scoped questions. The latter is where the developers of the language hang out and suitable for more open-ended discussion.
There are several linters for Tcl; see the list at https://tcl.wiki/3162. At one point I tried using ttclcheck because it implements static type checking, but never stuck with it or any other linter. This may be due to Tcl's sparse syntax and highly dynamic nature, because I do use linters and style checkers for other languages.
A fair amount of where tcl went wrong was the initial string type that couldn't handle binary data. They did fix it, but the inability was a showstopper for early adopters.
For strings, if a null was in the data, it truncated at that point, and there wasn't an alternative type that could handle it.
Poor resource management model is my biggest personal turn-off. The post actually mentions it when it talks about everything-is-a-string - the problem with that approach is that handles for external resources are then also strings, and this in turn kills any form of garbage collection (both tracing and refcounting), because it is possible to construct a string that is a valid handle out of various bits and pieces lying around. Thus, you have to manage all resources manually. For a high-level scripting language, I consider that unacceptable.
I don't really have much of a need for garbage collection, but I did investigate strong/weak references (which I would probably prefer over garbage collection). See http://wiki.tcl.tk/41605. That's the best I could do with my limited knowledge of the Tcl internals. My suspicion at the time was that if the Tcl core team really wanted to implement strong/weak references, then they would probably be able to come up with a proper way of doing that. And if they could do that they could do garbage collection. But I don't really know ...
I think the problem with such systems is that they have to contend with the infinite varieties of ways references can be stashed away. When a local is itself a reference string, that's well and good. What if it's a string that has a reference embedded in it somewhere? But that effectively describes all Tcl data structures...
Yes, the way I was looking at strong/weak references was that strong references could only be held as a value in local/global/class variables, including in lists and dictionaries.
And converting a strong reference to a string would give you a weak reference. So you wouldn't be able to, say, convert a list that included a strong reference to a string, then convert the string back to list, and have exactly the same list that you started with because the strong reference in the original list would be a weak reference in the resulting list.
Strings can represent list and dictionary data structures, and combinations of, but I'm not sure that strings represent all Tcl data structures in the same way. I'm thinking of Tcloo and Tcl arrays - I don't use those and know little about them.
I discovered Tcl and Tk a few months back. Spent a few days poking around and experimenting. At first I was incredibly impressed, and amazed I hadn't even heard of it before. But once I started digging deeper, the poor docs turned me off.
If anyone is interested in seeing a recent app example, check out git-gui [0]. It's bundled with git.
Could you provide more information on which documentation you found poor ? Tcl certainly has a lot of it, in the official manual pages for everything as well as the wiki.
I'm on macOS. Installing the latest version was confusing. There's a tcl-tk package in homebrew-core, and a tcl package in homebrew-cask. The tcl package is ActiveTcl. What's the difference? On the tcl.tk site, if you try getting the binary it'll point you to ActiveTcl.
Diving into the wiki was very confusing. Lots of articles have comments by random people, and it's not always clear if their comments are relevant or outdated. There's dozens of links, and hard to discern which ones are worth looking into. Lot of links are dead.
The differences between the different Tclkits is not obvious, too many choices. And how do they relate to starkit? I think I remember having downloaded an sdx compiled widget, and I couldn't find the sdx utility, so I couldn't unwrap it.
Tons of dead links in the Great Unified Tcl/Tk Extension Repository [0]. Almost nobody puts up screenshots of their widgets.
It's also frustrating to find out that Tcl Dev Kit is a paid component. I'm probably spoiled by other languages, so this might be pretty entitled of me, but I'd consider the dev kit's tools to be essential. The most important tools for me would be the debugger, linter, and inspector.
As a standalone user, I'm not going to pay $300 just to play around with a programming language. It would be a huge improvement if they were made freely available, even if under a non-commercial license. Then people can try it out, and if they find a good use-case in their job, they might buy a license. I've done that with other software. To give a concrete example: in a few college projects and hackathons I used highcharts [1], a JS charting library. Since it provides a free non-commercial license, I ended up learning how to use it pretty well. Fast forward a bit, and the company I was with wanted data-dense interactive charts. I evaluated a few options, but was most satisfied with highcharts, so I happily convinced them to buy a license.
That's also similar to what Qt has been doing too, and it has been hugely successful. You can use the free open source version, which is licensed under GPL and LGPGv3. But if you want to keep things locked down, you can pay ~$3500/year for their commercial offering. Most humans probably won't pay for the commercial version unless they're full time app developers, but businesses tend to have much deeper pockets.
I remember trying Tcl/Tk many years ago during high-school: the syntax was interesting and building GUI applications was extremely easy. I don't know why Tcl is not popular today, but there is one pretty cool Unix tool that uses/extends it called Expect [1]
Expect lets you automatize user interaction with terminal applications. And then there is DejaGnu, a testing framework, that uses Expect and Tcl. Probably the most important software project using DejaGnu right now is the GNU Compiler Collection. A not so significative project that also uses it is the interpreter of my toy language :) it took me a little bit to understand how to integrate it with Autotools but now I really like it (here is an example: https://github.com/pera/ad-hoc/blob/master/testsuite/ahci/dg...).
The first company I worked on was an heavy Tcl shop.
For me they went wrong on being a pure interpreted language, having to write all performance critical parts in C wasn't scaling for us.
It was there that I learned only to use languages with JIT/AOT support.
Also having Tk stuck on a Motif look and feel wasn't appealing to us as a mechanism to deliver good UI/UX to our customers, specially to the majority of them on Windows.
The greatest innovation of Tcl was how easy it was to extend with libs in C. I still thinks that Tcl's author famous paper about using "glue languages" is still one of the best ideas in software engineering.
Some of the UNIX systems I admin actually have Tcl installed by "default" (Solaris and AIX) and no Python. So I use Tcl there when I want to do things about shell.
Sounds intriguing! If you have any examples of projects where you've tried that out and how/why you felt that worked, it'd be interesting to read about.
That's the first I've ever heard anyone say that Stallman had anything to do with Tcl. Do you mean to imply that guile wouldn't exist if Tcl was GPLed? Or something else?
I'm not entirely sure about that. While Stallman is most famous for his license preferences, he has a longstanding, pretty strong pro-Lisp preference as well, dating back to his early work on Emacs Lisp. Guile Scheme was created as the official GNU extension language mostly because Stallman thought a version of Lisp was the right language for a standard GNU extension language, and Tom Lord convinced him that Scheme was the right version of Lisp for the job. It wasn't a preexisting GPL'd interpreter that he just picked because of its license.
Decades ago Synopsys chose it for Design Compiler. Mostly Hobson's choice (what good alternative did they have?)
But it was an awful language because it was so limited. Many commands in DC naturally want to return objects. But those don't exist in Tcl (maybe they do now?).
So DC had to invent "collections" to make up for the limitations. Which confused the heck out of engineers. Resulting in Stack Overflow questions such as this one:
I had a little contact with the language. The article nails the biggest problem with TCL:
"One actual technical problem that Tcl faces is the concept that all values must be representable as a string. This is more or less ok for things like lists, hash tables or numbers, but is problematic when the user wishes to represent a value that simply isn’t a string."
Thats actually not totally true. Internally, Tcl has two value types, string representation and actual value representation. Everything DOES have a string-representation though- some are made up (like file handles, fileX) and some are just ASCII forms of the values underneath (like integers).
Tcl is cool because you can manipulate the string form of values incredibly easily, but people confused this with "Everything is a string". It should be "Everything can be manipulated like a string".
Seems like the culture prunes back some languages and starts up new ones.
The only language that I think will escape this is JS due to the browser - unless we make a new sandbox app container designed to run scripts (a la java plugin).
I got into Linux (and now a long systems administration career) quite literally because I wanted to run eggdrop bots on a shell server. Programmed in TCL :-)
Quirky bit of personal history that amuses me to no end.
I can see that. There was (and is) a plethora of object systems, which could be seen as a double (triple?) edged sword. It provided choice, with many alternate features and methods (no pun intended), but perhaps at the expense of developer clarity - which one best serves my needs? Will I end up in a dead end? What are most others using? What serious problems might I be adopting? The "third edge" though, is a positive, though took time to arrive: the TclOO that was finally developed was informed by the technical and social impacts of years of experience with various OO systems, and indeed emerged mature and well-formed because of that. In fact, it was initially developed to only be an underpinning for other flavours of OO sugar to be bolted on top, in support of existing systems like [incr tcl] and Snit. It ended up being received as system good enough to use directly, in it's own right.
I've never have the chance to use the new core TclOO, but I really think they've made mistake at that time by implementing another new object system instead of promoting an existing one like [incr tcl] (even if not perfect/incomplete).
JO is still officially Tcl's BDFL, though he takes no active role except on rare occasions as the decider when conflicts among the core team can't be otherwise resolved.
I dunno why you got down voted, your point seems valid to me. Tcl thrived under John, after him it was ok when Hobbs was the de facto leader, it's sort of gone flat since he moved on. In my opinion.
Thank you for saying so. It's probably because my comment was so terse and comes off as flippant. But I assure you it was not meant to be. I think it very much matters that TCL doesn't have a BDFL. I'm a bit ashamed to admit that I'd forgotten that Ousterhout was initial head honcho. I got to know Tcl via Expect and Tk, like many others I'm sure. Kind of like how many encounter Ruby through Rails and Perl through having committed some awful deed in a previous life. Tk and Expect were always pretty niche though.
Well cool, I upvoted your stuff. I agree that the BDFL is extremely valuable. Tcl is doing ok but it's not the same as when there was someone with a lot of vision setting a clear direction. The core team that is left believes in everything is a string too much for my taste, I think Ousterhout would have fixed more stuff by now.
It's "gone flat" because there are a lot of languages out there to choose from. Despite not having a BDFL, the TCT has steadily improved the language and added features. It's popularity is where it is and that probably isn't going to change. It's hard to be top dog now days.
Perhaps because lots of languages have done well without a BDFL. Look at the top 10 languages in Tiobe or the RedMonk surveys, and the majority don't have BDFLs.
The rest (even though you wouldn't compare them to TCL cuz they're not in the same niche) have/had huge corporate sponsors and/or are entrenched industry standards and have also had iconic/notable figureheads (Gosling, K&R, Stroustrup, Hejlsberg, Eich).
More than anything, I would say that what "went wrong" is simply that the wind changed. Tech is driven by fashion more than anything else, something becomes "cool" and everyone scrambles to re-write perfectly good software in a new language for no particular reason (other than keeping their CVs up to date). Tcl is a powerful language that you can use to create complex systems with simple code, the holy grail. But instead the industry took a massive step backwards and said "event driven programming? let's use Javascript!"
> More than anything, I would say that what "went wrong" is simply that the wind changed. Tech is driven by fashion more than anything else,
That's not my recollection. And I disagree with the fashion thesis too. :)
So I used Tcl, perl, and python in the early 90's. Tcl owned embedding and Tk. Perl owned sysadmin and CPAN. And was fast. Python owned OO and "nice professionalism". Perl and python had hashes. Tcl got hashes. Tcl and perl picked up OO. Perl and python mooched Tk. But Tcl remained furry and batteries not included. Perl remained buggy and weird and unprofessional. And python remained without good code sharing. Turns out people wanted "nice" more than embeddability or CPAN. All three communities knew what their strengths and weaknesses were. And were variously able to deal with the weaknesses, or not.
I don't think it's the same use case. Tcl is really good as a CLI language, like Python.
NodeJS is not very good when it comes to test stuff in the CLI quickly due to its async API. Even when there are synchronous versions, most libraries are async so wrapping everything in promises is a bit of a pain.
IMHO Tcl really lost to Python, not JS. Python is an excellent way to test ideas quickly on the CLI.
I do a lot of web-scrapping and data transformations and to be able just to open a CLI, call a lib and test things out in 5 minutes for a PoC is just RAD.
Now that async functions are available in node, I'd say you can write some very nice async code with minimal efforts. Before that, many people were using generators to write coroutines (e.g. with the co module), which effectively achieved the same result.
Not saying you should change languages though, especially if you're happy with your existing toolset! But if you feel up to it, you might be surprised upon giving it a try.
I've written a few one-off scrappers without any complaints. It also works well for simple cross-platform scripts.
I don't recall the developer experience when installing python on windows, so maybe it's just as good. With node you only have to download and install the official release, and everything is good to go. Even when some package has native code, it generally "just works".
Blame the browser. If Brendan Eich had tried to repurpose an existing language instead of mashing together a new one; or if Microsoft had used their de-facto monopoly in early '00 to push abetter language, JS wouldn't be as big as it is today.
Netscape management gave "make it look like Java" orders. There was no time, on top of this. Last (more below in another reply) no extant command line interpreter was ready to be put in a browser. Way too many non-portable OS dependencies, unsafe FFI, etc. It was JS or bust (aka VBScript).
This I'll never understand. Why, for god sake why, did he had to create such a terrible scripting language while he had plenty of great open source existing ones ? I mean:
- lua appeared 2 years before
- python 5 years before
- perl 7 years
Instead we have this monstrosity with no namespace, terrible error handling, pitiful stdlib, limited expressiveness, atrocious data structure and type handling, so full of traps and gotchas we had to write a book about the part of the languages not to use.
I've read that he'd wanted to just use Scheme, but that they needed the language to have "Java" in the name, as well as curly braces. So, we got Javascript.
Lastly, because S-expressions can represent everything that is representable in SGML/XML/(X)HTML, but more succinctly, we could have basically had Scheme instead of HTML.
Imagine if, instead of JS/HTML/CSS, we had... Scheme. I'm pretty sure that the alter universes where this happened also all have peace, warp drives, and working cold fusion.
> Lastly, because S-expressions can represent everything that is representable in SGML/XML/(X)HTML, but more succinctly, we could have basically had Scheme instead of HTML.
I suggest (along with David Moon (Lisp Machine)) that a key disadvantage of sexp with respect to *ML, is that there's no place to hang on "extra stuff". Many lisps allow you to decorate the nodes with properties once the nodes are read, but the properties lack a printed representation. It's a homoiconicity fail. Sort of like not allowing comments in JSON might be, if a common case was then to attach comments to the objects after they're loaded. That very isn't common, so the restrictiveness is worth it. It's not clear that's the case with sexp.
Considering the language was first called Mocha and then Livescript, "Java in the name" was not a requirement - it's just that OO and Java were all the rage at the time, so they followed the fashion.
The worst crime Sun ever committed will turn out to be influencing the birth of JS.
Glibly listing unsafe languages that would have been crippled and flash-frozen if (impossible in the time allotted) jammed into Netscape 2 caused me to find this old comment for you:
Lua is another thing that shouldn't really have happened, since Tcl already better served its niche. Sometimes it's like the whole tech industry is sleepwalking backwards.
Lua was successful for good reasons. And Lua itself acknowledged Tcl, but didn't have the right trade offs for them.
"In 1993, the only real contender was Tcl, which had been explicitly designed to be embedded into applications. However, Tcl had unfamiliar syntax, did not offer good support for data description, and ran only on Unix platforms. We did not consider LISP or Scheme because of their unfriendly syntax. Python was still in its infancy. In the free, do-it-yourself atmosphere that then reigned in Tecgraf, it was quite natural that we should try to develop our own scripting language ... Because many potential users of the language were not professional programmers, the language should avoid cryptic syntax and semantics. The implementation of the new language should be highly portable, because Tecgraf's clients had a very diverse collection of computer platforms. Finally, since we expected that other Tecgraf products would also need to embed a scripting language, the new language should follow the example of SOL and be provided as a library with a C API."
Come on, much that I like playing with Tcl, the programmers world is a better place because of Lua/LuaJIT. If for nothing else but a pedagogic demonstration of a well designed small language.
At that time they already had C#, so it's not impossible to believe they could have done better than vbs.
The real problem would have been that they would have had to give other browsers a chance to adopt the new language, possibly even by providing dedicated resources to implement it for them; but Ballmer's MS didn't really "do" cooperation, they were happy to push ActiveX to lock out competitors.
Sometimes it seems as if every project is either a) everyone's first in a brand new language or b) maintaining a project that was everyone's first in a brand new language. How can we actually make progress like this?
> Tech is driven by fashion more than anything else
So I agree the field has remained disorganized, with it's research and development severely underfunded. There is no language implementation wiki. The field's research is often by years of intermittent incremental papers, and little bus-factor one projects. We're down to like one biggish industrial research lab. And ARPA, sigh. And professional progress, often seems sort of exploration by an army of wandering ants, rather than purposeful pursuit of economic development and human progress.
So with the poorly organized professional knowledge, and the unacceptability of high onboarding costs, yes, there's a lot of random motion. And the scrambling mob carves a flood plain.
But.
Cohort learning is actually a good learning strategy. And given how big the field has gotten, and the criticality of community, it's a plausible local heuristic to "follow the mob - it's path will likely at least be plausible, even though not optimum, and the inevitable obstacles can be collaborative tunneled through, or filled in with bodies". And the profession is not just larger, but vastly better trained than it used to be. There's a massive education process in progress.
And the "driven by fashion" argument gets used a lot. At least sometimes, it's clearly an "argument from failure of imagination". A "I can't imagine what they're thinking, they must all be nuts". Sometimes your expertise in some domain corner is enough to confidently say that. Or the nuttiness is nicely compact - "Google backs it, so I'm sure it will be supported for decades". But it seems most use of the argument is more... ambitious than that.
> Tcl is a powerful language that you can use to create complex systems with simple code, the holy grail.
Tcl/Forth/Smalltalk/Lisp/Self/APL/Oz/... we've had many many languages with glints of grail. We're just still really bad at combining and polishing them.
There's little funding for it. So it's a multi-decade incremental creep. An "if you're still alive to see it" bright side might be, it looks like the transition to "no longer crippling", when it finally happens, might be a "boom - new world" kind of thing.
EDIT: aside: I saw the other day that React native(?) could now be packaged up with it's own little embedded faux file system... and thought, yay, we're catching up with 1990's Tcl! (The Tcl app distribution story was excellent). You just need to have a half century of patience, and it will all work out. Patents only last two decades. And we're only failing, what, 7 billion people? Delay a year, miss a 130 million person cohort. No problem.
Yes, in the land of TLAs (three letter acronymis) or FLAs that is IT, having to pronounce TCL or TK is really hard :)
Speaking of which, is it "sequel" or "S.Q.L"? Is it "gooey" or "G.U.I"? I heard people also dropped SQL and GUI because they were confused by the pronunciation...
In a Lisp, code is trivially parsed because everything is a tree of conses, and the language derives tremendous power from that.
In Tcl, code is trivially parsed because everything is a string, and the language is hamstrung by it; it's a little like trying to code a major project in Bourne shell.
For a time, Tcl had the best C integration story of the scripting languages, with a thoughtfully designed extension interface that was easy to use. But every major scripting language has that now.
Tcl was early to what I guess I'll call mainstream metaprogramming (obviously, Lisp got there first) with "upvar" and "uplevel" and [incr tcl]. But Ruby --- which bears a lot of similarities to Tcl --- did all that stuff much better and more cleanly.