3 ms·

> No types at all, everything is a string At least there's no need for any kind of toString() method... This is a design decision which makes the language sma

> No types at all, everything is a string At least there's no need for any kind of toString() method... This is a design decision which makes the language smaller and easily composable. It also helps greatly with metaprogramming, because the code itself is also just a string - this makes Tcl homoiconic, which is a nice property to have. Last but not least, you can easily type-tag the values you use in more than one way if you want; you also have a built-in object system for cases where you need more structure in order for things not to get hairy. > Dynamic scoping rules and `uplevel` & Co Tcl is lexically scoped by default, it just provides ways to break out from lexical context. It's a good thing, allowing you to write for example this: http://rosettacode.org/wiki/Generic_swap#Tcl http://rosettacode.org/wiki/Generic_swap#Tcl without any hassle. Like all design decisions it has its downsides, but it's a powerful tool if used correctly. Tcl is not a bad language, it's just ill-suited for you or for your use case.

tempodox 11y ago
That rosetta code has NO static scoping (neither has Tcl, you got that wrong). It uses dynamic scoping with `upvar`. It's a design decision all right, just a really bad one.
- klibertp 11y ago
  > That rosetta code has NO static scoping That was the point! I pasted it as an example of what you can do with upvar, by bypassing lexical scoping. Take a look at other entries on that page: almost all high-level languages either pack the two variables into a list of some kind (passed by reference) or have a specialized language construct for this (inout etc.) > neither has Tcl This is very easy to disprove, take a look. This code: proc g {} { echo $a } proc f {} { set a 10 g } f results in an error in Tcl: can't read "a": no such variable while executing "echo $a" (procedure "g" line 2) invoked from within "g" (procedure "f" line 3) invoked from within "f" (file "main.tcl" line 35) while in a dynamically scoped language, like Emacs Lisp, it would work: (defun g () (message "%s" a)) (defun f () (let ((a 10)) (g))) (f) How can you argue with that, I wonder? :) > just a really bad one. It (upvar and uplevel) lets you easily define new control structures (think "unless", "until", "await", things like these). I don't think you can convince me that adding a powerful feature to the language is a bad decision... but that's indeed a matter of preference and there are people who use Go, so I'm not going to argue about this :)

tempodox 11y ago

That rosetta code has NO static scoping (neither has Tcl, you got that wrong). It uses dynamic scoping with `upvar`. It's a design decision all right, just a really bad one.

klibertp 11y ago
> That rosetta code has NO static scoping That was the point! I pasted it as an example of what you can do with upvar, by bypassing lexical scoping. Take a look at other entries on that page: almost all high-level languages either pack the two variables into a list of some kind (passed by reference) or have a specialized language construct for this (inout etc.) > neither has Tcl This is very easy to disprove, take a look. This code: proc g {} { echo $a } proc f {} { set a 10 g } f results in an error in Tcl: can't read "a": no such variable while executing "echo $a" (procedure "g" line 2) invoked from within "g" (procedure "f" line 3) invoked from within "f" (file "main.tcl" line 35) while in a dynamically scoped language, like Emacs Lisp, it would work: (defun g () (message "%s" a)) (defun f () (let ((a 10)) (g))) (f) How can you argue with that, I wonder? :) > just a really bad one. It (upvar and uplevel) lets you easily define new control structures (think "unless", "until", "await", things like these). I don't think you can convince me that adding a powerful feature to the language is a bad decision... but that's indeed a matter of preference and there are people who use Go, so I'm not going to argue about this :)