I’ve, these days, just started learning TCL and TK. I’ve always heard it’s a simple way to build GUI, and that both the TCL language and TK were easy to learn.
The people who told me that were right.
A part of it which I think many people would have a problem with is its type system.
The language is weakly typed, and before people starting to jump on me for saying such a thing, let me explain what I mean by that.
In TCL, you’re supposed to program by considering that everything is a string. Internally, that’s not how it works for performance reasons, but every value have a string representation, can be converted back and forth to strings, and will be so whenever needed. When you add 1 and 13, you should see these two as two strings which get parsed by the command which performs the addition operation, and then added internally, and then converted back to you as a string. Again, it’s unlikely to happen that way for performance reasons, but it’s given to you the illusion that this is how things are getting done.
The conceptual model of TCL is (together with some other stuff) that everything is a string.
It’s a little bit like in lisp, in which you have the illusion that your program is a lisp list. Which is not true, although the implementation gives you the illusion of that. Internally, many lisp implementations will interpret your code in strange ways, or compile to some other format (C, JVM Byte Code, CLR’s CLI, some internal byte code format the implementation uses, …).
In TCL, part of your code gets “bytecode compiled”, but part also remains interpreted.
Because, conceptually, you have the illusion that everything is a string, that’s how you should program (there is no other way): all your data are strings. That’s your only data type! Which means the string format is what says what “data type” you’re dealing with: “abc 12 d” is a list, also is a text, but not an integer; “1241″ is an integer, but “12314121441312415145677872″ is not an integer (sizes), and both are lists (of one element). This means that performing list operations on integers are fine because there are no lists or integers. The operations on lists only suppose the string has a list format. Thus, “conversions” (or “looking at the value from another perspective”) happens all the time (of course that, conceptually, there are no conversions; everything is string).
Which is why I say it’s weakly typed.
It’s also dynamically typed, because the various “data types” are not attached to any particular variable. A variable that used to hold what is an integer string may hold a list string.
However, notice that since there is only one data type (the string), all your variables are of type string, and that’s never gonna change. So, in that sense you could say that TCL is statically typed. However, it’s a useless categorization in my opinion.
To talk about typing, looking at the function types would be useful (maybe mandatory), but I won’t do that in here.
One of the things that you can do in TCL is use the value of a variable as a procedure to call. And any value can name a procedure: “procedure”, “function”, “abc”, “strip”, “10″, “12.31″, “do times”, “a+1-2″. You can then store the name of a procedure in a variable, and call it later. It’d just work, because to call a procedure, all you do is start a command with a string whose value names the procedure. If my variable v holds the value of “puts”, and “puts” names a procedure, calling the value of v is fine.
This implies that you can decide, very easily, in runtime, which procedure to call. This leads to a lot of dynamicity. For example, a simple Rock-Paper-Scissors game can be implemented by making three procedures: rock, paper, scissors, which takes a string, and put out the right output message based on the value of that string (e.g. if the rock procedure takes the scissors argument, then it’d print “win”). The game now is basically reading a word, then another, then calling the first on the second.
You can define 10 to name a procedure, and still use it as a number because the command to perform arithmetic doesn’t see a procedure or procedure name: it sees a string. You could then call 10, add 10, get the first element of the list 10, get the substring of 10 from the first up to the last, and so forth.
It’s not necessary to mention how fun it is to play around with languages like that. It looks like total disaster, but it doesn’t seem to lead to disastrous situations in practice; on the contrary. Only time will tell though.
TCL has a bunch of useful built ins. And it’d be interesting if I could show you some programs exemplifying that, but I will leave this to TK, which is what I come to now.
I got into TCL because of TK. I wanted to build GUI apps, and heard that TCL with TK formed an easy to use combination. Sounded good to me. After two days of studying TCL, I thought “this language is actually easy to learn and use, it seems, let me go to the TK side, and learn how to build GUI; if something appears that I have to go back, then I will”. So I started learning a little bit of TK.
I never built a GUI before, and I always thought it was a “hard” thing to do because I’ve looked at some GUI code in the past (from some examples written using C and xstep, and some examples from a QT book I started reading, using QT and C++).
It turns out that TK feels a lot declarative. I’d say more than HTML and CSS, because of the wider amount of options in TK. In HTML/CSS it happens a lot that you build a “widget” out other elements (menus out of lists, for example). This happens in TK too, of course, but you have a much broader range of widgets to start with. Also, laying out your widgets on the window is not like a “struggle with floats or positioning”, you actually can tell “sort of” where you want it to go, and it will go there (it’s actually hard to believe how simple it is).
It’s declarative because you don’t so much say what are the steps to build the GUI (although you can surely see it that way), but you say what you want to be true about your GUI with the provided commands. TK then will just take care from there.
This makes building GUI a lot nice.
So, it has been something like 4 or 5 days since I’ve started learning TCL/TK, and I wrote an app for me. A program which filters the contents of directory by a pattern I specify, and shows me the result in a listing. I used to do that using grep and ls, or find but opening the file later is not that “easy” that way (mostly because I usually don’t have a rule for selecting which file to open after filtering; mostly if I filter music or videos, and there is also the case when I filter, but am unsure on how many files the filter will give me back; opening is really easy if the filter gives only one file name back).
So, a 140 lines of TCL/TK code did the job, and it was much better than I expected; although it has its problems.
The code to build the GUI is less than 40 lines long. It’s a simple GUI, but it’s much smaller than what I expected.
Here is the code: http://pastie.org/pastes/4554713/text
Here is a photo of the program.
Dilter in the context menu, also openned on the side.
The program is intended to use as something you open by right clicking a directory in windows explorer (yes, I use windows), and using it from there. The program does the files filtering in real time (each keystroke will update the list, which is nice). It can be made to work on linux by changing one line, which is the one which opens the file for you when you double click its item.