The biggest early selling point of Tcl was Tk, as a relatively easy way to make good-enough GUI programs with open source on Unixen and the X Window System. Even much easier than the easier-to-use X toolkits like XView with C, and the alternatives only got more difficult from there. There were no Web frontends.
Tcl itself was quite clever as what I'd actually call a string-based scripting language (contrast with Bourne/C-shell/etc. that preceded it on Unix).
Originally, Tcl was among the handful of off-the-shelf extension languages. You write your big application in C or C++, and then you embed an interpreter for a higher-level extension language, for users or the original developer to add on functionality. The options at the time were usually a small Lisp/Scheme, Tcl, Python, or something entirely bespoke and probably quirky and half-butted.
During early dotcoms, there was considerable interest in Tcl for backend work, and it also wouldn't have been the worst choice to put into the browser. Like Python, Tcl would've been more accessible and democratizing-the-Web than JavaScript, and there were already solid off-the-shelf designs and implementations. (Scheme would've appeared slightly more intimidating than Python or Tcl, and was more powerful, which I think was why Tim Berners-Lee preferred Python over Scheme as the people's programming language for various Web purpose. The semantics of the JavaScript we got was more a hurried toy Scheme, plus the simplest object model, and a more intimidating syntax that came from systems programming.)
My pet project in those days was writing a C++ X-Windows gui toolkit, and I took a lot of inspiration from Tk. Both design, and "how do I do this" from the source code were invaluable.
Didn't Cisco use Tcl in one of their IOSes? Found it: <a href="https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ios_tcl/configuration/12-4t/ios-tcl-12-4t-book/nm-script-tcl.html" rel="nofollow">https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ios_tcl/co...
Yes the legacy Cisco IOS had a Tcl interpreter built in, you can drop in to the repl with the tclsh command. The command is still there on newer Linux based IOS versions
Expect was amazing - game changing. The things you could do with it couldn't be replicated elsewhere (well, clearly "could", but not reasonably so)
Y'all remember TkDesk at all? <a href="https://tkdesk.sourceforge.net/" rel="nofollow">https://tkdesk.sourceforge.net/
I loved it back in the day, tons of fun to configure with code, somehow friendly enough for me to play with in high school with no background knowledge and only some man pages to help me. Coupled with a lightweight WM like CTWM <a href="https://www.ctwm.org/index.html" rel="nofollow">https://www.ctwm.org/index.html it lead to a really performant desktop on the single-core ~400mhz machines we had in our computer lab....
So I also love Tcl, but I think it would have not been great as a web language. I think the small amount of type information we can pass via json is just about right, and tcl would have made it impossible.
You cannot encode arbitrary tcl data to a typed object "correctly" because every tcl dictionary is a valid list, and every list is a valid string (numbers are also strings, and so is code). So in a world of "tcl code on the web", both the sending and parsing ends of a 'tcl data stream' would need to know which type they're "supposed" to treat the data as.
Yep, the age of Python and the C-steeped culture of its original developers probably has a lot to do with the choice of Tcl/Tk as a basis for the standard library GUI framework. But even then, there's significant wrapping; and Python's type system is, if anything, even further away from the free-wheeling "stringly typed" Tcl than JavaScript is.
I do sometimes yearn for the alternate universe where web browsers ended up doing Python natively (and PyPy style optimizations became the default, and the dynamism was reined in to an extent where it could offer JavaScript-tier performance).
Aside from the emphasis on "continuation passing style" though I don't get how you're relating JavaScript to Scheme.
neilv · · focus · HN ↗
Tcl itself was quite clever as what I'd actually call a string-based scripting language (contrast with Bourne/C-shell/etc. that preceded it on Unix).
Originally, Tcl was among the handful of off-the-shelf extension languages. You write your big application in C or C++, and then you embed an interpreter for a higher-level extension language, for users or the original developer to add on functionality. The options at the time were usually a small Lisp/Scheme, Tcl, Python, or something entirely bespoke and probably quirky and half-butted.
During early dotcoms, there was considerable interest in Tcl for backend work, and it also wouldn't have been the worst choice to put into the browser. Like Python, Tcl would've been more accessible and democratizing-the-Web than JavaScript, and there were already solid off-the-shelf designs and implementations. (Scheme would've appeared slightly more intimidating than Python or Tcl, and was more powerful, which I think was why Tim Berners-Lee preferred Python over Scheme as the people's programming language for various Web purpose. The semantics of the JavaScript we got was more a hurried toy Scheme, plus the simplest object model, and a more intimidating syntax that came from systems programming.)
giancarlostoro · · focus · HN ↗
flopsamjetsam · · focus · HN ↗
Didn't Cisco use Tcl in one of their IOSes? Found it: <a href="https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ios_tcl/configuration/12-4t/ios-tcl-12-4t-book/nm-script-tcl.html" rel="nofollow">https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ios_tcl/co...
manbart · · focus · HN ↗
monista · · focus · HN ↗
You're not that old, are you? :) Before www, expect was the way to go.
<<a href="https://en.wikipedia.org/wiki/Expect" rel="nofollow">https://en.wikipedia.org/wiki/Expect>
RHSeeger · · focus · HN ↗
mikestorrent · · focus · HN ↗
I loved it back in the day, tons of fun to configure with code, somehow friendly enough for me to play with in high school with no background knowledge and only some man pages to help me. Coupled with a lightweight WM like CTWM <a href="https://www.ctwm.org/index.html" rel="nofollow">https://www.ctwm.org/index.html it lead to a really performant desktop on the single-core ~400mhz machines we had in our computer lab....
bloaf · · focus · HN ↗
You cannot encode arbitrary tcl data to a typed object "correctly" because every tcl dictionary is a valid list, and every list is a valid string (numbers are also strings, and so is code). So in a world of "tcl code on the web", both the sending and parsing ends of a 'tcl data stream' would need to know which type they're "supposed" to treat the data as.
agumonkey · · focus · HN ↗
zahlman · · focus · HN ↗
I do sometimes yearn for the alternate universe where web browsers ended up doing Python natively (and PyPy style optimizations became the default, and the dynamism was reined in to an extent where it could offer JavaScript-tier performance).
Aside from the emphasis on "continuation passing style" though I don't get how you're relating JavaScript to Scheme.
so-cal-schemer · · focus · HN ↗
[deleted] · · focus · HN ↗
[deleted]