9 ms·

Extending Tcl

120 points by blacksqr 8y ago

KasianFranks 8y ago
ANNOUNCE: Digital Trader - java/tcl/tk web agent (1997) https://groups.google.com/forum/#!msg/comp.lang.tcl/5-KIZWGYLMI/fU-ZAIF8ZYMJ https://groups.google.com/forum/#!msg/comp.lang.tcl/5-KIZWGY...
davidw 8y ago
Tcl's C API is very nice, and makes it easy to either integrate Tcl into a larger C app, or write bits and pieces of C as Tcl commands. I helped work on the 2nd edition of this book, which I think is still fairly relevant: https://amzn.to/2IB9OyR https://amzn.to/2IB9OyR
- aw3c2 8y ago
  Unobfuscated, direct URL: https://www.amazon.com/Tcl-Toolkit-2nd-John-Ousterhout/dp/032133633X/ https://www.amazon.com/Tcl-Toolkit-2nd-John-Ousterhout/dp/03...
- pjmlp 8y ago
  Writing Tcl extensions was one of the few times I actually enjoyed using C. It is probably one of the best languages to extend. Sadly it is also one of the slowest.
  - hedora 8y ago
    Years ago, I had to port a tcl/tk ui to java swing. I had source code to copy off of, but after two or three rewrites, the Java thing was still at least 100x slower than the tcl thing (granted, this was in the 1.1/1.2 days, but still...)
  - gaius 8y ago
    Really, it flies compared to Ruby...
    - srean 8y ago
      Is that right ? I have never used Ruby. I should have my expectations on running time in check in case I do try Ruby out -- I have been meaning to.
      - gaius 8y ago
        I don’t dislike Ruby - you can do some very clever things in very little code with it. But it is far from high-performance! Early Tcl was slow - but it was being compared to pure C. Recent Tcl is as snappy as any HLL.
        bch 8y ago
        Early (pre-8.0) Tcl was also literally string-processing the scripts. 8.0 brought a byte-compiler and the TclObj internal structure that maintained “native” values for types (I.e: a value “1.2” used as a floating-point value had its value cached as a float/double, versus reconstituting it from the string “1.2” every time it was needed. Note too this conversion happened nearly 20 years ago[0]. These days there’s some excitement surrounding the byte-compiling targeting LLVM[1], so faster still... [0] https://www.tcl.tk/software/tcltk/8.0.html https://www.tcl.tk/software/tcltk/8.0.html [1] https://wiki.tcl.tk/40985 https://wiki.tcl.tk/40985
    - petre 8y ago
      Not really. I did some prime number crunching and it's the slowest of them all. Maybe for simple scripts working with strings, but otherwise I'd pick Lua any day. LuaJIT just runs circles around other dynamic languages, only compiled stuff is able to beat it.
      - davidw 8y ago
        Tcl - or Ruby, Python without NumPy (which is an extension) or most scripting languages are not the right tool for the job for number crunching.
        8y ago
  - vancan1ty 8y ago
    I personally think that might depend on what you mean by "slow". Tcl/Tk programs can be very light and memory-efficient -- you can pack a lot of features into a program that only takes 10 megabytes or less at runtime and that starts up and responds to input near-instantly. The event loop abstraction which is well-integrated in Tcl makes it easy to handle sockets, files, timers, and gui events all on one loop which done right can keep your program very responsive without needing to worry about multithreading. In terms of pure runtime performance (CPU efficiency I guess), do you know of any reasonable benchmarks comparing TCL to say, Python and Ruby? I wonder if they might all be in the same ballpark?
    - pjmlp 8y ago
      We were a startup with our own webstack, similar to AOLServer. It was a great experience and we had quite a few in-house tooling that I only saw years later in Rails. Those issues lead us to become early .NET adopters as Microsoft was searching partners for getting their products ready to ship when .NET 1.0 would be announced to the world. Since then I only use scripting languages for shell scripting.
  - monetus 8y ago
    Isn't TCL almost as fast as C for certain things, like strings, but slow in other ways, like recursion? I haven't tried to do any performance optimizations yet really.
    - pjmlp 8y ago
      Not when you are trying to build a server on top of it.
      - ridruejo 8y ago
        It can be fairly fast for many use cases (specially because of async processing) and it was the basis one of the original scalable web servers that implemented multi-threading https://en.wikipedia.org/wiki/AOLserver https://en.wikipedia.org/wiki/AOLserver
        pjmlp 8y ago
        AOLServer was the one we were measuring ourselves against, see other responses.
        blacksqr 8y ago
        You had a web server faster than AOLServer, and you went out of business. Hm.
        pjmlp 8y ago
        We did not went out of business, I have not written that anywhere. In fact, the .NET re-rewrite was quite successful and many of the people involved on that team went on to create a very successful product based on the field lessons we had with the Tcl version.
      - blacksqr 8y ago
        Time to consider that your experience may be outdated. Wub, to take one example, is a pure-Tcl web server whose performance is comparable to Apache. Network latency in handling socket I/O swamps any differences in code execution speed.
- ridruejo 8y ago
  Yes, the C API is one of the main reasons it got the ACM award back 1997 https://en.wikipedia.org/wiki/ACM_Software_System_Award https://en.wikipedia.org/wiki/ACM_Software_System_Award
- neuland 8y ago
  How does Tcl's C API compare to Lua's? I've used that in a couple C projects and had a nice experience.
- Timothycquinn 8y ago
  I'm not a C programmer but I spent some time analysing major parts of C code for a SAP integration library that I maintained to get a better understanding of the SAP RFC interfaces. Never had an issue with the C code and TCL side of the integrations very easy to reason and maintain whilst covering massive amounts of integrations to SAP. More often then not, the problems I was involved with resolving on emergency escalation (line down) calls was on the SAP side of the world and never in the integration code in TCL and C. The biggest drawback with the TCL implementation from our application vendor was that they did not implement multi threading for TCL and instead implemented a node.js like event loop. As SAP calls were locking, this did cause locks for all other TCL calls.
  - bch 8y ago
    > implemented a node.js like event loop Who’s event-loop is like who’s? ;)
niftich 8y ago
Tcl is one of those rock-solid things that have been around for a while, where extrapolating from other projects of the same age you'd expect to find a somewhat muted community, and that's not the case at all. Dormancy and stagnation can have many causes: author hiatus, the code clearing some threshold feature-complete, obsolescence by competing tech that solves similar problems. And it seems Tcl has managed to stay relevant through a combination of usefulness (like its standard lib, or Tk) sufficient paradigm difference to tech that came later, in some cases future tech building on top of it instead of replacing it wholesale, willingness to fix common gripes in the core (numbers, unicode, binary), and a developer-focused (instead of consumer-focused) approach to packaging. It's probably helped by being a captive scripting language on some embedded platforms too. Languages that became big and popular in later years faced demands around the distribution of third-party packages. Perl became an early pioneer with a community repository, but later languages had to cope with the expectation of using a language-specific package manager that would download from the official repository, and automagically make packages available globally. Tcl encouraged user contributions in a less formal way [1] -- develop programs (code that uses builtin commands) or extensions (code that defines new commands) for your own use, and make them available if you so wish. This minor difference in attitude creates an ecosystem that feels different from a language package repo, where thousands of packages of varying quality sit, the long tail of them effectively unvetted. [1] http://wiki.tcl.tk/2352 http://wiki.tcl.tk/2352
- a_lieb 8y ago
  Obviously this more stable, slow-and-steady approach to the package ecosystem has its pros and cons, but the best fruit of it was SQLite, possibly the best library ever made. D. Richard Hipp describes it as "a Tcl extension that escaped into the wild." [1] [1] https://www.tcl.tk/community/tcl2017/assets/talk93/Paper.html https://www.tcl.tk/community/tcl2017/assets/talk93/Paper.htm...
- eridius 8y ago
  Does Tcl actually have any sort of package manager? I've started writing Tcl scripts again lately after a decade of not touching the language, and and I'm thankful that so far macOS has seemed to include every extension I wanted to use in the Tcl it ships with, but I'm waiting the day I hit a missing extension and have no idea how to install it.
srean 8y ago
A couple of ideas that Tcl pioneered were: (I) design for size, ease of extensibiliy and embedding, and (II) doing threads right. (I) became a feature offered by many other languages, but I think Tcl was the one that popularized it. This crown belongs to Lua now. (II) was not adopted as much as it should have been. I am looking at you Python. Interpreter as a library with interpreter state fully contained in an object, no globals or statics -- simplifies threads immensely. Run different interpreters in different threads, no need for global lock, no need for serialization-deserialization to talk to other interpreters in the same address space.
- ridruejo 8y ago
  For some time John Ousterhout was part of Sun Labs and Sun invested quite a bit of resources in it and bridges between Tcl and Java. The original idea was that Java was going to be the universal systems language and Tcl the universal scripting language. That was scrapped at some point because the messaging was too complex and it ended up being "Java for everything". Arguably we would have been better off with Java + Tcl than we ended up with Java + Javascript. When that happened JO went to found Scriptics, but it never got the traction it should (not helped being branded as "parasites" by Stallman)
  - rwmj 8y ago
    In one of those "could have been" moments, back in c.1994 I wrote a simple web browser which used SafeTcl (a sandboxed Tcl) to render. I got a few things wrong in hindsight - there was no static markup at all, the whole page was rendered by Tcl although there was a simple Tcl function to render blocks of text and TeX-like markup in Tcl strings. Tcl is more pleasant than Javascript, but still has some horrible parts like poor support for structs, nothing really equivalent to a pointer, clumsy escaping, and (at the time) no support for dynamically linked extensions.
    - auxym 8y ago
      FWIW, recent releases of Tcl have built-in dicts (hash tables), which greatly improve over the old "associative arrays". What I missed the most when doing Tcl was support for first class functions / closures. JimTCL seems to adress many of the pain points, for example it adds closures garbage-collected OO. http://jim.tcl.tk/index.html/doc/www/www/index.html http://jim.tcl.tk/index.html/doc/www/www/index.html

120 points by blacksqr 8y ago

ANNOUNCE: Digital Trader - java/tcl/tk web agent (1997) https://groups.google.com/forum/#!msg/comp.lang.tcl/5-KIZWGYLMI/fU-ZAIF8ZYMJ https://groups.google.com/forum/#!msg/comp.lang.tcl/5-KIZWGY...

davidw 8y ago

Tcl's C API is very nice, and makes it easy to either integrate Tcl into a larger C app, or write bits and pieces of C as Tcl commands. I helped work on the 2nd edition of this book, which I think is still fairly relevant: https://amzn.to/2IB9OyR https://amzn.to/2IB9OyR

aw3c2 8y ago
Unobfuscated, direct URL: https://www.amazon.com/Tcl-Toolkit-2nd-John-Ousterhout/dp/032133633X/ https://www.amazon.com/Tcl-Toolkit-2nd-John-Ousterhout/dp/03...
pjmlp 8y ago
Writing Tcl extensions was one of the few times I actually enjoyed using C. It is probably one of the best languages to extend. Sadly it is also one of the slowest.
- hedora 8y ago
  Years ago, I had to port a tcl/tk ui to java swing. I had source code to copy off of, but after two or three rewrites, the Java thing was still at least 100x slower than the tcl thing (granted, this was in the 1.1/1.2 days, but still...)
- gaius 8y ago
  Really, it flies compared to Ruby...
  - srean 8y ago
    Is that right ? I have never used Ruby. I should have my expectations on running time in check in case I do try Ruby out -- I have been meaning to.
    - gaius 8y ago
      I don’t dislike Ruby - you can do some very clever things in very little code with it. But it is far from high-performance! Early Tcl was slow - but it was being compared to pure C. Recent Tcl is as snappy as any HLL.
      - bch 8y ago
        Early (pre-8.0) Tcl was also literally string-processing the scripts. 8.0 brought a byte-compiler and the TclObj internal structure that maintained “native” values for types (I.e: a value “1.2” used as a floating-point value had its value cached as a float/double, versus reconstituting it from the string “1.2” every time it was needed. Note too this conversion happened nearly 20 years ago[0]. These days there’s some excitement surrounding the byte-compiling targeting LLVM[1], so faster still... [0] https://www.tcl.tk/software/tcltk/8.0.html https://www.tcl.tk/software/tcltk/8.0.html [1] https://wiki.tcl.tk/40985 https://wiki.tcl.tk/40985
  - petre 8y ago
    Not really. I did some prime number crunching and it's the slowest of them all. Maybe for simple scripts working with strings, but otherwise I'd pick Lua any day. LuaJIT just runs circles around other dynamic languages, only compiled stuff is able to beat it.
    - davidw 8y ago
      Tcl - or Ruby, Python without NumPy (which is an extension) or most scripting languages are not the right tool for the job for number crunching.
      - 8y ago
- vancan1ty 8y ago
  I personally think that might depend on what you mean by "slow". Tcl/Tk programs can be very light and memory-efficient -- you can pack a lot of features into a program that only takes 10 megabytes or less at runtime and that starts up and responds to input near-instantly. The event loop abstraction which is well-integrated in Tcl makes it easy to handle sockets, files, timers, and gui events all on one loop which done right can keep your program very responsive without needing to worry about multithreading. In terms of pure runtime performance (CPU efficiency I guess), do you know of any reasonable benchmarks comparing TCL to say, Python and Ruby? I wonder if they might all be in the same ballpark?
  - pjmlp 8y ago
    We were a startup with our own webstack, similar to AOLServer. It was a great experience and we had quite a few in-house tooling that I only saw years later in Rails. Those issues lead us to become early .NET adopters as Microsoft was searching partners for getting their products ready to ship when .NET 1.0 would be announced to the world. Since then I only use scripting languages for shell scripting.
- monetus 8y ago
  Isn't TCL almost as fast as C for certain things, like strings, but slow in other ways, like recursion? I haven't tried to do any performance optimizations yet really.
  - pjmlp 8y ago
    Not when you are trying to build a server on top of it.
    - ridruejo 8y ago
      It can be fairly fast for many use cases (specially because of async processing) and it was the basis one of the original scalable web servers that implemented multi-threading https://en.wikipedia.org/wiki/AOLserver https://en.wikipedia.org/wiki/AOLserver
      - pjmlp 8y ago
        AOLServer was the one we were measuring ourselves against, see other responses.
        blacksqr 8y ago
        You had a web server faster than AOLServer, and you went out of business. Hm.
        pjmlp 8y ago
        We did not went out of business, I have not written that anywhere. In fact, the .NET re-rewrite was quite successful and many of the people involved on that team went on to create a very successful product based on the field lessons we had with the Tcl version.
    - blacksqr 8y ago
      Time to consider that your experience may be outdated. Wub, to take one example, is a pure-Tcl web server whose performance is comparable to Apache. Network latency in handling socket I/O swamps any differences in code execution speed.
ridruejo 8y ago
Yes, the C API is one of the main reasons it got the ACM award back 1997 https://en.wikipedia.org/wiki/ACM_Software_System_Award https://en.wikipedia.org/wiki/ACM_Software_System_Award
neuland 8y ago
How does Tcl's C API compare to Lua's? I've used that in a couple C projects and had a nice experience.
Timothycquinn 8y ago
I'm not a C programmer but I spent some time analysing major parts of C code for a SAP integration library that I maintained to get a better understanding of the SAP RFC interfaces. Never had an issue with the C code and TCL side of the integrations very easy to reason and maintain whilst covering massive amounts of integrations to SAP. More often then not, the problems I was involved with resolving on emergency escalation (line down) calls was on the SAP side of the world and never in the integration code in TCL and C. The biggest drawback with the TCL implementation from our application vendor was that they did not implement multi threading for TCL and instead implemented a node.js like event loop. As SAP calls were locking, this did cause locks for all other TCL calls.
- bch 8y ago
  > implemented a node.js like event loop Who’s event-loop is like who’s? ;)

niftich 8y ago

Tcl is one of those rock-solid things that have been around for a while, where extrapolating from other projects of the same age you'd expect to find a somewhat muted community, and that's not the case at all. Dormancy and stagnation can have many causes: author hiatus, the code clearing some threshold feature-complete, obsolescence by competing tech that solves similar problems. And it seems Tcl has managed to stay relevant through a combination of usefulness (like its standard lib, or Tk) sufficient paradigm difference to tech that came later, in some cases future tech building on top of it instead of replacing it wholesale, willingness to fix common gripes in the core (numbers, unicode, binary), and a developer-focused (instead of consumer-focused) approach to packaging. It's probably helped by being a captive scripting language on some embedded platforms too. Languages that became big and popular in later years faced demands around the distribution of third-party packages. Perl became an early pioneer with a community repository, but later languages had to cope with the expectation of using a language-specific package manager that would download from the official repository, and automagically make packages available globally. Tcl encouraged user contributions in a less formal way [1] -- develop programs (code that uses builtin commands) or extensions (code that defines new commands) for your own use, and make them available if you so wish. This minor difference in attitude creates an ecosystem that feels different from a language package repo, where thousands of packages of varying quality sit, the long tail of them effectively unvetted. [1] http://wiki.tcl.tk/2352 http://wiki.tcl.tk/2352

a_lieb 8y ago
Obviously this more stable, slow-and-steady approach to the package ecosystem has its pros and cons, but the best fruit of it was SQLite, possibly the best library ever made. D. Richard Hipp describes it as "a Tcl extension that escaped into the wild." [1] [1] https://www.tcl.tk/community/tcl2017/assets/talk93/Paper.html https://www.tcl.tk/community/tcl2017/assets/talk93/Paper.htm...
eridius 8y ago
Does Tcl actually have any sort of package manager? I've started writing Tcl scripts again lately after a decade of not touching the language, and and I'm thankful that so far macOS has seemed to include every extension I wanted to use in the Tcl it ships with, but I'm waiting the day I hit a missing extension and have no idea how to install it.

srean 8y ago

A couple of ideas that Tcl pioneered were: (I) design for size, ease of extensibiliy and embedding, and (II) doing threads right. (I) became a feature offered by many other languages, but I think Tcl was the one that popularized it. This crown belongs to Lua now. (II) was not adopted as much as it should have been. I am looking at you Python. Interpreter as a library with interpreter state fully contained in an object, no globals or statics -- simplifies threads immensely. Run different interpreters in different threads, no need for global lock, no need for serialization-deserialization to talk to other interpreters in the same address space.

ridruejo 8y ago
For some time John Ousterhout was part of Sun Labs and Sun invested quite a bit of resources in it and bridges between Tcl and Java. The original idea was that Java was going to be the universal systems language and Tcl the universal scripting language. That was scrapped at some point because the messaging was too complex and it ended up being "Java for everything". Arguably we would have been better off with Java + Tcl than we ended up with Java + Javascript. When that happened JO went to found Scriptics, but it never got the traction it should (not helped being branded as "parasites" by Stallman)
- rwmj 8y ago
  In one of those "could have been" moments, back in c.1994 I wrote a simple web browser which used SafeTcl (a sandboxed Tcl) to render. I got a few things wrong in hindsight - there was no static markup at all, the whole page was rendered by Tcl although there was a simple Tcl function to render blocks of text and TeX-like markup in Tcl strings. Tcl is more pleasant than Javascript, but still has some horrible parts like poor support for structs, nothing really equivalent to a pointer, clumsy escaping, and (at the time) no support for dynamically linked extensions.
  - auxym 8y ago
    FWIW, recent releases of Tcl have built-in dicts (hash tables), which greatly improve over the old "associative arrays". What I missed the most when doing Tcl was support for first class functions / closures. JimTCL seems to adress many of the pain points, for example it adds closures garbage-collected OO. http://jim.tcl.tk/index.html/doc/www/www/index.html http://jim.tcl.tk/index.html/doc/www/www/index.html