8 ms·

LMDB: The first version of Redis, written in Tcl (2009)

186 points by avinassh 3y ago

LispSporks22 3y ago
I have good feels about Tcl. How come it fell out of favor?
- Cyph0n 3y ago
  Still huge in the circuit design/EDA (electronic design automation) space.
  - Aromasin 3y ago
    Yup, used in all the FPGA software tools. A lot of the new stuff coming out of Quartus at least is being written in Python though, or rewritten as such. Having worked in the field for the past year, I've definitely got quite a few gripes with the Tcl after some exposure. The syntax is not intuitive, especially for a scripting language. The standard library is far too small, basically just a subset of the C standard library plus regexps. The only true data types in Tcl are strings and associative arrays. As such, Tcl scripts do not scale very well. The performance is generally abysmal, not just because of the magic string conversions, but because standard library functions are incredibly slow in cases that are hard to avoid. Tcl fully parses lines before deciding that they should be executed (in the case of a command) or ignored (in the case of a comment). You should think of a comment as a "do nothing" command, rather than as a comment as in other languages. While not too egregious, if you're used to other languages that quirk causes numerous grievances. One positive is it's really easy to drop down into C or C++ when you come across tasks that make more sense in a lower-level language, so if you're using it for that purpose it's good.
    - bch 3y ago
      > Tcl fully parses lines before deciding that they should be executed (in the case of a command) or ignored (in the case of a comment). I don't know your measurements or use case but putting code in a [proc] will engage the bytecode compiler which might help you out?
- VWWHFSfQ 3y ago
  It has some niche use-cases but I think in general it was just too awkward. "Everything is a string" kinda puts people off. Lua has similar weirdness with various aspects but it's still highly successful in other niche areas. I happen to really like Lua. But a lot of people don't like the 1-based indexing and table container can be difficult for people get wrap their head around.
  - bch 3y ago
    > "Everything is a string" kinda puts people off. I can't speak for "people", but i think this might be a bit of misunderstanding combined w an implementation detail. I think most Tcl people these days would say "everything is representable as a string", which is to say types can be marshalled back/forth through a string representation. This (with other features) allows Tcl to be homoiconic[0] (it can evaluated the symbols it emits itself). Pre-8[1] (1997/1998(?)) Tcl internals did also indeed use char* strings to do its own work parsing/evaluating, but Tcl8 brought in so called Tcl_Obj structures w "dual ported" values that keep the iconic string representation available, as well as a native value (ie: integer when using the value as an integer, so you wouldnt need to do something like atoi() on a string rep when you wanted to do math). [0] https://en.wikipedia.org/wiki/Homoiconicity https://en.wikipedia.org/wiki/Homoiconicity [1] https://tcl.tk/software/tcltk/8.0.html https://tcl.tk/software/tcltk/8.0.html
    - IshKebab 3y ago
      Semantically everything is a string, even if they have performance optimisations to make that slightly less insane. Performance is only one of the issues with "everything is a string". Bug-proneness is probably a bigger issue and you can't fix that with optimisations.
  - jollyllama 3y ago
    Yes, it makes debugging a large or distributed TCL application hellish. Once you have had to deal with that, you will be put off of TCL for life.
  - canadianfella 3y ago
- lockhouse 3y ago
  I think there were several factors. While Tk (one of Tcl’s major killer apps) looked good on Windows and Mac, it retained the Motif look and feel for too long on UNIX platforms. This gave the impression of it being obsolete technology and made many people dismiss it for use in serious applications. It lacked a major company championing and investing in it. Its creator Dr. Ousterhout, moved onto other projects. Python, JavaScript, Ruby, and PHP won out on the scripting language popularity contest at the expense of Perl and Tcl. Richard Stallman had very strong opinions about Tcl that also did it no favors. This was known as the “Tcl War.” https://vanderburg.org/old_pages/Tcl/war/ https://vanderburg.org/old_pages/Tcl/war/
  - IshKebab 3y ago
    > If Tcl does become the "standard scripting language", users will curse it for years--the way people curse Fortran, MSDOS, Unix shell syntax, and other de facto standards they feel stuck with. Hear hear. Just Bash left to kill (and TCL in EDA but I won't hold my breath there - hardware people think they aren't software engineers so they don't care about software quality).
    - deleted 3y ago
      [deleted]
  - zerr 3y ago
    So the Lisp-like is Guile. Did they ever come up with the second (algebraic) language?
- orthoxerox 3y ago
  It spent too long actually storing everything as strings internally. When tcl 8 was finally released in 1999, tcl already had a reputation, people have been writing cgi-bin scripts in Perl for 6 years already and PHP was on the rise. Homoiconicity is cool, but cool doesn't necessarily mean useful.
- nobleach 3y ago
  I still recall coming across the "Sams Teach Yourself Tcl/Tk in 24 Hours" book at my office. I had been doing Linux Samba administration at that time and some of the tooling was written in tcl. So I brought the book home. It was the first time I had ever doing any GUI stuff that wasn't Delphi/VB/FoxPro! I loved it! I quickly realized I had nothing interesting I needed to build at that moment... so I put it back down. But just realizing that GUI programming was in reach without all the heavy Win32/GDI or Winforms, was so cool.
  - zerr 3y ago
    I felt the same, but with GTK.
- IshKebab 3y ago
  We got much better options... Basically anything really but even not-very-good languages like JavaScript and Python are significantly better than TCL. The only thing that TCL really beats is Bash. If you are restricted to easily embeddable languages then the options are much more limited, but even so there are obviously better options like Lua, or even rolling your own (e.g. GDScript, QuakeC). The only people still using TCL are those that can't leave 90% in the past, e.g. the entire EDA industry.
- ncr100 3y ago
  I am tickled to see this, first Redis implementation in TCL. TCL was (is?) slow and there was not the userbase that needed it, at the time, in my view. Maybe now with more diverse programmers addressing more diverse use-cases with their software, TCL can be more relevant.
- sokoloff 3y ago
  I've written a lot of Tcl in my career. I don't know if it "fell out of favor" as much as "never really had a ton of favor even at its peak". I have used it in the last decade to do some build system tooling where string/regex processing of log files emitted in prior steps was a big part of the functionality. It was nice that "nobody else is using Tcl, so I won't have any versioning conflicts" and that held true for over a decade, so the long-term cost was reasonable. If I had to learn a new language today, I can't say that I'd put Tcl very high on the list, despite being overall happy with it.
- Gordonjcp 3y ago
  VHS vs. Beta, basically. Tcl and Perl are about the same age, approximately similar in function, approximately similar in ease-of-use, and really the world could have gone either way. Just as with VHS and Beta, each had their strengths and weaknesses, but ultimately it came down to an avalanche of the "network effect" - everyone was using VHS so everyone used VHS / everyone was using Perl so everyone used Perl.
- davidw 3y ago
  I have some thoughts about that, as someone who had a small role in that community: https://journal.dedasys.com/2010/03/30/where-tcl-and-tk-went-wrong/ https://journal.dedasys.com/2010/03/30/where-tcl-and-tk-went...
- themerone 3y ago
  I read an opinion that the TCL community was divided into two factions. One faction wanted a lua like small embeddable interpreter. The other wanted a full feature Python like platform. Neither faction won, so TCL got stuck in the middle. I don't know if this is true, but it was such an interesting opinion, that it stuck with me.
torh 3y ago
I would recommend going back 9 days and read the story behind Redis: https://news.ycombinator.com/item?id=35871462 https://news.ycombinator.com/item?id=35871462
- dang 3y ago
  Thanks! Also related: LMDB – First version of Redis written in Tcl - https://news.ycombinator.com/item?id=14230960 https://news.ycombinator.com/item?id=14230960 - April 2017 (25 comments) Redis - https://news.ycombinator.com/item?id=494649 https://news.ycombinator.com/item?id=494649 - Feb 2009 (11 comments)
deleted 3y ago
[deleted]
tpmx 3y ago
That was certainly an unusual choice of language for a problem like that. But, I guess, use what you know. Seems like a decent fit, I didn't expect that - I mostly know Tcl from very odd Tcl/Tk GUI apps in the 90s/early 00s.
- ncr100 3y ago
  It's easy to prototype string passing tools with TCL, in my experience with the language at Uni.
- kristopolous 3y ago
  my favorite reference to it is in the HTML 4.0 standard https://www.w3.org/TR/1998/REC-html40-19980424/interact/scripts.html#h-18.2.2 https://www.w3.org/TR/1998/REC-html40-19980424/interact/scri... > "where "type" is an content type naming the scripting language. Examples of values include "text/tcl", "text/javascript", "text/vbscript"." It goes on to list text/tcl as a language, equivalent to javascript and even gives examples. There's a story behind this I read somewhere but I can't seem to find it. I once had one of those books that was like 500 pages by those companies like Que with a title like "The ___ Bible" which had at least a chapter on web tcl - in anticipation for the presumed support of it which I'll argue isn't around (besides this: https://wiki.tcl-lang.org/page/Using+Tcl+to+write+WWW+client+side+applications+within+the+WWW+browser https://wiki.tcl-lang.org/page/Using+Tcl+to+write+WWW+client...).
  - lmm 3y ago
    TCL/Tk was the original web-embedded language. You had TkLets, which were the inspiration for Java Applets and worked the same way (with a browser plugin etc.), but it was also suitable for Javascript-style scripting of webpages.
didip 3y ago
I think this is relevant... These are 3 OSS databases that can be an alternative to Redis: - KeyDB: https://github.com/snapchat/keydb https://github.com/snapchat/keydb - Dragonfly: https://github.com/dragonflydb/dragonfly https://github.com/dragonflydb/dragonfly - Skytable: https://github.com/skytable/skytable https://github.com/skytable/skytable I have used keyDB before. The raft consensus makes building an HA Redis easy.
- danogentili 3y ago
  We use keydb at work, and I absolutely do NOT recommend it due to its extreme instability, in fact we're currently in the process of switching to dragonfly precisely due to keydb's instability. Multimaster replication is convenient, but if you accidentally add the IP of the current replica to the replicaset, the entire cluster will crash if any of the nodes shuts down for any reason (note, not immediately, but days or even weeks after starting the cluster with everything working perfectly until one of the nodes crashes or shuts down). Enabling diskless replication in multimaster mode causes either deadlocks, or immediate crashes, depending on the overall LA of the system (!). These are just the issues I remember right now, because the related issues I opened in the repo are still open almost a year later; we had other crashes we had to workaround, too.
  - jdsully 3y ago
    Sorry it didn't work well for you. In the 6.3 release we tried to pack in too much although we've ironed out most of the issues. The hardest change has been moving away from fork() for background saving which has historically caused a lot of pain for running it in production and makes it difficult to do persistence. I definitely would have paced things out better if I could go back in time.
    - micw 3y ago
      To me it's still not clear if 6.3.x is stable (https://github.com/Snapchat/KeyDB/issues/494 https://github.com/Snapchat/KeyDB/issues/494) and performant (https://github.com/Snapchat/KeyDB/issues/470 https://github.com/Snapchat/KeyDB/issues/470).
ilrwbwrkhv 3y ago
It's amazing seeing the init version of arguably one of the most popular software of the modern era. Goes to show how much programming is like writing. You keep iterating and making it better.
ben7799 3y ago
I'm more surprised Tcl was used in 2009 than I am at any praise or complaint about the quality of Tcl. I used Tcl and Expect (which was a very cool extension of Tcl) in the late 90s in some automation projects as an intern. It did the job and yet I was aware of some of it's issue. But that was so far before 2009. It felt like Tcl was almost done by 2000, I never saw it used again. Perl came and went, Lua had arrived, Python had arrived, etc.. Tcl to me is like Python.. pretty good for small projects by a small team. Not so desirable for a giant enterprise product/platform with a big team.
- klodolph 3y ago
  Tcl is super interesting from a historical point of view. It seems to hit about halfway between shell and Lisp. With some small differences, it probably would have competed more directly against Perl, Python, or maybe Lua. As it is, it gave us Wish, plus a bunch of GUI wrappers for shell scripts, and we’re thankful for those.
  - ben7799 3y ago
    I think some of it back then was there was less internet communication and Tcl could be popular one place and Python was popular in another place and Perl popular in another team. Now we discuss everything so much communities converge on a common choice. Perl & Tcl really share the issue that undisciplined developers could make really obfuscated code that was hard to decipher.
- yamtaddle 3y ago
  > I used Tcl and Expect (which was a very cool extension of Tcl) I used "expect" about five years ago to help automate deploying an app to a local Roku box from the command line. Much faster dev loop than having to upload a zip to a webpage hosted on the Roku box.
- sgt 3y ago
  Makes me wonder, are there any current projects still using tcl? I know DDG is still using perl.
gt565k 3y ago
mIRC tcl scripts and tcl scripts for Eggdrop IRC bots oh man, the nostalgia!
- metadat 3y ago
  mIRC has its own language, "mrc", not tcl. But yeah, those were fun times with the eggdrop botnets! Eggdrop could be so stable.. pretty much industrial grade.
deleted 3y ago
[deleted]

186 points by avinassh 3y ago

LispSporks22 3y ago

I have good feels about Tcl. How come it fell out of favor?

Cyph0n 3y ago
Still huge in the circuit design/EDA (electronic design automation) space.
- Aromasin 3y ago
  Yup, used in all the FPGA software tools. A lot of the new stuff coming out of Quartus at least is being written in Python though, or rewritten as such. Having worked in the field for the past year, I've definitely got quite a few gripes with the Tcl after some exposure. The syntax is not intuitive, especially for a scripting language. The standard library is far too small, basically just a subset of the C standard library plus regexps. The only true data types in Tcl are strings and associative arrays. As such, Tcl scripts do not scale very well. The performance is generally abysmal, not just because of the magic string conversions, but because standard library functions are incredibly slow in cases that are hard to avoid. Tcl fully parses lines before deciding that they should be executed (in the case of a command) or ignored (in the case of a comment). You should think of a comment as a "do nothing" command, rather than as a comment as in other languages. While not too egregious, if you're used to other languages that quirk causes numerous grievances. One positive is it's really easy to drop down into C or C++ when you come across tasks that make more sense in a lower-level language, so if you're using it for that purpose it's good.
  - bch 3y ago
    > Tcl fully parses lines before deciding that they should be executed (in the case of a command) or ignored (in the case of a comment). I don't know your measurements or use case but putting code in a [proc] will engage the bytecode compiler which might help you out?
VWWHFSfQ 3y ago
It has some niche use-cases but I think in general it was just too awkward. "Everything is a string" kinda puts people off. Lua has similar weirdness with various aspects but it's still highly successful in other niche areas. I happen to really like Lua. But a lot of people don't like the 1-based indexing and table container can be difficult for people get wrap their head around.
- bch 3y ago
  > "Everything is a string" kinda puts people off. I can't speak for "people", but i think this might be a bit of misunderstanding combined w an implementation detail. I think most Tcl people these days would say "everything is representable as a string", which is to say types can be marshalled back/forth through a string representation. This (with other features) allows Tcl to be homoiconic[0] (it can evaluated the symbols it emits itself). Pre-8[1] (1997/1998(?)) Tcl internals did also indeed use char* strings to do its own work parsing/evaluating, but Tcl8 brought in so called Tcl_Obj structures w "dual ported" values that keep the iconic string representation available, as well as a native value (ie: integer when using the value as an integer, so you wouldnt need to do something like atoi() on a string rep when you wanted to do math). [0] https://en.wikipedia.org/wiki/Homoiconicity https://en.wikipedia.org/wiki/Homoiconicity [1] https://tcl.tk/software/tcltk/8.0.html https://tcl.tk/software/tcltk/8.0.html
  - IshKebab 3y ago
    Semantically everything is a string, even if they have performance optimisations to make that slightly less insane. Performance is only one of the issues with "everything is a string". Bug-proneness is probably a bigger issue and you can't fix that with optimisations.
- jollyllama 3y ago
  Yes, it makes debugging a large or distributed TCL application hellish. Once you have had to deal with that, you will be put off of TCL for life.
- canadianfella 3y ago
lockhouse 3y ago
I think there were several factors. While Tk (one of Tcl’s major killer apps) looked good on Windows and Mac, it retained the Motif look and feel for too long on UNIX platforms. This gave the impression of it being obsolete technology and made many people dismiss it for use in serious applications. It lacked a major company championing and investing in it. Its creator Dr. Ousterhout, moved onto other projects. Python, JavaScript, Ruby, and PHP won out on the scripting language popularity contest at the expense of Perl and Tcl. Richard Stallman had very strong opinions about Tcl that also did it no favors. This was known as the “Tcl War.” https://vanderburg.org/old_pages/Tcl/war/ https://vanderburg.org/old_pages/Tcl/war/
- IshKebab 3y ago
  > If Tcl does become the "standard scripting language", users will curse it for years--the way people curse Fortran, MSDOS, Unix shell syntax, and other de facto standards they feel stuck with. Hear hear. Just Bash left to kill (and TCL in EDA but I won't hold my breath there - hardware people think they aren't software engineers so they don't care about software quality).
  - deleted 3y ago
    [deleted]
- zerr 3y ago
  So the Lisp-like is Guile. Did they ever come up with the second (algebraic) language?
orthoxerox 3y ago
It spent too long actually storing everything as strings internally. When tcl 8 was finally released in 1999, tcl already had a reputation, people have been writing cgi-bin scripts in Perl for 6 years already and PHP was on the rise. Homoiconicity is cool, but cool doesn't necessarily mean useful.
nobleach 3y ago
I still recall coming across the "Sams Teach Yourself Tcl/Tk in 24 Hours" book at my office. I had been doing Linux Samba administration at that time and some of the tooling was written in tcl. So I brought the book home. It was the first time I had ever doing any GUI stuff that wasn't Delphi/VB/FoxPro! I loved it! I quickly realized I had nothing interesting I needed to build at that moment... so I put it back down. But just realizing that GUI programming was in reach without all the heavy Win32/GDI or Winforms, was so cool.
- zerr 3y ago
  I felt the same, but with GTK.
IshKebab 3y ago
We got much better options... Basically anything really but even not-very-good languages like JavaScript and Python are significantly better than TCL. The only thing that TCL really beats is Bash. If you are restricted to easily embeddable languages then the options are much more limited, but even so there are obviously better options like Lua, or even rolling your own (e.g. GDScript, QuakeC). The only people still using TCL are those that can't leave 90% in the past, e.g. the entire EDA industry.
ncr100 3y ago
I am tickled to see this, first Redis implementation in TCL. TCL was (is?) slow and there was not the userbase that needed it, at the time, in my view. Maybe now with more diverse programmers addressing more diverse use-cases with their software, TCL can be more relevant.
sokoloff 3y ago
I've written a lot of Tcl in my career. I don't know if it "fell out of favor" as much as "never really had a ton of favor even at its peak". I have used it in the last decade to do some build system tooling where string/regex processing of log files emitted in prior steps was a big part of the functionality. It was nice that "nobody else is using Tcl, so I won't have any versioning conflicts" and that held true for over a decade, so the long-term cost was reasonable. If I had to learn a new language today, I can't say that I'd put Tcl very high on the list, despite being overall happy with it.
Gordonjcp 3y ago
VHS vs. Beta, basically. Tcl and Perl are about the same age, approximately similar in function, approximately similar in ease-of-use, and really the world could have gone either way. Just as with VHS and Beta, each had their strengths and weaknesses, but ultimately it came down to an avalanche of the "network effect" - everyone was using VHS so everyone used VHS / everyone was using Perl so everyone used Perl.
davidw 3y ago
I have some thoughts about that, as someone who had a small role in that community: https://journal.dedasys.com/2010/03/30/where-tcl-and-tk-went-wrong/ https://journal.dedasys.com/2010/03/30/where-tcl-and-tk-went...
themerone 3y ago
I read an opinion that the TCL community was divided into two factions. One faction wanted a lua like small embeddable interpreter. The other wanted a full feature Python like platform. Neither faction won, so TCL got stuck in the middle. I don't know if this is true, but it was such an interesting opinion, that it stuck with me.

torh 3y ago

I would recommend going back 9 days and read the story behind Redis: https://news.ycombinator.com/item?id=35871462 https://news.ycombinator.com/item?id=35871462

dang 3y ago
Thanks! Also related: LMDB – First version of Redis written in Tcl - https://news.ycombinator.com/item?id=14230960 https://news.ycombinator.com/item?id=14230960 - April 2017 (25 comments) Redis - https://news.ycombinator.com/item?id=494649 https://news.ycombinator.com/item?id=494649 - Feb 2009 (11 comments)

deleted 3y ago

[deleted]

tpmx 3y ago

That was certainly an unusual choice of language for a problem like that. But, I guess, use what you know. Seems like a decent fit, I didn't expect that - I mostly know Tcl from very odd Tcl/Tk GUI apps in the 90s/early 00s.

ncr100 3y ago
It's easy to prototype string passing tools with TCL, in my experience with the language at Uni.
kristopolous 3y ago
my favorite reference to it is in the HTML 4.0 standard https://www.w3.org/TR/1998/REC-html40-19980424/interact/scripts.html#h-18.2.2 https://www.w3.org/TR/1998/REC-html40-19980424/interact/scri... > "where "type" is an content type naming the scripting language. Examples of values include "text/tcl", "text/javascript", "text/vbscript"." It goes on to list text/tcl as a language, equivalent to javascript and even gives examples. There's a story behind this I read somewhere but I can't seem to find it. I once had one of those books that was like 500 pages by those companies like Que with a title like "The ___ Bible" which had at least a chapter on web tcl - in anticipation for the presumed support of it which I'll argue isn't around (besides this: https://wiki.tcl-lang.org/page/Using+Tcl+to+write+WWW+client+side+applications+within+the+WWW+browser https://wiki.tcl-lang.org/page/Using+Tcl+to+write+WWW+client...).
- lmm 3y ago
  TCL/Tk was the original web-embedded language. You had TkLets, which were the inspiration for Java Applets and worked the same way (with a browser plugin etc.), but it was also suitable for Javascript-style scripting of webpages.

didip 3y ago

I think this is relevant... These are 3 OSS databases that can be an alternative to Redis: - KeyDB: https://github.com/snapchat/keydb https://github.com/snapchat/keydb - Dragonfly: https://github.com/dragonflydb/dragonfly https://github.com/dragonflydb/dragonfly - Skytable: https://github.com/skytable/skytable https://github.com/skytable/skytable I have used keyDB before. The raft consensus makes building an HA Redis easy.

danogentili 3y ago
We use keydb at work, and I absolutely do NOT recommend it due to its extreme instability, in fact we're currently in the process of switching to dragonfly precisely due to keydb's instability. Multimaster replication is convenient, but if you accidentally add the IP of the current replica to the replicaset, the entire cluster will crash if any of the nodes shuts down for any reason (note, not immediately, but days or even weeks after starting the cluster with everything working perfectly until one of the nodes crashes or shuts down). Enabling diskless replication in multimaster mode causes either deadlocks, or immediate crashes, depending on the overall LA of the system (!). These are just the issues I remember right now, because the related issues I opened in the repo are still open almost a year later; we had other crashes we had to workaround, too.
- jdsully 3y ago
  Sorry it didn't work well for you. In the 6.3 release we tried to pack in too much although we've ironed out most of the issues. The hardest change has been moving away from fork() for background saving which has historically caused a lot of pain for running it in production and makes it difficult to do persistence. I definitely would have paced things out better if I could go back in time.
  - micw 3y ago
    To me it's still not clear if 6.3.x is stable (https://github.com/Snapchat/KeyDB/issues/494 https://github.com/Snapchat/KeyDB/issues/494) and performant (https://github.com/Snapchat/KeyDB/issues/470 https://github.com/Snapchat/KeyDB/issues/470).

ilrwbwrkhv 3y ago

It's amazing seeing the init version of arguably one of the most popular software of the modern era. Goes to show how much programming is like writing. You keep iterating and making it better.

ben7799 3y ago

I'm more surprised Tcl was used in 2009 than I am at any praise or complaint about the quality of Tcl. I used Tcl and Expect (which was a very cool extension of Tcl) in the late 90s in some automation projects as an intern. It did the job and yet I was aware of some of it's issue. But that was so far before 2009. It felt like Tcl was almost done by 2000, I never saw it used again. Perl came and went, Lua had arrived, Python had arrived, etc.. Tcl to me is like Python.. pretty good for small projects by a small team. Not so desirable for a giant enterprise product/platform with a big team.

klodolph 3y ago
Tcl is super interesting from a historical point of view. It seems to hit about halfway between shell and Lisp. With some small differences, it probably would have competed more directly against Perl, Python, or maybe Lua. As it is, it gave us Wish, plus a bunch of GUI wrappers for shell scripts, and we’re thankful for those.
- ben7799 3y ago
  I think some of it back then was there was less internet communication and Tcl could be popular one place and Python was popular in another place and Perl popular in another team. Now we discuss everything so much communities converge on a common choice. Perl & Tcl really share the issue that undisciplined developers could make really obfuscated code that was hard to decipher.
yamtaddle 3y ago
> I used Tcl and Expect (which was a very cool extension of Tcl) I used "expect" about five years ago to help automate deploying an app to a local Roku box from the command line. Much faster dev loop than having to upload a zip to a webpage hosted on the Roku box.
sgt 3y ago
Makes me wonder, are there any current projects still using tcl? I know DDG is still using perl.

gt565k 3y ago

mIRC tcl scripts and tcl scripts for Eggdrop IRC bots oh man, the nostalgia!

metadat 3y ago
mIRC has its own language, "mrc", not tcl. But yeah, those were fun times with the eggdrop botnets! Eggdrop could be so stable.. pretty much industrial grade.

deleted 3y ago

[deleted]