in reply to Re: evil code of the day: global stricture control
in thread evil code of the day: global stricture control

I consider using Carp module only when needed useful, because Carp uses Exproter, which I really hate and try to avoid.

Another reason for such a dance is my own approach to bootstrap lightweight Perl+Tcl::Tk, much like PAR but without temporaries and with on-the-fly in-memory unzippings, where my first module (Tcl.pm) will not see anything, because perl library forest is not established yet.

  • Comment on Re^2: evil code of the day: global stricture control

Replies are listed 'Best First'.
Re^3: evil code of the day: global stricture control
by diotalevi (Canon) on Aug 02, 2007 at 13:58 UTC

    I'm guessing the chances you can get a perl process that has no Exporter.pm are zero to nil. I don't think your avoidance of Carp on the principle of also avoiding Exporter is sound.

    ⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

[reply]
      yes, Exporter in unavoidable.

      But, let me repeat my point, I have some bootstrap technique, and during first stage of bootstrapping no Exporter and Carp are available, so I must strip them out from Tcl.pm, which aims bootstrap.

[reply]

        Er, what? You're bootstrapping a build of perl then? Any perl that's been built is going to have those already and in fact ... if you can run perl code you can run either of those already. I don't get it.

        ⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

[reply]
Re^3: evil code of the day: global stricture control
by chromatic (Archbishop) on Aug 02, 2007 at 16:45 UTC

    The problem is that the patch to load Carp lazily actually added more code to the core than if the author had left well enough alone. Carp itself is tiny.

[reply]
      ... but your version always will read Carp.pm from disk, even when its not needed.

      We can discuss whether this optimization is premature or not, but sometimes avoiding Carp could be explained... somehow.

      Another example - when using DynaLoader elder Perl may times checked for $^O, like it could change during the run.

      There are Yin and Yang - some people stuck unneeded modules everywhere for the sake of imaginary improvement of code readability, others send optimization patches, because otherwise using innocent module will result in some tens of unneeded PMs loaded.
      It seems to me that if Ilya Zakharevich never send his optimization patches, then Perl could be as slow as Java...

[reply]
        We can discuss whether this optimization is premature or not...

        No, we can't. I never saw a profile, neither before nor after. All I saw was a silly knee-jerk argument that "OMG CARP IS TEH SLOOOOOOOW!" and a bunch of patches that added code that perl has to read from the disk, compile, and keep around in memory. There's absolutely no debate possible about whether this was a premature optimization.

        Any "optimization" without measurement is premature.

        It seems to me that if Ilya Zakharevich never send his optimization patches, then Perl could be as slow as Java...

        I don't know what that has to do with this subject, but I've achieved several very measurable optimizations by removing code and almost none by adding code.

[reply]
[d/l]

In Section Meditations