6 ms·

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 2n

by davidw 9y 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 9y 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 9y 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 9y 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 9y ago
  Really, it flies compared to Ruby...
  - srean 9y 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 9y 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 9y 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 9y 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 9y 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.
      - gaius 9y ago
        Right - both Python and Tcl/Tk are intended to offload heavy processing to C functions that they stitch together with high level controls.
      - ptrott2017 9y ago
        As DavidW points out Out of the box Tcl (like most scripting languages) was never designed for numeric processing. If you want to do numerics and number crunching in Tcl use one of the extensions such as Vectcl or the Mathemtcl. Tcl's C APi makes writing extensions (or wrapping existing libs) pretty straight forward too.
    - blacksqr 9y ago
      Note that the toplevel link is to a page full of simple techniques for enhancing base Tcl with C, Fortran, Lua etc. code, suggesting that Tcl offers the shortest path from dynamic language to serious number crunching power when it is needed.
- vancan1ty 9y 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 9y 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 9y 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 9y ago
    Not when you are trying to build a server on top of it.
    - ridruejo 9y 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 9y ago
        AOLServer was the one we were measuring ourselves against, see other responses.
        blacksqr 9y ago
        You had a web server faster than AOLServer, and you went out of business. Hm.
        pjmlp 9y 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 9y 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 9y 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 9y 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 9y 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 9y ago
  > implemented a node.js like event loop Who’s event-loop is like who’s? ;)

by davidw 9y ago

aw3c2 9y 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 9y 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 9y 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 9y ago
Really, it flies compared to Ruby...
- srean 9y 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 9y 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 9y 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 9y 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 9y 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.
    - gaius 9y ago
      Right - both Python and Tcl/Tk are intended to offload heavy processing to C functions that they stitch together with high level controls.
    - ptrott2017 9y ago
      As DavidW points out Out of the box Tcl (like most scripting languages) was never designed for numeric processing. If you want to do numerics and number crunching in Tcl use one of the extensions such as Vectcl or the Mathemtcl. Tcl's C APi makes writing extensions (or wrapping existing libs) pretty straight forward too.
  - blacksqr 9y ago
    Note that the toplevel link is to a page full of simple techniques for enhancing base Tcl with C, Fortran, Lua etc. code, suggesting that Tcl offers the shortest path from dynamic language to serious number crunching power when it is needed.
vancan1ty 9y 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 9y 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 9y 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 9y ago
  Not when you are trying to build a server on top of it.
  - ridruejo 9y 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 9y ago
      AOLServer was the one we were measuring ourselves against, see other responses.
      - blacksqr 9y ago
        You had a web server faster than AOLServer, and you went out of business. Hm.
        pjmlp 9y 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 9y 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 9y 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 9y 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 9y 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 9y ago
> implemented a node.js like event loop Who’s event-loop is like who’s? ;)