4 ms·

I see these Tcl posts from time to time here and I once had to work with a legacy code base build with that language and it wasn't good. Learning the language i

by myspy 3y ago

I see these Tcl posts from time to time here and I once had to work with a legacy code base build with that language and it wasn't good. Learning the language is not intuitive and the worst of it all is that I wasn't able to write any tests which would have helped to refactor that mess. If I recall it correctly there just wasn't a way to write tests because it's not supported.

arroz 3y ago
I mean, you can write tests in any language, you don’t need a framework
- jjoonathan 3y ago
  Yeah. You sometimes hear rules like "never write tests outside a framework," but this advice is aimed at the junior dev who doesn't want to learn the tooling, not at someone who is necrocoding in a 30 year dead language and needs to decide between loads of copy/paste and rolling their own testing framework (which would get used once, leading to amortization difficulty). Sometimes the constraints really do call for loads of copy/paste, and that's OK.
  - mkovach 3y ago
    DejaGnu has been around forever. https://git.savannah.gnu.org/cgit/dejagnu.git/tree/ https://git.savannah.gnu.org/cgit/dejagnu.git/tree/ I still use it for testing software. Add in expect and it is fairly simple to write tests against TCL applications (I do it all the time).
mschaef 3y ago
> Learning the language is not intuitive and the worst of it all is that I wasn't able to write any tests which would have helped to refactor that mess. Tcl is one of those languages that's centered heavily around a single dominant concept. In Tcl's case, the idea behind the language is that everything is a string and most of the computation is expressed through various forms of string substitution. The earliest versions of the language were actually implemented this way. Indexing into an array required the interpreter to parse through a string representation of the array looking for the element you requested. Interpretation of code worked the same way - it parsed your code as it went along. Later versions (>=8.0) added the notion of "dual-ported objects. These gave the interpreter the ability to cache more efficient representations of various kinds of object, while retaining its 'string gestalt' principle. The net of this is a language that's almost totally at odds with the way people think about coding, and yet has a great deal of deep expressive power that's easy to miss. (It's easily possible to do things in Tcl that might have otherwise been limited to something like a Lisp macro or some kind of preprocessing/code-gen technique.) This general approach can make the experience of using the language initially very difficult, since it's so unexpected and different from the usual previous experience. If it sticks, though, it can be a seductive sort of environment in which to work. Whether or not this is good or bad language design is a bit of an open question, but I'm glad languages like this exist. > If I recall it correctly there just wasn't a way to write tests because it's not supported. It's easy enough to write tests directly in C. There are plenty of ways to do tests in Tcl also. (Many of which are benefited by the string nature of the language I describe above.)
jollyllama 3y ago
Same. Imagine a distributed backend made mostly out of TCL. It was a nightmare.
- wduquette 3y ago
  TCL takes discipline, like any other language.
hedora 3y ago
I had the opposite experience. One of my first jobs was to port a legacy TCL GUI to Java Swing. Even though I understood exactly what the TCL was doing, the Java port was 20x more lines of code, and 100x slower. I spent a few months beating my head against the poorly designed padded cell that is the JVM, and then it was 40x longer, and 10x slower.
- CyberDildonics 3y ago
  That's more an indictment of java than an endorsement for TCL since you were dealing with something already working. I'm sure perl/tk, qt, fltk or many others would have been a much better experience.
wduquette 3y ago
Tcl has an excellent unit test suite, Tcltest, that's remarkably easy to use. It's been around a couple of decades. I've written more test cases using it than I could easily count.

by myspy 3y ago

arroz 3y ago

I mean, you can write tests in any language, you don’t need a framework

jjoonathan 3y ago
Yeah. You sometimes hear rules like "never write tests outside a framework," but this advice is aimed at the junior dev who doesn't want to learn the tooling, not at someone who is necrocoding in a 30 year dead language and needs to decide between loads of copy/paste and rolling their own testing framework (which would get used once, leading to amortization difficulty). Sometimes the constraints really do call for loads of copy/paste, and that's OK.
- mkovach 3y ago
  DejaGnu has been around forever. https://git.savannah.gnu.org/cgit/dejagnu.git/tree/ https://git.savannah.gnu.org/cgit/dejagnu.git/tree/ I still use it for testing software. Add in expect and it is fairly simple to write tests against TCL applications (I do it all the time).

mschaef 3y ago

> Learning the language is not intuitive and the worst of it all is that I wasn't able to write any tests which would have helped to refactor that mess. Tcl is one of those languages that's centered heavily around a single dominant concept. In Tcl's case, the idea behind the language is that everything is a string and most of the computation is expressed through various forms of string substitution. The earliest versions of the language were actually implemented this way. Indexing into an array required the interpreter to parse through a string representation of the array looking for the element you requested. Interpretation of code worked the same way - it parsed your code as it went along. Later versions (>=8.0) added the notion of "dual-ported objects. These gave the interpreter the ability to cache more efficient representations of various kinds of object, while retaining its 'string gestalt' principle. The net of this is a language that's almost totally at odds with the way people think about coding, and yet has a great deal of deep expressive power that's easy to miss. (It's easily possible to do things in Tcl that might have otherwise been limited to something like a Lisp macro or some kind of preprocessing/code-gen technique.) This general approach can make the experience of using the language initially very difficult, since it's so unexpected and different from the usual previous experience. If it sticks, though, it can be a seductive sort of environment in which to work. Whether or not this is good or bad language design is a bit of an open question, but I'm glad languages like this exist. > If I recall it correctly there just wasn't a way to write tests because it's not supported. It's easy enough to write tests directly in C. There are plenty of ways to do tests in Tcl also. (Many of which are benefited by the string nature of the language I describe above.)

jollyllama 3y ago

Same. Imagine a distributed backend made mostly out of TCL. It was a nightmare.

wduquette 3y ago
TCL takes discipline, like any other language.

hedora 3y ago

I had the opposite experience. One of my first jobs was to port a legacy TCL GUI to Java Swing. Even though I understood exactly what the TCL was doing, the Java port was 20x more lines of code, and 100x slower. I spent a few months beating my head against the poorly designed padded cell that is the JVM, and then it was 40x longer, and 10x slower.

CyberDildonics 3y ago
That's more an indictment of java than an endorsement for TCL since you were dealing with something already working. I'm sure perl/tk, qt, fltk or many others would have been a much better experience.

wduquette 3y ago

Tcl has an excellent unit test suite, Tcltest, that's remarkably easy to use. It's been around a couple of decades. I've written more test cases using it than I could easily count.