Tcl Core Team Interview 191
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.
I get it... (Score:4, Funny)
Maintaining TCL (Score:5, Funny)
Re:Maintaining TCL (Score:2, Interesting)
You can check out an HTMLized version here:
http://tcl.apache.org/sources/tcl/
Re:Maintaining TCL (Score:5, Interesting)
Re:Maintaining TCL (Score:2)
Re:Maintaining TCL (Score:3, Informative)
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 (Score:2, Informative)
Pass-by-name is still cool (Score:5, Interesting)
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 (Score:5, Interesting)
Re:Pass-by-name is still cool (Score:3, Insightful)
How exactly does P-B-N make recursion and package scoping any easier than it is in a decently designed language?
huh? (Score:3, Insightful)
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.
Download from here! (Score:4, Funny)
Look here [activestate.com]:
Geez, some people. Oh yeah, get the crack yourself.
Re:Download from here! (Score:2, Informative)
Re:Download from here! (Score:2)
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 (Score:1, Funny)
What an informative table of contents! (Score:3, Informative)
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 [osnews.com]
Tcl does not suck (Score:5, Interesting)
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 (Score:3, Interesting)
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 (Score:2)
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 (Score:2)
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 (Score:2, Informative)
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 (Score:2, Insightful)
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 (Score:2)
But what the hell do I know. I code VB. Eugh.
Re:Tcl does not suck (Score:2)
Re:Tcl does not suck (Score:2)
This economy is making smart people do funny things.
C++ (Score:2, Interesting)
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:Tcl does not suck (Score:2)
Re:Tcl does not suck (Score:2)
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 (Score:2)
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 (Score:2)
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.
not really multiple data types (Score:2)
Re:not really multiple data types (Score:2)
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 [lispworks.com] function), dispatch on them using typecase and etypecase [lispworks.com], 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 [lispworks.com], or "declare [lispworks.com]" 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 [cons.org] and SBCL [sourceforge.net] 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.
Re:Tcl does not suck (Score:5, Insightful)
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 [mini.net] and they're even keeping tabs on who says Tcl sucks [mini.net] and why.
Re:Tcl does not suck (Score:2)
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 (Score:2)
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 (Score:2)
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 (Score:2)
Re:Tcl does not suck (Score:2)
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:
Well, that's my 2c.
Re:Tcl does not suck (Score:2)
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 (Score:2)
Those who don't understand UNIX are doomed to reinvent it, poorly.
--Henry Spencer
Re:Tcl does not suck (Score:2)
those who can't handle LISP parens are doomed to reimplement it, with a different syntax
Re:Tcl does not suck (Score:2)
Then again, there has to be some reason why people invent and use Python or Dylan.
Tcl in the Mars Explorer project! (Score:4, Interesting)
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 [cornell.edu]. Any more info would be appreciated!
Re:Tcl in the Mars Explorer project! (Score:3, Insightful)
Re:Tcl in the Mars Explorer project! (Score:1)
Re:Tcl in the Mars Explorer project! (Score:2)
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)
TCL in real life (Score:5, Interesting)
<Shameless Plug>Check out TPOP [networkhackers.com]!</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...)
More TCL in real life (Score:2, Informative)
Ayam 3d [ayam3d.org] (3D modeling package)
Source-Navigator [sourceforge.net] (Source code browser and more)
Insight [redhat.com] (gdb GUI)
Re:TCL in real life (Score:1)
Also, a lot of Cisco routers run Tcl.
Oh, and so does AOL, with AOLserver.
And when they found out they were on slashdot..... (Score:4, Funny)
I knew it! (Score:2, Funny)
Everybody needs it... (Score:1)
I am not lesdyxic!!!
Is Tcl the new COBOL? (Score:3, Insightful)
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? (Score:1)
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? (Score:2, Insightful)
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 [aolserver.com].
So yes, it is used quite heavily.
talli
Re:Is Tcl the new COBOL? (Score:1)
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? (Score:2, Interesting)
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? (Score:2)
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.
they must be doing something right (Score:4, Insightful)
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 (Score:2)
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 (Score:2)
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 (Score:2)
Re:they must be doing something right (Score:2)
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.
TCL vs TK / Ousterhout bailing/ maintaining code (Score:5, Interesting)
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.
Re:TCL vs TK / Ousterhout bailing/ maintaining cod (Score:2, Insightful)
Re:TCL vs TK / Ousterhout bailing/ maintaining cod (Score:3, Insightful)
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 (Score:3, Interesting)
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.
Re:TCL vs TK / Ousterhout bailing/ maintaining cod (Score:2)
You do realize that Tk is available now for many languages, including Perl [cpan.org]?
Re:TCL vs TK / Ousterhout bailing/ (Score:2)
hmm (Score:1)
Re:hmm (Score:2)
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 (Score:4, Informative)
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.
Your most unusual Tcl application (Score:1)
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 (Score:1)
Re:Your most unusual Tcl application (Score:1)
Re:Your most unusual Tcl application (Score:2, Interesting)
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 (Score:5, Informative)
Tcl runs the operator interface of Shell Oil's Auger, a drilling rig in the Gulf of Mexico. See pictures of the rig here [shellus.com], and read about the system integrators here [cpu.com].
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 [www.tcl.tk].
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 [usenix.org] all the way to full 24x7 operation [usenix.org]. ComputerWorld [computerworld.com] ran an article [computerworld.com] about the project.
Science geeks will be interested that a Tcl interface is used to program the Hubble Space Telescope [noao.edu]
Database heavies will be intrigued by the intimate role that Tcl has in Oracle Enterprise Manager. [orafaq.org]
I could go on all evening, this is just the tip of the proverbial iceberg.
Re:Your most unusual Tcl application (Score:3, Interesting)
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.
Learning TCL (or others) (Score:4, Interesting)
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).
Friendly user comunity (Score:1)
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.
Re:Learning TCL (or others) (Score:1)
Re:Learning TCL (or others) (Score:1)
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) (Score:3, Informative)
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 [atdor.com], 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.
I love TCL (Score:2)
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 (Score:2)
Quote from Interview (Score:2, Funny)
"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.]AOLServer (Score:2, Informative)
Nice but ... (Score:3, Insightful)
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 ... (Score:2)
Tcl and Perl (Score:2, Interesting)
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 (Score:2, Funny)
Re:Tcl and Perl (Score:2)
Some of the largest websites in the world use Tcl (Score:3, Informative)
This is because they use AOLserver [aolserver.com] which is a massively scaleable and powerful web application server. Some of its features are:
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) [openacs.org] 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 [mit.edu] 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
Re:Some of the largest websites in the world use T (Score:2)
what TCL is good for (Score:2, Insightful)
By the way, check out GVI [electionmethods.org], the Graphical Voter Interface, which I wrote in TCL/TK.
What is wrong with a minimal core language? (Score:4, Interesting)
Re:What is wrong with a minimal core language? (Score:2)
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? (Score:2)
It's definitely incremental. Here's how you instantiate a class in [incr tcl], straight from the manpage:
fileselectiondialog
This creates a fileselectiondialog with the path
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? (Score:2)
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] [activestate.com] to magicify the callback. As for stuff escaping scope, the incr Tcl local [activestate.com] proc helps a bit with that.
Re:I don't get it (Score:3, Interesting)