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 72 posts

Re: Tcl the Misunderstood (2006)

#11

Post by bsder »

The biggest problem with Tcl is the fact that C won.

This means that "" and {} are expected to work a certain way from C and when you hit Tcl you are HORRIBLY confused.

It's especially confusing as {} is simply quoting and has nothing to do with scope. The fact that Tcl is written such that {} is used with indentation in if-statements muddies the issue even further.

I suspect that a choice of ` (backtick) for Tcl " and " instead of Tcl {} would have made Tcl way less confusing to the vast majority of programmers.

I understand why things weren't done that way--having the ability to know that your quote has different characters for open vs close is very valuable for efficient parsing.

Nevertheless, the Tcl choices were unfortunate given the way history played out.

Re: Tcl the Misunderstood (2006)

#12

Post by foobarian »

Another excellent aspect of Tcl I found is extensibility of JO's C implementation. At some point I needed to write some native code for speed and making this visible to the Tcl interpreter was a pleasure. Plus the codebase is so clean and well written.

Re: Tcl the Misunderstood (2006)

#13

Post by WillAdams »

One thing which I've always not understood about Tcl/TK is why there isn't a standard graphical tool for laying out a GUI program.

For a long while, when I might have used Tcl/TK, I instead used Runtime Revolution/Livecode (a cross-platform HyperCard clone) which had a very nice system for interactively drawing programs.

I'd really like for there to be an agreed-upon standard option for graphical program development which was interactive and cross-platform.

Re: Tcl the Misunderstood (2006)

#14

Post by ufo »

lilyball wrote: post #2

I've long wished to have the free time to write a Tcl-derived language, because it really is so elegant in many ways, it just needs a bit of modernization in some areas. It's been years since I really thought much about this but I recall one of the things it's missing is closures (it does have lambdas at least). Reading through this article, the memoize implementation does have an issue which is if the memoized comma…

Closures are not easy to fit with "everything is a string", which favors dynamic scoping over lexical scope. I wonder what you'd change to make tcl more amenable to modernization.

Re: Tcl the Misunderstood (2006)

#15

Post by AceJohnny2 »

andrelaszlo wrote: post #9

A lot of the power of expect seems to come from the fact that it's (normally) configured/scripted in Tcl https://linux.die.net/man/1/expect I really like that it, like the article mentions, just looks like config for basic scripts but also scales to whatever you need it to do.

indeed, and other ports of Expect (Perl Pexpect, Python PyExpect) feel awkward as the constructs don't map quite as well to those languages.

Re: Tcl the Misunderstood (2006)

#17

Post by lilyball »

bsder wrote: post #11

The biggest problem with Tcl is the fact that C won. This means that "" and {} are expected to work a certain way from C and when you hit Tcl you are HORRIBLY confused. It's especially confusing as {} is simply quoting and has nothing to do with scope . The fact that Tcl is written such that {} is used with indentation in if-statements muddies the issue even further. I suspect that a choice of ` (backtick) for Tcl "…

In Tcl, "quoting" and "scope" are the same thing.

Re: Tcl the Misunderstood (2006)

#18

Post by mhalle »

bsder wrote: post #11

The biggest problem with Tcl is the fact that C won. This means that "" and {} are expected to work a certain way from C and when you hit Tcl you are HORRIBLY confused. It's especially confusing as {} is simply quoting and has nothing to do with scope . The fact that Tcl is written such that {} is used with indentation in if-statements muddies the issue even further. I suspect that a choice of ` (backtick) for Tcl "…

The use of {} for strings without substitutions and effectively for scope are actually interrelated, remarkably.

Scopes are special syntactic forms that delegate variable substitution to the associated procedures. For example, a "for" statement evaluates the body of the function after substituting the loop variable. In a string based language, that's basically the same as expressing the scope in a string form where the string content is passed verbatim as an argument without variable substitution or function invocation.

Having used Tcl extensively back in the day, I am not sure that this syntactic cleverness really was a major impediment to adoption. It was just something to learn. Same was true with [] meaning lisp-like function calling rather than array definition.

Baseline Tcl's biggest challenge, in my opinion, was providing mechanisms to write modular code for larger programs and data encapsulation. Core Tcl put off decisions about the appropriate mechanisms to do so by only providing "namespaces" as a building block for higher level third-party syntax. That led to fragmentation at a time when other languages were gaining popularity.

Re: Tcl the Misunderstood (2006)

#19

Post by lilyball »

generalizations wrote: post #6

The biggest weakness IMHO is the inability to comment out elements of an array. Even bash lets you do this and it makes testing and dev so much easier. Really wanted to love it, but that got in the way too many times.

By arrays you mean something like this?

  array set foo {
    a 1
    b 2
    c 3
  }
If the inability to comment out entries here is a problem, that's also something you can fix, you can write something like

  proc decomment body {
    …
  }
such that you can then write the following and it will remove commented lines:

  array set foo [decomment {
    a 1
    # b 2
    c 3
  }]

Re: Tcl the Misunderstood (2006)

#20

Post by davidw »

foobarian wrote: post #12

Another excellent aspect of Tcl I found is extensibility of JO's C implementation. At some point I needed to write some native code for speed and making this visible to the Tcl interpreter was a pleasure. Plus the codebase is so clean and well written.

Yes! Tcl's C code is a real pleasure to work with and extend.

I got to write some of the updates in this 2nd edition regarding the C interface:

https://www.oreilly.com/library/view/tcl-and-the/97803216017...

Post reply on HN