Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

Tcl Core Team Interview 191

Posted by CmdrTaco from the tcl-me-donal dept.
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.
This discussion has been archived. No new comments can be posted.

Tcl Core Team Interview More

Tcl Core Team Interview

Comments Filter:

  • I get it... (Score:4, Funny)

    by AEton ( 654737 ) on Monday March 10, 2003 @08:02PM (#5481070)
    how they came to maintaining TCL and so forth.
    That's a pun! Tee hee.

  • Maintaining TCL (Score:5, Funny)

    by TOOSuave ( 610521 ) on Monday March 10, 2003 @08:04PM (#5481088)
    I hope maintaining TCL is easier than maintaing projects written in TCL...
    • 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 (Score:5, Interesting)

        by hobbs ( 82453 ) on Monday March 10, 2003 @09:27PM (#5481631)
        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 [acm.org]. It's a level of code cleanliness that many systems just dream of.
        • 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 [acm.org], 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!)
    • 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 (Score:2, Informative)

        by lvirden ( 6151 )
        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 (Score:5, Interesting)

    by ObviousGuy ( 578567 ) <ObviousGuy@hotmail.com> on Monday March 10, 2003 @08:13PM (#5481156) Homepage Journal
    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 (Score:5, Interesting)

      by Inode Jones ( 1598 ) on Monday March 10, 2003 @09:09PM (#5481464) Homepage
      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.
    • 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?

    • huh? (Score:3, Insightful)

      by Trepidity ( 597 )
      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.

  • Download from here! (Score:4, Funny)

    by Anonymous Coward on Monday March 10, 2003 @08:18PM (#5481185)
    I couldn't believe all the questions before you can download this stuff!
    Look here [activestate.com]:

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

    • Re:Download from here! (Score:2, Informative)

      by dkf ( 304284 )
      If all you want is the source, just grab it from SourceForge [sf.net]. 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.
  • You won't be able to see this post for two minutes anyway.

  • What an informative table of contents! (Score:3, Informative)

    by LeninZhiv ( 464864 ) on Monday March 10, 2003 @08:22PM (#5481205)
    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 [osnews.com] .

  • Tcl does not suck (Score:5, Interesting)

    by Anonymous Coward on Monday March 10, 2003 @08:23PM (#5481215)
    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)

    • 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.
      • 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?
        • > 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 (Score:2, Informative)

            by ofgencow ( 51564 )
            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 (Score:2, Insightful)

        by tallniel ( 534954 )
        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.
    • 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.
      • 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.

    • C++ (Score:2, Interesting)

      by pyrrho ( 167252 )
      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.
    • TCL has not had one data type since arrays arrived.
    • 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.
      • 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.
        • 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).
          • Common Lisp has a hierarchy of types starting with t [lispworks.com], the general type. Its subtypes include number [lispworks.com], integer [lispworks.com], fixnum [lispworks.com], string [lispworks.com], cons [lispworks.com], list [lispworks.com], array [lispworks.com], hashtable [lispworks.com], function [lispworks.com], 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 [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)

      by Eil ( 82413 ) on Tuesday March 11, 2003 @01:07AM (#5482613) Homepage Journal

      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.
      • 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.

      • > 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) =.

        • 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.

    • 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.

  • Tcl in the Mars Explorer project! (Score:4, Interesting)

    by $$$$$exyGal ( 638164 ) on Monday March 10, 2003 @08:26PM (#5481235) Homepage Journal
    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 [cornell.edu]. Any more info would be appreciated!

  • TCL in real life (Score:5, Interesting)

    by dmayle ( 200765 ) on Monday March 10, 2003 @08:34PM (#5481271) Homepage Journal

    <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...)

  • I knew it! (Score:2, Funny)

    by t0ny ( 590331 )
    I always said TLC didnt write their own music!
  • Everybody needs some TLC

    I am not lesdyxic!!!

  • Is Tcl the new COBOL? (Score:3, Insightful)

    by JLyle ( 267134 ) on Monday March 10, 2003 @08:54PM (#5481384) Homepage
    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?
    • 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.
      • 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 [aolserver.com].


        So yes, it is used quite heavily.


        talli

    • 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.
    • 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.
    • 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 [xotcl.org] 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.

  • they must be doing something right (Score:4, Insightful)

    by g4dget ( 579145 ) on Monday March 10, 2003 @09:07PM (#5481450)
    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.

    • 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.

      • 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.

        • 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 [activestate.com] 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.
          • 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.

  • TCL vs TK / Ousterhout bailing/ maintaining code (Score:5, Interesting)

    by CresentCityRon ( 2570 ) on Monday March 10, 2003 @09:08PM (#5481458)
    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.
    • 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.
    • 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 $$$.

    • 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.

    • 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 [cpan.org]?

  • hmm (Score:1)

    by ergonal ( 609484 )
    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 (Score:2)

      by lewp ( 95638 )
      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 (Score:4, Informative)

    by zapatero ( 68511 ) on Monday March 10, 2003 @09:12PM (#5481506) Journal
    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.
  • 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.

    • A content-management system that ran Ampex robotic tape drives.
    • #!/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" } }
    • #!/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 (Score:5, Informative)

      by kennykb ( 547805 ) on Monday March 10, 2003 @10:09PM (#5481849)
      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 [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.

    • 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.

  • Learning TCL (or others) (Score:4, Interesting)

    by DarkMan ( 32280 ) on Monday March 10, 2003 @09:18PM (#5481561) Journal
    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).

    • 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.
    • 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.
    • 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 [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.

  • 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.

  • "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)

    by 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).

  • Nice but ... (Score:3, Insightful)

    by wayne606 ( 211893 ) on Tuesday March 11, 2003 @12:05AM (#5482382)
    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.
    • 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 [www.tcl.tk]. 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.

  • Tcl and Perl (Score:2, Interesting)

    by Continental Drift ( 262986 )
    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.

    • So you like Perl's reference syntax better? Wierd.
    • 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 (Score:3, Informative)

    by tsmoke ( 455045 ) on Tuesday March 11, 2003 @01:56AM (#5482749)
    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 [aolserver.com] 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) [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

    • 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.

  • what TCL is good for (Score:2, Insightful)

    by RussP ( 247375 )
    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 [electionmethods.org], the Graphical Voter Interface, which I wrote in TCL/TK.

  • What is wrong with a minimal core language? (Score:4, Interesting)

    by patthoyts ( 598899 ) on Tuesday March 11, 2003 @05:13AM (#5483170) Homepage
    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.

    • 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.

    • > 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...

      • 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.

Slashdot Top Deals

Math is like love -- a simple idea but it can get complicated. -- R. Drabek

Close