3 ms·

This is so misleading that i don't know where to start. Don't get me wrong, i wish more people would take a look at Tcl, because it has clever tricks. But this

This is so misleading that i don't know where to start. Don't get me wrong, i wish more people would take a look at Tcl, because it has clever tricks. But this page is puzzling: >But while in Lisp is usually needed to write macros, in Tcl you have to write normal procedures Well, in Lisp, macros are written... basically in the same way as normal procedures/functions. The difference is minimal: Use the quasiquote and comma operators (for something that can be described as "code templating"), and make sure to use "gensym" whenever you need to generate a symbol (and don't want it to collide with other existing symbols.) That's it. The rest is just as if writing a normal function. >Lisp has types, more or less like Python and Ruby. For example in order to use a number as argument of a string manipulation function, there is to convert from one type to the other. This is because Lisp is strongly typed, which is universally regarded today as a Good Thing. >strings as base type is usually more useful, because many thinks like HTML, XML, Networking Protocols, are about strings more than they are about lists. There are many things wrong here. In Lisp, if you need to deal with HTML or XML, instead of having to be losing time doing string operations, you just write HTML or XML directly in your code as s-expressions (take a look at most of the libraries for outputting HTML in Lisp). Thus, you do it the high-level way. >The Tcl world is less fragmented. There aren't a big number of implementations of Tcl I wonder if this is truly an advantage for Tcl. Common Lisp has a dozen implementations and your code will run unchanged in all of them, as long as you don't use implementation-dependent features (And for them, there are already many portable libraries, so those features are not implementation-dependent anymore.)

kazinator 9y ago
> I wonder if this is truly an advantage for Tcl. I wonder whether it's even true of Tcl. Tcl has had moving target semantics over its lifetime so in fact there are multiple implementations of Tcl. How well does the current Tcl emulate previous versions, so that code can run unmodified, and how far back does that go? Here is a Tcl page that lists some semantic changes from 7 to 8: ftp://ftp.tcl.tk/pub/tcl/doc/compiler.html Even though many of the changes are for the better, yikes!
- bch 9y ago
  Personally I found Lisp and scheme (I'm lumping them together for their similarities) confounding to get into. There are many, many different implementations, and it seemed to me you are adopting a culture and specific ecosystem more than anything. To my mind, it was difficult. Tcl seemed much less fragmented to me. There is one canonical implementation of Tcl, managed by the Tcl Core Team (TCT). There is (at least) one popular re-implementation (Jim Tcl), interestingly enough originally implemented by the author of the original article we're discussing here. Re: backward compatibility... I'd say Tcl is remarkably stable. A core tenet is "everything is a string" (EIAS), and logically, this has been honoured. Originally (before Tcl 8, or 8.4(?)) internal components of Tcl were literally strings. As in C "char " strings. It is (and has been) byte-coded for a long time now, and uses Tcl_Obj internals, with a string representation, and a high-performance "native" representation as well. It does still logically behave as if EIAS, though. That cited doc you mention doesn't actually seem to have a bearing in reality for some of its assertions, to my eyes. It would perhaps have "gotchas" for authors/users of scripts, but doesn't invalidate the EIAS core tenet. Additionally, that document was last edited 20 years ago. It's ancient, as is Tcl < 8.0.
  - flavio81 9y ago
    >found Lisp and scheme (I'm lumping them together for their similarities) (...) there are many, many different implementations You are lumping them together, as you mention, but they are very different precisely on this regard: Scheme has a lot of very different implementations but code portability is an issue, while Lisp (Common Lisp) has a dozen implementations but code written in CL will generally compile and run straight away in any of them, due to language standarization. Another lisp-like language to consider is Clojure, in its JVM implementation.
    - bch 9y ago
      Thanks. I was actually more attracted to scheme, then did become a bit confused, but maybe I should just head over to lisp and check harder to see what's what.

kazinator 9y ago

> I wonder if this is truly an advantage for Tcl. I wonder whether it's even true of Tcl. Tcl has had moving target semantics over its lifetime so in fact there are multiple implementations of Tcl. How well does the current Tcl emulate previous versions, so that code can run unmodified, and how far back does that go? Here is a Tcl page that lists some semantic changes from 7 to 8: ftp://ftp.tcl.tk/pub/tcl/doc/compiler.html Even though many of the changes are for the better, yikes!

bch 9y ago
Personally I found Lisp and scheme (I'm lumping them together for their similarities) confounding to get into. There are many, many different implementations, and it seemed to me you are adopting a culture and specific ecosystem more than anything. To my mind, it was difficult. Tcl seemed much less fragmented to me. There is one canonical implementation of Tcl, managed by the Tcl Core Team (TCT). There is (at least) one popular re-implementation (Jim Tcl), interestingly enough originally implemented by the author of the original article we're discussing here. Re: backward compatibility... I'd say Tcl is remarkably stable. A core tenet is "everything is a string" (EIAS), and logically, this has been honoured. Originally (before Tcl 8, or 8.4(?)) internal components of Tcl were literally strings. As in C "char " strings. It is (and has been) byte-coded for a long time now, and uses Tcl_Obj internals, with a string representation, and a high-performance "native" representation as well. It does still logically behave as if EIAS, though. That cited doc you mention doesn't actually seem to have a bearing in reality for some of its assertions, to my eyes. It would perhaps have "gotchas" for authors/users of scripts, but doesn't invalidate the EIAS core tenet. Additionally, that document was last edited 20 years ago. It's ancient, as is Tcl < 8.0.
- flavio81 9y ago
  >found Lisp and scheme (I'm lumping them together for their similarities) (...) there are many, many different implementations You are lumping them together, as you mention, but they are very different precisely on this regard: Scheme has a lot of very different implementations but code portability is an issue, while Lisp (Common Lisp) has a dozen implementations but code written in CL will generally compile and run straight away in any of them, due to language standarization. Another lisp-like language to consider is Clojure, in its JVM implementation.
  - bch 9y ago
    Thanks. I was actually more attracted to scheme, then did become a bit confused, but maybe I should just head over to lisp and check harder to see what's what.