4 ms·

It's weird, I spent 3 years working on one of what must have been the largest TCL codebases in existence, since then I've reached for the language exactly zero

It's weird, I spent 3 years working on one of what must have been the largest TCL codebases in existence, since then I've reached for the language exactly zero times in personal or professional use. I have very little fondness for the language.

jakswa 3y ago
same. Back in ~2009 I had the pleasure/horror of debugging/fixing "TCL drivers" for a piece of Java software that aimed to integrate with various pieces of hardware. I'll never risk putting anyone else through a similar torture if I can help it. ...then again I've left a trail of Ruby/Rails behind me that might get the same job done :)
jacknews 3y ago
I think the comparison to bash etc is apt. tcl is definitely much better, but equally uninspiring.
- mikrotikker 3y ago
  More like PHP in my mind.
IggleSniggle 3y ago
I think it is extremely cool as a toy language. I've loved learning it for fun. I absolutely never ever would want to have to use it to do something productive
- nmz 3y ago
  What would you use instead?
  - IggleSniggle 3y ago
    For almost all the things I would use tcl for, I would instead pick whatever scripting language my team happens to be most comfortable with, with an eye on any larger company norms. In my various organizations, this has usually meant one of: - python - nodejs - bash Of those, I personally would prefer bash as the “organizer of commands,” but that’s probably not surprising from someone who would learn tcl for fun. Usually, the use case for these things is some combination of gluing programs together or gluing programs to the specifics of their OS. In that regard you might think, that picking a language specific for the problem at hand would be wise. But pragmatically, I believe you want devs who are mostly focused on feature work in their own programs to nevertheless be able to “bring their head above the water” and still have immediate intuition about how to swim. So even though nodejs might suck for this, it’s also extremely approachable for somebody who spends all their days in js. I am really drawn to the idea of doing all of this in something like nix, but I tried it and didn’t have time to get past the learning curve. And that points to the other issue: You’re probably going to need to glue rpm scripts, Dockerfiles, specific system tools which have different amounts of portability, etc. At the end of the day, if there’s a “lingua franca” for the organization, it usually makes sense to use it so that nobody needs to spend any time becoming accustomed to the idioms of some unfamiliar language while they are simultaneously dealing with the unfamiliar terrain of dealing with other systems that they have very incomplete knowledge of. If there’s no lingua franca, I default to bash as a larger lingua franca
- lanstin 3y ago
  In the 1990s the services in AOL were all written in C, using a very very good event based callback library, which had Tcl embedded in it. We had a very rigorous standard of nothing in the server was hard wired, any change that ops might want to make would be applied to a running server, and dev had the job to expose all configurable state as either Tcl Vars or Tcl commands. It was a no thread environment (one process per CPU and one CPU for the OS) so while your Tcl command was running you could do anything to the in memory structures you wanted as long as it was fast. The ability to have a Turing complete language available for ops to do config in was extremely useful, they wrote amazing Tcl making configuration on the fly. Not sure any of it would have carried thru till today even if the business hadn’t stumbled, but it very productive in the 1990s.
- karl_gluck 3y ago
  This is a more interesting take to me than others since it seems you’ve actually learned it? I see the response later that you’d rather use whatever the team already uses, but could you explain this very strong opinion? I maintained a 200,000 loc TCL codebase running the front end for millions of lines of industrial C spread over hundreds of machines. It was glorious. After moving on, I’m still struggling to figure out why TCL is so unpopular outside that domain. Other comments seem to boil down to not understanding the language or how to apply it. So what’s your take?
  - IggleSniggle 3y ago
    That does sound glorious. And, to be clear, I am merely an amateur (lover of) rather than experienced practitioner. It’s also the only lisp-like I’ve learned, and it gets a fair amount of credit from me on those grounds alone. At any rate, the opinion is very strong because 1) the pragmatic angle that I’ve already mentioned, 2) the tooling hasn’t kept up, 3) the performance isn’t worth fighting for (although it’s really still fairly good), 4) the footguns are gloriously just around the corner. I don’t know if all lisps suffer from that last one, and I don’t know about you, but there seems to be a clever solution hiding in every line. I think it would take discipline to have a codebase that remained cohesive and in a “single language”
thenewwazoo 3y ago
For a company in the rental automobile space?

jakswa 3y ago

same. Back in ~2009 I had the pleasure/horror of debugging/fixing "TCL drivers" for a piece of Java software that aimed to integrate with various pieces of hardware. I'll never risk putting anyone else through a similar torture if I can help it. ...then again I've left a trail of Ruby/Rails behind me that might get the same job done :)

jacknews 3y ago

I think the comparison to bash etc is apt. tcl is definitely much better, but equally uninspiring.

mikrotikker 3y ago
More like PHP in my mind.

IggleSniggle 3y ago

I think it is extremely cool as a toy language. I've loved learning it for fun. I absolutely never ever would want to have to use it to do something productive

nmz 3y ago
What would you use instead?
- IggleSniggle 3y ago
  For almost all the things I would use tcl for, I would instead pick whatever scripting language my team happens to be most comfortable with, with an eye on any larger company norms. In my various organizations, this has usually meant one of: - python - nodejs - bash Of those, I personally would prefer bash as the “organizer of commands,” but that’s probably not surprising from someone who would learn tcl for fun. Usually, the use case for these things is some combination of gluing programs together or gluing programs to the specifics of their OS. In that regard you might think, that picking a language specific for the problem at hand would be wise. But pragmatically, I believe you want devs who are mostly focused on feature work in their own programs to nevertheless be able to “bring their head above the water” and still have immediate intuition about how to swim. So even though nodejs might suck for this, it’s also extremely approachable for somebody who spends all their days in js. I am really drawn to the idea of doing all of this in something like nix, but I tried it and didn’t have time to get past the learning curve. And that points to the other issue: You’re probably going to need to glue rpm scripts, Dockerfiles, specific system tools which have different amounts of portability, etc. At the end of the day, if there’s a “lingua franca” for the organization, it usually makes sense to use it so that nobody needs to spend any time becoming accustomed to the idioms of some unfamiliar language while they are simultaneously dealing with the unfamiliar terrain of dealing with other systems that they have very incomplete knowledge of. If there’s no lingua franca, I default to bash as a larger lingua franca
lanstin 3y ago
In the 1990s the services in AOL were all written in C, using a very very good event based callback library, which had Tcl embedded in it. We had a very rigorous standard of nothing in the server was hard wired, any change that ops might want to make would be applied to a running server, and dev had the job to expose all configurable state as either Tcl Vars or Tcl commands. It was a no thread environment (one process per CPU and one CPU for the OS) so while your Tcl command was running you could do anything to the in memory structures you wanted as long as it was fast. The ability to have a Turing complete language available for ops to do config in was extremely useful, they wrote amazing Tcl making configuration on the fly. Not sure any of it would have carried thru till today even if the business hadn’t stumbled, but it very productive in the 1990s.
karl_gluck 3y ago
This is a more interesting take to me than others since it seems you’ve actually learned it? I see the response later that you’d rather use whatever the team already uses, but could you explain this very strong opinion? I maintained a 200,000 loc TCL codebase running the front end for millions of lines of industrial C spread over hundreds of machines. It was glorious. After moving on, I’m still struggling to figure out why TCL is so unpopular outside that domain. Other comments seem to boil down to not understanding the language or how to apply it. So what’s your take?
- IggleSniggle 3y ago
  That does sound glorious. And, to be clear, I am merely an amateur (lover of) rather than experienced practitioner. It’s also the only lisp-like I’ve learned, and it gets a fair amount of credit from me on those grounds alone. At any rate, the opinion is very strong because 1) the pragmatic angle that I’ve already mentioned, 2) the tooling hasn’t kept up, 3) the performance isn’t worth fighting for (although it’s really still fairly good), 4) the footguns are gloriously just around the corner. I don’t know if all lisps suffer from that last one, and I don’t know about you, but there seems to be a clever solution hiding in every line. I think it would take discipline to have a codebase that remained cohesive and in a “single language”

thenewwazoo 3y ago

For a company in the rental automobile space?