Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The author missed one of the other huge advantages of Tcl: it is extremely easy to add Tcl to a C++ project as a scripting language. It took me about half an hour, and I had never done it before. Once added, it makes interactive debugging of big projects almost pleasant.


This is why I love Tcl too. As a general purpose language I'd rather use something else, but for projects where you want to make it easy to redefine certain behaviours without rebuilding and you don't want to implement your own DSL (and you shouldn't want that, trust me...) Tcl is right there waiting for you.

I find myself building projects where I implement system specific stuff in C with Tcl bindings and then use Tcl to tie the libraries together. It makes for modular software and easy testing, both unit testing through tcltest and testing stuff interactively in development.

It's not The Best Language(tm), but it really ties the room together.


> It's not The Best Language(tm), but it really ties the room together.

Haha, very well put. A lot of the time, I just want something that lets me tinker interactively with C/++ code (changing variables, calling methods, etc) to make sure it's doing what I want without having to recompile, dive into the debugger, or write a custom command interface. Plus, some things are just far less painful to write in Tcl--namely, anything to do with strings.


I've been pretty pleased with Tcl for this as well. Its syntax is convenient for interactive use and fine for actual coding in, without being faintly insane like many shells.

The main drawback to it I've found is its insistence on being able to convert everything from an object to a string and then back again. It's all too easy, when using certain functions (I think `lappend' is the one that caused me a lot of bother), to have your objects silently converted into strings. This is one piece of shell insanity that Tcl has kept. It's not a good one.

If your objects aren't really representable as strings - in my case, I'm storing a pointer to some C/C++ object in a TclObj, and relying on Tcl's refcounting to manage the lifetimes - this is what you'd do in something like Lua - then this can leave you a bit stuck. And even if you did support this, this could well leave you with two equivalent objects where you'd rather have one individual one. Tcl should take a leaf out of Lua's book, or Python's, on this matter.

A shame. It's not the only thing I didn't really love, but it was the only thing that really bothered me. I considered changing language, but the Tcl syntax is very convenient. So in the end I just worked around it by reimplementing a bunch of list primitives that didn't turn things into strings so damn often, and used those instead.


Agreed. List functions stringifying everything in sight is really inefficient and error-prone, and definitely one of the things that I dislike about Tcl.

For most purposes I've used it, the convenience of the language outweighs its problems, but I've thought about rewriting some of Tcl to fix the minor annoyances like these.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: