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 sim

      • by ziggy (25) on 2002.08.16 14:28 (#11861) Journal
        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 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...

          • 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