1. 31

Did any language end up taking that “highly programmable” space that antirez thought that TCL could be molded into, or has that point in the language design space been passed over for the time being?

  1.  

  2. 6

    I would say Lua took at least part of the space TCL was occupying. It is small but pretty versatile thanks to metatables. We see it used in configuration files and such things, and it was chosen for use in Redis by Antirez himself.

    1. 8

      Did any language end up taking that “highly programmable” space?

      Lisp had a chance for renaissance at that time. Paul Graham promoted Arc and Rich Hickey made Clojure. Neither was a huge success, although Clojure is still going.

      Maybe “highly programmable” is a trap. It encourages to create dialects and fragments the community. In contrast, the Python philosophy “There should be one– and preferably only one –obvious way to do it” seems to be more successful.

      1. 16

        Maybe “highly programmable” is a trap. It encourages to create dialects and fragments the community.

        Or maybe Paul Graham is just an asshole?

        Clojure solves a problem I don’t have: Needing Java without wanting to write Java. I’m old enough I can do what I want, and if I don’t want to write Java, I’m not going to write Java.

        I think we have a bunch of programming-language parts, and we don’t know how they fit together yet. It’s not even clear that we have all of the parts either; There still exist dumb interpreted languages that beat the pants off of the JVM and LLVMs of the world.

        In contrast, the Python philosophy “There should be one– and preferably only one –obvious way to do it” seems to be more successful.

        Popular.

        Time will tell if it will be more successful; I think not.

        I don’t have any large Python programs that I wrote ten years ago that run with a current version of Python. I still have TCL and Lisp programs however, that work fine. But this isn’t a support of super-flexible languages, it’s really just a jab at Python: I have C programs I wrote twenty years ago that still run, in production, and on the Internet without any updates.

        The appeal of programming, to me, is that I tell the computer what to do. I don’t really like the computer telling me I’m wrong, and so Python already has very little appeal for me. Combining that with the fact that the python steering “team” clearly don’t know what they’re doing either (e.g. a dozen or so IO models, and thus anything with IO needs a dozen or so implementations), means that I don’t pay very much mind to the opinion of Pythoners either.

        I don’t think “the” language is here yet.

        1. 5

          I thought clojure was a pretty big success. If people are making companies and products with it, i don’t see why it matters if it isn’t totally mainstream.

        2. 3

          I work for a company that uses TCL as our primary language. Naviserver is a solid web server that is still under some level of development. It is, however, very difficult to hire developers. If you’ve got some experience and want to work from home.. ping me.

          1. 1

            I got my start in the web world programming openacs using TCL/aolserver/postgres. Who’s still using that?

          2. 2

            Tcl has a number of faults

            It would be interesting to know what those faults are.

            1. 12

              As someone that has tried out TCL as of a year ago, I might have a couple ideas.

              One is that you don’t really have the ability to use pointers/references, which changes a lot of patterns. File handles get stored into global hashtables, and have to be explicitly deleted. I really like how TK does things, but it’s theme has to be set to non-default values to look modern. There were three rather specific things that led me to move on when I was trying to get into it.

              1. The TCL documentation is very patchworked. That’s fine for someone like myself, but it does add up with other small things
              2. TCL’s odbc driver doesn’t handle very wide columns well, leading to some faults. This isn’t a fault of the language, but it kinda was a buzzkill for the use case that I had been exploring for it (quick desktop side reporting for some stuff at work)
              3. TCL doesn’t have closures/lexical scope in the way that JS/Lua/Scheme do. This means that you get strange things like having to use a global variable to collect data from a thread that you launch with and try to vwait. I was using a thread to lanch a database query and trying to marshal the data back to the UI. Figuring out that global scope problem took me 3 hours, and felt kinda ugly when I realized what the fix was.

              I didn’t get turned off of TCL until I re-tried building a GUI in C#/VS and realized that modern tooling was such that C# was just about as expressive as TCL, and I didn’t have to worry about expr and how to nest my strings correctly. Stringly typed programs require a certain level of defensiveness (at least for me) and create a slightly strange set of inflexibilities around data layout, even as they allow you easily meta-program. After you get used to GC’d languages with reference types, you need a good reason to change mental models.

              That being said, Tk is an approach to GUI layout that I’d love to see properly replicated in other platforms. TCL is the only language where it’s trivial to build a GUI via a REPL. If I ever get around to building a GUI toolkit in PISC, I plan on learning as much from Tk on that front as possible.

              Another aspect of it all is that I’m not doing desktop GUI programming on a regular basis anymore. My hobby time goes into either game jams in Lua, or working on the PISC language and the various bits of tooling around that. At work I’m doing C# and ASP.NET web forms. TCL doesn’t have enough of a compelling web server story compared to C#, Go, or Java, and using TCL in place of JS just seems like it’d be an exercise in obscurity, which as fun as it could be to figure out, isn’t a way to ship things quickly.

              That being said, TCL has left a very strong legacy in software in our modern era. SQLite and Redis were both influenced by it, as are likely countless other tools. PISC is influenced by it. It still sees use in more than few places. But it lacks a tastemaker, and there are few things it does better enough than other toolkits the language itself to see wide use outside of the industries that have already adopted it.

              1. 2

                I agree with the criticisms you explain, and they’re well-put. I’m particularly interested to hear about the influence you feel TCL has had on other systems, especially SQLite since I happen to be reasonably familiar with it - I hadn’t heard that before, and although I sort of see similarities I would love to hear about what you see.

                1. 8

                  SQLite has been advertised as a TCL extension. The SQLite author (D. Richard Hipp) was a member of the TCL core committee for some time, until he got off. You can also see the influence in how SQLite is relatively loosely type compared to SQL Server or Postgres. You can also see the influence in how SQLite is designed to be embedded into an application. Tk gets a similar treatment when it is used. In a sense, SQLite is a bit stringly typed. That turns out to be much less of a problem in a SQL database, since SQL already forces you to keep yourself from thinking in terms of a memory graph,

                  For redis, I point you to this lobste.rs submission I made earlier this afternoon.

                  PISC is a scripting language that I’ve been working on, and it’s not primarily influenced by TCL, but there are flavors of that come through. $var for getting the value of a variable, for example.

                  I have spent some time in the past attempting to create the TCL with a better memory model that I wanted, though I got a bit stuck in the parsing phase due to the desire I had at the time for heavy DSL support. Not having written a full parser for anything recursive at that point, I ended up getting stuck a lot. The key to the nice aspects of TCL’s syntax is that it is effectively as LISP with one level of parens removed, if you squint a bit.

                  1. 4

                    Huh! Thanks. That all makes sense.

                    Yeah, I agree that TCL is almost-sort-of a bit like Lisp, if the “code and also data” type were strings instead of cons cells. That was what attracted me to it, at one point.

                    1. 3

                      Yeah. Though I will say it was the easy interactivity that attracted me to it, personally. The first time I was able to attack a console to a running GUI, and change the layout of said GUI, it was akin to the programming equivalent of crack. Most normal REPLs seemed super tame by comparison. I’ve since gotten used to the idea, but what an impression.

                      1. 2

                        There is a similarity. Closest one from string land to Lisp is definitely REBOL:

                        https://en.wikipedia.org/wiki/Rebol

                        It’s successor Red targets system programming on top of that:

                        https://en.wikipedia.org/wiki/Red_(programming_language)

                        Both languages are big on DSLing or transforming within apps. REBOL was used to make a platform for enterprises with super-tiny apps on client side. Red was being used especially in Syllable operating system last I checked.

                2. 4

                  As an additional thought, TCL’s ease of commands is something that I try to replicate with PISC, though PISC is stack based.

                  TCL is really worth a study if one is interested in the design of programming language syntax for human use, as it got a lot of stuff right, especially the command/args style of programming, Tk, the raw interactivity that it supports, and event driven threading. It may even be worth picking up for developing little visualizations for personal use, or use as a part of the expect tool.

                3. 1

                  TCL is a really amazing language. It has a superficially c-like syntax but allows you to define your own control structures and syntax. This ends up being put to good use. A fun example: in TCL you define function using the following syntax:

                  proc functioname [args] {
                    body
                  }
                  

                  But our particular implementation had a custom wrapper called ad_proc that added keyword arguments with defaults AND added all of our api docs to automatically generated API web pages.

                  ad_proc next_user_id {
                   {-user_id 10}
                  } {
                   functionname does some cool stuff and takes an optional parameter called user_id which defaults to 10
                  } {
                     puts $user_id
                  }
                  

                  The biggest drawback with TCL in my experience was datastructures. Our resultset from the database was basically a bunch of magic that created a bunch of variables called row:1 row:2, etc in a particular stack frame. That’s right, in order to pass a bunch of rows to the templating engine you had to call a function that created locals in a user-specified stack frame. http://openacs.org/api-doc/proc-view?proc=template::multirow&source_p=1

                  upvar $multirow_level_up $name:$i row