notes-computer-programming-programmingLanguageDesign-prosAndCons-tcl

" And the nice thing about my retarded debugger front-end is that it looks like shell commands: blah blah blah. As opposed to blah("blah","blah"). And this, folks, is what I think Tcl, being a tool command language, gets right.

I come from the world of pop infix languages (C/Java/Python/Ruby/you name it). Tcl basically freaks me out with its two fundamental choices:

    Tcl likes literals, not variables. Tcl: string, $var. Pop infix: "string", var.
    Tcl likes commands, not expressions. Tcl: doit this that, [expr $this+$that]. Pop infix: doit("this","that"), this+that.

So basically, pop infix languages (and I use the term in the most non-judgmental, factual way), pop infix languages are optimized for programming (duh, they are programming languages). Programming is definitions. Define a variable and it will be easy to use it, and computing hairy expressions from variables is also easy. Tcl is optimized for usage. Most of the time, users give simple commands. Command names and literal parameters are easy. If you are a sophisticated user, and you want to do pmem 0 bkpt [expr [pmem 0 pc] + 1], go ahead and do it. A bit ugly, but on the other hand, simple commands are really, really simple.

And eventually, simple commands become all that matters for the user, because the sophisticated user grows personal shortcuts, which abstract away variables and expressions, so you end up with pmem 0 bkpt nextpc or something. Apparently, flat function calls with literal arguments is what interactive program usage is all about.

I'm not saying that I'm going to use Tcl as the extension language of my next self-made lovecraftian toolchain (I was thinking more along the lines of doing that one in D and using D as my scripting language, 'cause it compiles fast enough and it's apparently high-level enough). I haven't thought enough about this, but the grotesque escaping/quoting in Tcl still freaks me out; I don't want to program like that. All I'm saying is that I like the interactive part. Specifically:

    Short code matters a lot; short interactive commands matter much more.
    An interactive command language must be a real language (loops, functions and all).
    Tcl allows for the shortest commands and it's a real language. I'm fascinated.

....

And then we have interactive shells. And in Python it's doit("xx","yy"). And in Lisp it's (doit "xx" "yy"), or (doit :xx :yy), or (doit xx yy) if you make it a macro. And in Ruby it's doit :xx :yy, if you use symbols and omit parens. And that's about as good as you can get without using your own parser as in doit "xx yy", which can suck in the (more rare) case when you do need to evaluate expressions before passing parameters, and doesn't completely remove overhead. Also note how all these languages use (), which makes you press Shift, instead of [] which doesn't. Ruby and Perl let you omit (), but it costs in readability. And [] is unanimously reserved for less important stuff than function calls.

The whole point of short code is saving human bandwidth, which is the single thing in a computing environment that doesn't obey Moore's law and doesn't double once in 18 months. Now, which kind of bandwidth is the most valuable? I'll tell you which. It's the interactive command bandwidth. That's because (1) you interact a lot with your tools and (2) this interaction isn't what you're trying to do, it's how you're trying to do it, so when it isn't extremely easy it's distracting and extremely frustrating.

This is why an editor that doesn't have short keyboard shortcuts for frequently used commands is a stupid fucking piece of junk and should go down the toilet right now. This is why a Matlab vector - [1 2 3] - is much better than a Python list - [1,2,3] (ever noticed how the space bar is much easier to hit than a comma, you enlightened dynamic language devotee? Size does matter). And don't get me started about further wrapping the vector literal for Numeric Python.

...

Ad-hoc scripting languages - the sub-Turing tar pit

Many debuggers have scripting languages. gdb has one, and Green Hills MULTI has one. Ad hoc command languages usually get the command-syntax-should-be-easy part right - it's command arg arg arg… They then get everything else wrong. That is, you usually don't have any or some of: data structures, loops, conditionals and user-defined functions, option for expression evaluation in all contexts, interface to the host OS, and all the stuff which basically would make the thing a programming language. Or you get all those things in a peculiar, defective form which you haven't seen anywhere else.

I wish people stopped doing that. I understand why many people do that very well - they don't know any language which isn't a 3rd generation one (presumably C++ or Java).

...

So basically we have 3GL people, who realize that commands should be short ("it's a simple thing we're doing here"), but they don't see that you need a real Turing-complete programming language for the complicated cases. And we have 4GL people, who optimize for the complicated case of programming ("what's a scripting language - it's a programming language, dammit!"), and they don't care about an extra paren or quotation mark.

And then we have Tcl, which makes easy things really easy and scales to handle complicated cases (well, almost, or so I think). And not only does it make plain funcalls easy - it reserves [] for nested funcalls, in the Lispy prefix form of outercall arg [innercall arg arg] arg… [] is better than (). Pressing Shift sucks. And custom keyboard mapping which makes it possible to type parens without pressing Shift is complete idiocy, because you won't be able to work with anyone's machine. This shit matters, if you program all day long it does.

I don't know if I'd use Tcl. It's less of a programming language than your typical pop infix 4GL. For starters, [expr] is a bitch. And then there are "advanced" features, like closures, that I think Tcl lacks. It has its interesting side from a "linguistic" perspective though. It has really few core syntax, making it closer to Lisp and Forth than the above-mentioned pop infix ilk. So you can use Tcl and claim for aristocracy. Of course you'll only manage to annoy the best programmers this way; the mediocre won't know what you're talking about, seeing only that Tcl doesn't look enough like C to be worth the name of a language. "

" Anyway, I've recently been wishing that my main GUI programming language (a modern version of hypertalk - http://www.runrev.com) was a) more extensible, b) had multi-threading support. This week I stumbled upon another article defending tcl, and on reading further I found out tcl was just about _the_ most extensible language, and had implemented threading in exactly the way I thought threading should be implemented. Then I started reading about the new OO core features coming in tcl 8.6, and they are look like the most appealing way of doing OO that I've ever seen. "

"

    That was a great read, thank you. I went through a similar process recently. I'd used Tcl a couple of years ago while dabbling with Expect (an essential utility in its own right), and mostly saw it as just another scripting language but with an eccentric range of different types of bracket. After spending some time over at http://wiki.tcl.tk/, I started to realise how easy Tcl is to misjudge. There's some beautifully succinct code over there. And Tk is a breath of fresh air for rapid GUI development.
    Tcl is what I imagine someone would come up with if they set about re-designing your typical unix shell language from scratch: trying to do it properly, cleanly, extensibly. The seemingly familiar syntax disguises the language's most interesting features, such as everything being a string, and all the control structures actually being commands. I sometimes find myself thinking that Tcl is more akin to Lisp than it is to C, and what seemed like idiosyncrasies become part of the beauty of the language: the simplicity and consistency of it. But, yeah, I agree that [expr] is pretty hard to like, and the "if 0 { … }" block commenting technique, with its balanced-braces requirement… :^)

... "

"

---

"

    Few years ago I was interfacing a motion control processor (for controlling servos in CNC machines) and got tired of C compilation. As a side tool I created a Tcl wrapper for all motion chip API and then the real fun began. It was astonishing how much easier everything became. Tcl is a powerful language that makes things easy , especially the things that are ridicously hard in C (meta-programming, expression eval, dynamic data structures, threading, network communication and many more). I only wish that Tcl was easier to embed in other languages, not only C but C# and Java too - it could become a perfect application scripting library." "

--

" Tcl had unfamiliar syntax, did not offer good support for data description, and ran only on Unix platforms "

--

" Anyone who says their favorite dynamic language is unsurpassed in automation abilities, easy embedding, Unicode, event handling, and GUI integration probably knows nothing about Tcl." -- http://www.modernperlbooks.com/mt/2009/11/walled-gardens-vm-sharecroppers-and-sugar-daddies.html

---