"Tcl as a way of life"

My notes from the Richard Suchenwirth's invited talk. (This was a great surprise and a treat, and worth coming to the conference just to meet him and hear him speak.)

You code it, you test it and it works. Some languages give you this more often than others.

Majored in Chinese studies with focus on linguistics and computer science, except there was no computer science speciality (formally) in 1977. Took a seminar on linguistic computing--was only student.

First big iron was an IBM 1130 programming on punch cards in Fortran. Had 32K. Moved on to Univac, Vaxen, etc. until personal computers. Languages wise looked around and did substantial things in Basic, Lisp, Prolog, C, Forth, APL. Quite a variety of machines and languages. He thought this would continue for ever.

12 years ago he switched to industy (Siemens). 10 years ago first introduced to Tcl. Decided to use it as a configuration and flow control language. Worked developing software dealing with postal automation. Internally mostly in C and C++, but Tcl used in various parts for special settings, testing, and configuration. Tcl is a good language to work with.

Expected an even better language to come along, but nothing has. Except awk on the command line for short things.

He wondered what makes Tcl different? Foremost conclusion is that Tcl is a friendly language. It has a friendly syntax that doesn't frighten people away; can be sketched on the back of the envelope. Tcl has friendly memory management. Tcl has friendly errors--this sounds strange. Errors sound like something bad (newer languages call them Exceptions which makes them sound like high levels of engineering). Error messages in Tcl are the most friendly of all the languages he has seen so far. The other extreme is C where you either get a segmentation failure or bus error. In Tcl you can just type something you know is wrong but Tcl will tell you how you might have wanted to do it right. Works as online documentation.

Not aware of other languages where you can write your own debugger in the language in <= 6 lines yourself. Doesn't think the demand for debuggers is as big in other languages where you are in trouble without them.

Finally when everything else fails, read the manual. Every word of the man page can be read and taken seriously. They are a friendly neighbor. When you need them they are there and you can rely on them.

He's observed that Tcl has a very friendly community. comp.lang.tcl has a lower flame rate and higher signal to noise ratio. He's checked that for comp.lang.c and comp.lang.lisp, etc. He's learned much from the community that is active there.

DKF put one of Richard's comp.lang.tcl posts on the wiki in 1999 (radical language modification). Didn't know about the wiki before. After thinking about it a day realized wiki was a great way to publish information to others. Wiki format allows longer explanatory format. The wiki has been a fascination for seven years now. Has moved a small selection of the hundreds of wiki pages to the Tcl wiki book project (wikibooks is a sister project of wikipedia). The book is now eight or nine chapters. Printer-friendly version is now about 160 pages (on A4 paper).

The three legs that the community stands on worldwide is the wiki, the newsgroup, and the chat (since 2001). It is always worth having a look at the chat.

What makes Tcl feel different from almost all the languages (although Lisp and Logo come close) is the feeling of empowerment. In Tcl it is possible to unconceivably much with comparably little effort. Wishful thinking is a very useful thing in Tcl. And a pen and a back of an envelope. "Tcl might be one of the shortest parsers between specification and implementation." It's a fascinating experience after ten years.

Tcl supports (encourages) simple thinking. If you came from years of assembly you might have a different style but Tcl will support it.

William Occam said "entities shall not be multipled beyond necessity." Make things as simple as possible. Code for today. What do you know about tomorrow? Especially feature creep. Too often we have more features than we really want. Lessons can be taken from extreme programming community. Need to meet in the middle of under-engineering and over-engineering where true engineering occurs. Easier to reach starting from the under-engineering end of the spectrum.

Prefers idea reuse to straight code reuse. One example is the K combinator. proc K {a b} {set a}. Simple programs can be read like poetry. Could put this line of code in a library, but then you'd have to do a [package require ...]. For such a simple thing it is not worth creating a dependency, even on tcllib.

He remembers what hard work it was to write software for Chinese, Russian, Arabic, etc. before the days of Unicode. Tcl's Unicode support is superb. In a world with so many cross connections cannot ignore the fact that other languages [other than western ones] exist. Very pleasant to display in Tk if you have the appropriate font.

If you've looked around the wiki seen pages ending in -lish. Comes from greeklish a greek term when they use latin characters to write greek. His wiki pages started as a fun project.

On the weekends it sometimes happens he is bored. Then it is time for a fun project. Thinking of something that is new interesting that he's never done. Thinks about it, paper and pen as starting place. Design APIs. Go to the computer code it, test it then upload it to the Wiki. It is getting harder and harder to find interesting bits that can be done in half a day that hasn't been done before. Part of the fun is starting from an empty piece of paper in the morning to complete results in the afternoon. Keep an eye on http://wiki.tcl.tk/RS.

Tcl is a great experimental language. One could call it a great computer science library, like Lisp. Possible to write a state machine in ten lines. Great to get something in such short length.

Functional programming. In the last decades there has been considerable development. John Backus presented in 1977 theoretical design of programming without variables. Functions composed with other functions. It was pretty amazing reason. As so often his fingers began to itch. "How would one do this in Tcl?" Didn't take very long and he could run the examples from Backus's paper one by one. After half a day or so he could make a Wiki page describing the code.

Another flavor is reverse polish notation like in Forth, Postscript, or Joy. You have one big variable that is a stack. Every function pushes or pops from the stack. Functions fall together in a way that they do what they should. In English if you describe an algorith, hypotenus. The square root is the sum of the squares. This just describes functions that compose together.

Has heard someone say "advocating object oriented programming is like promoting pants oriented clothing. Sometimes it covers your ass but it doesn't always fit."

NEM posted a wiki page about using [namespace ensemble] as an object system. RS and Miguel Sofer added and sketched out new ideas. Method dispatch is very fast.

Some possibilities and comparisons are always good to have. Doesn't know of any other language that supports so many different flavors of OO. Everyone can hack up their own OO in ten to fifty lines of code. Not so important that a guru come down from the mountain with an OO system.

Fortran and Lisp, still in use after fifty years. He's confident that fifty years from now Tcl will still be alive. On the chat and the newsgroup see newbies asking questions. Community is very patient and very supportive. Best possible reaction.

From ten years of being in the community, not good at hype and not good at proselytizing. Language is not only engineering, but it is also an art form and a matter of taste. You can't force someone to share your taste. What we can do is spread the word. Mention Tcl in suitable situations. Show some Tcl code if it is worthy to be shown. And (most importantly) help people. If we stay a friendly community no need to worry that we'll die out.


—Michael A. Cleverly

Comment:

  1. Richard Suchenwirth wrote (at Tue, 17 Oct 2006, 09:47):
Great summary! This is even more valuable because I myself don't have a writeup of that talk, just a paper with reminders. Just a few corrections of misunderstandings, which might have come from my non-native pronunciation of English:

It's a pity we couldn't talk together... but I had a hard time just following some of the crosstalk when 10..30 people talked in the same room at the same time :)

Permanent URL for this post: http://blog.cleverly.com/permalinks/254.html