6 ms·

TCL is... semantically, amazing. It is syntactically hideous. As much as we like to claim that we're technical people and form over function blah blah blah...

TCL is... semantically, amazing. It is syntactically hideous. As much as we like to claim that we're technical people and form over function blah blah blah... aesthetics and readability matter.

virtue3 6y ago
one of my professors described TCL as "what a bunch of grad students made for a programming language". Always got a chuckle out of me.
- the_hoser 6y ago
  Pretty close. It was a professor that was tired of people writing languages to embed in their applications, so he wrote a language to embed in applications. Very much an XKCD 927 story.
  - bch 6y ago
    The guy who also brought us raft[0], log structured file systems[1], and Ousterhouts Dichotomy[2], among other things, in case you were thinking “not a bunch of grad students, but ‘some professor’.” [0] https://en.wikipedia.org/wiki/Raft_(computer_science) https://en.wikipedia.org/wiki/Raft_(computer_science) [1] https://en.wikipedia.org/wiki/Log-structured_file_system https://en.wikipedia.org/wiki/Log-structured_file_system [2] https://en.wikipedia.org/wiki/Ousterhout's_dichotomy https://en.wikipedia.org/wiki/Ousterhout's_dichotomy
    - the_hoser 6y ago
      I figured that details like that didn't matter in the context of the joke. He was a smart and productive person that designed an ugly programming language.
petre 6y ago
It's also quite slow.
- bch 6y ago
  That means nothing in isolation. Fill us in.
  - petre 6y ago
    In Tcl everything is a string. If you work with numbers for instance it's quite slow. Or maybe loop or set operations are slow. Dunno. Compare these two: Lua https://p.thorsen.pm/5ecb8ce026ab Tcl https://p.thorsen.pm/ee8a792acd52 Results: Lua 5.2: 0m0,027s LuaJIT 2.1: 0m0,016s Tcl 8.6: 0m0,630s I'd pick Lua over Tcl any day.
    - bch 6y ago
      Thanks for the exercise - I got an order of magnitude improvement on Tcl just by bracing the expressions: Bad: expr $i +$j + 2 Good: expr {$i + $j + 2} ... it saves interpretation and evaluation to occurring once, hoisted in the [expr] engine; it’s idiomatic. The lua version still appeared faster, though I’ve only spent 2 minutes looking at this. Again, strings should play no issue here; values must be able to generate a string-representation, but it’s computed lazily, and in this case, the $i, $j, etc in Tcl are working with native integers. I’m happy we have things like Tcl and Lua; either one of them makes development enjoyable. I appreciate you taking time to write your code samples.
int_19h 6y ago
The bigger problem is that "everything is a string" semantics hinders garbage collection. Ever noticed how all OO libraries for Tcl require explicit disposal of objects?
- bch 6y ago
  I don’t use Tcl OO these days (used to use [incr tcl], quite a while ago), but don’t know how EIAS (everything is a string) affects this. It’s more accurately described as “everything has a string-representation”... but that’s the same for an int, a list, a float... and they don’t need special destruction, and Tcl doesn’t leak because of that.
  - int_19h 6y ago
    They don't need destruction because they're all value types, and assignments are copies. But for OO, you need some form of references. And if your reference is a string, how do you know that it is a reference? Worse yet, if it's a part of a larger string, how do you know that said string contains a reference? Keep in mind that while, yes, Tcl lists have a more efficient internal representation when Tcl knows that it's a list, a string that happens to be a valid representation of a list is also a list, just by virtue of existing - but it won't get a special list representation until you try to use it like one! It's just a string like "foo bar baz". Or, say, "objref#1 objref#2 objref#3". And the semantics of the language is EIAS through and through - all those internal representations are optimizations that are not supposed to change the observed behavior, only performance. A GC cannot treat lists without internal representation differently from those with it without breaking this. So it has to assume that any string is potentially a list that contains object references. So a proper Tcl GC would have to be incredibly pessimistic about what it considers to be roots of the object graph - basically, any substring that looks like an object reference, has to be considered as one. Now imagine just how much string scanning such a GC would have to do in a non-trivial app for a single sweep!
    - bch 6y ago
      I’ll have to dig in and study a bit - I don’t know how [the object system] works off the top of my head. It sounds like you’re familiar with Tcl internals, so I presume you know that (if we stick w the list as a prototypical “complex” structure) that the management is reference counts, freed when count==0, and may be >1 if this is a shared item (I’m going to refrain from calling it an object, though internally they’re a Tcl_Obj type, which has nothing to do with OO-programming). In a list, the list is an item, and ea. element is an item, with (of course) incr/decr references at when appropriate, as determined by the language rules itself. Wrt strings vs lists, a string could be considered a single “blob”, but coercion to a proper list (“shimmering” in Tcl parlance) does the tokenization with requisite ref. counting as part of the conversion. ...I think the above may be entertainment more for anybody else who’s following along, but if that illuminating for you too, that’s a bonus. Perhaps you could show me by example: What’s a piece of (eg) Ruby and what you think a Tcl workalike would appear as, and where that falls down.
_ph_ 6y ago
I quite like TCL, but had my issues with the syntax as well, unless I read about how it works in the TCL book by Ousterhout (highly recommended). The key bing, that the syntax is extremely simple and systematic - a little bit like Lisp s-expressions - which allows for a very simple general parser and also makes it possible to write TCL extensions in pure TCL. This is a very Lisp-like trait of TCL.
- the_hoser 6y ago
  All of this is true, but it doesn't matter. Most programmers are put off by s-expressions, too. Aesthetics matter.
  - _ph_ 6y ago
    It does matter. Aesthetics do matter, but for a programming language, technical capabilites matter much more. The regular syntaxes of Lisp and TCL give it many powers not being present in languages with more "fancy" syntaxes.
    - the_hoser 6y ago
      I'd like to live in a world where that is true, but we just don't. Languages only need to be powerful enough to solve the problems actually being solved by 9 to 5 programmers. Aesthetics and ergonomics matter much more.
    - bch 6y ago
      _ph_, on this case I think it’s fair to say the aesthetic and ergonomics are the technical capability, to degrees. For example, building a custom looping control does benefit aesthetics and ergonomics. It could be viewed as 2 sides of the same coin.

TCL is... semantically, amazing. It is syntactically hideous. As much as we like to claim that we're technical people and form over function blah blah blah... aesthetics and readability matter.

virtue3 6y ago

one of my professors described TCL as "what a bunch of grad students made for a programming language". Always got a chuckle out of me.

the_hoser 6y ago
Pretty close. It was a professor that was tired of people writing languages to embed in their applications, so he wrote a language to embed in applications. Very much an XKCD 927 story.
- bch 6y ago
  The guy who also brought us raft[0], log structured file systems[1], and Ousterhouts Dichotomy[2], among other things, in case you were thinking “not a bunch of grad students, but ‘some professor’.” [0] https://en.wikipedia.org/wiki/Raft_(computer_science) https://en.wikipedia.org/wiki/Raft_(computer_science) [1] https://en.wikipedia.org/wiki/Log-structured_file_system https://en.wikipedia.org/wiki/Log-structured_file_system [2] https://en.wikipedia.org/wiki/Ousterhout's_dichotomy https://en.wikipedia.org/wiki/Ousterhout's_dichotomy
  - the_hoser 6y ago
    I figured that details like that didn't matter in the context of the joke. He was a smart and productive person that designed an ugly programming language.

petre 6y ago

It's also quite slow.

bch 6y ago
That means nothing in isolation. Fill us in.
- petre 6y ago
  In Tcl everything is a string. If you work with numbers for instance it's quite slow. Or maybe loop or set operations are slow. Dunno. Compare these two: Lua https://p.thorsen.pm/5ecb8ce026ab Tcl https://p.thorsen.pm/ee8a792acd52 Results: Lua 5.2: 0m0,027s LuaJIT 2.1: 0m0,016s Tcl 8.6: 0m0,630s I'd pick Lua over Tcl any day.
  - bch 6y ago
    Thanks for the exercise - I got an order of magnitude improvement on Tcl just by bracing the expressions: Bad: expr $i +$j + 2 Good: expr {$i + $j + 2} ... it saves interpretation and evaluation to occurring once, hoisted in the [expr] engine; it’s idiomatic. The lua version still appeared faster, though I’ve only spent 2 minutes looking at this. Again, strings should play no issue here; values must be able to generate a string-representation, but it’s computed lazily, and in this case, the $i, $j, etc in Tcl are working with native integers. I’m happy we have things like Tcl and Lua; either one of them makes development enjoyable. I appreciate you taking time to write your code samples.

int_19h 6y ago

The bigger problem is that "everything is a string" semantics hinders garbage collection. Ever noticed how all OO libraries for Tcl require explicit disposal of objects?

bch 6y ago
I don’t use Tcl OO these days (used to use [incr tcl], quite a while ago), but don’t know how EIAS (everything is a string) affects this. It’s more accurately described as “everything has a string-representation”... but that’s the same for an int, a list, a float... and they don’t need special destruction, and Tcl doesn’t leak because of that.
- int_19h 6y ago
  They don't need destruction because they're all value types, and assignments are copies. But for OO, you need some form of references. And if your reference is a string, how do you know that it is a reference? Worse yet, if it's a part of a larger string, how do you know that said string contains a reference? Keep in mind that while, yes, Tcl lists have a more efficient internal representation when Tcl knows that it's a list, a string that happens to be a valid representation of a list is also a list, just by virtue of existing - but it won't get a special list representation until you try to use it like one! It's just a string like "foo bar baz". Or, say, "objref#1 objref#2 objref#3". And the semantics of the language is EIAS through and through - all those internal representations are optimizations that are not supposed to change the observed behavior, only performance. A GC cannot treat lists without internal representation differently from those with it without breaking this. So it has to assume that any string is potentially a list that contains object references. So a proper Tcl GC would have to be incredibly pessimistic about what it considers to be roots of the object graph - basically, any substring that looks like an object reference, has to be considered as one. Now imagine just how much string scanning such a GC would have to do in a non-trivial app for a single sweep!
  - bch 6y ago
    I’ll have to dig in and study a bit - I don’t know how [the object system] works off the top of my head. It sounds like you’re familiar with Tcl internals, so I presume you know that (if we stick w the list as a prototypical “complex” structure) that the management is reference counts, freed when count==0, and may be >1 if this is a shared item (I’m going to refrain from calling it an object, though internally they’re a Tcl_Obj type, which has nothing to do with OO-programming). In a list, the list is an item, and ea. element is an item, with (of course) incr/decr references at when appropriate, as determined by the language rules itself. Wrt strings vs lists, a string could be considered a single “blob”, but coercion to a proper list (“shimmering” in Tcl parlance) does the tokenization with requisite ref. counting as part of the conversion. ...I think the above may be entertainment more for anybody else who’s following along, but if that illuminating for you too, that’s a bonus. Perhaps you could show me by example: What’s a piece of (eg) Ruby and what you think a Tcl workalike would appear as, and where that falls down.

_ph_ 6y ago

I quite like TCL, but had my issues with the syntax as well, unless I read about how it works in the TCL book by Ousterhout (highly recommended). The key bing, that the syntax is extremely simple and systematic - a little bit like Lisp s-expressions - which allows for a very simple general parser and also makes it possible to write TCL extensions in pure TCL. This is a very Lisp-like trait of TCL.

the_hoser 6y ago
All of this is true, but it doesn't matter. Most programmers are put off by s-expressions, too. Aesthetics matter.
- _ph_ 6y ago
  It does matter. Aesthetics do matter, but for a programming language, technical capabilites matter much more. The regular syntaxes of Lisp and TCL give it many powers not being present in languages with more "fancy" syntaxes.
  - the_hoser 6y ago
    I'd like to live in a world where that is true, but we just don't. Languages only need to be powerful enough to solve the problems actually being solved by 9 to 5 programmers. Aesthetics and ergonomics matter much more.
  - bch 6y ago
    _ph_, on this case I think it’s fair to say the aesthetic and ergonomics are the technical capability, to degrees. For example, building a custom looping control does benefit aesthetics and ergonomics. It could be viewed as 2 sides of the same coin.