4 ms·

> Tcl has declined in use over the years, and while there's a vocal community of people who like it, To my way of thinking, Tcl is one of the languages that fa

> Tcl has declined in use over the years, and while there's a vocal community of people who like it, To my way of thinking, Tcl is one of the languages that falls into the same category as Lisp, Smalltalk, and Forth. Like those three, Tcl takes a relatively smaller number of concepts compared to most other languages and tries to get more mileage out of combining them together than resorting to adding new conceptual layers. For Tcl, the core concepts strings and string manipulation. Most languages have these things, but very few languages build their list libraries, evaluators, etc. nearly as directly upon them as does Tcl. The net result of this approach is a language that's almost guaranteed to feel strange for the vast majority of developers, who work in languages that tend to be composed of larger numbers of more specialized features. So immediately off-putting to large numbers of potential users. The other property these languages share, once you get past the initial barriers to entry, is a certain sense of enablement and power. The first few times, you realize how control flow structures, etc. are easily implemented in terms of user-visible language constructs, it's at first gratifying and exciting to see and then potentially enabling. After all, it's easier to write a custom expression evaluator in Tcl than, say Java or Python. So the community of opinion around these opinions tend to bifurcate along lines of whether or not the individual in question has spent enough time to truly 'grok' the nature of the language. And note that this can be totally orthogonal to opinions on whether or not the language should actually be used. It's easily possible to not 'get' the nature of Tcl or Lisp and yet have it be the thing you have to write to program your EDA tool or AutoCad. Similarly, it's easily possible to see the power of a language like Tcl and lament either that too few people understand its full power or that it's full power is maybe too flexible to be used in a production setting on a large industrial project. None of that means these languages are not worth pursuing, but I do think this line of thought helps explain how they succeed and fail in the marketplace of ideas. > I never got the impression that Tcl was popular nor that its popularity was increasing. Because it was developed as part of work on EDA tools, it developed a niche there. Also in early web via AOLserver. Where it truly shown, however, was in GUI programming on Unix. Tcl and its GUI library Tk were around X11 before virtually anything other than the original Xt-derived widget libraries. Even more than that, you could open up an interactive 'wish' session and get an active and clickable button on the screen in literally three interactive commands. Compared in ease of use of almost anything other than Visual Basic, Tcl/Tk was light years ahead, and Tcl/TK far surpassed VB in expressivity. (For the reasons I mention above.) Between this and a few other libraries like 'expect', it's hard to overstate exactly how much power Tcl/Tk put in your hands, and relatively easy to use at that. To be honest, there are still large swaths of modern development where we've really regressed in expressive power. (Although HTML/JS does make it pretty easy to get a button on the screen in the simplest case.)

adwn 6y ago
> The other property these languages share, once you get past the initial barriers to entry, is a certain sense of enablement and power. That's the thing that Lisp/Smalltalk/Forth/Tcl proponents, who lament the unpopularity of their favorite language [1], frequently get wrong. It's not the case that others don't see the light and don't grok the power and flexibility that those languages bring, but that those don't really matter that much in most practical use cases, and that they're even detrimental to building and maintaining a large code base with multiple developers. Yes, it's great that you can write your own control flow constructs. So what? A sane language already includes those constructs, and they're known and understood by all users of the language without having to first read the documentation of some third-party lib (haha, just kidding, there is none – read the code, dummy!). [1] I don't mean to imply that you're one of them, I'm talking in general.
- zeveb 6y ago
  > Yes, it's great that you can write your own control flow constructs. So what? A sane language already includes those constructs, and they're known and understood by all users of the language without having to first read the documentation of some third-party lib (haha, just kidding, there is none – read the code, dummy!). I do not believe that novel control statements are any different from novel functionality. A sane language already includes plenty of standard functions, but that doesn't relieve the need for more. New functions, like new control statements, may be poorly documented. The fundamental power of computing is abstraction. Functions, macros and control structures are all different types of abstraction. The only way to build a successful, malleable large program is to abstract, and to avoid macros and new control structures is simply to require larger teams (because someone has to hand-write all the code which the computer could be writing for you) and more ad hoc approaches.
  - adwn 6y ago
    > A sane language already includes plenty of standard functions, but that doesn't relieve the need for more. The difference is that I write new functions on a daily basis, while I almost never need new control flow constructs. And if it turns out that such a construct would be useful, then it's almost always better to also have syntax and compiler support for it (for error checking, more descriptive parser errors, optimizations).

adwn 6y ago

> The other property these languages share, once you get past the initial barriers to entry, is a certain sense of enablement and power. That's the thing that Lisp/Smalltalk/Forth/Tcl proponents, who lament the unpopularity of their favorite language [1], frequently get wrong. It's not the case that others don't see the light and don't grok the power and flexibility that those languages bring, but that those don't really matter that much in most practical use cases, and that they're even detrimental to building and maintaining a large code base with multiple developers. Yes, it's great that you can write your own control flow constructs. So what? A sane language already includes those constructs, and they're known and understood by all users of the language without having to first read the documentation of some third-party lib (haha, just kidding, there is none – read the code, dummy!). [1] I don't mean to imply that you're one of them, I'm talking in general.

zeveb 6y ago
> Yes, it's great that you can write your own control flow constructs. So what? A sane language already includes those constructs, and they're known and understood by all users of the language without having to first read the documentation of some third-party lib (haha, just kidding, there is none – read the code, dummy!). I do not believe that novel control statements are any different from novel functionality. A sane language already includes plenty of standard functions, but that doesn't relieve the need for more. New functions, like new control statements, may be poorly documented. The fundamental power of computing is abstraction. Functions, macros and control structures are all different types of abstraction. The only way to build a successful, malleable large program is to abstract, and to avoid macros and new control structures is simply to require larger teams (because someone has to hand-write all the code which the computer could be writing for you) and more ad hoc approaches.
- adwn 6y ago
  > A sane language already includes plenty of standard functions, but that doesn't relieve the need for more. The difference is that I write new functions on a daily basis, while I almost never need new control flow constructs. And if it turns out that such a construct would be useful, then it's almost always better to also have syntax and compiler support for it (for error checking, more descriptive parser errors, optimizations).