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

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