5 ms·

I've managed to work on two TCL codebases in my career, one in 1992ish, and one in 2011ish. I was very surprised to be working on it the second time! I've said

I've managed to work on two TCL codebases in my career, one in 1992ish, and one in 2011ish. I was very surprised to be working on it the second time! I've said it before, but working on TCL is interesting, kinda fun, and ultimately a lesson in frustration once you get to a certain sized codebase. It really hammered home the need for static typing as your repo gets over 50k lines because it is so "type free". However, it is a cool thought experiment for it's premise, which is more-or-less, "what if everything is a string". It has a lot of benefits, and a lot of nasty side effects. I'm glad I spent time doing it, and I think the use case for which it was made ("Tool Control" roughly speaking) it has good ideas. TK was fun, as well, I miss it in some ways. But ultimately, I find TCL is a dead end for a programming language - the negatives accumulate too quickly.

keithalewis 3y ago
You can have any type you want, as long as it's a string. :-) Don't forget about https://core.tcl-lang.org/expect/index https://core.tcl-lang.org/expect/index. Comes in very handy sometimes.
- kevin_thibedeau 3y ago
  Tcl hasn't been string based for over 20 years. It's time for this myth to die.
  - tyingq 3y ago
    If it's a myth, the myth seems driven by the TCL team itself. https://wiki.tcl-lang.org/page/everything+is+a+string https://wiki.tcl-lang.org/page/everything+is+a+string Yes, there is some detail about internal dual representation.
    - kevin_thibedeau 3y ago
      That wiki page has been around since before Tcl 8. Nobody says lisp is hampered because everything is an S-expr.
      - tyingq 3y ago
        > That wiki page has been around since before Tcl 8 Maybe, but it's clearly been updated after Tcl 8. And while the page itself isn't calling it something that hampers tcl, it does cover that it's somewhat unusual, that is has implications, and so on.
        dkfellows 3y ago
        Technically, all values are considered subtypes of strings, but the notion of types is quite different to those of many other languages. In particular, Tcl's types do not describe the memory storage model of their values. (They're implemented with 64-bit words and buffers and arrays and so on, but that's not what the value model describes.) It works well as long as your goal isn't to totally eliminate boxing of values.
- zylent 3y ago
  after using expect and TCL heavily for years, I can firmly say they suck at scale. Ruby https://github.com/ytti/oxidized/blob/master/lib/oxidized/model/ios.rb https://github.com/ytti/oxidized/blob/master/lib/oxidized/mo... or TextFSM https://github.com/google/textfsm https://github.com/google/textfsm are much better options if you need to do a /lot/ of parsing
- cpeterso 3y ago
  Tcl may not be strongly typed, but it is "stringly typed". :)
7thaccount 3y ago
I never understand people's frustrations until I hear 50k loc base lol. That sounds hard in any language. I'd guess Tcl is pretty awesome if you keep things around 1000 loc or below (i.e. scripting).
- 999900000999 3y ago
  In something like C# or Java with a good ide I imagine it's not too bad. Interpreted languages like Python and JavaScript do suffer when code bases reach a certain size.
  - ElectricalUnion 3y ago
    Even adding half-baked, not compile/runtime checked types such as "Python's Type annotations", "Python's Type Stubs", "Javascript @type-infused-jsdocs" and "Javascript with Typescript Declaration Files" manages to make those modern IDEs a lot smarter for things like checking if you're doing really obvious bad things until you go really ham into metaprogramming.
- girishso 3y ago
  > That sounds hard in any language. Yes, it is hard in many languages, having experienced it first hand. Just wanted to point out my experience with Elm (I know) 200k loc, I can refactor the codebase fearlessly, knowing that once it compiles it will "mostly" just work. I fondly remember porting Elm 0.18 to 0.19, which was a big change in the language itself and the libs, me and my co-worker working across time zones almost 24/7 for over a week to make the damn thing compile, it was like struggling in the darkness, unable to see "anything" in the browser for like 7 days and when it finally compiled.. it mostly just worked! It's sad that to see Elm getting so much negative publicity, but I do enjoy working every day on it.
  - westernpopular 3y ago
    Last I checked Elm was getting negative publicity not because of the language itself (heard a lot of good things about that) but because of the leadership?
mikrotikker 3y ago
I still work on a TCL codebase. I hate it. It makes heavy use of upvars, uplevels, and even a DSL written in TCL. It's so limiting. The interpreter only uses a single thread so better hope you don't need to do much computing with it. It's so hard to debug. Oh and be careful not to use brackets in your comments cos it interprets comments as if they're code... The codebase is too big to rewrite but we're slowly untangling and hacking bits off to write in golang, but most of the business logic is in that DSL.
xedrac 3y ago
It's the exact same story with Python and Lisp. I love dynamically typed languages for fun little projects, but really don't like working with them on big must-not-fail type projects.

keithalewis 3y ago

You can have any type you want, as long as it's a string. :-) Don't forget about https://core.tcl-lang.org/expect/index https://core.tcl-lang.org/expect/index. Comes in very handy sometimes.

kevin_thibedeau 3y ago
Tcl hasn't been string based for over 20 years. It's time for this myth to die.
- tyingq 3y ago
  If it's a myth, the myth seems driven by the TCL team itself. https://wiki.tcl-lang.org/page/everything+is+a+string https://wiki.tcl-lang.org/page/everything+is+a+string Yes, there is some detail about internal dual representation.
  - kevin_thibedeau 3y ago
    That wiki page has been around since before Tcl 8. Nobody says lisp is hampered because everything is an S-expr.
    - tyingq 3y ago
      > That wiki page has been around since before Tcl 8 Maybe, but it's clearly been updated after Tcl 8. And while the page itself isn't calling it something that hampers tcl, it does cover that it's somewhat unusual, that is has implications, and so on.
      - dkfellows 3y ago
        Technically, all values are considered subtypes of strings, but the notion of types is quite different to those of many other languages. In particular, Tcl's types do not describe the memory storage model of their values. (They're implemented with 64-bit words and buffers and arrays and so on, but that's not what the value model describes.) It works well as long as your goal isn't to totally eliminate boxing of values.
zylent 3y ago
after using expect and TCL heavily for years, I can firmly say they suck at scale. Ruby https://github.com/ytti/oxidized/blob/master/lib/oxidized/model/ios.rb https://github.com/ytti/oxidized/blob/master/lib/oxidized/mo... or TextFSM https://github.com/google/textfsm https://github.com/google/textfsm are much better options if you need to do a /lot/ of parsing
cpeterso 3y ago
Tcl may not be strongly typed, but it is "stringly typed". :)

7thaccount 3y ago

I never understand people's frustrations until I hear 50k loc base lol. That sounds hard in any language. I'd guess Tcl is pretty awesome if you keep things around 1000 loc or below (i.e. scripting).

999900000999 3y ago
In something like C# or Java with a good ide I imagine it's not too bad. Interpreted languages like Python and JavaScript do suffer when code bases reach a certain size.
- ElectricalUnion 3y ago
  Even adding half-baked, not compile/runtime checked types such as "Python's Type annotations", "Python's Type Stubs", "Javascript @type-infused-jsdocs" and "Javascript with Typescript Declaration Files" manages to make those modern IDEs a lot smarter for things like checking if you're doing really obvious bad things until you go really ham into metaprogramming.
girishso 3y ago
> That sounds hard in any language. Yes, it is hard in many languages, having experienced it first hand. Just wanted to point out my experience with Elm (I know) 200k loc, I can refactor the codebase fearlessly, knowing that once it compiles it will "mostly" just work. I fondly remember porting Elm 0.18 to 0.19, which was a big change in the language itself and the libs, me and my co-worker working across time zones almost 24/7 for over a week to make the damn thing compile, it was like struggling in the darkness, unable to see "anything" in the browser for like 7 days and when it finally compiled.. it mostly just worked! It's sad that to see Elm getting so much negative publicity, but I do enjoy working every day on it.
- westernpopular 3y ago
  Last I checked Elm was getting negative publicity not because of the language itself (heard a lot of good things about that) but because of the leadership?

mikrotikker 3y ago

I still work on a TCL codebase. I hate it. It makes heavy use of upvars, uplevels, and even a DSL written in TCL. It's so limiting. The interpreter only uses a single thread so better hope you don't need to do much computing with it. It's so hard to debug. Oh and be careful not to use brackets in your comments cos it interprets comments as if they're code... The codebase is too big to rewrite but we're slowly untangling and hacking bits off to write in golang, but most of the business logic is in that DSL.

xedrac 3y ago

It's the exact same story with Python and Lisp. I love dynamically typed languages for fun little projects, but really don't like working with them on big must-not-fail type projects.