Tcl Core Team Interview

Gentu writes "OSNews features a nice and long-ish interview with the Tcl core development team for just about everything. " Covers a lot of ground like what they actually use Tcl for, how they came to maintaining Tcl and so forth.

Comments

I get it...

[AEton]

how they came to maintaining TCL and so forth.

That's a pun! Tee hee.

Re:I get it...

[Anonymous Coward]

Postfix all the way! RPN is to DAL as Forth is to C.

Maintaining TCL

[TOOSuave]

I hope maintaining TCL is easier than maintaing projects written in TCL...

Re:Maintaining TCL

[Anonymous Coward]

Yes -- if I want something hard to maintain that integrates with Tk, I'll use Perl, dammit.

Re:Maintaining TCL

[TOOSuave]

>> Yes -- if I want something hard to maintain that >> integrates with Tk, I'll use Perl, dammit. That sounds like the way to go... At least perl can be strict!!!

Re:Maintaining TCL

[DavidNWelton]

Actually, Tcl's C source code is some of the most beautiful I have ever seen. It is a pleasure to read and study. This is one of the reasons why it is so popular for embedding/extending.

You can check out an HTMLized version here:

http://tcl.apache.org/sources/tcl/

Re:Maintaining TCL

[hobbs]

Tcl's C source code is some of the most beautiful I have ever seen.

As a lead maintainer, I have to of course agree, but it is an interesting note that Tcl/Tk is the only major scripting language that has won ACM's Software System award. It's a level of code cleanliness that many systems just dream of.

Re:Maintaining TCL

[EvilTwinSkippy]

I second that.

Though truth be told my biggest problem is compiling my stuff for all the different platforms my extensions are used on. I haven't owned a MacOS box in years and I can't find anyone who can relink the library for new Tcl versions.

Re:Maintaining TCL

[RevAaron]

Tcl may be the only "pure scripting" language" which has won the ACM/SS. By a "pure scripting language" I mean a language which is limited for the most part to scripting and often not used for much else. In contrast, Smalltalk, a language which can be used for scripting, embedding, as well as full-blown client and server side application development has also won the award. (not to dis Tcl, it definately has its uses!)

Re:Maintaining TCL

[lvirden]

Contact the Tclkit support team (http://www.equi4.com/tclkit/)- I seem to remember reading that someone there has worked out the sourceforge compile farm details for building software on quite a few platforms.

Pass-by-name is still cool

[ObviousGuy]

With the rest of computing going off in the direction of pass-by-reference, it's kind of refreshing to see some languages sticking to their antiquated guns and pushing pass-by-name.

It's kind of a forgotten art, but P-B-N makes some things like recursion and package scoping very very easy.

Re:Pass-by-name is still cool

[Inode Jones]

Actually, Tcl can use pass-by-reference if you want it to. Tcl objects are dual-ported: they have an internal representation and a string representation. If you define your own representations, you can have the Tcl objects point directly to your internal structures without any need to do name lookups. This is VERY fast, especially if name lookups are expensive.

Re:Pass-by-name is still cool

[hagbard5235]

No, no it's not. There is a reason no one else uses pass by name. It sucks.

How exactly does P-B-N make recursion and package scoping any easier than it is in a decently designed language?

Download from here!

[Anonymous Coward]

I couldn't believe all the questions before you can download this stuff!
Look here:

Geez, some people. Oh yeah, get the crack yourself.

Re:Download from here!

[Anonymous Coward]

I'm surprised that I got funny moderation for my little link... I was sure it was gonna get offtopic or flamebait... Why is this funny?

Re:Download from here!

[daBass]

That's only the ActiveTcl Windows binaries, the source is a bit easier to get to, just like any other scripting language. But I do agree with you and wish someone would make an easier available windows binary. I still use 8.2 on windows for that reason!

Re:Download from here!

[Anonymous Coward]

Try tclkit:
http://www.equi4.com/pub/tk/8.4.2/

Re:Download from here!

[dkf]

If all you want is the source, just grab it from SourceForge. We do recommend that people download either the binaries from ActiveState or Tclkit because that saves a configure/make/make-install cycle and you can be sure that someone's actually checked that the build went right. And the people involved in both are really nice anyway.

Re:Download from here!

[hobbs]

There is no need to register anything to get the Windows binary from ActiveState (note that it specifically says "Contact info is not required to download". Only for the Tcl Dev Kit (which is a commercial product akin to ActiveState's Perl Dev Kit) requires registration because a license is sent to the user (free trial or the real thing).

You should really consider the upgrade to 8.4 because there is several years more development in it. New widgets, updated features, much faster, etc.

Slow down cowboy

[ObviousGuy]

You won't be able to see this post for two minutes anyway.

What an informative table of contents!

[LeninZhiv]

From the article:

Table of contents

1. TCL/TK Interview, Part 1
2. TCL/TK Interview, Part 2
3. TCL/TK Interview, Part 3
4. TCL/TK Interview, Part 4
5. TCL/TK Interview, Part 5
6. TCL/TK Interview, Part 6

Good thing they have it all on one page with the Printer-friendly version .

Re:What an informative table of contents!

[Anonymous Coward]

Worst of all, they mis-capitalize it in their section headers (but I've had that corrected now) - now now children, remember, TCL/TK bad, Tcl/Tk good! (Though most would argue they're both bad )

Tcl does not suck

[Anonymous Coward]

Tcl is a language that has a only one syntax for every kind of operation. It has only one data type, though under the hood it stores data that you use as, say, an integer, appropriately. The 'if' statement, rather than being a special construct, is just another procedure which happens to take code to be evaluated as one of its textual arguments. There are no exceptions to the syntax, which makes it easier to understand. It happens to be the opposite of Perl's "natural language" approach, but - so what! It also, much like Perl, has a huge potential for unreadable code, but so does every language.

Most people who hate Tcl just base their opinions on hearsay. I only respect the views of those who actually have maintained code.

It is easy, ecstatically so, to write organized, well-performing Tcl applications at any capacity. This is also true of Perl or even C++ (if you have a high pain threshold). That is to say, C++'s approach to simplicity and readability - if I dare assert that it has one at all - is being a low-level language, which keeps you in touch with the entire process on a byte-by-byte level, so it's never a challenge to understand what's going on under the hood. Perl's Way is to act like a natural language, so reading it taps into our inherent linguistic talents. And Tcl's is to just have an extraordinarily simple syntax - and in my opinion, it works.

The hysterical anti-Tcl sentiment is unfounded. My reply to one of these Tcl trolls on Everything2 goes into more detail: http://everything2.com/index.pl?node_id=1325568

(I'd be in under my normal account, but I can't retrieve my old password)

Re:Tcl does not suck

[ObviousGuy]

Simplicity of syntax is great for academics. Good libraries and good support for various programming paradigms is good for life outside the ivory tower.

Even taking a look at your example syntax, it's hard to see how TCL has improved the cleanliness of the code at all. You've got curly braces, square brackets, dollar signs, and worst of all white space delineating the function parameters.

Re:Tcl does not suck

[BitwizeGHC]

They say that those who do not understand LISP are doomed to reimplement it, poorly.

Tcl stands as starkly illustrative of this principle.

Re:Tcl does not suck

[Anonymous Coward]

Most people who hate Tcl just base their opinions on hearsay. I only respect the views of those who actually have maintained code.

I haven't maintained tcl code, because I take one look at it and puke. Ignoring people who don't code in it is bound to skew your perspective.

Perl's Way is to act like a natural language, so reading it taps into our inherent linguistic talents.

Does that mean that CmdrTaco is autistic? ;)

Re:Tcl does not suck

[Elwood P Dowd]

Iduno. Passing arguments by reference in TCL drove me completely bonkers. Perhaps I did it the wrong way (It's been a long time. I don't even recall what was the matter.) but I submit that I'm a pretty sharp guy, and the right way should have been easier to figure out.

But what the hell do I know. I code VB. Eugh.

Re:Tcl does not suck

[rodgerd]

TCL has not had one data type since arrays arrived.

Re:Tcl does not suck

[Anonymous Coward]

Arrays (the approximate equivilant of hashes in Perl) are not a data type, they're a variable type in Tcl. They're a special kind of variable with named sub-variables. You access one with normal variable syntax, but with parenthesis added, eg $a(b) to extract the item with the key 'b' from the variable a.

Re:Tcl does not suck

[Z4rd0Z]

They do? I've only heard:

Those who don't understand UNIX are doomed to reinvent it, poorly.
--Henry Spencer

Re:Tcl does not suck

[Anonymous Coward]

Passing arguments by reference in TCL drove me completely bonkers. Perhaps I did it the wrong way (It's been a long time. I don't even recall what was the matter.) but I submit that I'm a pretty sharp guy, and the right way should have been easier to figure out.

It works basically like this:

proc foo {a b} {
upvar $a localvar;
set localvar $b;
}

and then you do:

foo var val

to set var to val.

Re:Tcl does not suck

[Trepidity]

Tcl is a language that has a only one syntax for every kind of operation. It has only one data type, though under the hood it stores data that you use as, say, an integer, appropriately. The 'if' statement, rather than being a special construct, is just another procedure which happens to take code to be evaluated as one of its textual arguments. There are no exceptions to the syntax, which makes it easier to understand.

Congratulations, you just described the features LISP had back in 1956. If you really want to run a language with those features, use Scheme, which is at least a bit cleaner.

Re:Tcl does not suck

[Eil]

I've racked my brain trying to figure out why Tcl is hated by so many in the "pop" geek community. The only answer that I've been able to come up with is the fact that those making the complaints are those who: a) do not actually know Tcl and haven't taken the time to understand it and b) are zealots of some other scripting language. A third possible reason that comes to mind is perhaps that some people just can't stand the idea of something that doesn't even closely resemble C-style syntax.

I started using Tcl/Tk at the suggestion of a fellow LUG member after explaining that I needed something a bit more complicated than xmessage to drive a script that I was working on. I dug in, found it strange, then found it cool, then found it fun, and finally knew enough to start doing some real work. I now use Tck/Tk on a daily basis on a wide variety of projects and have no intention of giving it up. A 5-year-old can understand the syntax, the commands are very well documented, and the community is stellar... none of the condescending holier-than-thou's that always seem to surround the hip scripting language of the month.

The Tcl'ers Wiki has quite a few pages examining why some people like Tcl and they're even keeping tabs on who says Tcl sucks and why.

Re:Tcl does not suck

[RevAaron]

Simplicity of syntax is great for academics. Good libraries and good support for various programming paradigms is good for life outside the ivory tower.

Then it's a good thing that Tcl sports a fair amount of decent libraries.

There are plenty of people who do not think that Tcl is the epitome of simple syntax- myself included. It includes syntax elements which I think are unnecesary, and there are certainly languages with simpler syntaxes which also support a good number of libraries.

What big gap in functionality do you see in Tcl?

Re:Tcl does not suck

[RevAaron]

If you can't wrap your head around the concept of passing arguments by reference, perhaps you've been doing VB for too long. :P It's not all that difficult of a concept, but if you're used to doing things the VB way and have never ventured outside of it, I could see how you could get stuck on it.

Re:Tcl does not suck

[RevAaron]

Um, but Lisp has more than one data type. No Lisp dialect or implementation to my knowledge has only one data type. You at least have to have lambdas, strings, symbols, and numbers.

But yeah, Tcl is largely a reinvention of Lisp with uglier syntax and (usually) poorer performance for a 1-to-1 translation. Sure, you lose the parens, but you get curly braces and dollar signs in return. eww. But all the same, I don't think there is anything wrong with Tcl stealing those ideas- I'd rather have Tcl implement good ideas from Lisp than bad ideas from C.

Re:Tcl does not suck

[DavidNWelton]

Lisp is definitely a beautiful thing. On the other hand, Tcl is a very practical glue language that very readily plays nice with a lot of environments. Most importantly, it's super easy to embed and extend. From what I have seen of Lisp, it has a tendency to go off in another direction completely - it's never enough just to have lisp running, they want to go for the OS too.

Re:Tcl does not suck

[russellh]

They say that those who do not understand LISP are doomed to reimplement it, poorly.

those who can't handle LISP parens are doomed to reimplement it, with a different syntax

Re:Tcl does not suck

[Elwood P Dowd]

Uh, no. I've been doing VB for a few months. I'm much more at home with Perl, C, Java, etc.

This economy is making smart people do funny things.

Re:Tcl does not suck

[RapaNui]

Hear, hear...

Far too many of the 'anti-tcl' element have no experience whatsoever with the language.
I've been using it for some years now on quite a few large(-ish) projects, and sure, it has it's drawbacks (typing, anyone?), but the advantages more than make up for it.
Any performance (speed)-critical bits get done in C or something, and the 'glue' and GUI are Tcl/TK.
Also, the ease with which extensions can be built and added (Think SWIG!) helps a lot.

Since everyone's so anti-, here's my Anti-Perl link for the day: (flame away!!)

Here..

Ugh! call that a language??

Re:Tcl does not suck

[miu]

I've racked my brain trying to figure out why Tcl is hated by so many in the "pop" geek community.

I'm not a "pop" geek and I don't hate tcl, but it is never my first choice for a solution.

The only answer that I've been able to come up with is the fact that those making the complaints are those who: a) do not actually know Tcl and haven't taken the time to understand it

I've used tcl off and on for several years. Many people probably first run into it as I did, as the scipting/configuration langauage of a device or application. In my case it was the only way to do things that should have been much simpler. I learned the language and managed to do what I needed, but I always felt like just shoving it out of the way and doing something simpler.

and b) are zealots of some other scripting language.

What can I say, I prefer perl, python, a shell, or my own quick and dirty parser.

A third possible reason that comes to mind is perhaps that some people just can't stand the idea of something that doesn't even closely resemble C-style syntax.

Maybe the creators of C got something right.

I think some more realistic reasons people don't like tcl are those who: a) have performance requirements or b) need a large module library that can be easily ported or c) prefer an environment with quick turn around like lisp or python.

Re:Tcl does not suck

[Twylite]

I have a love-hate relationship with TCL. In the past I have been part of a large development effort where the basis was TCL (read: the rapid prototype looked good, worked, and the chaps upstairs didn't see a need to rewrite in a different language) and was amazed by its power, extensibility and simplicity.

On the other hand I have found it the second most difficult language I've had to learn, its constructs for complex operations (such as callbacks) can be very confusing, and it lacks several important features than mean a lot of workarounds.

To get into specfics:

• Tcl does not have threading support. I am aware of a threads library that exists now, but its still not part of the core, and poorly documented. I haven't even found a starkit that has it. With Tcl 7.x and even 8.0 we were forced to use extensions and/or script/batch files to invoke multiple interpretters, and introduce nasty platform-specific hacks.
• Tcl's support for reusable code (especially GUI code) is either rotton, or simple doesn't fit into modern design idioms. A simple reusable dialog that can attach to one of several sets of back-end data (and with the possibility to display several such dialogs simultaneously) is incredibly hard to do "right" in Tcl (e.g. getting a button to call back to the right function, which is easy in an OO paradigm). incrTcl/Tk doesn't help much either: without rewriting the megawidgets you're stuck with a very strange look and feel that doesn't really fit in with ANY platform. This is all, of course, related to ...
• Tcl doesn't have native object support. And it sorely needs it.
• On the up side, Tclkit and starkits have brought Tcl a LONG way, and I think we can look forward to Tcl being used a lot more on the client end as client-server applications increase their support for multiple platforms.

Well, that's my 2c.

Re:Tcl does not suck

[__past__]

those who can't handle LISP parens are doomed to reimplement it, with a different syntax

Parents? What parens? Oh, you mean those tiny little things Emacs handles for me.

Then again, there has to be some reason why people invent and use Python or Dylan.

Re:Tcl does not suck

[Anonymous Coward]

TCL owes a lot of its syntax to LISP. This is alluded to in the interview when Mark mentioned the self-representing nature of the code.
LISP-like languages tend to polarize programmers into those loving them and those hating them.
The study of LISP has fallen out of favor in the software education community lately, thus depriving yound programmers of a very useful and powerful paradigm.

Re:Tcl does not suck

[tallniel]

OK - let's take these points in order.

Firstly you comment on lack of good libraries (perhaps missing Expect and Tk as obvious counter-arguments). There are plenty of libraries for Tcl of very good quality, as a quick trawl of the Tcl'ers Wiki, the Tcl FAQ or the Tcl developer exchange would show you.

Next, you move on to not supporting various programming paradigms. I'm completely lost by this statement. Tcl supports procedural, functional, OO etc styles quite easily. One of Tcl's key advantages is that it is easily adaptable to new paradigms. The fact that Tcl only contains the basic constructs for procedural programming in the core command set maybe where you are getting this from. A bit more in-depth look would show you that Tcl easily allows you to build on these to create whatever language/programming environment fits your problem. It's a very powerful technique.

Life outside the ivory tower seems to use Tcl quite a bit, if you look at places like IBM, AOL and NASA. Tcl is used in misson-critical applications which have run 24/7 for years.

As for syntax, Tcl has used the minimum set to do the job well. If you don't like using whitespace to delimit function parameters, you can define your own function construct which takes parameters separated by commas, or whatever. That's the beauty of Tcl - if you don't like it, you can change it *from within Tcl!* See wiki pages on Radical Language Modification and others for more details.

On top of all this, Tcl has great i18n and asynchronous I/O which most other languages still don't come anywhere near (especially on Windows). Threading is getting very robust. Virtual filesystem support, which enables technology like starkits, is also very cool. Tcl still has a lot to recommend it.

Re:Tcl does not suck

[scrytch]

> I've racked my brain trying to figure out why Tcl is hated by so many in the "pop" geek community.

• It is slow. Granted it's faster than a shell script, but even ruby runs circles around it.
  
• It has oodles of "gotchas" on when things are evaled, on pass-by-name, and so forth
  
• Making actual complex apps with GUIs is impossible with any modern design pattern because all events execute at the topmost scope, so you need to keep everything important in globals.
  
• Ousterhout flogged it constantly with buzzwords as a b2b-leveraging, cross-synergy-enabling, pick-the-buzzword-of-the-week solution.
  

The shame about TCL is that it's almost an awesome language, but I just keep finding it lacking where I really needed something from it. The syntax is beautiful, I haven't seen a language this unpolluted with punctuation characters as syntax decorations since lisp. Its killer app is still expect, since no other expect package I've seen for other language comes near the ease of programming expect (shame about those lousy primitive regexes though, get with the times and use pcre). I just don't see Tcl evolving to add anything that people have come to expect, like anonymous functions (having to name and explicitly delete my "lambda" functions does not cut it) =.

Re:Tcl does not suck

[Fwongo]

It's not slow. In the Computer Language Shootout, it fares about as well as Perl usually. Tcl is just fine performance wise, thank-you-very-much.

Re:Tcl does not suck

[Anonymous Coward]

Making actual complex apps with GUIs is impossible with any modern design pattern because all events execute at the topmost scope, so you need to keep everything important in globals.

Stuck with Tcl 7.6?
Namespaces work since 8.0 , you just have to know what your doing, there always is [namespace code] to help building working events. No one needs globals. Namespaces work.

Take xotcl one of the many tcl-OO extensions (take the OO-paradigm you want, iTcl like C++, xotcl like smalltalk, TOOP like java), throw in some Tk and you have all the design patterns you need.

Re:Tcl does not suck

[Anonymous Coward]

Re: I just don't see Tcl evolving to add anything that people have come to expect,

Actually, I suspect that if someone came along with a proposal for anonymous functions, prepared to implement it, in a way that didn't break Tcl, it would be added. Certainly there have been requests for it over time. And in fact there have been numerous lamda-like experiments.

So far, no one has wanted it badly enough to do the work to get it into the core distribution.

Which is probably the greatest weakness Tcl has - lots of ideas, but too few implementors.

Re:Tcl does not suck

[DavidNWelton]

Tcl has excellent threading support, actually, in Tcl 8.4. You need an external lib to access it from Tcl itself, but it's in the core, and it's done very well. Compare with Python's "one big mutex".

Re:Tcl does not suck

[Borogove]

Any sufficiently large C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp. - Philip Greenspun

Re:Tcl does not suck

[Anonymous Coward]

Well, it's not like lisp went away. Modern Common Lisps like CMUCL absolutely smoke TCL.

Re:Tcl does not suck

[Eil]

You make some reasonable points and quite a few of them are the same that I see even advanced Tcl hackers complain about. But there are a couple I wish to counter:

It is slow. Granted it's faster than a shell script, but even ruby runs circles around it.

I argue that if you're doing anything computationally expensive then you shouldn't be using a scripting language at all. That said, Tcl can byte-compile portions of the script for a fairly sizable speedup. You're not ever going to get C or C++ speeds, but performance should fall in line with Perl or Python. If you *must* use Tcl and high performance is required, you can always write an extension in C and call it from Tcl.

It has oodles of "gotchas" on when things are evaled, on pass-by-name, and so forth

It's been my experience that these "gotchas" aren't all that difficult to learn and work around. I've found that most of the time, these are indicitive of the fact that I'm trying to do something the wrong way. This is one of the tradeoffs of Tcl... you don't have to memorize dozens and dozens of symbol operators but you do have to bear in mind that some things aren't always as they appear. ;)

Making actual complex apps with GUIs is impossible with any modern design pattern because all events execute at the topmost scope, so you need to keep everything important in globals.

That is a valid complaint, but this is a problem with any language that isn't OO. Luckily, there are several Tcl extensions that add OOP to Tcl. The most popular is [incr Tcl] and is pretty fab if I do say so myself. I've just started aquainting myself with it the past few weeks and I'm amazed how much easier it makes things (and Tcl makes things pretty easy by itself, in my opinion).

Ousterhout flogged it constantly with buzzwords as a b2b-leveraging, cross-synergy-enabling, pick-the-buzzword-of-the-week solution.

I'm not up on the "politics" of Tcl, but I'm pretty sure Ousterhout doesn't really have much to do with Tcl anymore. The Tcl core team (headed by Jeffrey Hobbs and co) do not publicize Tcl very much but they are all very active on the c.l.tcl newsgroup and make an substantial effort to help even the most clueless.

I just keep finding it lacking where I really needed something from it

There have been many times where I once thought the same thing. In my case, it usually turned out that I wasn't looking hard enough or wasn't thinking from a Tcl point of view. YMMV of course, but I strongly believe that there isn't much that Tcl can't do.

Your point about anonymous functions is valid.

Re:Tcl does not suck

[dissy]

> What big gap in functionality do you see in Tcl?

First I'd like to say I love TCL, and its my script language of choice.
Alot of times its also my programming language of choice as well.

However, one thing it is Very lacking in todays day and age is built-in (and thus cross platform) networking support.
It can basically handle TCP over IP and thats it right now.

For linux and BSD (and one or two other unixes, thou not all of them by far) you have the scotty plugin, but as i said, that is not cross platform at all.

There needs to be built in raw IP, and thus UDP/ICMP support as well.

The plugins that do exist I also concider a disadvantage.
I generally want my apps to be cross platform, but practically no plugins are, they are nearly all made for one OS and thats it.
So you have to either not use plugins at all (which I do, and is quite limiting) or code support for an external program you write in another language such as C, which is annoying.

If they added raw IP support in the core TCL libs, so others could write UDP and whatnot libs around that in pure tcl, life would be perfect in the TCL world.

Just my $0.02 :)

Re:Tcl does not suck

[ofgencow]

If they added raw IP support in the core TCL libs, so others could write UDP and whatnot libs around that in pure tcl, life would be perfect in the TCL world.

There is an extension for raw packets: pktsrc
http://qacafe.com/pktsrc.htm

I would like to see native UDP support, but I can live with an extension for ICMP.

Re:Tcl does not suck

[rodgerd]

Yes, but they don't match the behaviour my parent was describing. Prior to arrays, everything was a string, with lists being a magic string, and any operator could be used on any variable.

Arrays are not "just strings", as anyone looking for consistent behaviour between array, list, and string operators quickly discovers to their frustration, not to mention interacting with procs.

Re:Tcl does not suck

[Twylite]

Its the "you need an external lib to access it from Tcl itself" that I'm referring to. I have seen many comments on how great the threading in the core is, and even when using to/from C/C++ ; but as an application developer its pretty useless to me if I can start a thread from within my (Tcl) program.

Re:Tcl does not suck

[KewlPC]

For that particular script, it's supposed to be obfuscated.

Me, too.

[Anonymous Coward]

Very funny.

Easy as 1 1 + . 2 Ok ...

Tcl in the Mars Explorer project!

[$$$$$exyGal]

From page 5 of the interview:

and the use of Tcl in the Mars Explorer project (the one that didn't crash!).

I was particularly interested in that use of Tcl, so I searched the web for more info, and all I could find was this document. Any more info would be appreciated!

Re:Tcl in the Mars Explorer project!

[SystematicPsycho]

All the info you need

Re:Tcl in the Mars Explorer project!

[kennykb]

The first paper about Tcl on Mars that I saw was this one presented at the second Tcl/Tk workshop in 1994. Does that help?

Re:Tcl in the Mars Explorer project!

[Anonymous Coward]

Excellent! Thank you. I don't have a postscript viewer right now, but I'll take a look at it later.

--gal

Re:Tcl in the Mars Explorer project!

[Anonymous Coward]

Now how often do you see a geek girl go around searching for projects that use Tcl??? Something tells me this isn't a girl...

Re:Tcl in the Mars Explorer project!

[dissy]

TCL is used in all sorts of strange and unexpected places that most dont even know about.

If you happen to have enable access to a cisco router with a newer 11.x or any 12.x version of IOS, you will note that tclsh is embedded into the router itself.

You have access to data structures in the router, can manipulate this data in any way tcl allows, and use it to envoke IOS commands as well.

A friend of mine wrote an inhouse TCL script for his router that monitored the BGP tables, and when they hit a certan size it would remove some of the smaller routes advertized so the tables did not fill up the limited memory (it was a low end router)

Re:Tcl in the Mars Explorer project!

[qohen]

Google to the rescue (i.e. you can do a "view as text" on .ps.gz files):
Here's the article as text

Re:Tcl in the Mars Explorer project!

[david.e.smyth]

I wrote the paper. I instigated the use of Tcl on the Mars Pathfinder project. Do a Google search on:

Smyth Tcl Mars

to find several URLs for text and postscript representations of the paper.

Initially, Tcl was very useful. We eventually migrated everything to object-oriented C code, so Tcl did not make it to Mars. However, it did (and does) remain a key language for tools used to auto-generate the code we flew on Mars Pathfinder, on Deep Space One and others, and now on the Mars Exploration Rovers project.

The biggest reason we did not fly Tcl to Mars was that Tcl is simply too hard to validate to the level of completeness required for interplanetary flight software (even one bug has killed several spacecraft). The bug that scared me was where some message (sent from one thread to another) had a comma or paren or curly brace or something that caused the parsing of the argument to be totally different from what was expected. The need to validate all interfaces to not just values (of course) but also syntax simply seemed intractable. This is true for every useful scripting language I can think of.

Tcl enabled an enormous breakthrough in how we handled telemetry (data communicated from the spacecraft to Earth). This breakthrough software from Mars Pathfinder has been used on every interplanetary spacecraft since.

The architecture we evolved using Tcl, and migrated to object-oriented C, resulted in zero bugs in the code that used it (most of the 'Sagan Station' code, none of the 'Sojourner' rover code). We used many "responsible objects" running in separate threads, passing messages. Originally, the messages were all Tcl scripts, and each responsible object ran a Tcl interpreter (multi-threaded, with incrTcl and other extensions). The architecture was based on the Actor concept of Gul Agha and others, and the original (but not later) concept of the Law of Demeter, and is described in simple email conversations you can read starting here:

http://www.ccs.neu.edu/home/lieber/LoD.html

I don't get it

[tarquin_fim_bim]

"Emacs or Vi? What platforms do you use?"

How come this one did'nt get the -1 Flamebait treatment?

Re:I don't get it

[ObviousGuy]

For the most part, they were all Emacs losers. It's interesting that Mark Harrison, the only one to have "real world" experience (as opposed to academia and the Open Source world), uses vi.

TCL in real life

[dmayle]

<Shameless Plug>Check out TPOP!</Shameless Plug> It's a POP mail client written entirely in TCL (by me) for the Tivo. (Tivo is heavily dependant on TCL for its functionality...)

Re:TCL in real life

[Anonymous Coward]

Up until now I've found TCL interesting, and had it on my to-learn list (heavily used in tools in my industry). But if I find out that TCL is responsible for the "My Tivo thinks I like gay porn" problem, I might reconsider.

"No, really boss! That's not my porn, it's TCLs fault! I didn't do it! Or him."

All things considered, straight C programming might not be a bad thing after all. Does Ruby have this problem? Is she available & straight? I've heard funny things about Perl and "Python."

Re:TCL in real life

[DavidNWelton]

One of my favorites is ETLinux, written by Alessandro Rubini (author of Linux Device Drivers).

Also, a lot of Cisco routers run Tcl.

Oh, and so does AOL, with AOLserver.

And when they found out they were on slashdot.....

[Black Copter Control]

They were TCLed pink.

TCL JIT - is it any good?

[Anonymous Coward]

Every variable being a string in TCL hurt performance in the early years. But I hear they developed a JIT. Anyone know if it is any good? How does it compare to Java, PHP or Perl speedwise?

Re:TCL JIT - is it any good?

[patthoyts]

That's not really correct. What they did was put in a bytecode compiler and introduce a dual-ported data type. Instead of everything being a string, everything has a string representation and an internal representation. The currently valid rep is 'shimmered' on demand. Keeping doubles/lists in their internal rep significantly speeds up operations. The bytecode compilation step introduces some overhead, but this is recouped if the compiled procedure is ever called more than one time.

In short - yes, it is good.

Re:TCL JIT - is it any good?

[Fwongo]

There's not always a string rep - something can be just an integer or just a list, for example, if you're careful never to use it like a string.

More TCL in real life

[BLAG-blast]

Here are some TCL apps that most people don't realize are TCL apps.

Ayam 3d (3D modeling package)

Source-Navigator (Source code browser and more)

Insight (gdb GUI)

Re:More TCL in real life

[Anonymous Coward]

Source Navigator sucks - ugly UI, slow, and overall useless.

Insight is worthless compared to both DDD and gvd.

Both are old Cygnus products that were once state-of-the-art for Unix, but are now ancient relics.

Re:More TCL in real life

[Hal-9001]

There also used to be a neat AOL Instant Messenger client (actually linked to by AOL) written in Tcl/Tk which was more featureful than AOL's Windows client. Unfortunately, the name escapes me at the moment...

Re:More TCL in real life

[lvirden]

Are you referring to TiK http://tik.sf.net/ ?

Re:More TCL in real life

[Hal-9001]

Yeah, that was the one. I think there was also a command-line version called toc, or maybe that's one of the two protocols that AOL uses for instant messaging, but I'm feeling too lazy today to look up the details. :-p

Re:More TCL in real life

[Anonymous Coward]

Insight is worthless compared to both DDD and gvd

How come, is the greatness of Motif or because you work on gtkada?

I knew it!

[t0ny]

I always said TLC didnt write their own music!

Everybody needs it...

[Cryacin]

Everybody needs some TLC

I am not lesdyxic!!!

Is Tcl the new COBOL?

[JLyle]

The last time I spent any time working with Tcl -- about five years ago -- I got frustrated by some of the same problems that it sounds like they're still facing (e.g. no standard methods for defining modules or objects). Based on the interviewees' responses to the "What are you working on now?" question(s), it doesn't sound like these issues are high priority, either (e.g. it sounds like most of Jeff's time at ActiveState is devoted to working on Tcl development tools).

I wonder if anyone setting out on a new software project even considers Tcl as a scripting language anymore, over (say) Ruby or Python. Has Tcl become the new COBOL, in the sense that its only relevance is for maintenance of legacy code?

Re:Is Tcl the new COBOL?

[ObviousGuy]

How much legacy code is written in TCL in the first place? I'm sure there are a few systems that used it, but is it really such a huge development platform?

As you said, Ruby, Python, and Perl (I added that) are used for most of the scripting projects I've seen and I don't think my experience has been especially different from anyone else's. TCL has always been an oddity language, one that you write projects in for the novelty of it not because it offers anything that couldn't be more easily had in better, more mature languages.

Re:Is Tcl the new COBOL?

[DavidNWelton]

No, Java is the new cobol - people just don't realize it yet.

In any case, some people like having a language that's flexible enough that it's possible to have an object system as an extension (Scheme is like this, for example). While there is no standard object system, there are a couple of pretty popular ones, and those who need one just pick one and get on with their lives. Incr Tcl even has a book written about it.

Re:Is Tcl the new COBOL?

[LeninZhiv]

For my part, I use Tcl/Tk for the GUI in my projects, but I don't build the whole thing with Tcl. What's handy about it is you can write your program in whatever language you want to, then start up an inferior wish process and send your GUI commands (generated at runtime) to that.

This gives a lot of easy flexibility, and also lets you use compiled languages as well as ones that don't have an up-to-date set of Tk bindings of their own (in my case, Common Lisp).

So for people who are just sending wish commands generated by another program like myself, it doesn't matter if Tcl itself lags in areas like OO, since you're only issuing commands one line at a time and the details are managed by the calling program.

Re:Is Tcl the new COBOL?

[hobbs]

Things that are a high priority are what the community feels need addressing. OO is well handled in Tcl, which has namespaces in the core and popular extensions like [incr Tcl] and the more recent xotcl framework being commonly used.

It is being used in new development and new systems. At the last conference there was a paper on our (ActiveState's) work for Cisco in making some tweaks to the core to port it to their router environment. This is all recent development, and turned out quite well.

Remember that Tcl excels above all others at being a glue language. While it is a powerful scripting language that many rely on without C, it is still very easy to integrate into larger projects that require a scripting language. It has not lost its "Tool Command Language" roots, while becoming ever more powerful.

Re:Is Tcl the new COBOL?

[Anonymous Coward]

Tcl has a strong (and growing) foothold in the Electronic CAD software (chip design, etc). The data that these tools work with is often too complicated to be effectively manipulated with a gui, so most vendors include some sort of command-line interface. In the bad old days you usually got a custom language invented just for the tool. These were invariably crappy. Nowdays most vendors have figured out that it's just as easy to add a Tcl interpreter with hooks into their application. Users get a full-featured language to control the application and Vendors can get back to adding features to the product.

Tcl is a good "lowest-common-denominator" language. Experts and novices can be productive with it.

Re:Is Tcl the new COBOL?

[tsmoke]

Well, actually....

Some of the largest sites in the world use Tcl almost exclusively, including AOL.com, Netscape.com and Mapquest.com. They use it because it is the embedded scripting language in the web app server AOLserver.

So yes, it is used quite heavily.

talli

Re:Is Tcl the new COBOL?

[Anonymous Coward]

Re: problems from five years ago still being faced

Probably due to the fact that there is not much group development done against the core in Tcl.

The TCT appears to be, in essence, a team designed to vote on the ideas that others bring to the table and propose to make to Tcl. If the idea comes without resources to implement it, the idea in all likelihood is going to show up as a Feature Request in sf.net; sitting on the shelf and waiting for someone to champion it. There is a team of people who are responsible for pieces of the core; sometimes they have particular projects they want to implement, or that they hear in the community and decide to take on. The maintainers also take on bug reports and performance problems on a regular basis. But it seems like there's not a general plan that for instance the TCT agrees upon and parcels out to developers to implement for the next release .
Or maybe there is, and I just keep missing those emails on the TCT's mailing list.

they must be doing something right

[g4dget]

I don't know what it is about Tcl/Tk, but somehow it seems to be the one tool that lets me build GUIs with the least amount of hassles. Python/Gtk+, wxPython, Perl/Gtk+, Guile, and all of those, still seem to require a lot more work to get anything done. The utility and conciseness of Expect also has not been met by any other tool, IMO.

Also, if you look at areas where Tcl/Tk applications compete with applications written in other toolkits (Zircon, Tkabber, etc.), the Tcl/Tk applications may be uglier, but they tend to be far more feature-complete.

Of course, Tcl/Tk has its limits, and something like iTcl/iTk is rather ugly. But overall, it looks to me Tcl/Tk must be doing something right, and it might be well worth for the developers of other GUI tools to try to figure out what that might be so that we might get the best of both worlds.

Re:they must be doing something right

[hobbs]

something like iTcl/iTk is rather ugly

I would have to agree somewhat that the default look of itk is rather outdated (Motif-based), but that is not a limitation of Tk. Because Tk allows you to toss up windows with such minimal code as pack [button .b -text "Hello" -command {puts "Hello World"}], many users create simple GUIs that just work, without putting any extra time into spit and polish.

You might prefer Tk megawidget toolkits like Bwidgets that did more spit and polish on the megawidgets, but any UI builder should always spend some time to adjust basic defaults to get the look they want. Even that is easy in Tk, with simple things like option add *Scrollbar.borderWidth 1 to affect the borderwidth size of all scrollbars created.

Re:they must be doing something right

[g4dget]

I would have to agree somewhat that the default look of itk is rather outdated (Motif-based), but that is not a limitation of Tk.

I wasn't referring to the appearance, I was referring to design and APIs of iTcl. People have had (I think legitimate) complaints about how large Tcl/Tk projects become difficult to manage, but in my experience, I don't find iTcl helps all that much.

[...] Tk allows you to toss up windows with such minimal code as pack [button .b -text "Hello" -command {puts "Hello World"}]

That was my point: Tcl/Tk is the fastest way I know to create small to medium sized GUIs and it's an enormously practical tool, but the language also has some serious limitations.

In any case, the biggest practical problems with Tcl/Tk I find are that a lot of extensions still aren't part of it: iTcl doesn't ship with Tcl, and drag-and-drop doesn't ship with Tk.

Re:they must be doing something right

[hobbs]

the biggest practical problems with Tcl/Tk I find are that a lot of extensions still aren't part of it

That is what ActiveTcl tries to address. Look at the feature list in the link above. Many major extensions to get you going quickly. The community is right now pondering the whole archive repository, but we want to make sure that it is done right.

Re:they must be doing something right

[g4dget]

There is a difference between good packaging (I don't need ActiveTcl for that, I already get it with Debian) and integration. One may be able to argue whether sound support should be part of a core source distribution, but I think the object system and drag-and-drop should be.

I think there is a risk that when an open source project becomes associated with a company that sells support or packaging for it, in order for the company to be able to add value to the product, the open source version ends up being more cumbersome to install or use. That's not necessarily a deliberate strategy, but when it comes down to allocating programmer time, creating a more integrated open source solution probably ends up being low priority--since the perception is that the commerciallly packaged version already addresses that need. I hope that's not the case here with making a more integrated Tcl/Tk source distribution.

Re:they must be doing something right

[lvirden]

Re: but I think the object system and drag-and-drop should be.

And either or both of these _can be_ - once someone steps up to the plate to do the work to get them integrated, etc.

Lots of people ask for lots of things in Tcl.
Until someone sees it important enough to do the work, the requests sit on a list, or in an email, or a usenet posting, or whatever.

TCL vs TK / Ousterhout bailing/ maintaining code

[CresentCityRon]

At the 1998 Usenix convention in New Orleans Ousterhout asked how many people used TCL w/o TK. Few raised their hands. Then he asked how many used both. Most raised their hands! Finally he asked about just TK users. Far more raised their hands than the just TCL crowd. He was surprised. He seemed to feel that TK was an addon. For a number of developers that I know and myself TK was the glitz and feature that drew me in. Otherwise I would have stuck with Perl.

With Ousterhout looking for greener pastures does this weaken the product? I would think so. If he doesn't believe in it then why should I? How long as he been gone. I couldn't tell exactly from the interview. If I missed it sorry.

I don't know about anyone else but I get in a "TCL" frame of mind. If I go off and do some C++ or Perl coding I cannot seem to read TCL code for a bit. I have to "warm up" or something. I'm aware of flaws in other languages - Perl syntax for example - but you can get some nasty TCL bugs that will simply doom you. It IS tricky at times.

I feel that TCL's strength was it was an early tool that worked across platforms, and was great for X GUIs. Today that is much more common among tools.

-Ron
PS: Ousterhout AND Welch used to reply to my questions years ago. They were terribly generous with their time answering emails. It kept me working with the tool.

hmm

[ergonal]

I was thinking about TCL the other day, and why I never bothered to learn it. The main reason is that unless you write eggdrop scripts/etc, is it really worth your time? Especially when there's already the three P's to learn (Perl/PHP/Python).

Re:hmm

[lewp]

Is it worth your time? Well, it's simple enough that in the time you spent thinking about why you never learned it the other day you probably could have gotten a good start on actually learning it.

So yeah, it's worth your time. Or, at least it was. Maybe it's not if you never think about it again. Of course, now you will. There is no spoon.

Some TCL Strengths

[zapatero]

One place that TCL really shines is with async sockets. TCL makes it really easy to prototype a server. It's builtin support of the server socket [socket -server cmd ...] enables a very easy creation of an non-forking iterative server, that does surprisingly well. And is also remarkably portable between windows, Linux, and Solaris.

I've also used Python for this, but I feel that Python's asyncore is still too buggy for prime time, and also the asynchore library is slightly more complex to utilize.

Another great aspect of TCL is how easy it is to extend. I can compare directly to JNI and Python extensions. TCL by far has the easiest and cleanest extension API for C or C++.

And finally embedding an TCL interpreter into another ap, is equally easy... Hence the near ubiquitour support of TK in other scripting languages, including Python and Perl.

Opinions from experience.

Re:Some TCL Strengths

[khanyisa]

If you want to do async socket stuff in Python, you should check out Twisted Matrix which can do anything (apparently)

Re:Some TCL Strengths

[jemfinch]

I've also used Python for this, but I feel that Python's asyncore is still too buggy for prime time, and also the asynchore library is slightly more complex to utilize.

I can agree that it's probably somewhat more complex to use, but "too buggy for prime time"? It's been used in numerous projects, not the least of which is Zope. It's been used in production "prime time" situations for several years now with no major difficulties. At the very least, it's 847 lines of code. That's about 30 minutes of reading.

Jeremy

Your most unusual Tcl application

[Inode Jones]

So: calling all Tcl/C programmers out there: what was YOUR most unusual Tcl application?

For me, it would have to be a CD-ROM/CD-audio copy protection testbed. Think of cdrdao, but with all low-level functionality as Tcl commands. The tool could rip audio, playing it through speakers, while simulating the effects of twiddling the P-channel bit, in real-time! Could burn it too.

Re:Your most unusual Tcl application

[zapatero]

A content-management system that ran Ampex robotic tape drives.

Re:Your most unusual Tcl application

[syberdave]

#!/usr/bin/tclsh while {1} { puts -nonewline "crap@syberpc:~$ " flush stdout; set instr [gets stdin] set mcmd [lindex "$instr" "0"] if {"$mcmd" == "exit"} { break } elseif {"$mcmd" == "cd"} { if {[string length [lindex "$instr" "1"]] != 0} { puts "bash: cd: [lindex "$instr" "1"]: No such file or directory" } } elseif {"$mcmd" == ""} { } else { puts "bash: $mcmd: command not found" } }

Re:Your most unusual Tcl application

[syberdave]

#!/usr/bin/tclsh

while {1} {
puts -nonewline "crap@syberpc:~$ "
flush stdout;
set instr [gets stdin]

set mcmd [lindex "$instr" "0"]

if {"$mcmd" == "exit"} { break
} elseif {"$mcmd" == "cd"} {
if {[string length [lindex "$instr" "1"]] != 0} {
puts "bash: cd: [lindex "$instr" "1"]: No such file or directory"
}
} elseif {"$mcmd" == ""} {
} else {
puts "bash: $mcmd: command not found"
}

}

#sry... im new to this

Re:Your most unusual Tcl application

[kennykb]

Ohh, where to begin? Many of the most important Tcl applications are so unusual that you don't realize that Tcl is there under the hood.

Tcl runs the operator interface of Shell Oil's Auger, a drilling rig in the Gulf of Mexico. See pictures of the rig here, and read about the system integrators here.

Don't like oil rigs? Well, it's highly unlikely that you can mod this post down without the Tcl that's built into practically every Cisco router on the planet. Read Cisco's tesimonial.

Once you've done that, go log off and watch TV. Oh yeah, did you know that the NBC network control system is a Tcl application? It is; it's been in the digital broadcast system from prototype all the way to full 24x7 operation. ComputerWorld ran an article about the project.

Science geeks will be interested that a Tcl interface is used to program the Hubble Space Telescope

Database heavies will be intrigued by the intimate role that Tcl has in Oracle Enterprise Manager.

I could go on all evening, this is just the tip of the proverbial iceberg.

Re:Your most unusual Tcl application

[WetCat]

A 20-lines program that test freshness of
Real Player and Media Player links for Windows, using
COM.
Java programmer who tried to do the same,
ends with 2 weeks of trying and no result.

Re:Your most unusual Tcl application

[trb]

I've written a few unusual Tcl/Tk apps, but I'd say that the most unusual one was called Robospud, the automatic couch potato.

Robospud was a fixture for testing code in cable tv set-top box. It ran on an old Solaris box. A tv remote control was wired to a serial port, it acted as the "keyboard." The tv's screen was hooked to a video capture board on the Sun. Robospud would push the buttons on the remote, and "watch" the tv, making sure the right control screens came up on the set-top box.

It was written in expectk (tcl/tk/expect). It was a great alternative to testing set-top code by sitting their pushing buttons on a remote control, I met people who were well-paid to perform this mundane task.

C++

[pyrrho]

Actually C++'s approach to simplicy is called...

Class Systems.

It's ridiculous to say C++ is a low level language. You can work at whatever high level you want. For god's sake with MS Dev you can even work in "draw an interface click to write code" mode.

No one has convinced me that C++ isn't arbitrarily high or low level, depending on what the developer wants.

Re:C++

[Anonymous Coward]

It's ridiculous to say C++ is a low level language.

It is not garbage collected and it has pointers. It is a low level language. QED.

That is not to say that there is anything wrong with that, but if you have to manage your own memory allocation then you are most definitely using a low level language.

Re:C++

[Anonymous Coward]

You can have garbage collection in C++ if you really want.

Re:C++

[pyrrho]

but you don't HAVE to manage your own memory. You can EASILY use a class system that manages memory for you! It can employ garbage collection.

I MIGHT do something low level in C++, it doesn't stop me.

But I MIGHT do something high level in C++, it doesn't stop me there either.

Would you say that to be High Level a language has to close off access to low level powers?

Learning TCL (or others)

[DarkMan]

I'm at this point where I'm finding i'm doing everything in C, Fortran or shell.

I'm reckoning that I aught to learn a language that sits in the middle.

Is TCL a good option here? Or would I be better with Python or Perl. (Ruby's out - don't know anyone to ask stupid questions about Ruby to).

Re:Learning TCL (or others)

[Anonymous Coward]

Perl's got the least restrictions of any of those languages. You aren't tied to any specific paradigm like OO in Python or Stupidity in TCL.

Re:Learning TCL (or others)

[hagbard5235]

Run, do not walk, away from Tcl. I've written applications in Python, Perl, and Tcl. Python is a joy, Perl will do exactly as advertised ( get the job done), Tcl is a nightmare. I would never, under any circumstances, use Tcl for any purpose if not forced.

Re:Learning TCL (or others)

[Anonymous Coward]

Oh come off it. Perhaps you like Python better but
don't try to paint Tcl with a "run away" brush.
There are many areas where Tcl is far better that
Python or Perl, and some areas where the reverse
is true. I am not bothered by folks that like
one tool or the next, but your pointless Tcl
bashing is just stupid.

Re:Learning TCL (or others)

[hagbard5235]

I might be willing to give you superior async networking, and it has it's place in providing VERY simple capabilities as an embedded language, but other than that I challenge you to name one task where Tcl is the best choice.

I'm not a one language wonder by any means, I'll happily use ( and have used in the past ) Perl, Python, Php, C, C++, or Java depending on the problem. I've got no problem learning a new language.

So here's the challenge, name one task where Tcl is the best choice for the job.

Re:Learning TCL (or others)

[WetCat]

People ARE different. And some people can find
TCL syntax best fit for them. You can write a lot
on other languages, but for me TCL is a best choice.
May be not for you.

Re:Learning TCL (or others)

[ofgencow]

When I hear comments like that, I'm only impressed that the author is one who couldn't program his
way out of a wet paper bag. There is such wealth of examples of other programmers doing interesting and useful projects with Tcl - to claim otherwise lays blame at the authors feet, not the language. Of course this is true for languages beside Tcl, too.

Most of the Tcl criticisms I've read from others are based around a) not actually learning the Tcl language before using it, or b) expecting it to be more like some other language (which it isn't).

Re:Learning TCL (or others)

[roalt]

Please do not listen to anyone who gives you advise unless they know where you want to use your programming language for.

Personally, I use Tcl for shell scripts that tend to become too large or too complex. I think for parsing text files, Python but especially perl are also useful, although I have no experience in them.

If you some some extra interaction with the user than use Tcl/Tk, It's excellent at (fast) creating interactive applications.

Anyone that tell you, you cannot program large applications with Tcl/Tk don't listen to them. I've written 10.000+ lines of code Tcl/Tk programs (see here, unfortunately all in Dutch) and constructions like namespaces help keep your code clean.

Main problem in Tcl (with large programs) is that you have to track yourself what you put in variables, there's no way to enforce it (is it an array, a list, a list of array, a list of lists ?). But then again, you can circumvent that by using wrapping functions.

Re:Learning TCL (or others)

[Anonymous Coward]

Run, do not walk, away from Perl. Ugh!

Re:Learning TCL (or others)

[Anonymous Coward]

RE: Or would I be better with Python or Perl. (Ruby's out - don't know anyone to ask stupid questions about Ruby to)

If that's your reason for eliminating Ruby, you probably should eliminate Perl as well - no place to get answers to stupid questions there either...

Re:Learning TCL (or others)

[DavidNWelton]

Some areas where Tcl is superior:

* Embedding/extending - you have access to pretty much everything. The C code is a pleasure to work with.
* Unicode support.
* I/O system - stacked channels.
* The possibility to write 'little languages' with it - you can easily write constructs such 'if', 'for', and 'while' in Tcl itself - something you can't do in the other languages.
* Abstraction - all these languages do sockets, for example, but Tcl gives you a truely 'higher level' approach to them, instead of warmed-over direct access to the C layer.

Re:Learning TCL (or others)

[dkf]

Python is a joy,

Can anyone actually point to a really solid Python application? I've used a number of them (including both Mailman and Zope) and I've yet to see one that doesn't have stupid and annoying "features". But perhaps that's the fault of the people programming with Python and not the language. After all, we don't blame sysadmins for the idiocy of users...

Perl will do exactly as advertised

So long as the advertising doesn't include maintenance six months in the future. On the other hand, as CowboyNeal probably knows full well, a decently obscure sendmail.cf is simultaneously a well-formed Perl program, so you can save on disk space... :^)

Re:Learning TCL (or others)

[dkf]

So, you'd rather have Perl's paradigm of Squiggle-Factor 9? It takes all sorts, I suppose...

Re:Learning TCL (or others)

[dkf]

I'm at this point where I'm finding i'm doing everything in C, Fortran or shell.

I'm reckoning that I aught to learn a language that sits in the middle.

Now that's a good instinct. You definitely ought to be looking for something to help there.

Is TCL a good option here? Or would I be better with Python or Perl. (Ruby's out - don't know anyone to ask stupid questions about Ruby to).

Long-standing arguments between language fanatics notwithstanding, you should choose whichever of the languages suits your own personal style best. After all, it's not all that hard to quickly try all of them and all of them can do the "code integration" thing. I know that the Tcl community is virtually always welcoming towards newcomers, and many people find that to be a big plus, but one of the things we always recommend is that people choose something that suits them. After all, they're the ones putting the effort in to learn something new.

If you decide that you want to progress from calling your C and C++ code as external programs to integrating it into your scripting lanugage, you should probably look at SWIG as your first step to getting the wrapper code; it doesn't do as neat a job as hand-written stuff, but it is a much quicker way to get something working.

Re:TCL vs TK / Ousterhout bailing/ maintaining cod

[kennykb]

Ousterhout and Welch are still members of the Tcl Core Team, even if they aren't in the interview. Ousterhout doesn't do *any* coding anymore, on any project; a severe hand injury makes it impossible for him to type. And I have nothing but respect for Ousterhout's wisdom in letting himself be bought out two years ago, when a software company was still worth something. I'd hardly call it "bailing", more like "taking a profit." The point that Ousterhout and Welch used to reply to questions is a good one. The Tcl community is still like that. comp.lang.tcl is one of very few newsgroups where newbies don't get flamed to a crisp.

Re:TCL vs TK / Ousterhout bailing/ maintaining cod

[hobbs]

With Ousterhout looking for greener pastures does this weaken the product?

You will be surprised to find that many in the community would disagree. While everyone appreciates the efforts he put into Tcl, many felt that he was being too strict about the development path. Ousterhout's response was to create the Tcl Core Team, which has been positive. There are now many more people that work directly on the core, as well as a team of people that can discuss direction. John still does get involved in core discussions, and his opinion does carry a lot of weight, but there is no one person having a magic overriding vote or veto.

BTW, he still does use it, he has just decided that there is more to life than language development (he prefers building products). He has always been a good capitalist at heart, and language designers don't see big $$$.

Re:TCL vs TK / Ousterhout bailing/ maintaining cod

[Anonymous Coward]

You guys wouldn't get to see Guido or Larry responding to your comments on Slashdot!

Friendly user comunity

[DavidNWelton]

I think one of the best things about Tcl is the user comunity. In reality, of course you will be able to do anything you want with any of those languages.

Tcl's user comunity makes it a very positive experience to use the language, though. Not everyone values having others to ask when they need help, but if that's important to you, Tcl's certainly not a bad choice at all.

I love TCL

[EvilTwinSkippy]

What I love about TCL is once the code becomes too complex, nasty or slow, you can easily write a C extension as a drop in replacement.

I have some libraries that I have written that, depending on your platform, will use a C level extension, an operating system call, or run a TCL procedure designed to emulate the behavior. The scripts are fat dumb and happy.

TCL doesn't try to be anything but that 100 mph tape that holds your application together.

Re:I love TCL

[WetCat]

And you also can use Object-Oriented supplement -
[Incr TCL]
Why not?

Re:I love TCL

[EvilTwinSkippy]

Well sure. I actually have written/still use a few wrappers for SQL interfaces that use Incr Tcl.

Quote from Interview

[Xcott Craver]

"I was visiting to show off some research I was doing at the University of Oregon using Tcl (related to wearable computers)."

"Here, try this, it's a wearable tickle machine. Hey, wait, come back...."

--X [Who can't wait to see one of these on ThinkGeek.]

It's "Tcl", not "TCL", fools. Tk, not TK.

[Anonymous Coward]

It's Tcl, said "tickle." Tk is capitalized as shown and is said "Tee-kay." Get it straight.

AOLServer

[Anonymous Coward]

Don't be fooled by the name. Yes, AOL owns this, but it's Open Source and Free Software. It's basically a webserver that heavily relies on Tcl. It's fast and uses a small footprint. And because it uses threaded Tcl, it could use a single thread to make multiple queries to a databse, thereby reducing the number of processes that needs to be spawned by your database server. Think about 8 queries on a single connection to an Oracle server instead of 8 connections (1 connection per query).

Re:TCL vs TK / Ousterhout bailing/ maintaining cod

[dcuny]

I was initially quite impressed by Tcl/Tk when I first encountered it a number of years ago. I had been looking for a cross-platform toolkit, and Tk looked like exactly the thing I had been looking for.

The layout managers were an especially nice feature, since they would manage the placement of widgets on the windows automatically. Coming from a Windows/Mac background, I had never seen anything like it.

Unfortunately, the actual experience of using Tcl/Tk was less nice. Even though it had a Windows-esque wrapping, the widgets still seemed to behave like Motif widgets (yech!), and the applications didn't scale well to low resolutions (800x600) - they all seemed to have been written for people with huge X Terminals.

As others have pointed out, the Tcl grammar is quite consistant, but so is LISP. It just felt klunky.

I spent some time browsing the Net looking for a version of Tk that stood alone from Tcl. There was one I found, but it was unmaintained. I dug into the code for a while, trying to see if I could do it myself, but it seemed pretty tightly embedded. Besides, trying to keep up with the changes to Tk seemed hopeless task.

To be fair, Tcl/Tk had a particular niche it was aiming for: being a "glue" language. For that, it seems to do an admiral job. But other languages (Lua, Perl) or toolkits (wxWindows, Qt) seem better poised in the market.

Nice but ...

[wayne606]

Tcl is an okay language - I have been using it for more than 10 years in some big applications. But I've been using Python for about a year now and I feel that it's much better for real programming. The data structures are much richer - not everything is a string, it's faster, more readable, and makes good programming more natural.

John was a great software guy but he wasn't a language designer and (no offense) it kind of shows up in Tcl. The way comments work, and the fact that error messages don't tell you a line number from a source file, are both side effects of Tcl's hacky implemention.

The one huge advantage that Tcl has is Tk and even though other languages have Tk bindings they all seem awkward and second-class. But is that a strong enough advantage? I guess it depends on the application.

Re:Nice but ...

[Anonymous Coward]

The problem with comparing TCL to most other languages is that TCL was designed to be intermixed within an application in order to quickly prototype and deploy. As an embedding language it is stupid easy to create compiled libraries to access as commands within the language. When used as inteded, TCL looks little like tclsh, although it is powerful in its own right.
Also it really set the standard for socket level programming, it is really easy to build a full featured web server in a couple hundred lines of code -with error checking and 1.1 compatibility.
Most of my personal projects use Ruby because I am forcing myself to truely learn the object model, but where I work, TCL is the internal standard for quick and reliable application generation.

I only wish a CPAN module repository existed for TCL as for Perl.

Re:Nice but ...

[DavidNWelton]

It sounds like you have more than enough experience to judge whether the language works for you - one comment though. You may not like some of the rules of the language, but... the implementation is very nice, in my opinion. It gives you all kinds of wonderful stuff at the C level. Interpreters, stacked channels, linking tcl and C variables, variable and command traces, the event loop, and on and on. It's all very nicely written, and extremely well documented C code.

Re:Nice but ...

[hobbs]

The way comments work

Tcl has a real advantage in that it is the only language that holds strictly to a very short set of syntax rules. There are only 11, and it makes for a simple, yet powerful language. Comments fall strictly in those rules.

the fact that error messages don't tell you a line number from a source file

Errors in a procedure give you the relative line number in that procedure. There is a good reason for that - procedures can (and often are) defined (or redefined) at runtime.

Re:Nice but ...

[wayne606]

Tcl does have a very short set of syntax rules. But that doesn't necessarily mean that the resulting syntax is really optimal. I think that these should be comments:

set abc 123 # set the value

set xyz {
item1 # this is the first one
item2
}

etc. They aren't because IMHO the syntax rules of Tcl are designed more for simplicity than for producing a language that works like other languages.

The error reports could probably be done in such a way that if you got the procedure from sourcing a file it would give you a line number but if it was redefined at run time that would work the same way as it does now. That's probably not a big deal.

My other historical gripe with Tcl is that unlike python it doesn't come with "batteries included". There are a lot of packages such as Expect, Incr Tcl, BLT, bwidgets, etc that should have been bundled with the core distributions early on. (Of course you would be able to build without them.) But in the past the Tcl group suffered from a bad case of not-invented-here syndrome and that made life tougher for users who had to download packages from different places, patch the core, etc etc. Also I wonder how long it took to reimplement the grid geometry manager when blt::table was already available and worked fine, but for some reason was never pulled into the core Tk.

Well, I don't want to rehash all the Tcl vs XXX discussions from the last 10 years...

Re:TCL vs TK / Ousterhout bailing/ maintaining cod

[DavidNWelton]

I don't use windows... but apparently the look and feel there has improved a lot from Tk's early days on that platform.

huh?

[Trepidity]

How does pass-by-name make recursion any easier?

The only decent advantage I've seen for pass-by-name is the oft-cited Jensen's device (lets you calculate summations rather elegantly by taking advantage of the way pass-by-name works). On the whole, it leads to a lot of unintuitive behavior, which means a lot of bugs.

Tcl and Perl

[Continental Drift]

TCL is to Perl as Esperanto is to English

I've programmed both professionally, and while I'd rather use Java when working in a large group, I think Perl is prettier. TCL is elegant, but I hate passing all variables by value, and I think "uplevel" is a terrible idea. I find Perl more fun.

Re:Tcl and Perl

[patthoyts]

So you like Perl's reference syntax better? Wierd.

Re:Tcl and Perl

[Anonymous Coward]

Uhhh, is this a joke? Perl pretty? Perl
has to rank as one of the *worst* languages
ever written. How this language became popular
is beyond me.

Re:Tcl and Perl

[hobbs]

I hate passing all variables by value

Tcl is designed to be simple, and "passing things by value" is a very simple concept. At the same time, Tcl does have a very modern core. Things haven't been actually passed by value for years. What actually happens is a pointer to the value is passed on the stack the the next procedure. It is very efficient.

I think "uplevel" is a terrible idea

Then don't use it. It is a power-user feature, and allows things that aren't possible in many other languages (like creation of new control structures), but most users will not require it.

Some of the largest websites in the world use Tcl

[tsmoke]

Some of the largest websites in the world use Tcl as their scripting language, including AOL.com, Netscape.com, Mapquest.com and DigitalCities.com.

This is because they use AOLserver which is a massively scaleable and powerful web application server. Some of its features are:

• Multi-threaded - It's been multi-threaded since its original development in 94 or 95.
  
• Native DB API and DB connection pooling
  
• Embedded scripting language, which is Tcl, which allows for extremely fast development. It also allows for .ADP pages, like .ASP, .JSP or .PSP pages.
  

The reason Tcl is the embedded language is that AOLserver was developed in the early nineties, when Tcl was the hot new language. If the system were to be developed today, I'm sure that the developers would have chosen Python, Perl or some other more buzzword compliant language that has a strong following.

That being said, Tcl in AOLserver still rocks for developing DB backed websites. In fact, the Open Architecture Community System (OpenACS) is a complete web toolkit for building just these kinds of sites. The Sloan School of Management at MIT recently funded the development of an open source course management system called dotLRN that is build using the OpenACS as its foundation.

So Tcl isn't just a GUI tool or a glue language. It's also a great language for web scripting!

talli

what TCL is good for

[RussP]

TCL is a command language for TK. For that purpose it is excellent, but for general scripting it is awkward at best. If you have a GUI intensive application to write, use TCL/TK, otherwise use another language, such as Python.

By the way, check out GVI, the Graphical Voter Interface, which I wrote in TCL/TK.

not really multiple data types

[Trepidity]

I'm most familiar with Scheme, so can't comment on Lisp directly, but it's generally considered to only have one data type -- that of "Scheme object" (or "Scheme thing"). As with the parent poster's description of TCL, each object is internally stored with a particular data type, which can be tested with various predicates (like number?), but there's no actual typing system. You can assign anything to anything else, and call any function on any other object, and there will be no static type errors because there are no types. There will be run-time errors if you try to do things like take the first element of something that internally isn't a list, but that's unavoidable in any language (including TCL).

Re:not really multiple data types

[__past__]

Common Lisp has a hierarchy of types starting with t, the general type. Its subtypes include number, integer, fixnum, string, cons, list, array, hashtable, function, structure and class objects etc. You can also define own types, for example "all integers between 11 and 42" or "string or list", not to mention structs and OO classes.

In most cases you don't deal with types directly: just try to do with a Lisp object whatever you want, if it isn't allowed an error is signaled. You can, hoever, explicitly check for types at runtime (using the check-type function), dispatch on them using typecase and etypecase, use them for method dispatch (you can write methods for all kinds of objects, not only for the classes you invented yourself.), get the type using type-of, or "declare" the types of your objects and functions, so the compiler can optimize and/or check appropriately, depending on your compiler settings (and your Lisp implementation, of course.) Given a reasonable implementation (the free CMUCL and SBCL systems are great when it comes to optimizing and type-checking), you can have the best of both static and dynamic typing, use whatever approach is more useful in a given situation.

Like Scheme (and I guess TCL), it's an object that has a type, not a name. You can bind a string to the symbol "foo" and then an array of flying deamons after that, but that won't change the type of the string itself - it stays a string until it's gcd.

YOU DID IT!

[Anonymous Coward]

you did not FAIL IT! YOU DID IT!
congradulations
grandmother bakes cake for you

Re:TCL vs TK / Ousterhout bailing/ maintaining cod

[Anonymous Coward]

He has one hand he can still use. There are one-handed Dvorak layouts he could use if he really wanted to.

As it stands, he uses speech recognition for e-mails and such.

I hate TCL's syntax

[Anonymous Coward]

TCL may only have a few simple rules, but you had better understand those rule REAL WELL or you will spend endless hours trying to figure out what is happening. Where you put spaces, or not, putting braces in comments, whether you comment with ;# or just #, whether your string is a string or a list (maybe those empty list entries will dissapear when you uplevel). I could go on and on about the syntax. Sure, you can do most things you need to, but it takes me longer to design and debug than perl. Is it a list, or a string --- you decide. Some say that is powerful, I think it is confusing. Everything is a procedure, so you need to remember countless procedures. Why [lindex $list 7] instead of $list[7]. Why [set foo 7] instead of $foo = 7. If I want to use a reference to an array, its [set [set _ref]($item) to see the contents. I hate it.

In TCL, you spend a lot of time trying to figure out how TCL wants you to do something, whereas in perl, you just do it.

TCL's big advantage is that instruments and EDA software understand it, so it will never go away.
I HATE the syntax, but I love what it makes possible.

meBigGuy

What is wrong with a minimal core language?

[patthoyts]

A number of the comments above revolve around Tcl's percieved lack of a standard object system. There is one, it's called [incr Tcl]. There are also a large number of other object systems many that fit naturally into the system for which they have been designed. I see no reason to insist on incorporating any object system into the core language. Much better to keep the basics small and compact and allow extension. The now standard Tcl distribution from ActiveState supplies all the bells and whistles you might need. But if you want a minimal system, you need go no further than the tcl sourceforge project and obtain just the language core. I would favour making the language more modular. Not less. Get the TCP sockets out into a loadable module. Chop out the regexp engine. This way if your intention is to drive a washing machine without internet access, you can use only the pieces you need. I've yet to meet another language that is as easy to extend with compiled modules as Tcl. Minimalism - it's the way forward.

Re:What is wrong with a minimal core language?

[Twylite]

incrTcl is on of several object systems for Tcl. The primary problem with an object system being an add-in is that Tk cannot then rely on having an object system available, which means you can't create generic encapsulations of Tk widgets as objects, short of using an entirely new widget set (such as incr Tk).

incr Tk has its own problems: it is very large, and provides its own look and feel that is very weird on most platforms.

Now that we have Tclkit, I would also support having sockets and regexp as modules; but an object system shouldn't be an add-on to a language anymore than security should be an add-on to an application.

Re:What is wrong with a minimal core language?

[patthoyts]

Now that we have TclKit and TclKit includes [incr Tcl] as standard I would say we have exactly the best of both worlds. A minimal tclsh and a generally useful tclkit.

I disagree - I _do_ feel that the object system should be an add-on. It should just be as well supported and as easily available as the core language.

Re:What is wrong with a minimal core language?

[scrytch]

> A number of the comments above revolve around Tcl's percieved lack of a standard object system. There is one, it's called [incr Tcl]

It's definitely incremental. Here's how you instantiate a class in [incr tcl], straight from the manpage:

fileselectiondialog .foo.bar.#auto -background red

This creates a fileselectiondialog with the path .foo.bar.(someautogeneratedname). See, in tcl, you have to create all your components in the top level namespace, you have to know the path to them (don't bother trying to set it in an enclosing scope, your event handlers won't execute in them), and you have to delete them when you're finished -- no garbage collection going on for objects here.

There's of course ways to get static scope and local variables. Each of them requires extra syntactic decoration that generates unique global names for you. All of a sudden, python+tkInter starts looking a whole lot better to prototype your GUI with...

Re:What is wrong with a minimal core language?

[RobKow]

Idioms:

set fsd [fileselectiondialog #auto -background red]

What's so bad about that? There's no reason to worry so much about scoping of procs (which is what both Tk widgets and incr Tcl class instances become) most of the time.

If you want event handlers from another scope use the appropriate [code] to magicify the callback. As for stuff escaping scope, the incr Tcl local proc helps a bit with that.

Why you should not use Tcl

[Anonymous Coward]

Have everybody forgotten the TCL-war?

TCL vs Java

[Anonymous Coward]

People complain about Tcl's speed, but in many ways it is pretty quick.

I'm working on a Java front end to talk to a Tcl back end. The back end runs on a 100Mhz 486 w/ 32MB of ram.

To do the Java (develop it -- with Netbeans) I needed to find a 1GHZ+ Pentium box with 256 MB of ram (could use more). And you know what with all that the TCL application starts (from source, remember) much faster than the (compiled) java app. Apples to oranges in some ways, sure, but still...

Plus TCL has built-in associative arrays and lists (how in gods name did they leave this out of Java), better event handling, and you get the source!

-- ac at work

Re:TCL vs TK / Ousterhout bailing/ maintaining cod

[gorilla]

For a number of developers that I know and myself TK was the glitz and feature that drew me in. Otherwise I would have stuck with Perl.

You do realize that Tk is available now for many languages, including Perl?

Re:Some of the largest websites in the world use T

[hobbs]

The reason Tcl is the embedded language is that AOLserver was developed in the early nineties, when Tcl was the hot new language. If the system were to be developed today, I'm sure that the developers would have chosen Python, Perl or some other more buzzword compliant language that has a strong following.

Those who don't understand might presume this, but they are incorrect. Tcl would still be chosen again, as it has advantages other Perl and Python that make it ideally suited for that development. Tcl is the easiest to embed and extend, which is a core port of AOLServer's architecture. More importantly, Tcl is the easiest to learn and use, which is very important because the people creating these web pages are not computer scientists - they are web designers, page authors and the like.

Tcl, Beauty and LISP

[Borogove]

Anyone who wants to claim Tcl is as clean and beautiful as LISP should demonstrate a better Tcl implementation of this:

http://www.backroom.uklinux.net/lambda.tcl.txt

As far as I'm concerned, Tcl is great as a basic scripting language, but it isn't on a par with Python or Ruby for anything involving complicated data manipulation.

Re:Tcl, Beauty and LISP

[dkf]

Try looking at the Tcler's Wiki for a better solution to this.

Re:Tcl, Beauty and LISP

[Borogove]

No good - it relies on being able to define each combinator as a procedure in the global namespace. This provides no support for anonymous lamba expressions.

TCL and Javascript

[Rick BigNail]

Which is better as an "extention" language?

Both are equally powerful. Both are different from traditional language like C and pascal, so they both requires different thinking patterns.

TCL has better implementation and community support, but javascript is more popular and easier to learn.

It's a tough choice.

Re:TCL and Javascript

[dkf]

TCL has better implementation and community support, but javascript is more popular and easier to learn.

Easy. If you're going to operate inside a web-page/browser, use Javascript. Otherwise don't. Use anything else. Hell, use Java as an extension language instead of Javascript (and Java's not a good choice at all for that!)

Re:TCL and Javascript

[lvirden]

Are there really people extending desktop or server applications to use javascript?

I'd really be interested in reading more about this. When I read javascript code, I find it rather gruesome. However, the only javascript I've ever seen used was on web pages.

While using Tcl as a web page language is possible, it requires the user to download and install a plugin; that makes it less desirable to many people for extranet/internet applications.

For intranet, one can make it easier by pre-installing the plugin on the various in-house desktops.

Re:TCL and Javascript

[Rick BigNail]

Are there really people extending desktop or server applications to use javascript?

I want to know as well.

You could find open source javascript runtime by searching ecmascript and runtime on google.

I believe qtscript is based on ecmascript. Flash also use it for user scripting.

Re:Some of the largest websites in the world use T

[tsmoke]

That's technically true. But since Jim and folks originally built it as a product to sell, they probably would not choose Tcl because it would take a lot more work selling it.

Believe me. I know. I need to sell AOLserver all the time. I love doing it, but the bigotry and phobia against Tcl is a real hard climb.

If nsd used Perl or Python, it would be the toast of the /. world. For no other reason than buzzword compliance.

talli

Re:TCL vs TK / Ousterhout bailing/

[CresentCityRon]

Yes but my comment was circa '93-94. I don't think there was a port to Perl back then. So it was a very interesting library to have access to.