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

31–40 of 81 posts

Re: Tcl the Misunderstood (2006)

#31

Post by zelphirkalt »

thesz wrote: post #22

Tcl forces you to create new data, because you have to think and work harder to introduce effects on variables in upper scope through the use of uplevel and upvar. This reduces side effects significantly and makes data transformation explicit. Which, in turn, reduces cognitive load and increase productivity. Tcl also does not have distinguished NULL value like Python, C, C++, C# and many other languages. You do not h…

Does this non-existence of a no-value not only mean, that when there is no result value, another value (like false or empty string or empty list or whatever) will be used to express that fact, or that an exception is used? One would have to check for those in some cases as well. Those might not be always good alternatives reducing required checks. How does it work?

Re: Tcl the Misunderstood (2006)

#32

Post by IshKebab »

This is nonsense. I have had the misfortune of having to learn TCL (it's standard in the EDA world unfortunately) and it is most assuredly a toy language. That doesn't mean you can't write big complicated programs with it. You can do that with any language. But stuff like this is an outright lie:

> There are no types, and you don't need to perform conversions, however, you aren't likely to introduce bugs because the checks on the format of the strings are very strict.

You aren't likely to introduce bugs when literally every type is a string. Even lists. Lists are strings. Lists of strings are strings. Maps are strings.

It's pretty insane, and the interpreter does some horrible magic so that if you never access a list as a string it can store it internally as a real list (to avoid insanely bad performance) but to the programmer it's still a string and nothing prevents you from treating it as such.

I actually made a semi-funcitonal WASM-to-TCL transpiler to avoid having to write TCL. Worked kind of well! Unfortunately WASM is quite large and I lost interest before completing it.

Re: Tcl the Misunderstood (2006)

#33

Post by Dreami »

ufo wrote: post #27

The thing that I most appreciate about Tcl is that it feels like Unix shell "done right". It is still a bit weird because everything is a string, but it doesn't have all those footguns around variable expansion, such as word splitting. It also has decent support for subroutines and local variables, no weirdness with subshells and so on.

Has there been an attempt at doing a shell?

Re: Tcl the Misunderstood (2006)

#35

Post by siskiyou »

Dreami wrote: post #33
ufo wrote: post #27

The thing that I most appreciate about Tcl is that it feels like Unix shell "done right". It is still a bit weird because everything is a string, but it doesn't have all those footguns around variable expansion, such as word splitting. It also has decent support for subroutines and local variables, no weirdness with subshells and so on.

Has there been an attempt at doing a shell?

tclsh is included https://tcl.tk/man/tcl8.5/UserCmd/tclsh.htm

If you meant a login shell... https://wiki.tcl-lang.org/page/Is+tclsh+or+wish+suitable+as+...

Re: Tcl the Misunderstood (2006)

#36

Post by layer8 »

deepsun wrote: post #23

Watching someone learns basics of programming in Python, I realized that Python is actually not that easy to learn for beginners as I thought: 1. Types in Python are implicit. It's really hard to explain that they need to always think about what type something is, especially when they haven't grasped the concept of types yet. 2. Indentation as part of the language. I thought it's a great thing for beginners, but it's…

The traditional answer was to use a BASIC dialect. Minimal syntax, minimal structure, simple imperative commands. A lot simpler than Pascal. I don’t know TCL very well, but its scope semantics may be confusing. I’d take a look at LOGO also.

Re: Tcl the Misunderstood (2006)

#37

Post by mmargerum »

deepsun wrote: post #23

Watching someone learns basics of programming in Python, I realized that Python is actually not that easy to learn for beginners as I thought: 1. Types in Python are implicit. It's really hard to explain that they need to always think about what type something is, especially when they haven't grasped the concept of types yet. 2. Indentation as part of the language. I thought it's a great thing for beginners, but it's…

I think Go is the easiest language , outside of basic, that i've ever had to learn

Re: Tcl the Misunderstood (2006)

#38

Post by codeflo »

deepsun wrote: post #23

Watching someone learns basics of programming in Python, I realized that Python is actually not that easy to learn for beginners as I thought: 1. Types in Python are implicit. It's really hard to explain that they need to always think about what type something is, especially when they haven't grasped the concept of types yet. 2. Indentation as part of the language. I thought it's a great thing for beginners, but it's…

I've seen beginners, especially those without a very strong maths background, struggle with the concept of syntax. The idea that you need to put the thing you want the program to do into a very specific form. That any deviation is an error, even though "it's clear" to humans. I think that's something fundamental beginners need to learn, regardless of the language they use.

But once you accept that there are rules to follow, and that they are somewhat arbitrary, languages do differ wildly in the amount and obscurity of syntactic forms you need to learn just to get started. Just count the amount of different syntactic concepts in this simple program:

    #include 

    int main(int argc, char **argv) {
        printf("Hello world\n");
        return 0;
    }
and compare it to the Python version.

Re: Tcl the Misunderstood (2006)

#39

Post by pjmlp »

It might be powerful, and Lisp like, however in any large application eventually the amount of C code in extensions to make it perform, outgrows the TCL code.

And then one stars wondering if it isn't better to migrate to something else.

Re: Tcl the Misunderstood (2006)

#40

Post by pjmlp »

jrapdx3 wrote: post #10

I think it's worth pointing out that in the years since this article was written (2006) quite a few new features have been added to Tcl. A few of the more significant include coroutines, robust object-oriented system, tailcalls, apply (lambdas), namespace ensembles, et.al. Of course some of these features were already present in other languages. However, steady improvements to Tcl have pushed the language well beyond…

TCL already had a couple of well known packages for OOP before 2006, like [incr Tcl].
Post reply on HN