Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tcl the misunderstood (2006)

antirez.com

Post reply on HN
Print view View original

11–20 of 49 posts

Re: Tcl the misunderstood (2006)

#11

Post by binarymax »

fuzzix wrote: post #4

> i18n just happens No it doesn't... unless machine translation is "there" and built into Tcl. > Every string is internally encoded in utf-8, all the string operations are Unicode-safe, including the regular expression engine. Basically, in Tcl programs, encodings are not a problem - they just work Really? Perl's Unicode support is pretty much second-to-none, IME, but you still need to know the encoding of your file…

I don't understand the purpose of your comment. OK so perl is great. This article isn't about Perl...it's about the semi-obscure and commonly underestimated Tcl (which is also a great language).

Re: Tcl the misunderstood (2006)

#12

Post by j45 »

Tcl is certainly not a toy language. I was introduced to it when running an eggdrop bot in the irc days, and I suspect for many of us was one of the first more feature complete languages we had no choice but to learn because we wanted to add custom functionality to our bots.

I haven't kept up with it and enjoyed seeing there's still those who find it productive

Re: Tcl the misunderstood (2006)

#13

Post by gjm11 »

binarymax wrote: post #11
fuzzix wrote: post #4

> i18n just happens No it doesn't... unless machine translation is "there" and built into Tcl. > Every string is internally encoded in utf-8, all the string operations are Unicode-safe, including the regular expression engine. Basically, in Tcl programs, encodings are not a problem - they just work Really? Perl's Unicode support is pretty much second-to-none, IME, but you still need to know the encoding of your file…

I don't understand the purpose of your comment. OK so perl is great. This article isn't about Perl...it's about the semi-obscure and commonly underestimated Tcl (which is also a great language).

I don't think fuzzix was trying to divert the discussion onto Perl, but citing it as an example of a language generally agreed to do an excellent job of handling character encodings in which it still isn't true (as the article alleges for Tcl) that "encodings are not a problem - they just work".

The purpose of the comment seems clear enough to me: to point out two claims made by the article that seem implausibly optimistic:

1. That i18n "just happens", which as fuzzix says is surely impossible unless Tcl includes magical machine translation facilities.

2. That "encodings are not a problem - they just work", which would require Tcl to tell by some ingenious means what encoding is used by any given file -- something that Perl, despite being exactly the sort of language that doesn't mind the kind of heuristic complexity it would take to do this well, and being generally acknowledged to do a good job of handling Unicode, punts on).

Re: Tcl the misunderstood (2006)

#14

Post by fuzzix »

binarymax wrote: post #11
fuzzix wrote: post #4

> i18n just happens No it doesn't... unless machine translation is "there" and built into Tcl. > Every string is internally encoded in utf-8, all the string operations are Unicode-safe, including the regular expression engine. Basically, in Tcl programs, encodings are not a problem - they just work Really? Perl's Unicode support is pretty much second-to-none, IME, but you still need to know the encoding of your file…

I don't understand the purpose of your comment. OK so perl is great. This article isn't about Perl...it's about the semi-obscure and commonly underestimated Tcl (which is also a great language).

To state the problem explicitly, internal storage format of strings doesn't mean you can handle all data streams seamlessly. Internal consistency is fine, but ultimately your program will have I/O.

If I open an ISO-8859-15 or UCS-2 file in a Tcl program, how is this handled? Does it seamlessly detect encoding and translate to UTF-8 or is there more to this issue than what's stated in the article? Also, are the strings stored in a canonicalised form? If not, how simple is it to perform normalisation?

I brought up Perl because it's my experience of a language with excellent encoding support and helps make the point that the issue is probably more complex than just how strings are stored and manipulated internally.

Re: Tcl the misunderstood (2006)

#15

Post by gjm11 »

arnsholt wrote: post #6

An interesting corollary to concept 5 (the fact that everything in Tcl is a string) is that this means that Tcl is actually homoiconic. It does it completely differently from Lisp, but still ends up in the same place: code and data have the same representation.

You can represent arbitrary C++ code as a string, too, and C++ has a fairly decent string type. Does that make C++ homoiconic? I wouldn't say so, because the structure of the code is lost when you represent it as a string and because C++ doesn't give you any way of using the code represented thus (e.g., there's no standard way to compile it).

(The second of those isn't strictly part of what's meant by homoiconicity. You could, after all, write your own compiler, just as you might write a metacircular evaluator in Lisp. But it seems like an important part of the spirit of the thing.)

Tcl may be homoiconic -- it's been years since I looked at Tcl and I don't remember anywhere near enough details to try to pronounce on this -- but if so, it isn't merely because it represents everything as strings. It'll be to do with simple string operations being able to do all the parsing you need (on account of the syntax being simple and/or there being string operations that do things like parsing out a {...} block of code), and with there being a usable eval.

Re: Tcl the misunderstood (2006)

#16

Post by [deleted] »

fuzzix wrote: post #14
binarymax wrote: post #11

Earlier quoted context omitted.

I don't understand the purpose of your comment. OK so perl is great. This article isn't about Perl...it's about the semi-obscure and commonly underestimated Tcl (which is also a great language).

To state the problem explicitly, internal storage format of strings doesn't mean you can handle all data streams seamlessly. Internal consistency is fine, but ultimately your program will have I/O. If I open an ISO-8859-15 or UCS-2 file in a Tcl program, how is this handled? Does it seamlessly detect encoding and translate to UTF-8 or is there more to this issue than what's stated in the article? Also, are the string…

[deleted]

Re: Tcl the misunderstood (2006)

#17

Post by gaius »

aristus wrote: post #3

Back at the beginning of time I worked with Vignette StoryServer, which spun out of aolserver, one of the first "database-backed dynamic website" servers. The scripting language was TCL 7.something. I never encountered it again, but its elegance always stayed with me. Except for uplevel. Fucking evil.

It gives you the capability to extend the language itself, something you can't really do in most other languages. Tcl, Forth and Lisp are the only ones I can think of. These days you get "monkey patching" and so on, but it's nowhere near as nice.

Re: Tcl the misunderstood (2006)

#18

Post by NigelTufnel »

arnsholt wrote: post #6

An interesting corollary to concept 5 (the fact that everything in Tcl is a string) is that this means that Tcl is actually homoiconic. It does it completely differently from Lisp, but still ends up in the same place: code and data have the same representation.

Interesting. I've never worked with Tcl, is it possible to write Common Lisp loop macro in Tcl?

Re: Tcl the misunderstood (2006)

#19

Post by cantfindmypass »

j45 wrote: post #12

Tcl is certainly not a toy language. I was introduced to it when running an eggdrop bot in the irc days, and I suspect for many of us was one of the first more feature complete languages we had no choice but to learn because we wanted to add custom functionality to our bots. I haven't kept up with it and enjoyed seeing there's still those who find it productive

TiVo used to use it pretty heavily. I'm not sure if they still do.

Re: Tcl the misunderstood (2006)

#20

Post by [deleted] »

plg wrote: post #2

A really nice article to get one started! thx Another topic I would like to see introduced in a similarly friendly way is event loops. At my work I am dealing with some Tcl/Tk code that uses event loops and it's a bit of mental gymnastics to get my head around what gets executed when.

[deleted]
Post reply on HN