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

41–49 of 49 posts

Re: Tcl the misunderstood (2006)

#41

Post by nivertech »

Funny, that recently I was thinking how elegant and LISPy Tcl is.

I just finished building a CAD-like visualization utility in Tcl/Tk which using a complex Tcl-based internal DSL to define complex multilayer geometries.

Tk and it's Canvas widget are great for things like this.

Many years ago I also wrote an IDE for Image Processing algorithm development in Tcl/Tk, which also heavily used Canvas. I was able to build a complex GUI Imaging application literally in the wish shell, all while learning Tcl/Tk and [Incr Tcl] OOP system.

The trick was to bind key like F11 to reload source files and redraw GUI.

For the Image Processing stuff or anything else compute intensive - Tcl was very slow, so I either spawned external processes or used native implemented Tcl commands.

Tcl versions changed native command API, so many native extensions weren't ported to newer Tcl versions. I have some code that uses old 2001-based Tcl, because the native packages weren't ported.

I know that there is a package manager for Tcl, but I don't think it's widely used.

So, if you need to glue many different utilities with simple control logic and put some GUI above it - Tcl/Tk is great.

Re: Tcl the misunderstood (2006)

#42

Post by dolphenstein »

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.

Tcl might've been elegant but StoryServer most certainly wasn't. Http variables automatically injected into the code was a particularly fun security risk. Then they provided helpful (to hackers) error messages that could be googled. Still came up with a result all these years later! :-) http://www.google.com/#q=intitle%3A"StoryServer+Error"

Re: Tcl the misunderstood (2006)

#43

Post by na85 »

fuzzix wrote: post #40
mst wrote: post #34

Earlier quoted context omitted.

This article is from 2006. Perl's unicode support is excellent now. In 2006 5.10 wasn't out yet, and anything before 5.8.5 had all sorts of odd unicode bugs. Or: Tcl got there significantly before we did.

That is a fair point, but I'm not trying argue that Perl is somehow better. I am just using it as a reference point. I'm more suggesting the article may be overstating the ease-of-use / capabilities of Tcl. To be clear, I'm not arguing against using Tcl in favour of Perl or anything else. It's just that my experience with a language with great encoding support doesn't jive with what's claimed here.

Well I think that particular clause was written for C-style language users where the unicode support is definitely subpar.

Re: Tcl the misunderstood (2006)

#44

Post by na85 »

VMG wrote: post #35

I came away from this impressed, but still thinking that it is a "toy language" in the sense that it is too powerful. You sometimes do not want to have to worry what a line of code means, and TCL does not allow that. > The Tcl community developed a number of OOP systems, radical language modifications, macro systems, and many other interesting things, just writing Tcl programs Well there's your problem. It becomes im…

>You sometimes do not want to have to worry what a line of code means, and TCL does not allow that.

Comments in Tcl work perfectly fine.

Re: Tcl the misunderstood (2006)

#45

Post by rodgerd »

ewindisch wrote: post #8
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.

This is one the reasons I like parsing HTTP requests through TCL. Everything in HTTP is a string, there are no numerals. Typecasting arguments from query strings is the source of many ills. It isn't much of a problem with TCL since like HTTP, everything is a string. Everything else about web service backends in TCL is pretty sad and frustrating, though. Unless it's embedded, anyway.

Everything in TCL is a string. Until you treat it like a number. And it has a leading zero. Then it's octal.

(Understanding TCL lists are just delimited strings lets you do interesting things. Sometimes unintentionally.)

Re: Tcl the misunderstood (2006)

#46

Post by dded »

na85 wrote: post #44
VMG wrote: post #35

I came away from this impressed, but still thinking that it is a "toy language" in the sense that it is too powerful. You sometimes do not want to have to worry what a line of code means, and TCL does not allow that. > The Tcl community developed a number of OOP systems, radical language modifications, macro systems, and many other interesting things, just writing Tcl programs Well there's your problem. It becomes im…

>You sometimes do not want to have to worry what a line of code means, and TCL does not allow that. Comments in Tcl work perfectly fine.

> Comments in Tcl work perfectly fine

I agree with what you're saying, but allow me to go meta.

Comments in Tcl are a bit strange. This works:

  # say howdy
  puts hello
But this does not:

  puts hello   # say howdy
For the later, you have to insert a semicolon:

  puts hello;  # say howdy
I get bitten by this time and time again.

Re: Tcl the misunderstood (2006)

#47

Post by na85 »

dded wrote: post #46
na85 wrote: post #44

Earlier quoted context omitted.

>You sometimes do not want to have to worry what a line of code means, and TCL does not allow that. Comments in Tcl work perfectly fine.

> Comments in Tcl work perfectly fine I agree with what you're saying, but allow me to go meta. Comments in Tcl are a bit strange. This works: # say howdy puts hello But this does not: puts hello # say howdy For the later, you have to insert a semicolon: puts hello; # say howdy I get bitten by this time and time again.

Yeah I got bit by that too, once. But it makes sense. If everything is a command, then "#" must also be a command. Essentially like a NOOP.

Once I visualized it that way, I never got tripped up by that again.

And regardless of this fact, comments exist. They may not be as convenient as using // or // in C its friends, but they exist. To say that tcl does not allow one to know what a complicated line of code means is absurd.

Re: Tcl the misunderstood (2006)

#48

Post by dded »

na85 wrote: post #47
dded wrote: post #46

Earlier quoted context omitted.

> Comments in Tcl work perfectly fine I agree with what you're saying, but allow me to go meta. Comments in Tcl are a bit strange. This works: # say howdy puts hello But this does not: puts hello # say howdy For the later, you have to insert a semicolon: puts hello; # say howdy I get bitten by this time and time again.

Yeah I got bit by that too, once. But it makes sense. If everything is a command, then "#" must also be a command. Essentially like a NOOP. Once I visualized it that way, I never got tripped up by that again. And regardless of this fact, comments exist. They may not be as convenient as using // or / / in C its friends, but they exist. To say that tcl does not allow one to know what a complicated line of code means is…

> If everything is a command, then "#" must also be a command

In my mind, that's an argument that at least something shouldn't be a command. But perhaps it simplifies implementation enough to be worth it.

> To say that tcl does not allow one to know what a complicated line of code means is absurd.

Fully agree with you there. And for what it's worth, in the Tcl I encounter, there's rarely a line of code that complicated. Perl is often accused of being a write-only language. I think Tcl, if anything, is the opposite. It always seems readable.

Re: Tcl the misunderstood (2006)

#49

Post by dfox »

NigelTufnel wrote: post #18
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?

It's not possible to write CL's loop macro per-se (tcl does not have macros, but commands/functions which are executed each time and there isn't an distinct macroexpansion/compilation phase), but it's certainly possible to write something that essentially matches behavior and user interface of loop (and it's probably significantly easier to do than writing loop in CL).
Post reply on HN