16 ms·

Tcl: Everything Is a String

227 points by blacksqr 7y ago

jhallenworld 7y ago
Tcl: one of the slowest languages https://github.com/trizen/language-benchmarks https://github.com/trizen/language-benchmarks
- bbmario 7y ago
  wtf luajit is a monster
  - steveklabnik 7y ago
    It really is. Mike Pall is... beyond words. https://web.archive.org/web/20170102051538/http://article.gmane.org/gmane.comp.lang.lua.general/75426 https://web.archive.org/web/20170102051538/http://article.gm... (Discussed on HN: https://news.ycombinator.com/item?id=2588696 https://news.ycombinator.com/item?id=2588696)
  - chaorace 7y ago
    I think it's cheating a bit to compare JIT vs runtime script evaluation. I'd be more interested to see LuaJIT performance measured against something more comparable, like JS running on V8.
  - tomnipotent 7y ago
    Probably why it's so popular in games as a scripting engine (going back to 2003).
    - est 7y ago
      > in games as a scripting engine (going back to 2003) you are think of lua, luajit is a different beast. http://luajit.org/changes.html http://luajit.org/changes.html LuaJIT 1.0.3 — 2005-09-08 This is the first public release of LuaJIT.
      - tomnipotent 7y ago
        Didn't realize they had the Python/PyPy thing going on. Thanks for the info!
  - stjohnswarts 7y ago
    I thought it was dead/dying though? No future plans to add new features, especially sense the creator said he was done with it...
- forinti 7y ago
  But it's the fastest way to put together a GUI.
  - criddell 7y ago
    Does Tcl deal with platform-specific GUI elements, or does it restrict you to a lowest common denominator set of widgets? Are there different dialog layout controllers? For example, in Swing there's BoxLayout, CardLayout, SpringLayout, etc...
    - pwg 7y ago
      You get both native and custom GUI elements with modern Tk. And yes, there are plural "layout controllers" (Tk calls them "geometry managers").
    - fooblitzky 7y ago
      I believe they are referring to the Tk GUI toolkit, which is intended for use from Tcl and really nice to work with. It is full featured and has plenty of widgets and layout controllers. You can find out all about Tk here: https://tkdocs.com/ https://tkdocs.com/ It is really fast and easy to create GUIs using Tcl/Tk, e.g. here is a Tcl script to create a paint-like program in less than 50 lines: https://pastebin.com/6qibnQcJ https://pastebin.com/6qibnQcJ The main downside is that the look and feel is not native, and a bit dated. There are some efforts to update the look, but it's not as slick as Gtk etc.
  - jhallenworld 7y ago
    What about tkinter for Python?
    - nrclark 7y ago
      I dunno if you were going for irony or not with that!
  - ThomasBHickey 7y ago
    I always thought Java should have just used Tk rather than developing AWT, which never worked very well.
- haolez 7y ago
  Tcl is really nice to work with. It’s a weird mix between a programming language and a command line interface. If you’ve never touched it, I recommend you to do so if you are curious :)
- igouy 7y ago
  Maybe Tcl does recursion poorly — those all seem to be tiny recursive functions. Maybe there was something Tcl did well? https://web.archive.org/web/20060924085254/http://shootout.alioth.debian.org/gp4/benchmark.php?test=regexdna&lang=all https://web.archive.org/web/20060924085254/http://shootout.a...
  - databasher 7y ago
    TCL had an amazing architecture for someone who was working in C. In C, you'd (1) create an instance of a TCL interpreter, (2) register your C functions with the TCL interpreter, and then (3) load scripts into the TCL interpreter. You'd do all your fast stuff in your C code, and just use the TCL for stitching together the high-level logic.
    - pinopinopino 7y ago
      This, it is really easy to embed the tcl interpreter. Far easier than perl and python, even easier than lua.
      - lanstin 7y ago
        Especially the commands were invoked command_name(argv, argc) and the thing was just like a CS 101 C program. Dead simple, and as they mentioned just used to orchestrate the fast stuff. You shouldn't make a command block a long time, but you could grab a handle to the output destination and set it up to stream output there from the C.
- mhd 7y ago
  Tcl: No significant difference to Python or Perl It matters even less for Tcl, as it's supposed to tie pieces written in more performant languages together. See "Ousterhout's dichotomy"[1]. Sadly that also moved it closer to something like Rexx (or Lua these days), and thus no proper module/package community ever arose in time. [1]: https://en.wikipedia.org/wiki/Ousterhout%27s_dichotomy https://en.wikipedia.org/wiki/Ousterhout%27s_dichotomy
  - jhallenworld 7y ago
    Maybe true, but there are fast math extensions: https://realpython.com/numpy-tensorflow-performance/ https://realpython.com/numpy-tensorflow-performance/
    - ori_b 7y ago
      Yes. Those work by tying python to pieces written in a more performant language.
    - mhd 7y ago
      And Perl has PDL. Not aware of anything for Tcl beyond math::statistics, but I think it waned in popularity way before the ML bubble started inflating. But in my experience, the strategy for Tcl is the inverse of Python when it comes to domming/subbing with your "partner language". You _extend_ python, you _embed_ Tcl. At least in the areas where Tcl still survives. It lost long ago against the P-languages, but still faces Lua rather bravely in the enterprise/engineering sector.
- deaps 7y ago
  A pretty good read on tcl - and why the F5 devices use tcl for their iRules (2012, Updated two years ago). https://devcentral.f5.com/s/articles/irules-concepts-tcl-the-how-and-why https://devcentral.f5.com/s/articles/irules-concepts-tcl-the...
geogra4 7y ago
My first job was in Tcl. I grew to really like the language, though when I had to leave the company I was at a pretty strong disadvantage due to how uncommon it is. Everything is a string is a great way to reduce the mental load about typing.
- commandlinefan 7y ago
  One of my earlier jobs was porting Travelocity.com from TCL to Java - the TCL programmers loved the old site and absolutely hated the "new" one. I don't think I've ever managed to make more enemies in my professional life than I did in those couple of years.
  - ramses0 7y ago
    CARL!
  - stjohnswarts 7y ago
    I remember you >_< , whipper snapper!
  - geogra4 7y ago
    Tcl to Java is a huge change. Totally different syntax / syntactic style. I can imagine the annoyance of the Tcl programmers having to deal with the inherant verbose-ness of java.
    - commandlinefan 7y ago
      Yeah, and this was in the relatively early days of Java, too, so the front-end was all JSP. Oh, did I mention they originally gave us a three-month deadline to port the ENTIRE site?
- ghettoimp 7y ago
  > Everything is a string is a great way to reduce the mental load about typing. I feel almost the exact opposite way... Everything is a string means I have to "know" whether any given function takes {a single element, a list of elements, a glob, a list of globs, ???}. When I inevitably mess it up, I don't get any help at all from the language. In the best case, I'll hit a run-time error and figure it out. In the worst case, my program will just do some random thing that isn't what I wanted, and I'll get to debug it.
davidw 7y ago
I think the article doesn't make enough mention of the fact that internally, most things are not actually strings for much of their lifetime. They must be able to be represented that way, but that's different than everything being a string all the time. It does create a few problems, but they're a bit more subtle than "OMG, the integers are strings all the time!"
- kevin_thibedeau 7y ago
  This is an old wiki entry that dates from the pre-8.0 days of Tcl (The history is truncated). For the past 20 years everything has been representable as a string.
  - blacksqr 7y ago
    It is old, but continuously updated. Last update, last Friday.
    - kevin_thibedeau 7y ago
      That is irrelevant when the main thrust of the article is outdated and reflects the worldview from before Tcl_Obj was added.
winrid 7y ago
Redis was originally in Tcl! https://gist.github.com/antirez/6ca04dd191bdb82aad9fb241013e88a8 https://gist.github.com/antirez/6ca04dd191bdb82aad9fb241013e...
- dickeytk 7y ago
  It seems they’ve held onto the “everything is a string” pattern too
- yellowapple 7y ago
  SQLite was also originally a Tcl extension, IIRC. They're still very closely intertwined.
- derefr 7y ago
  And SQLite was originally a TCL extension! From https://www.sqlite.org/tclsqlite.html https://www.sqlite.org/tclsqlite.html: > The SQLite library is designed to be very easy to use from a Tcl or Tcl/Tk script. SQLite began as a Tcl extension and the primary test suite for SQLite is written in TCL. SQLite can be used with any programming language, but its connections to TCL run deep. Given both of these, it kind of feels like something about the Tcl philosophy leads people to build (or draws in the sort of person who builds) simple/elegant data storage layers. Makes me more curious about it.
  - winrid 7y ago
    Wow!
  - lanstin 7y ago
    Ousterhout's book on Tcl has a chapter one that is essentially "How to do small reusable things in unix and win" - it's absolutely brilliant and explains how to think in unix and why composable entities with simple interfaces have done so well. SQLite and TCL are the best of unix philosophy made concrete. I just read in this thread that he expanded it to an entire book - I'll be reading that as soon as I finish binging The Family Man on Prime Video. Extending TCL with a new C command is exactly as hard as a CS 101 C program (which at the time was the lower limit on easy for CS folk).
IshKebab 7y ago
> This is one of the central features of Tcl. One of the biggest missing features surely? "Everything is a string" is a terrible design.
- protomyth 7y ago
  Yet UNIX pipes are strings and amazingly popular. Its amazing how we don't see a movement to get typed streams so we can give up the reparse culture of UNIX. I guess PowerShell does typing.
  - pjc50 7y ago
    The problem with typed streams is that couples the implementations together on both ends and tends to de-genericise them. You get a "grep" that would only work on strings when actually you'd be quite happy grepping numbers 99% of the time. Also in order to serialise them you'd need fully typed files. Notice that you can't serialise a Powershell stream. The world tried "everything is XML" and more recently "everything is JSON" as a solution to this. The latter is almost there.
    - derefr 7y ago
      What CLI userlands (POSIX, Powershell, Plan9) are missing, IMHO, is a self-describing serialization "stream container" format, like Avro (https://avro.apache.org https://avro.apache.org), the interchange format used in Hadoop, Kafka, and several other systems of the "gluing IO-streaming components of different languages together into an ETL pipeline" variety. (Which is, of course, exactly what you're doing when you write a Unix pipeline, just in-the-small.) Where in self-describing data formats like JSON or XML (or even the more efficient encodings like ASN.1), every term is "described in place", taking up a lot of encoding overhead and bandwidth; in a self-describing stream container format, each encoded stream first encodes a schema (or the ID of one) for what it's about to transmit; and then transmits the terms encoded using the schema. Because schemas are referred to by embedding them in the document in a normalized form, each stream received by a client can be handled by a hybrid approach between building up just-in-time dynamic parsers from the schema, if it's not known; or recognizing known schemas (by e.g. hashing the representation of the schema, which works since it's in a normal form) and using a baked-in decoder for that specific schema if available. This would work pretty well as an enhancement to standard POSIX CLI IO-streaming tools; they'd be able to use specific logic to optimize the parsing of a few schema-encoded types they "expect", while also faithfully (but less efficiently) handling data of any type by falling back to a generic parser routine. (By which I don't mean "falling back to treating the stream as text", but rather "falling back to treating the stream as the custom type that the sender specified." Sort of like how, in most languages, you can compile regexes that are available at compile time, but also have a regex interpreter for regexes received at runtime.)
rongenre 7y ago
Everything is a string including the comments -- commenting code actually degrades performance!
- mschaef 7y ago
  I'm pretty sure this hasn't been true for 20 years. Tcl 8.0 introduced a form of byte compilation. [1] While the comments might slow down the compilation a bit, I doubt they have any impact at runtime these days. 1] https://www.tcl.tk/software/tcltk/8.0.html#What's%20New%20in%20Tcl%208.0 https://www.tcl.tk/software/tcltk/8.0.html#What's%20New%20in...
- pwg 7y ago
  This has not been true since the introduction of the bytecode compiler in Tcl 8.4 (well over ten years ago now). Tcl 8.4+ will byte code compile the proc's, and part of that is removing the comments from the code execution path. So comments only get 'seen' once (at byte code compilation time, upon first use of a proc) and then have no effect on execution performance from that point forward.
- ThePadawan 7y ago
  IIRC this was also the case for node/V8/I don't recall: Whether a function was inlineable was decided based on its size - and that was determined based on size-as-text instead of size-as-AST. This lead to the situation where adding too much comment text (I believe it was 512 bytes total for the function) led to the inliner refusing to inline the code, and thus performance regressions.
- mdaniel 7y ago
  This business falls into the "well that's handy" followed by the "who in the world thought honoring continuation characters in comments was a good idea?!" #! /bin/sh # the next line restarts using tclsh \ exec tclsh "$0" ${1+"$@"} This page is just filled with wow: https://wiki.tcl-lang.org/page/comment https://wiki.tcl-lang.org/page/comment with an especial nod toward: set two [1 + 1] ;# line comment needs a statement terminator
  - 7y ago
nrclark 7y ago
Heart️ for Tcl. Tcl wasn't my first language, but it's near and dear to my heart. It's a little oddball for sure. I can't decide whether it's Python trying to be Bash, or Bash trying to be Python. But it's surprisingly expressive. Everything is strange about the syntax - from "everything is a string" to "expr" to the weird variable-assignment syntax. It's also really tiny, and has a great async event-loop framework. It has built-in support for sockets and non-blocking I/O. It has a GUI toolkit that's pretty useful for making quick-and-dirty tools. It's incredibly easy to use interactively with a REPL. And it's still the scripting language of choice for the FPGA industry, which is where I got my start as a software engineer. The Tcl community is small and stable. And the language just keeps soldiering onwards, in a gradual way. It feels like it's been stable and fully-realized for the last 20 years. No breaking API changes, no syntax changes. It just keeps on keeping on, providing automation to tools that need it. Tcl has outlived a bunch of newer languages, and I hope it sticks around for another 20 years.
- toraobo 7y ago
  > Python trying to be Bash, or Bash trying to be Python The fact that "everything is a string" is cute and odd but the end result is really closer to shell scripting than a real object-oriented language like Python. You routinely have to deal with string/list quoting and constructing complex data structures is tricky if they have to be represented with just strings and hashes. Sure: it's flexible and you can reimplement all the features of a high-level language but I'd rather use a language which has all the features already.
  - nrclark 7y ago
    Tcl has native support for lists and dicts, and provides full-featured functions for working with both. You're absolutely right that the feel is "more than Bash, less than Python." But it's not accurate to say that you need to do a bunch of weird string parsing in order to implement a high-level datatype. And yes - the list quoting rules are weird! No doubt about that.
    - mst 7y ago
jadbox 7y ago
Everything being a string at a language level is similar to the paradigm as 'everything is an object' in java. Outside of select use-cases (scripts/text proc), the language generally fights against both conciseness and performance. I worked with UCLA where a few teams needed to use Tcl to maintain existing web servers, and virtually every developer highly complained about using it (aside from one or two career Tcl-ers). To be honest, I don't personally have much experience with Tcl, but from what I've seen/heard, I wouldn't ever think of building web servers upon it.
- Mountain_Skies 7y ago
  One of my first jobs after college involved creating websites using Vignette StoryServer. At the time Tcl was the only language you could use with it. I was happy when a new version was released that supported Java and ASP. Tcl looked like voodoo magic to me but I'm sure for those who really got it, they were pretty productive with it.
  - kiwidrew 7y ago
    You've brought back some painful memories for me. I'm permanently allergic to the words "lindex" and "upvar", and cringe whenever I see a "," character in a URL... Vignette's only redeeming qualities were that: (1) the page templates permitted the execution of arbitrary Tcl code, not just the small subset that was documented by Vignette; and (2) much of the Vignette functionality was itself actually implemented in Tcl. This led to the glorious discovery that one could simply bypass the entire crazy Vignette system and use it like a very expensive (and somewhat slower) AOLserver. I sometimes feel sorry for the poor souls who inherited my terrifying and entirely undocumented creation, but that's what happens when management forces developers to use the entirely wrong tool for the task at hand. ("We spent $100k USD on this software so we're damn well going to use it!")
tabtab 7y ago
I had a bit of trouble knowing which "escape level" I'm in while debugging. You have strings that wrap strings that wrap strings, etc. Maybe with more experience I'd learn to manage string nesting levels better, but there does seem to be a non-trivial learning curve, at least for us mortals.
nerpderp82 7y ago
Tcl is an alien technology I wish I embraced when I was first exposed to it. I didn't quite get it, I was confused, so I gravitated towards Perl because it reminded me of C somewhat. I wasn't aware of my cognitive blind spots. In many ways Tcl is more powerful than most implementations of Lisp. Like a Lisp crossed with a Forth with the ability to turn spheres inside out with no tearing during execution. Magic.
- pmoriarty 7y ago
  "In many ways Tcl is more powerful than most implementations of Lisp." Could you elaborate on this? In what ways is it more powerful? Also, I don't get what connection TCL has with Forth. They seem uttery different from each other to me.
  - ithkuil 7y ago
    One thing those three languages have in common is that they are almost syntax-less. Each, in its own particular way, allows user defined code to process tokens of the program source before it gets to the core interpreter, allowing users to implement custom control structures and DSLs.
    - stjohnswarts 7y ago
      I've seen a lot of people compare it to Forth for DSL implementation
  - dmux 7y ago
    You can delay evaluation of Tcl expressions, for one.
- flavio81 7y ago
  >turn spheres inside out with no tearing during execution. Magic. What does "turn spheres inside out" mean? >with no tearing Is this painful?
  - 7y ago
gilbetron 7y ago
I have about 5 years of heavy experience with TCL, split in half by 15 years away from it. I got a lot done with it, and it is an interesting language, but I have never, ever said, "I wish I was using TCL" in any situation. It is a unique journey down an alternate path for computer languages, that really ends up nowhere compelling, but the path itself is not arduous, although the bugs can be.
- fluffything 7y ago
  I had 1 year of full-time experience with TCL, and I can basically summarize it in the same way as you: got a lot done with it, wasn't horrible, but don't miss it. In retrospect, I am kind of happy that somebody actually went and built TCL. "Everything is a string" is not really a sound PL paradigm, but someone needed to get stuff done, and it worked quite fine for that. It's super simple and super powerful, and beginners can be productive with it really quickly.
- stjohnswarts 7y ago
  Similar, I was forced to write scripts in it when I was at a more silicon/hardware oriented company. It's an interesting language but I much preferred moving on to ruby/python for my V&V activities.
skybrian 7y ago
It's nice to guarantee that every value has a string representation. The not-so-nice part is that you have no static types and therefore no easy way to guard against mixing up safe and unsafe strings, so security reviewers will have a hard time. This is a design from before when the dangers of handling untrusted input as bare strings and doing escape handling all over the codebase were understood.
jascii 7y ago
For me Tcl's killer app has been Expect: https://core.tcl-lang.org/expect/index https://core.tcl-lang.org/expect/index there is nothing quite like it if you have to manage 1000's of devices and cli's are the only thing you have to do it!
- stjohnswarts 7y ago
  have you used pexpect?
ahartmetz 7y ago
Everything is a string in CMake, too. Even lists. Be very afraid of strings containing the separator character ';'...
crispyambulance 7y ago
My favorite thing in the Tcl ecosystem was "Expect". It's a tool you can use to automate ssh/telnet/serial connections to other machines. It has a really mature and elegant way of handling the automation of command/response scenarios in connections to other machines. I do similar stuff with .net now, but it's not as pretty. I wish there were a modern equivalent of Expect that as as nice.
- catalogia 7y ago
  Years back I worked on an automated test framework for small/mid-business scale cisco-clone routers that used Expect to drive the telnet CLI interface and put the routers through their paces. I remember something a more senior engineer at the company told me: Expect is the best tool for when you need to get a job done the wrong way. (Using Expect was his idea, to be clear.)
  - crispyambulance 7y ago
    Curious... your colleague said Expect was "the best wrong way", what would have been the "correct" way in your scenario? How would something like that best be done now? Ansible?
- AstroJetson 7y ago
  I also love Expect and still use it. It makes a lot of what used to be "fingerbone tasks" go super quick.
- dharmab 7y ago
  Expect is an amazing tool for dealing with old hardware that _insists_ on interactive prompts instead of CLI flags.
  - oefrha 7y ago
    Also great for automated tests of interactive functionality in your own projects.
  - rikkus 7y ago
m4r35n357 7y ago
gitk !!! also Linux kernel config
kroger 7y ago
A nice article to quickly understand Tcl defining features is "Tcl the Misunderstood": http://antirez.com/articoli/tclmisunderstood.html http://antirez.com/articoli/tclmisunderstood.html And some previous HN discussion on the article: https://news.ycombinator.com/item?id=7069642 https://news.ycombinator.com/item?id=7069642 https://news.ycombinator.com/item?id=4920831 https://news.ycombinator.com/item?id=4920831 Edit: grammar
FabianBeiner 7y ago
TCL. That brings me down the memory lane to IRC and all those Eggdrop bot scripts I've written. :)
pjmlp 7y ago
Actually since Tcl 8 that is no longer true, yet it keeps being repeated as such. http://www.tcl.tk/software/tcltk/8.0.html http://www.tcl.tk/software/tcltk/8.0.html TclTk was great, but it also teached me never again to rely on languages without JIT or AOT available on their toolchains. Rewriting Tcl functions into C code was a routine task.
- takeda 7y ago
  Yeah, but that just changed internally, in the language everything is still a string.
  - wrenky 7y ago
    A better way to phrase it (..even before tcl 8) is that everything can be TREATED like a string. Numbers arent being converted to and from strings, things like sockets/files arent strings (their handles are though!)
    - _ph_ 7y ago
      Right. I think the one great feature it shapes with Lisp is, that everything has a textual representation. That means, all types of values can be presented as text and can be recreated from a textual representation. For Lisp, it is S-Expressions, which can be printed and read, for TCL it is the syntax which can be printed as strings and interpreting strings as data.
      - dmux 7y ago
        >I think the one great feature it shapes with Lisp is, that everything has a textual representation. Is this true even for procedures? I was recently playing around with Scheme and was disappointed that once a procedure is defined, it got internalized and didn't have a textual representation other than #<proc> or the like. In TCL, procedure signatures and bodies are stored within the runtime. You could essentially dump the entire state to a TCL file.
- sokoloff 7y ago
bachmeier 7y ago
This paper by John Ousterhout (creator of Tcl) is a good read if you think Tcl is a weird language plagued by bad design decisions. If that describes you, it's probably the case that you don't understand the problem Tcl was designed to solve. https://web.stanford.edu/~ouster/cgi-bin/papers/tcl-usenix.pdf https://web.stanford.edu/~ouster/cgi-bin/papers/tcl-usenix.p...
- bloaf 7y ago
  >Almost all Tcl ‘‘programs’’ will be short, many only one line long. I weep silently over the 50kloc tcl codebase I help maintain.
foobar_ 7y ago
There is an object-oriented extension to Tcl which is along the lines of CLOS. http://media.wu-wien.ac.at/whatIsXOTcl.html http://media.wu-wien.ac.at/whatIsXOTcl.html Lispers need to stop thinking that they are the only ones who can do "macros" and "DSLs". The evidence is clearly on the contrarian side. You can have syntax and macros and be practical. If the failure of Tcl has taught us anything its that performance is important.
- flavio81 7y ago
  >Lispers need to stop thinking that they are the only ones who can do "macros" and "DSLs". The evidence is clearly on the contrarian side. We know that one can do "macros" in many other languages including of course TCL. The question is how difficult is to do them and how easy is to have control over there. Lisps, due to code being s-expressions, make macro creation extremely easy, and Common Lisp has useful tools to ease working with macros, for example macroexpand, which is integrated into most Lisp IDEs to easily visualize, in-place within the code, how a macro will expand into, step by step. In comparison to that, most languages that do allow macros, make it a cumbersome, buggy task.
  - foobar_ 7y ago
    XML, Julia, Rust, Crystal, Forth? support macros too. I was just pointing out that it can be done without sexp. Yes, the tooling sucks. Grammatical implementation is less powerful but that seems better than implementing a grammar ontop of sexps. You get some lexical freedom ontop of pure text that you don't get implementing grammars on top of sexps, respecting lisps tokenisation rules. I wonder how far Lisp would have come if people had taken the source-source translator approach of js and just implemented an Algol frontend to lisp. There's plenty of things that Lisp had that are far more useful than just macros. I think Tcl is the Unix answer to Lisp. Worse is better somehow evolved into a Lisp.
    - kazinator 7y ago
      > I wonder how far Lisp would have come if people had taken the source-source translator approach of js and just implemented an Algol frontend to lisp. People did that a number of times over Lisp's history, so Lisp would have come exactly where it has come. The first Algol-like front end to Lisp was supposed to be the direct descendant of Lisp 1, namely Lisp 2. This branch went nowhere. The descendants of Lisp trace back to Lisp 1.5. In the early 70's there was something called CGOL. It still exists. There have been various more recent things in that direction. And of course, certain contemporary languages are basically sort of Lisp-like things with Algol bolted on. Lisp 2: https://en.wikipedia.org/wiki/LISP_2 https://en.wikipedia.org/wiki/LISP_2 Manual with code examples: http://www.softwarepreservation.org/projects/LISP/lisp2/AbrahamsEtAl-LISP2.pdf http://www.softwarepreservation.org/projects/LISP/lisp2/Abra... CGOL: https://en.wikipedia.org/wiki/CGOL https://en.wikipedia.org/wiki/CGOL
ycombonator 7y ago
It still powers some companies with an annual rev ~1B.
wanderer2323 7y ago
The string is a stark data structure and everywhere it is passed there is much duplication of process. It is a perfect vehicle for hiding information. -- Alan Perlis
- ken 7y ago
  I think Tcl strings aren't exactly what Perlis was talking about. First, the language knows how they're used, so there's a JIT (or whatever) behind the scenes eliminating the literal deserialize-process-serialize pattern you see in shell scripts. Second, a lot of Tcl data types (hash tables, sockets, etc) can be represented by strings but the string is just a simple reference to a rich internal structure. It's almost more like a pointer than a string in other languages.
  - lanstin 7y ago
    I know this item is old but surely no shell script should be limited by string copying of the language? Maybe string shuffling thru pipes, but that's the reason the CPU briefly spikes.
nahumba 7y ago
ha! i 'member this. hmmmmm Stringly Typed. yes. yes. https://blog.codinghorror.com/new-programming-jargon/ https://blog.codinghorror.com/new-programming-jargon/ now that you put a duck in news. i call to remove it. thankyou.
pinewurst 7y ago
Don't forget the amazing AOLserver, which was a very elegant web applications server with Tcl as the native template language. This was a great environment.
- gnachman 7y ago
  I was tech lead for it for a couple years. Glad someone remembers it :)
  - lanstin 7y ago
    Hey! I wrote flap in TCL module for it! Loved using AOLserver but writing the extension taught me to fear threads - now loving Golang :) but I miss AOL, AOLserver, SAPI and TCL in the evenings.
derefr 7y ago
About a decade ago now, I was writing a group chat system of the Slack/Discord variety, and I was pondering how I'd like to support markup. I wanted to do something more powerful than just the regular "bold/emphasis/strikeout/links/etc." set, as the users of this group-chat were the type who would enjoy adding animations and other "effects" to their text, especially on top of their custom emoticons/stickers. (Don't fret, this wasn't team-productivity software ;) What I ended up doing was extending the backend with support for parsing messages using a "command language"—essentially Tcl. The "everything is a string" feature of Tcl-like languages was essential, because I wanted these "commands" to be arbitrarily composable, and both the input and output were required to be strings (i.e. HTML), so commands couldn't pass data-structures to one-another; they had to accept strings, and emit strings. The user was not allowed to enter arbitrary HTML in their message (this was filtered out as a pre-filtering step), but any Tcl command was allowed to take HTML-strings as input and emit HTML-strings as output, and the string that was eventually generated, HTML and all, was treated as the user's actual message. Many of the implemented commands would parse the input HTML-string into an AST, tweak it somehow, and then re-emit it as a string. An example of such a command would be something like: And then [spoiler the protagonist died [rotate 5 [big :ohno:]]] ...where 'rotate' and 'big' layer together CSS effects (combining CSS classes with a bit of custom element style to parameterize it, with each rewriting the HTML AST structure of the previous to ensure the CSS effects "stack" correctly); and 'spoiler' is just a CSS class with pseudo-selector behaviors. Another example would be: [type oh nooo[sfx fall]oooooooo] ...which would use a CSS class+JS trigger to display the message one character at a time the first time it became viewport-visible... and embed a hidden <audio> element at the top of the message body, that would get triggered as the typing progressed to it. Sort of like the dialogue event-scripting in a video game. And, of course, just like an IRC bot, you could rely on the backend being Turing complete, in ways like: # generate random numbers [roll 1d6] # set a countdown timer on a user, # resetting it whenever the user talks [deadmanswitch 5mins I'm slacking off again!] # get the backend to (use a job queue to) # fetch a resource, plop it into its own download folder, # and then post a link to the retrieved copy [dl http://example.com] # same, but also create a BitTorrent torrent for # the file, register it with a BT tracker on # the backend, and then emit the URL of the torrent file [torrent [dl http://example.com]] --- At this point, I don't really think there's much room for a new group chat system; but this one feature was really cool to me, and I always wish I had seen it implemented in some bigger product.
eesmith 7y ago
> This simple and unified perspective on type is fundamental to the design of Tcl, and puts it in an exclusive category programming languages that do not have at least two data types that can be distinguished. The other languages in this category are forth, BCPL, and assembly language. What about TRAC? https://en.wikipedia.org/wiki/TRAC_(programming_language) https://en.wikipedia.org/wiki/TRAC_(programming_language)
elamje 7y ago
The SQLite author is a big Tcl user. I believe the codebase is primarily Tcl when you include the test suite, though the core implementation is obviously a C library. D Richard Hipp is his name and he has some nice talks online. He uses his own text editor and chat app he wrote in Tcl to maintain the project and communicate with other developers.
- catalogia 7y ago
  From what I understand, D Richard Hipp's appreciation of Tcl is the reason SQLite has dynamic typing. (I believe I heard this in one of his talks that's on youtube, which are excellent.)
  - elamje 7y ago
    That makes sense. I heard him say that the pain points of dynamic typing are mostly just people using it for web apps that eventually have to migrate to Postgres and the like, causing some headaches because client server DB’s are much more rigid, causing errors. I agree that his talks are great! He’s such an enthusiastic guy. I hope SQLite will adopt default foreign keys and WAL sometime soon, but I understand that he needs to keep it as backwards compatible as possible.
stevekemp 7y ago
If you're not familiar with TCL this introduction from redis-author Antirez is worth a read: http://antirez.com/articoli/tclmisunderstood.html http://antirez.com/articoli/tclmisunderstood.html
RandomGuyDTB 7y ago
That's really weird. I didn't know this was a thing but I had a dream a couple days ago that I was using a language in which everything was a string (like Lisp but with strings instead of lists). Guess I'll have to give it a whirl.
tyingq 7y ago
They fixed it later, but in the beginning, everything was a C string. Meaning you couldn't output a NULL char. Pretty frustrating when I discovered this while trying to write a length encoded protocol :)
neilobremski 7y ago
I have never used Tcl but this headline truly intrigued me. It sounds like the antithesis of JavaScript's "everything is an object". An object is very abstract whereas a string is very ... literal? I know many generic operations I can already do with a string but then inspecting its contents (which would be a generic operation) may reveal other capabilities, restrictions, what have you. Hmm ...
monetus 7y ago
I think it is worth mentioning that I learned TCL through the Pure Data audio language, which was designed with the idea of continuously supporting at least 20 years of hardware IIRC. It is such a useful language.
known 7y ago
In AWK every value is Integer/String
lyrachord 7y ago
Not only for Tcl, all compiler writers should know it.
jsgrahamus1953 7y ago
For most of the past 38 years I have earned my living as a computer programmer/developer using the Mumps programming language. It, too, views most everything as a string (or an array), and sometimes that string can also function as a number.

227 points by blacksqr 7y ago

Tcl: one of the slowest languages https://github.com/trizen/language-benchmarks https://github.com/trizen/language-benchmarks

bbmario 7y ago
wtf luajit is a monster
- steveklabnik 7y ago
  It really is. Mike Pall is... beyond words. https://web.archive.org/web/20170102051538/http://article.gmane.org/gmane.comp.lang.lua.general/75426 https://web.archive.org/web/20170102051538/http://article.gm... (Discussed on HN: https://news.ycombinator.com/item?id=2588696 https://news.ycombinator.com/item?id=2588696)
- chaorace 7y ago
  I think it's cheating a bit to compare JIT vs runtime script evaluation. I'd be more interested to see LuaJIT performance measured against something more comparable, like JS running on V8.
- tomnipotent 7y ago
  Probably why it's so popular in games as a scripting engine (going back to 2003).
  - est 7y ago
    > in games as a scripting engine (going back to 2003) you are think of lua, luajit is a different beast. http://luajit.org/changes.html http://luajit.org/changes.html LuaJIT 1.0.3 — 2005-09-08 This is the first public release of LuaJIT.
    - tomnipotent 7y ago
      Didn't realize they had the Python/PyPy thing going on. Thanks for the info!
- stjohnswarts 7y ago
  I thought it was dead/dying though? No future plans to add new features, especially sense the creator said he was done with it...
forinti 7y ago
But it's the fastest way to put together a GUI.
- criddell 7y ago
  Does Tcl deal with platform-specific GUI elements, or does it restrict you to a lowest common denominator set of widgets? Are there different dialog layout controllers? For example, in Swing there's BoxLayout, CardLayout, SpringLayout, etc...
  - pwg 7y ago
    You get both native and custom GUI elements with modern Tk. And yes, there are plural "layout controllers" (Tk calls them "geometry managers").
  - fooblitzky 7y ago
    I believe they are referring to the Tk GUI toolkit, which is intended for use from Tcl and really nice to work with. It is full featured and has plenty of widgets and layout controllers. You can find out all about Tk here: https://tkdocs.com/ https://tkdocs.com/ It is really fast and easy to create GUIs using Tcl/Tk, e.g. here is a Tcl script to create a paint-like program in less than 50 lines: https://pastebin.com/6qibnQcJ https://pastebin.com/6qibnQcJ The main downside is that the look and feel is not native, and a bit dated. There are some efforts to update the look, but it's not as slick as Gtk etc.
- jhallenworld 7y ago
  What about tkinter for Python?
  - nrclark 7y ago
    I dunno if you were going for irony or not with that!
- ThomasBHickey 7y ago
  I always thought Java should have just used Tk rather than developing AWT, which never worked very well.
haolez 7y ago
Tcl is really nice to work with. It’s a weird mix between a programming language and a command line interface. If you’ve never touched it, I recommend you to do so if you are curious :)
igouy 7y ago
Maybe Tcl does recursion poorly — those all seem to be tiny recursive functions. Maybe there was something Tcl did well? https://web.archive.org/web/20060924085254/http://shootout.alioth.debian.org/gp4/benchmark.php?test=regexdna&lang=all https://web.archive.org/web/20060924085254/http://shootout.a...
- databasher 7y ago
  TCL had an amazing architecture for someone who was working in C. In C, you'd (1) create an instance of a TCL interpreter, (2) register your C functions with the TCL interpreter, and then (3) load scripts into the TCL interpreter. You'd do all your fast stuff in your C code, and just use the TCL for stitching together the high-level logic.
  - pinopinopino 7y ago
    This, it is really easy to embed the tcl interpreter. Far easier than perl and python, even easier than lua.
    - lanstin 7y ago
      Especially the commands were invoked command_name(argv, argc) and the thing was just like a CS 101 C program. Dead simple, and as they mentioned just used to orchestrate the fast stuff. You shouldn't make a command block a long time, but you could grab a handle to the output destination and set it up to stream output there from the C.
mhd 7y ago
Tcl: No significant difference to Python or Perl It matters even less for Tcl, as it's supposed to tie pieces written in more performant languages together. See "Ousterhout's dichotomy"[1]. Sadly that also moved it closer to something like Rexx (or Lua these days), and thus no proper module/package community ever arose in time. [1]: https://en.wikipedia.org/wiki/Ousterhout%27s_dichotomy https://en.wikipedia.org/wiki/Ousterhout%27s_dichotomy
- jhallenworld 7y ago
  Maybe true, but there are fast math extensions: https://realpython.com/numpy-tensorflow-performance/ https://realpython.com/numpy-tensorflow-performance/
  - ori_b 7y ago
    Yes. Those work by tying python to pieces written in a more performant language.
  - mhd 7y ago
    And Perl has PDL. Not aware of anything for Tcl beyond math::statistics, but I think it waned in popularity way before the ML bubble started inflating. But in my experience, the strategy for Tcl is the inverse of Python when it comes to domming/subbing with your "partner language". You _extend_ python, you _embed_ Tcl. At least in the areas where Tcl still survives. It lost long ago against the P-languages, but still faces Lua rather bravely in the enterprise/engineering sector.
deaps 7y ago
A pretty good read on tcl - and why the F5 devices use tcl for their iRules (2012, Updated two years ago). https://devcentral.f5.com/s/articles/irules-concepts-tcl-the-how-and-why https://devcentral.f5.com/s/articles/irules-concepts-tcl-the...

geogra4 7y ago

My first job was in Tcl. I grew to really like the language, though when I had to leave the company I was at a pretty strong disadvantage due to how uncommon it is. Everything is a string is a great way to reduce the mental load about typing.

commandlinefan 7y ago
One of my earlier jobs was porting Travelocity.com from TCL to Java - the TCL programmers loved the old site and absolutely hated the "new" one. I don't think I've ever managed to make more enemies in my professional life than I did in those couple of years.
- ramses0 7y ago
  CARL!
- stjohnswarts 7y ago
  I remember you >_< , whipper snapper!
- geogra4 7y ago
  Tcl to Java is a huge change. Totally different syntax / syntactic style. I can imagine the annoyance of the Tcl programmers having to deal with the inherant verbose-ness of java.
  - commandlinefan 7y ago
    Yeah, and this was in the relatively early days of Java, too, so the front-end was all JSP. Oh, did I mention they originally gave us a three-month deadline to port the ENTIRE site?
ghettoimp 7y ago
> Everything is a string is a great way to reduce the mental load about typing. I feel almost the exact opposite way... Everything is a string means I have to "know" whether any given function takes {a single element, a list of elements, a glob, a list of globs, ???}. When I inevitably mess it up, I don't get any help at all from the language. In the best case, I'll hit a run-time error and figure it out. In the worst case, my program will just do some random thing that isn't what I wanted, and I'll get to debug it.

davidw 7y ago

I think the article doesn't make enough mention of the fact that internally, most things are not actually strings for much of their lifetime. They must be able to be represented that way, but that's different than everything being a string all the time. It does create a few problems, but they're a bit more subtle than "OMG, the integers are strings all the time!"

kevin_thibedeau 7y ago
This is an old wiki entry that dates from the pre-8.0 days of Tcl (The history is truncated). For the past 20 years everything has been representable as a string.
- blacksqr 7y ago
  It is old, but continuously updated. Last update, last Friday.
  - kevin_thibedeau 7y ago
    That is irrelevant when the main thrust of the article is outdated and reflects the worldview from before Tcl_Obj was added.

winrid 7y ago

Redis was originally in Tcl! https://gist.github.com/antirez/6ca04dd191bdb82aad9fb241013e88a8 https://gist.github.com/antirez/6ca04dd191bdb82aad9fb241013e...

dickeytk 7y ago
It seems they’ve held onto the “everything is a string” pattern too
yellowapple 7y ago
SQLite was also originally a Tcl extension, IIRC. They're still very closely intertwined.
derefr 7y ago
And SQLite was originally a TCL extension! From https://www.sqlite.org/tclsqlite.html https://www.sqlite.org/tclsqlite.html: > The SQLite library is designed to be very easy to use from a Tcl or Tcl/Tk script. SQLite began as a Tcl extension and the primary test suite for SQLite is written in TCL. SQLite can be used with any programming language, but its connections to TCL run deep. Given both of these, it kind of feels like something about the Tcl philosophy leads people to build (or draws in the sort of person who builds) simple/elegant data storage layers. Makes me more curious about it.
- winrid 7y ago
  Wow!
- lanstin 7y ago
  Ousterhout's book on Tcl has a chapter one that is essentially "How to do small reusable things in unix and win" - it's absolutely brilliant and explains how to think in unix and why composable entities with simple interfaces have done so well. SQLite and TCL are the best of unix philosophy made concrete. I just read in this thread that he expanded it to an entire book - I'll be reading that as soon as I finish binging The Family Man on Prime Video. Extending TCL with a new C command is exactly as hard as a CS 101 C program (which at the time was the lower limit on easy for CS folk).

IshKebab 7y ago

> This is one of the central features of Tcl. One of the biggest missing features surely? "Everything is a string" is a terrible design.

protomyth 7y ago
Yet UNIX pipes are strings and amazingly popular. Its amazing how we don't see a movement to get typed streams so we can give up the reparse culture of UNIX. I guess PowerShell does typing.
- pjc50 7y ago
  The problem with typed streams is that couples the implementations together on both ends and tends to de-genericise them. You get a "grep" that would only work on strings when actually you'd be quite happy grepping numbers 99% of the time. Also in order to serialise them you'd need fully typed files. Notice that you can't serialise a Powershell stream. The world tried "everything is XML" and more recently "everything is JSON" as a solution to this. The latter is almost there.
  - derefr 7y ago
    What CLI userlands (POSIX, Powershell, Plan9) are missing, IMHO, is a self-describing serialization "stream container" format, like Avro (https://avro.apache.org https://avro.apache.org), the interchange format used in Hadoop, Kafka, and several other systems of the "gluing IO-streaming components of different languages together into an ETL pipeline" variety. (Which is, of course, exactly what you're doing when you write a Unix pipeline, just in-the-small.) Where in self-describing data formats like JSON or XML (or even the more efficient encodings like ASN.1), every term is "described in place", taking up a lot of encoding overhead and bandwidth; in a self-describing stream container format, each encoded stream first encodes a schema (or the ID of one) for what it's about to transmit; and then transmits the terms encoded using the schema. Because schemas are referred to by embedding them in the document in a normalized form, each stream received by a client can be handled by a hybrid approach between building up just-in-time dynamic parsers from the schema, if it's not known; or recognizing known schemas (by e.g. hashing the representation of the schema, which works since it's in a normal form) and using a baked-in decoder for that specific schema if available. This would work pretty well as an enhancement to standard POSIX CLI IO-streaming tools; they'd be able to use specific logic to optimize the parsing of a few schema-encoded types they "expect", while also faithfully (but less efficiently) handling data of any type by falling back to a generic parser routine. (By which I don't mean "falling back to treating the stream as text", but rather "falling back to treating the stream as the custom type that the sender specified." Sort of like how, in most languages, you can compile regexes that are available at compile time, but also have a regex interpreter for regexes received at runtime.)

rongenre 7y ago

Everything is a string including the comments -- commenting code actually degrades performance!

mschaef 7y ago
I'm pretty sure this hasn't been true for 20 years. Tcl 8.0 introduced a form of byte compilation. [1] While the comments might slow down the compilation a bit, I doubt they have any impact at runtime these days. 1] https://www.tcl.tk/software/tcltk/8.0.html#What's%20New%20in%20Tcl%208.0 https://www.tcl.tk/software/tcltk/8.0.html#What's%20New%20in...
pwg 7y ago
This has not been true since the introduction of the bytecode compiler in Tcl 8.4 (well over ten years ago now). Tcl 8.4+ will byte code compile the proc's, and part of that is removing the comments from the code execution path. So comments only get 'seen' once (at byte code compilation time, upon first use of a proc) and then have no effect on execution performance from that point forward.
ThePadawan 7y ago
IIRC this was also the case for node/V8/I don't recall: Whether a function was inlineable was decided based on its size - and that was determined based on size-as-text instead of size-as-AST. This lead to the situation where adding too much comment text (I believe it was 512 bytes total for the function) led to the inliner refusing to inline the code, and thus performance regressions.
mdaniel 7y ago
This business falls into the "well that's handy" followed by the "who in the world thought honoring continuation characters in comments was a good idea?!" #! /bin/sh # the next line restarts using tclsh \ exec tclsh "$0" ${1+"$@"} This page is just filled with wow: https://wiki.tcl-lang.org/page/comment https://wiki.tcl-lang.org/page/comment with an especial nod toward: set two [1 + 1] ;# line comment needs a statement terminator
- 7y ago

nrclark 7y ago

Heart️ for Tcl. Tcl wasn't my first language, but it's near and dear to my heart. It's a little oddball for sure. I can't decide whether it's Python trying to be Bash, or Bash trying to be Python. But it's surprisingly expressive. Everything is strange about the syntax - from "everything is a string" to "expr" to the weird variable-assignment syntax. It's also really tiny, and has a great async event-loop framework. It has built-in support for sockets and non-blocking I/O. It has a GUI toolkit that's pretty useful for making quick-and-dirty tools. It's incredibly easy to use interactively with a REPL. And it's still the scripting language of choice for the FPGA industry, which is where I got my start as a software engineer. The Tcl community is small and stable. And the language just keeps soldiering onwards, in a gradual way. It feels like it's been stable and fully-realized for the last 20 years. No breaking API changes, no syntax changes. It just keeps on keeping on, providing automation to tools that need it. Tcl has outlived a bunch of newer languages, and I hope it sticks around for another 20 years.

toraobo 7y ago
> Python trying to be Bash, or Bash trying to be Python The fact that "everything is a string" is cute and odd but the end result is really closer to shell scripting than a real object-oriented language like Python. You routinely have to deal with string/list quoting and constructing complex data structures is tricky if they have to be represented with just strings and hashes. Sure: it's flexible and you can reimplement all the features of a high-level language but I'd rather use a language which has all the features already.
- nrclark 7y ago
  Tcl has native support for lists and dicts, and provides full-featured functions for working with both. You're absolutely right that the feel is "more than Bash, less than Python." But it's not accurate to say that you need to do a bunch of weird string parsing in order to implement a high-level datatype. And yes - the list quoting rules are weird! No doubt about that.
  - mst 7y ago

jadbox 7y ago

Everything being a string at a language level is similar to the paradigm as 'everything is an object' in java. Outside of select use-cases (scripts/text proc), the language generally fights against both conciseness and performance. I worked with UCLA where a few teams needed to use Tcl to maintain existing web servers, and virtually every developer highly complained about using it (aside from one or two career Tcl-ers). To be honest, I don't personally have much experience with Tcl, but from what I've seen/heard, I wouldn't ever think of building web servers upon it.

Mountain_Skies 7y ago
One of my first jobs after college involved creating websites using Vignette StoryServer. At the time Tcl was the only language you could use with it. I was happy when a new version was released that supported Java and ASP. Tcl looked like voodoo magic to me but I'm sure for those who really got it, they were pretty productive with it.
- kiwidrew 7y ago
  You've brought back some painful memories for me. I'm permanently allergic to the words "lindex" and "upvar", and cringe whenever I see a "," character in a URL... Vignette's only redeeming qualities were that: (1) the page templates permitted the execution of arbitrary Tcl code, not just the small subset that was documented by Vignette; and (2) much of the Vignette functionality was itself actually implemented in Tcl. This led to the glorious discovery that one could simply bypass the entire crazy Vignette system and use it like a very expensive (and somewhat slower) AOLserver. I sometimes feel sorry for the poor souls who inherited my terrifying and entirely undocumented creation, but that's what happens when management forces developers to use the entirely wrong tool for the task at hand. ("We spent $100k USD on this software so we're damn well going to use it!")

tabtab 7y ago

I had a bit of trouble knowing which "escape level" I'm in while debugging. You have strings that wrap strings that wrap strings, etc. Maybe with more experience I'd learn to manage string nesting levels better, but there does seem to be a non-trivial learning curve, at least for us mortals.

nerpderp82 7y ago

Tcl is an alien technology I wish I embraced when I was first exposed to it. I didn't quite get it, I was confused, so I gravitated towards Perl because it reminded me of C somewhat. I wasn't aware of my cognitive blind spots. In many ways Tcl is more powerful than most implementations of Lisp. Like a Lisp crossed with a Forth with the ability to turn spheres inside out with no tearing during execution. Magic.

pmoriarty 7y ago
"In many ways Tcl is more powerful than most implementations of Lisp." Could you elaborate on this? In what ways is it more powerful? Also, I don't get what connection TCL has with Forth. They seem uttery different from each other to me.
- ithkuil 7y ago
  One thing those three languages have in common is that they are almost syntax-less. Each, in its own particular way, allows user defined code to process tokens of the program source before it gets to the core interpreter, allowing users to implement custom control structures and DSLs.
  - stjohnswarts 7y ago
    I've seen a lot of people compare it to Forth for DSL implementation
- dmux 7y ago
  You can delay evaluation of Tcl expressions, for one.
flavio81 7y ago
>turn spheres inside out with no tearing during execution. Magic. What does "turn spheres inside out" mean? >with no tearing Is this painful?
- 7y ago

gilbetron 7y ago

I have about 5 years of heavy experience with TCL, split in half by 15 years away from it. I got a lot done with it, and it is an interesting language, but I have never, ever said, "I wish I was using TCL" in any situation. It is a unique journey down an alternate path for computer languages, that really ends up nowhere compelling, but the path itself is not arduous, although the bugs can be.

fluffything 7y ago
I had 1 year of full-time experience with TCL, and I can basically summarize it in the same way as you: got a lot done with it, wasn't horrible, but don't miss it. In retrospect, I am kind of happy that somebody actually went and built TCL. "Everything is a string" is not really a sound PL paradigm, but someone needed to get stuff done, and it worked quite fine for that. It's super simple and super powerful, and beginners can be productive with it really quickly.
stjohnswarts 7y ago
Similar, I was forced to write scripts in it when I was at a more silicon/hardware oriented company. It's an interesting language but I much preferred moving on to ruby/python for my V&V activities.

skybrian 7y ago

It's nice to guarantee that every value has a string representation. The not-so-nice part is that you have no static types and therefore no easy way to guard against mixing up safe and unsafe strings, so security reviewers will have a hard time. This is a design from before when the dangers of handling untrusted input as bare strings and doing escape handling all over the codebase were understood.

jascii 7y ago

For me Tcl's killer app has been Expect: https://core.tcl-lang.org/expect/index https://core.tcl-lang.org/expect/index there is nothing quite like it if you have to manage 1000's of devices and cli's are the only thing you have to do it!

stjohnswarts 7y ago
have you used pexpect?

ahartmetz 7y ago

Everything is a string in CMake, too. Even lists. Be very afraid of strings containing the separator character ';'...

crispyambulance 7y ago

My favorite thing in the Tcl ecosystem was "Expect". It's a tool you can use to automate ssh/telnet/serial connections to other machines. It has a really mature and elegant way of handling the automation of command/response scenarios in connections to other machines. I do similar stuff with .net now, but it's not as pretty. I wish there were a modern equivalent of Expect that as as nice.

catalogia 7y ago
Years back I worked on an automated test framework for small/mid-business scale cisco-clone routers that used Expect to drive the telnet CLI interface and put the routers through their paces. I remember something a more senior engineer at the company told me: Expect is the best tool for when you need to get a job done the wrong way. (Using Expect was his idea, to be clear.)
- crispyambulance 7y ago
  Curious... your colleague said Expect was "the best wrong way", what would have been the "correct" way in your scenario? How would something like that best be done now? Ansible?
AstroJetson 7y ago
I also love Expect and still use it. It makes a lot of what used to be "fingerbone tasks" go super quick.
dharmab 7y ago
Expect is an amazing tool for dealing with old hardware that _insists_ on interactive prompts instead of CLI flags.
- oefrha 7y ago
  Also great for automated tests of interactive functionality in your own projects.
- rikkus 7y ago

m4r35n357 7y ago

gitk !!! also Linux kernel config

kroger 7y ago

A nice article to quickly understand Tcl defining features is "Tcl the Misunderstood": http://antirez.com/articoli/tclmisunderstood.html http://antirez.com/articoli/tclmisunderstood.html And some previous HN discussion on the article: https://news.ycombinator.com/item?id=7069642 https://news.ycombinator.com/item?id=7069642 https://news.ycombinator.com/item?id=4920831 https://news.ycombinator.com/item?id=4920831 Edit: grammar

FabianBeiner 7y ago

TCL. That brings me down the memory lane to IRC and all those Eggdrop bot scripts I've written. :)

pjmlp 7y ago

Actually since Tcl 8 that is no longer true, yet it keeps being repeated as such. http://www.tcl.tk/software/tcltk/8.0.html http://www.tcl.tk/software/tcltk/8.0.html TclTk was great, but it also teached me never again to rely on languages without JIT or AOT available on their toolchains. Rewriting Tcl functions into C code was a routine task.

takeda 7y ago
Yeah, but that just changed internally, in the language everything is still a string.
- wrenky 7y ago
  A better way to phrase it (..even before tcl 8) is that everything can be TREATED like a string. Numbers arent being converted to and from strings, things like sockets/files arent strings (their handles are though!)
  - _ph_ 7y ago
    Right. I think the one great feature it shapes with Lisp is, that everything has a textual representation. That means, all types of values can be presented as text and can be recreated from a textual representation. For Lisp, it is S-Expressions, which can be printed and read, for TCL it is the syntax which can be printed as strings and interpreting strings as data.
    - dmux 7y ago
      >I think the one great feature it shapes with Lisp is, that everything has a textual representation. Is this true even for procedures? I was recently playing around with Scheme and was disappointed that once a procedure is defined, it got internalized and didn't have a textual representation other than #<proc> or the like. In TCL, procedure signatures and bodies are stored within the runtime. You could essentially dump the entire state to a TCL file.
sokoloff 7y ago

bachmeier 7y ago

This paper by John Ousterhout (creator of Tcl) is a good read if you think Tcl is a weird language plagued by bad design decisions. If that describes you, it's probably the case that you don't understand the problem Tcl was designed to solve. https://web.stanford.edu/~ouster/cgi-bin/papers/tcl-usenix.pdf https://web.stanford.edu/~ouster/cgi-bin/papers/tcl-usenix.p...

bloaf 7y ago
>Almost all Tcl ‘‘programs’’ will be short, many only one line long. I weep silently over the 50kloc tcl codebase I help maintain.

foobar_ 7y ago

There is an object-oriented extension to Tcl which is along the lines of CLOS. http://media.wu-wien.ac.at/whatIsXOTcl.html http://media.wu-wien.ac.at/whatIsXOTcl.html Lispers need to stop thinking that they are the only ones who can do "macros" and "DSLs". The evidence is clearly on the contrarian side. You can have syntax and macros and be practical. If the failure of Tcl has taught us anything its that performance is important.

flavio81 7y ago
>Lispers need to stop thinking that they are the only ones who can do "macros" and "DSLs". The evidence is clearly on the contrarian side. We know that one can do "macros" in many other languages including of course TCL. The question is how difficult is to do them and how easy is to have control over there. Lisps, due to code being s-expressions, make macro creation extremely easy, and Common Lisp has useful tools to ease working with macros, for example macroexpand, which is integrated into most Lisp IDEs to easily visualize, in-place within the code, how a macro will expand into, step by step. In comparison to that, most languages that do allow macros, make it a cumbersome, buggy task.
- foobar_ 7y ago
  XML, Julia, Rust, Crystal, Forth? support macros too. I was just pointing out that it can be done without sexp. Yes, the tooling sucks. Grammatical implementation is less powerful but that seems better than implementing a grammar ontop of sexps. You get some lexical freedom ontop of pure text that you don't get implementing grammars on top of sexps, respecting lisps tokenisation rules. I wonder how far Lisp would have come if people had taken the source-source translator approach of js and just implemented an Algol frontend to lisp. There's plenty of things that Lisp had that are far more useful than just macros. I think Tcl is the Unix answer to Lisp. Worse is better somehow evolved into a Lisp.
  - kazinator 7y ago
    > I wonder how far Lisp would have come if people had taken the source-source translator approach of js and just implemented an Algol frontend to lisp. People did that a number of times over Lisp's history, so Lisp would have come exactly where it has come. The first Algol-like front end to Lisp was supposed to be the direct descendant of Lisp 1, namely Lisp 2. This branch went nowhere. The descendants of Lisp trace back to Lisp 1.5. In the early 70's there was something called CGOL. It still exists. There have been various more recent things in that direction. And of course, certain contemporary languages are basically sort of Lisp-like things with Algol bolted on. Lisp 2: https://en.wikipedia.org/wiki/LISP_2 https://en.wikipedia.org/wiki/LISP_2 Manual with code examples: http://www.softwarepreservation.org/projects/LISP/lisp2/AbrahamsEtAl-LISP2.pdf http://www.softwarepreservation.org/projects/LISP/lisp2/Abra... CGOL: https://en.wikipedia.org/wiki/CGOL https://en.wikipedia.org/wiki/CGOL

ycombonator 7y ago

It still powers some companies with an annual rev ~1B.

wanderer2323 7y ago

The string is a stark data structure and everywhere it is passed there is much duplication of process. It is a perfect vehicle for hiding information. -- Alan Perlis

ken 7y ago
I think Tcl strings aren't exactly what Perlis was talking about. First, the language knows how they're used, so there's a JIT (or whatever) behind the scenes eliminating the literal deserialize-process-serialize pattern you see in shell scripts. Second, a lot of Tcl data types (hash tables, sockets, etc) can be represented by strings but the string is just a simple reference to a rich internal structure. It's almost more like a pointer than a string in other languages.
- lanstin 7y ago
  I know this item is old but surely no shell script should be limited by string copying of the language? Maybe string shuffling thru pipes, but that's the reason the CPU briefly spikes.

nahumba 7y ago

ha! i 'member this. hmmmmm Stringly Typed. yes. yes. https://blog.codinghorror.com/new-programming-jargon/ https://blog.codinghorror.com/new-programming-jargon/ now that you put a duck in news. i call to remove it. thankyou.

pinewurst 7y ago

Don't forget the amazing AOLserver, which was a very elegant web applications server with Tcl as the native template language. This was a great environment.

gnachman 7y ago
I was tech lead for it for a couple years. Glad someone remembers it :)
- lanstin 7y ago
  Hey! I wrote flap in TCL module for it! Loved using AOLserver but writing the extension taught me to fear threads - now loving Golang :) but I miss AOL, AOLserver, SAPI and TCL in the evenings.

derefr 7y ago

About a decade ago now, I was writing a group chat system of the Slack/Discord variety, and I was pondering how I'd like to support markup. I wanted to do something more powerful than just the regular "bold/emphasis/strikeout/links/etc." set, as the users of this group-chat were the type who would enjoy adding animations and other "effects" to their text, especially on top of their custom emoticons/stickers. (Don't fret, this wasn't team-productivity software ;) What I ended up doing was extending the backend with support for parsing messages using a "command language"—essentially Tcl. The "everything is a string" feature of Tcl-like languages was essential, because I wanted these "commands" to be arbitrarily composable, and both the input and output were required to be strings (i.e. HTML), so commands couldn't pass data-structures to one-another; they had to accept strings, and emit strings. The user was not allowed to enter arbitrary HTML in their message (this was filtered out as a pre-filtering step), but any Tcl command was allowed to take HTML-strings as input and emit HTML-strings as output, and the string that was eventually generated, HTML and all, was treated as the user's actual message. Many of the implemented commands would parse the input HTML-string into an AST, tweak it somehow, and then re-emit it as a string. An example of such a command would be something like: And then [spoiler the protagonist died [rotate 5 [big :ohno:]]] ...where 'rotate' and 'big' layer together CSS effects (combining CSS classes with a bit of custom element style to parameterize it, with each rewriting the HTML AST structure of the previous to ensure the CSS effects "stack" correctly); and 'spoiler' is just a CSS class with pseudo-selector behaviors. Another example would be: [type oh nooo[sfx fall]oooooooo] ...which would use a CSS class+JS trigger to display the message one character at a time the first time it became viewport-visible... and embed a hidden <audio> element at the top of the message body, that would get triggered as the typing progressed to it. Sort of like the dialogue event-scripting in a video game. And, of course, just like an IRC bot, you could rely on the backend being Turing complete, in ways like: # generate random numbers [roll 1d6] # set a countdown timer on a user, # resetting it whenever the user talks [deadmanswitch 5mins I'm slacking off again!] # get the backend to (use a job queue to) # fetch a resource, plop it into its own download folder, # and then post a link to the retrieved copy [dl http://example.com] # same, but also create a BitTorrent torrent for # the file, register it with a BT tracker on # the backend, and then emit the URL of the torrent file [torrent [dl http://example.com]] --- At this point, I don't really think there's much room for a new group chat system; but this one feature was really cool to me, and I always wish I had seen it implemented in some bigger product.

eesmith 7y ago

> This simple and unified perspective on type is fundamental to the design of Tcl, and puts it in an exclusive category programming languages that do not have at least two data types that can be distinguished. The other languages in this category are forth, BCPL, and assembly language. What about TRAC? https://en.wikipedia.org/wiki/TRAC_(programming_language) https://en.wikipedia.org/wiki/TRAC_(programming_language)

elamje 7y ago

The SQLite author is a big Tcl user. I believe the codebase is primarily Tcl when you include the test suite, though the core implementation is obviously a C library. D Richard Hipp is his name and he has some nice talks online. He uses his own text editor and chat app he wrote in Tcl to maintain the project and communicate with other developers.

catalogia 7y ago
From what I understand, D Richard Hipp's appreciation of Tcl is the reason SQLite has dynamic typing. (I believe I heard this in one of his talks that's on youtube, which are excellent.)
- elamje 7y ago
  That makes sense. I heard him say that the pain points of dynamic typing are mostly just people using it for web apps that eventually have to migrate to Postgres and the like, causing some headaches because client server DB’s are much more rigid, causing errors. I agree that his talks are great! He’s such an enthusiastic guy. I hope SQLite will adopt default foreign keys and WAL sometime soon, but I understand that he needs to keep it as backwards compatible as possible.

stevekemp 7y ago

If you're not familiar with TCL this introduction from redis-author Antirez is worth a read: http://antirez.com/articoli/tclmisunderstood.html http://antirez.com/articoli/tclmisunderstood.html

RandomGuyDTB 7y ago

That's really weird. I didn't know this was a thing but I had a dream a couple days ago that I was using a language in which everything was a string (like Lisp but with strings instead of lists). Guess I'll have to give it a whirl.

tyingq 7y ago

They fixed it later, but in the beginning, everything was a C string. Meaning you couldn't output a NULL char. Pretty frustrating when I discovered this while trying to write a length encoded protocol :)

neilobremski 7y ago

I have never used Tcl but this headline truly intrigued me. It sounds like the antithesis of JavaScript's "everything is an object". An object is very abstract whereas a string is very ... literal? I know many generic operations I can already do with a string but then inspecting its contents (which would be a generic operation) may reveal other capabilities, restrictions, what have you. Hmm ...

monetus 7y ago

I think it is worth mentioning that I learned TCL through the Pure Data audio language, which was designed with the idea of continuously supporting at least 20 years of hardware IIRC. It is such a useful language.

known 7y ago

In AWK every value is Integer/String

lyrachord 7y ago

Not only for Tcl, all compiler writers should know it.

jsgrahamus1953 7y ago

For most of the past 38 years I have earned my living as a computer programmer/developer using the Mumps programming language. It, too, views most everything as a string (or an array), and sometimes that string can also function as a number.