3 ms·

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 goo

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

IshKebab 8mo ago
> best thing about TCL is easy syntax and that everything is a string :) What? That's the worst thing about TCL.
- iberator 8mo 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.
  - IshKebab 8mo 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.
    - bmacho 8mo 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.
      - IshKebab 8mo ago
        No they aren't. Everything is a string. The runtime does some optimisation where it actually does use different types under the hood but they don't change the semantics. If you try to pass a list into a function expecting a string it will just treat the list as a string. No type error or anything, not even at runtime. CMake is the same. Terrible design. Real types are useful.
        deleted 8mo ago
        [deleted]
    - ux266478 8mo 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.
    - isr 8mo ago
      Well, if you use flightaware to track flights, you're using tcl. The vast majority of their codebase is in tcl.
    - zwischenzug 8mo ago
      If you place a sports bet online, odds (!) are that it will run through tcl in its business logic. I may even have written some of it.
- bmacho 8mo 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.
  - IshKebab 8mo ago
    I'm aware. It's awful because of the implications for the programmer, not the runtime.
- antirez 8mo 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.
  - petcat 8mo 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.
    - graemep 8mo 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 https://www.tcl-lang.org/man/tcl8.4/TclCmd/string.htm I have seen terrible code in Python, C, and more.
      - Treblemaker 8mo ago
        The objections to tcl I see most often seem to reflect an outdated or incomplete understanding of the language and its capabilities. As with many interpreted languages, maybe it's just too easy to iterate interactively with code until it "just works", rather than taking the time to design the code before writing it, leading to perception that it is a "write-only" language. However, despite its reputation, even Perl can be written in a way that is human-readable. I agree with you that it is more a reflection of the programmer or the work environment than of the language itself.
    - Treblemaker 8mo ago
      > When "everything is a string" then you have no choice but to literally treat everything as a string. As someone who has been developing tcl almost daily for more than 30 years, both object oriented and imperative code, I have not found it necessary to think this way. Can you explain what leads you to this conclusion?
Pay08 8mo ago
That's certainly a take...
tonyedgecombe 8mo ago
I agree, so much for the benevolent dictator idea.
robinsonb5 8mo 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.
pjmlp 8mo 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/Changes8.0.html 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.
- apgwoz 8mo ago
  There have always been attempts at caching non-string values in Tcl for performance gains, but the semantics are the same. The value’s types are whatever the operator requires and an error when not compatible. If, internally, $x is an integer, and you pass it to a string function, well, $x gets temporarily turned into a string. Dynamic with “weak” types.
  - pjmlp 8mo ago
    Which is exactly the quoted text.
    - apgwoz 8mo ago
      No. The quoted text says nothing about the value semantics, only the representation…
      - pjmlp 8mo ago
        Well, if you followed the link under the quoted text, you would get the next sentence, > The new objects make it possible to store information in efficient internal forms and avoid the constant translations to and from strings that occurred with the old interpreter.
tverbeure 8mo ago
The worst thing about tcl is that it exists... and it's still the language of choice for EDA tools.
- xantronix 8mo ago
  I'd be curious to know what your experiences with Tcl have been, to better understand why you feel this way.
  - elevation 8mo ago
    It's a combination of cumbersome syntax and the vendor's poor API design and execution environment. For a syntax example, compare python to Tcl. In python, there's a compact array lookup operator, and dictionaries allow string keys: mydata["channel"][2] Tcl, however, requires a function call to access an array index, resulting in nested function calls with magic numbers for the simplest expressions: lindex [lindex $mydata 35] 2 # Tcl Then there isn't any static type checking so you have to run code to see if it would work; the shape of a return may surprise you. Connecting to hardware may be your only opportunity to exercise certain code paths. So for any non trivial task, Tcl becomes effectively write-only. Some tools allow you to export Tcl scripts that automate tasks like project creation to help you avoid tracking intermediate objects in source control, but because the Tcl cwd path can change throughout a script, they export every source path as a hard coded absolute path, including whatever developer's home directory it might be residing in. This is not suitable for source control (because it would preclude building on any other machine) so then you have to post process these scripts before tracking them. But since it's Tcl there aren't good scriptable tools for programmatic Tcl AST manipulation, so you have to modify these files with some sort of a state machine, looking for various sentinels to trigger the various string replace behaviors you need. It's not all Tcl's fault, but if a vendor is only using Tcl for automation and you need automation, you have a battle ahead of you. Outside the language, you'll often find that your runtime tool locks the UI thread to run your scripts, so long running operations are impossible to pause or cancel. And I've never seen a vendor expose adequate objects to allow full control, so often, the critical actions you hoped to automate are only possible through the GUI. In the 90s, an integrated Tcl interpreter was a good sign that your vendor cared about developers. Today it's more a sign of neglect.

IshKebab 8mo ago

> best thing about TCL is easy syntax and that everything is a string :) What? That's the worst thing about TCL.

iberator 8mo 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.
- IshKebab 8mo 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.
  - bmacho 8mo 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.
    - IshKebab 8mo ago
      No they aren't. Everything is a string. The runtime does some optimisation where it actually does use different types under the hood but they don't change the semantics. If you try to pass a list into a function expecting a string it will just treat the list as a string. No type error or anything, not even at runtime. CMake is the same. Terrible design. Real types are useful.
      - deleted 8mo ago
        [deleted]
  - ux266478 8mo 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.
  - isr 8mo ago
    Well, if you use flightaware to track flights, you're using tcl. The vast majority of their codebase is in tcl.
  - zwischenzug 8mo ago
    If you place a sports bet online, odds (!) are that it will run through tcl in its business logic. I may even have written some of it.
bmacho 8mo 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.
- IshKebab 8mo ago
  I'm aware. It's awful because of the implications for the programmer, not the runtime.
antirez 8mo 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.
- petcat 8mo 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.
  - graemep 8mo 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 https://www.tcl-lang.org/man/tcl8.4/TclCmd/string.htm I have seen terrible code in Python, C, and more.
    - Treblemaker 8mo ago
      The objections to tcl I see most often seem to reflect an outdated or incomplete understanding of the language and its capabilities. As with many interpreted languages, maybe it's just too easy to iterate interactively with code until it "just works", rather than taking the time to design the code before writing it, leading to perception that it is a "write-only" language. However, despite its reputation, even Perl can be written in a way that is human-readable. I agree with you that it is more a reflection of the programmer or the work environment than of the language itself.
  - Treblemaker 8mo ago
    > When "everything is a string" then you have no choice but to literally treat everything as a string. As someone who has been developing tcl almost daily for more than 30 years, both object oriented and imperative code, I have not found it necessary to think this way. Can you explain what leads you to this conclusion?

Pay08 8mo ago

That's certainly a take...

tonyedgecombe 8mo ago

I agree, so much for the benevolent dictator idea.

robinsonb5 8mo 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.

pjmlp 8mo 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/Changes8.0.html 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.

apgwoz 8mo ago
There have always been attempts at caching non-string values in Tcl for performance gains, but the semantics are the same. The value’s types are whatever the operator requires and an error when not compatible. If, internally, $x is an integer, and you pass it to a string function, well, $x gets temporarily turned into a string. Dynamic with “weak” types.
- pjmlp 8mo ago
  Which is exactly the quoted text.
  - apgwoz 8mo ago
    No. The quoted text says nothing about the value semantics, only the representation…
    - pjmlp 8mo ago
      Well, if you followed the link under the quoted text, you would get the next sentence, > The new objects make it possible to store information in efficient internal forms and avoid the constant translations to and from strings that occurred with the old interpreter.

tverbeure 8mo ago

The worst thing about tcl is that it exists... and it's still the language of choice for EDA tools.

xantronix 8mo ago
I'd be curious to know what your experiences with Tcl have been, to better understand why you feel this way.
- elevation 8mo ago
  It's a combination of cumbersome syntax and the vendor's poor API design and execution environment. For a syntax example, compare python to Tcl. In python, there's a compact array lookup operator, and dictionaries allow string keys: mydata["channel"][2] Tcl, however, requires a function call to access an array index, resulting in nested function calls with magic numbers for the simplest expressions: lindex [lindex $mydata 35] 2 # Tcl Then there isn't any static type checking so you have to run code to see if it would work; the shape of a return may surprise you. Connecting to hardware may be your only opportunity to exercise certain code paths. So for any non trivial task, Tcl becomes effectively write-only. Some tools allow you to export Tcl scripts that automate tasks like project creation to help you avoid tracking intermediate objects in source control, but because the Tcl cwd path can change throughout a script, they export every source path as a hard coded absolute path, including whatever developer's home directory it might be residing in. This is not suitable for source control (because it would preclude building on any other machine) so then you have to post process these scripts before tracking them. But since it's Tcl there aren't good scriptable tools for programmatic Tcl AST manipulation, so you have to modify these files with some sort of a state machine, looking for various sentinels to trigger the various string replace behaviors you need. It's not all Tcl's fault, but if a vendor is only using Tcl for automation and you need automation, you have a battle ahead of you. Outside the language, you'll often find that your runtime tool locks the UI thread to run your scripts, so long running operations are impossible to pause or cancel. And I've never seen a vendor expose adequate objects to allow full control, so often, the critical actions you hoped to automate are only possible through the GUI. In the 90s, an integrated Tcl interpreter was a good sign that your vendor cared about developers. Today it's more a sign of neglect.