picol: A Tcl interpreter in 500 lines of code(github.com)
97 pointsby tosh9 hours ago7 comments
  • analog313 hours ago
    Quite a few years ago, I was looking for a way to program microcontrollers via an onboard interpreted language, and happened on the picol code. I still have my version somewhere. It was delightfully straightforward and easy for an amateur to modify. So I first got it to compile on a Teensy, then added a REPL, floating point, and a few functions to do things like flip the GPIO bits and read the ADC.

    Today of course there are things like CircuitPython, and I enjoy using it too, but it's such a beast that it's really impenetrable for someone at my skill level if I want to add low level functions.

    • antirez32 minutes ago
      Thanks for your comment! Maybe it's time for picol2.c, same amount of lines of code, but floats and [expr]. I'm going to use a few hours today to get there. Such small changes would make it more practical for real use cases where one wants to retain understandability.
  • stevekemp7 hours ago
    Sadly it seems the blog post that was released in the past is no longer available, but the wayback machine has a copy

    https://web.archive.org/web/20220303135439/https://oldblog.a...

    That provides background about the constraints/limitations in this code.

    • antirez6 hours ago
      Restored. Recently I migrated all my stuff into a new server and missed to migrate the /pages of the old blog. Thanks.
  • seyz5 hours ago
    Classic antirez. Does more in 500 LOC than most frameworks in 50k.
  • iberator7 hours ago
    best thing about TCL is easy syntax and that everything is a string :) Unique and simple and easy language with very slow changes.

    Something like Python in good old days of 2.x before young internet javasceipt devs started pouring A LOT of new features to the language (feature creep).

    Nowadays Python is so complex and flooded with ex C, C++, Java, JavaScript, Haskell programmers adding so many features, so fast that it's impossible to follow and understand them :(

    Languages should not evolve on that rate. No time to master it :(

    /rant

    • pjmlp5 hours ago
      Tcl has stopped being everything a string with the release of Tcl 8.0 and bytecode engine.

      > In earlier versions of Tcl, strings were used as a universal representation; in Tcl 8.0 strings are replaced with Tcl_Obj structures ("objects") that can hold both a string value and an internal form such as a binary integer or compiled bytecodes.

      http://www.ira.inaf.it/Computing/manuals/tcl/man-8.0/Changes...

      I remember this quite well, because as part of the core team tasked with writing native C extensions, the migration to Tcl 8 had quite an impact on our code.

      I learned Python with version 1.6, and have a few O'Reilley books proving the point the language wasn't really that simple, those that never bothered reading the reference manuals end-to-end though it was.

    • robinsonb56 hours ago
      There's certainly something to be said for stable, uncomplicated and minimalist tooling that wont evolve out from under you and leave you with something that won't just-work five years from now.

      I guess that's why Tcl is so popular in the EDA arena. I can stick some custom JTAG tooling in a Cyclone II design and talk to it by Tcl-scripting the 15-year-old software - and be confident that the same code (both in the FPGA and on the host computer) would work with the latest software and a current device.

      Having said that, Tcl's not entirely free of compatibility and fragmentation frustrations: I sometimes wish that OpenOCD used full-fat Tcl rather than JimTcl, just so that I could make use of Tk. Being able to plot a histogram of data collected from the FPGA or make clickable buttons to trigger events is very useful.

    • tverbeure35 minutes ago
      The worst thing about tcl is that it exists... and it's still the language of choice for EDA tools.
      • xantronix13 minutes ago
        I'd be curious to know what your experiences with Tcl have been, to better understand why you feel this way.
    • tonyedgecombe7 hours ago
      I agree, so much for the benevolent dictator idea.
    • Pay087 hours ago
      That's certainly a take...
    • IshKebab7 hours ago
      > best thing about TCL is easy syntax and that everything is a string :)

      What? That's the worst thing about TCL.

      • iberator7 hours ago
        I love it. Living proof that languages doesn't need forced types.

        Data is Data. It's kinda object programming as visioned in the 70".

        So easy and trivial language.

        • IshKebab4 hours ago
          > Living proof that languages doesn't need forced types.

          The opposite surely? TCL is practically dead, and only lingers on in the EDA industry (which has zero taste). Virtually every successful language today has at least a few different basic types for numbers, arrays, strings, maps and so on.

          • ux266478an hour ago
            TCL's typicing discipline comes from shell languages and awk, which are decidedly not dead. The overwhelming majority of programmers have less than no taste, so language usage rates in general don't really mean much.
          • bmacho4 hours ago
            Tcl has these types as well. They are special strings.

            Number: string of digits. List: strings separated by space. Dictionary: key value pairs in a list.

      • antirez6 hours ago
        It depends on the use case. For instance you open a socket, write there any value you have without serialization, read it in the other side, data transfer done.
        • petcat5 hours ago
          The convenience of not having to marshal data over a network is certainly a use case. But I'll admit that two of the worst programs I ever saw were written in Perl and TCL. Somehow just a big jumble of inscrutable regexes.

          When "everything is a string" then you have no choice but to literally treat everything as a string. Painful. Very cool project though.

          • graemep4 hours ago
            That sounds more like someone who over-uses regexes - the developer is the problem, not the language

            TCL has a lot of options for manipulating strings - take a look at just the built in string command for a start: https://www.tcl-lang.org/man/tcl8.4/TclCmd/string.htm

            I have seen terrible code in Python, C, and more.

      • bmacho6 hours ago
        It's only the interface that is of a string. An array is a list of strings with space between, but only for the programmer. The runtime is free to use an actual array.
        • IshKebab4 hours ago
          I'm aware. It's awful because of the implications for the programmer, not the runtime.
  • JSR_FDED8 hours ago
    I remember we had users at a chip foundry who were super deep into TCL. Is it still used anywhere else? Would you use it for a new project if you for instance already knew Python or Lua?
    • catwell8 hours ago
      Antirez (the author of this interpreter) uses it for the Redis test suite.

      Personally, I know Lua and Python very well but I still used TCL a few years ago for something very specific: using ODBC on Windows. I gave more details on the Lua mailing list here: http://lua-users.org/lists/lua-l/2021-01/msg00067.html

      • JSR_FDED8 hours ago
        That was interesting to read. So in your case it came down to ecosystem depth, especially on Windows - where there was a TCL solution to talk ODBC, but the equivalent Lua functionality had issues on Windows.
    • uwagar3 minutes ago
      i like calling a function f without arguments simply as

      f # first word in TCL command line is a command

      rather than

      f ();

      if there was also a function called g, i like to do things like

      set a f

      $a # calls f

      so i can now

      set a g

      $a # calls g

      cool i think.

    • shawn_w3 hours ago
      I like tcl as an alternative to shell for any non-trivial scripts.

      And its coroutines + built in event loop makes for really nice seamless async style programming.

    • amelius6 hours ago
      By the way, I'm guessing that Tcl was (is?) big in EDA because John Ousterhout also wrote the EDA tool Magic.

      https://en.wikipedia.org/wiki/Magic_(software)

      • w4der2 hours ago
        Tcl's first "release" was in 1988 and Magic was released in 1984, but it seems like John Ousterhout then wrote Tcl to have a common interface across tools [https://web.stanford.edu/~ouster/cgi-bin/tclHistory.php]. It still is a big thing in EDA, because (in theory) it lets a chip designer run their designs by tools from different vendors
    • smartmic6 hours ago
      It is at the core of the SQLite test suite and also a first-class citizen in interfacing to it.
    • danhor8 hours ago
      It's still the lingua-franca of ASIC/FPGA/Simulation, especially for scripting the tools.

      I think it's slowly being replaced there by Python, but it's very slow.

      • xantronix8 minutes ago
        > but it's very slow

        The process of replacing Tcl, or Python itself?

    • vodou8 hours ago
      It is still used for operations procedures in, at least, European space industry. E.g., in mission control systems from Terma (CCS5 and TSC).
    • rausr7 hours ago
      We've got Check Point Firewalls at work, and during updates I see lots of .tcl in the web UI.
    • sprash7 hours ago
      Tcl/Tk to this day is the best tool to make GUI frontends for CLI applications. Besides that, in the past I used it in production for intranet database entry applications. It has since been replaced by Flask. In my opinion the higher complexity of the Flask version is no way justified and we should have kept the much simpler ~2k LOC Tcl/Tk solution.
      • jhbadger6 hours ago
        In the 1990s, entire GUI applications would be written in Tcl/Tk -- not just the frontend -- the entire thing.
      • WillAdams4 hours ago
        What is the best and easiest to install binary distribution?

        I was looking into this for v9 and gave up on finding a binary which was:

        - easily found

        - agreed upon as the one to use

        - available for and easy to install on all three platforms

        Should I look again?

      • fuzztester6 hours ago
        >Tcl/Tk to this day is the best tool to make GUI frontends for CLI applications.

        Why? Please elaborate. I've heard others say this, but would like to know more.

        >Besides that, in the past I used it in production for intranet database entry applications.

        GUI apps?

        • pwg25 minutes ago
          > Why? Please elaborate.

          Tk's GUI object model is sitting at a reasonable maxima between trivial to make use of vs. triggering the events necessary to make the GUI active.

          Small example. You want a button on your GUI that triggers a procedure called "process" when it is clicked, this is the code you need (if you are fine with the remaining defaults) (and assuming you used 'pack' as the geometry manager):

              button .process -text "Process Entries" -command process
    pack .process -side top
          And a fully active GUI button will now appear at the bottom of your Tk window, with a label of "Process Entries" and when you click it, a Tcl procedure named "process" will be executed.
        • sprash4 hours ago
          > Why?

          CLI applications typically read text from stdin and write text to stdout. The tcl model of "everything is a string" makes exactly the right abstraction to create GUI frontends for CLI applications rapidly and keep them simple at the same time.

    • AceJohnny27 hours ago
      I'm looking to use TCL for an embedded platform, as the scripting shell. Its simplicity and small size is key, as is its easy integration with C.
  • anthk9 hours ago
    JimTCL has more features and it's almost as small.