Live data from Hacker News

Tcl the Misunderstood (2006)

antirez.com

11–20 of 81 posts

Re: Tcl the Misunderstood (2006)

#11
post #4
post #2

> Every string is internally encoded in utf-8, all the string operations are Unicode-safe This seems very slightly disingenuous, if my memory is correct. I don't remember all the details, but I ran into an issue with a Tcl application a while back and Unicode support. Digging into it, I recall that the Tcl interpreter actually represents every character as a predefined number of bytes, set by a preprocessor definitio…

> Digging into it, I recall that the Tcl interpreter actually represents every character as a predefined number of bytes, set by a preprocessor definition. Ah, that’s exactly what old python did. Wonder of it was inspired by the tcl solution. Fwiw because they rejected indexing recent cpython uses a variable encoding based on contents (possibilities are iso-8859-1, ucs2, or ucs4). That does mean adding an astral code…

That's pretty much what every older language did.

I assume its because the original unicode only supported 2 byte characters, and even after astral characters became a thing it took a while for them to be used for non-cjk things.

Re: Tcl the Misunderstood (2006)

#12
My favourite thing about Tcl is (was? This was 25 years ago) that adding commands just requires a couple of Tcl things, then an argc/argv, so it was relatively simple to turn an existing C program into a Tcl command:

     int my_command (ClientData clientData, Tcl_Interp *interp, int argc, const char *argv[]) { ... } 
However, that might have been the only thing I liked about Tcl. For some binary data import tasks I ended up writing a Perl program that translated it into Tcl.

Re: Tcl the Misunderstood (2006)

#13
post #11
post #4

Earlier quoted context omitted.

> Digging into it, I recall that the Tcl interpreter actually represents every character as a predefined number of bytes, set by a preprocessor definition. Ah, that’s exactly what old python did. Wonder of it was inspired by the tcl solution. Fwiw because they rejected indexing recent cpython uses a variable encoding based on contents (possibilities are iso-8859-1, ucs2, or ucs4). That does mean adding an astral code…

That's pretty much what every older language did. I assume its because the original unicode only supported 2 byte characters, and even after astral characters became a thing it took a while for them to be used for non-cjk things.

> That's pretty much what every older language did.

The fixed size, but I’m referring to the compile-time width switch.

I may be wrong but I was under the impression most older langages simply remained on their original character width (or left the issue ill defined and/or added an ancillary type like C).

Re: Tcl the Misunderstood (2006)

#14
post #7

The idea that Tcl was a toy came from the 90s and the Tcl Wars Stallman was involved with. But to Stallman, anything other than Lisp is pretty much a toy. Tcl is indeed a deep, deep rabbithole -- again, deeper than our dimension allows and lined with toothed cilia... but I can totally see where a person might look in Tcl's deadlights and want to be there.

Ironically Tcl is very Lisp-like in certain respects, though also quite different. Rabbitholes notwithstanding Tcl can be enormously useful and productive. In particular I think the built-in Tcl object-oriented features are a real asset and not nearly the same sort of rabbithole as you encountered in the past.

Re: Tcl the Misunderstood (2006)

#16
I remember bumping into Tcl as part of Tcl/Tk, during my xwindows days. Never realised there was still so much work ongoing for the language!

Reminds me of Forth too... do people still make firmware with Forth?

Re: Tcl the Misunderstood (2006)

#18
post #14
post #7

The idea that Tcl was a toy came from the 90s and the Tcl Wars Stallman was involved with. But to Stallman, anything other than Lisp is pretty much a toy. Tcl is indeed a deep, deep rabbithole -- again, deeper than our dimension allows and lined with toothed cilia... but I can totally see where a person might look in Tcl's deadlights and want to be there.

Ironically Tcl is very Lisp-like in certain respects, though also quite different. Rabbitholes notwithstanding Tcl can be enormously useful and productive. In particular I think the built-in Tcl object-oriented features are a real asset and not nearly the same sort of rabbithole as you encountered in the past.

It does have very flexible metaprogramming capability and the syntax of the language can be extended in the language itself, very much like Lisp, and like Lisp it has a high skill ceiling and a huge possibility space to explore.

It's the ways in which it is not like Lisp, the features that Lisp hackers discovered decades ago were nests of bugs and confusion that... arghhh.

My overall impression of Tcl, however, is quite positive -- and Tcl/Tk is a JATO bottle for rapid GUI development that no Lisp implementation has yet been able to match -- not without embedding or incorporating Tcl itself (e.g., PS/Tk: https://wiki.tcl-lang.org/page/PS%2FTk).

Re: Tcl the Misunderstood (2006)

#20
post #6

Quoted post unavailable.

HN gets numerous articles submitted multiple times, as people discover them for the first time. It's frowned upon to repost too frequently but this was last posted to HN on Oct 28, 2019 so I see no problem with it.
Post reply on HN