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.
> 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.
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.
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).
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.
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?
Correct. Elm's publicity issues stem from how closed off the leadership is. There's Evan (creator) and a handful of trusted others that have a huge amount of sway over how the language and, arguably more importantly, the core libraries develop. They also get special access to write libraries that rely on native JS code (something you can't do as of 0.19 even locally in your own projects).
Elm is a great language and I've written extensively[1] about how nice it is to use in production. But if you want to get involved in the community, it feels like there's not much to get involved in. The fact that even on the Elm Discourse[2], posts auto-lock after 10 days means that the forum is now pretty dead compared to what it used to be in 2018-2019.
I have the same feeling with Swift.
I did a refactor recently w/o really thinking about it, just fixing (compilation) errors as they happened, and it just worked on first try.
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.
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.
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.
