Well, I've started dabbling in Tcl. It's something I've been meaning to do for Quite Some Time Now.
I have to say that the experience, over all, has been very satisfactory and non-frustrating. That is, it has not been what I expected it to be!
The Scary Thing About Tcl, as Perl hackers are typically led to believe, is its Obnoxious Shell-like Whitespace-based Parsage. Also its Ubiquitous Symbolic References. And "Variable Scoping is Hacked and Twisted, so Use Global Variables For Your Mental Health".
But in practice, I find that Tcl has an elegant -- if imperfect -- consistency that is easy to program in. Yes, it's been a mental adjustment, but not a huge one.
One of the things I like about Tcl is its Lispiness. Essentially, square braces are eval'ed like lists in Lisp, and curly braces are like quoted lists. A block of code is just a block of terms that might (might!) get sent to the eval function. In fact, Tcl's syntax is extremely reminiscent of Lisp's. (One thing that's different is Tcl's (less than desirable) sensitivity to newlines.)
I also like Tcl's built-in support for event loops.
Basically what it boils down to is that all the things I've heard people say to try to scare me away from Tcl have turned out to be bogus.
That's not to say there aren't a few good reasons to continue using Perl... but mostly they're cultural, or community things. The one thing about perl that can be said to be qualitatively better, as a language, is that it is possible to write things much more tersely. Well, I'm sure there are others. I'm sure the Tcl regex engine hasn't kept up with Perl's, for example.
Are you using extensions, or just core Tcl[/Tk]?Basically what it boils down to is that all the things I've heard people say to try to scare me away from Tcl have turned out to be bogus.
When I last looked at Tcl (back in the days of 7.6, I think), I was quite turned off that there were so many different extensions, and that some extensions were basically a new environment with Tcl embedded in it (similar to expect). I was less than inclined to start learning/using Tcl when the first task was to sort out what the differences were between the various OO extensions (some in pure Tcl, others requiring a new interpreter).
Re:Extensions
jdporter on 2002-08-16T19:04:29
Well, I think it's safe to say that that's one aspect of Tcl-land that could stand some significant straightening out.
But letting that daunt one from climbing the Tcl learning curve makes about as much sense as being put off by Perl's alleged shortcomings. I believe that once one has been inculcated with Tcl-think, the range of available extensions may appear as an interesting landscape awaiting exploration. You say that your "first task was to sort out what the differences were between the various OO extensions", but I have to say, I don't believe that's true. Tcl has a core language, and lots of good things can be done with just the core.
A lot of what there was to dislike about Tcl when you looked at it has been fixed in version 8... but the plethora of extensions isn't one of them. And in this respect, as in so many others, Tcl is close kin to Lisp; and so I, for one, am not inclined to play up the importance of it.
One of the things I like about Tcl is that it, like Perl, has made no attempt to be paradigmatically pure. (This is the big reason why I'm not at all inclined the invest any time in Ruby or Python.) What Tcl *is*, that Perl isn't, is syntactically simple. It's not quite as simple as Lisp, but almost. As with Lisp (and perhaps this is a weakness), almost all semantics are implemented by "commands" (functions), which can come from anywhere, and so you get very little help from the language itself when you want to figure out what a statement means.
Re:Extensions
jordan on 2002-08-16T19:10:53
I first worked with Tcl back in in 1989 with Tcl 1.0. I ported Tcl 1.0 and 2.0 to VMS and used it for some projects.
I used it off and on through about 1995. Doing a fair amount of scripting work mostly. I did very little Tk.
I agree with jdporter, it's easy to be productive quickly.
The way I was most productive with Tcl was by using it as an extension language to APIs I was working with. That's why there's a myriad of extensions. Embedding Tcl in C and writing C to be called from Tcl is incredibly simple.
Unfortunately for the Tcl world, there was not enough behind any large subset of extensions to make up a standard library. There was/is TclX, on which I was credited with early development - but I actually didn't do very much, which was a Unix API extension set for Tcl. Much of that work was folded into later Tcl revisions.
The real killer was that there were numerous incompatible OO extension sets, so that a big set of classes and library could never be built up. I think that now, [incr Tcl] would be considered the dominant one. I never tried to put together a large app in Tcl, but I understand from those who have that things like [incr Tcl] are critical to success here.
In the Perl world, the OO features (deprecated as they may be) are not an extension set and there's normally no problem getting modules to work together.
I'm more productive today using Perl for the things I want to do today than I think I would be using Tcl. Supporting extensions written in C is easier in Tcl, I think, but, so far, all of the APIs I've needed someone else has done already. I've played with XS and I think I run up support for an API if I really needed it.
If I was interested in augmenting C/C++ APIs with an extension language for testing and development purposes today, I might look into lua. I've played with lua some and it seems interesting. The language itself is extensible through a facility which allows your program to catch what would be considered syntax errors (without your extensions) and call your own functions based on the new syntax. Looks easy to integrate with C/C++, too.
Re:Extensions
ziggy on 2002-08-16T19:28:05
If we're looking at Perl as a successful ecosystem that doesn't have Tcl's problems, I'm not so sure that the standard library is the biggest failing of Tcl. Without getting into semantic wars, I don't think I would put DBI, LWP, and Inline in Perl's "standard library". CPAN is fundementally different from something like java.lang.* and java.util.*.Unfortunately for the Tcl world, there was not enough behind any large subset of extensions to make up a standard library.Could it be that the answer is even more basic? That Tcl failed to thrive because it was too easy to create extensions, but too difficult to share them? That is, Tcl was so easily embeddable, but never adequately addressed the issue that XS does for Perl: embedding something compiled into the core environment? That could also explain why something like [incr Tcl] dominates the Tcl OO space...
Re:Extensions
jordan on 2002-08-17T02:20:46
- Without getting into semantic wars, I don't think I would put DBI, LWP, and Inline in Perl's "standard library". CPAN is fundementally different from something like java.lang.* and java.util.*.
The term "standard library" was unfortunate. I guess what I really meant was that there was no CPAN. No body of code that can be fitted together to build applications.
There is a lot of Tcl code out there, but fitting it together is about the same as fitting together C libraries into applications. Possible, certainly, but involving some work.
- That is, Tcl was so easily embeddable, but never adequately addressed the issue that XS does for Perl: embedding something compiled into the core environment?
You could say that any Tcl extension is built into the core environment. It's just that this new extended environment is no longer the "core" environment and it takes work to integrate this extended Tcl with other extensions.
I think I remember reading somewhere that Ousterhout thought that OO was way overrated and that it wasn't even necessary for graphics programming. This was heresy in the late 80's, but he went on to prove how much powerful graphics programming you could do with Tk without a real OO environment. (You could argue that Tk uses objects, but that's just because it manipulates Widgets in X which are objects. Programming in Tk is pretty much straight procedural.)
I'm not unsympathetic to the view that OO is oversold and far from the panacea that it's made out to be. However, the thing that you don't have if you don't go to the trouble of trying to make a full OO environment is good namespace management and modularization/extension (Class Hierarchies). Perl's modules/packages provide a framework for building CPAN whether you use OO or not. [incr Tcl] provides much of this, but the code available for [incr Tcl] is a small subset of the code available for Tcl in general, and both pale in comparison to CPAN.
When Larry (and others) designed Perl 5 to have "full" OO, what they inadvertently invented was all the infrastructure that made CPAN possible.
Part of the Perl win is in the community that built CPAN (and all the other on-line resources, including tutorials, FAQs, etc.) and part of it is the infrastructure that allows things like CPAN to be built meaningfully.
