Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • 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.

    Are you using extensions, or just core Tcl[/Tk]?

    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

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

      • Unfortunately for the Tcl world, there was not enough behind any large subset of extensions to make up a standard library.

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

        Could it be that the answer is

          • 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, c