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.
  • by ziggy (25) on 2002.08.15 13:18 (#11802) Journal
    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 out what the differences were between the various OO extensions (some in pure Tcl, others requiring a new interpreter).

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

      • 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