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.
  • How many useful development tools are we willing to sacrifice (making development harder) in order to make development "easier".

    I'd have some sympathy if there were any chance of getting (for example) function signatures, the method keyword, or the class keyword into Perl 5 this side of the heat death of the universe, but that's not going to happen because "that would make maintaining existing code harder".

    • You know, that's funny, because working method signatures in Perl 5 are one of my new favourite things.

      use MooseX::Method::Signatures;
      method morning (Str $name) {
          $self->say("Good morning ${name}!");
      }

      • Which demonstrates my point that there will be an increasingly widespread use of source filters... (I'm assuming that's what that it implemented using).

        • Nope, MooseX::Method::Signatures is Devel::Declare and a heaping spoonful of other magic.

          • ... and Devel::Declare is a source filter, albeit (as peregrin put it on #p5p) "keyhole source filters".

            • While its true DD and traditional source filters both change the source code, it is unfair to simply lump DD in with source filters. "Source filter" is a dirty word. DD does not share the traditional problem with source filters, that of trying to parse Perl and their global nature. For example, a source filter might decide to alter code-like strings and regexes. DD won't be fooled by that. It gets around this problem by (ab)using Perl's own parser.

              DD brings in its own bag of problems, but calling it a

              • I agree that it does not share some of the side-effects, and the level of collateral damage is greatly reduced.

                But it still makes arbitrary changes to the lexical structure of the language. From a static parsing point of view, THAT is the critical problem here.

                The problems with collateral damage are only a problem from the point of view of an executing parser.

      • I meant in the Perl 5 core.

  • And now the primary interface to Moose is using D:D or something like it ...

    Actually, MooseX::Declare is just another way to use Moose, but very surely not the primary.

    Many people are using MooseX::Declare, and find it very nice and elegant, but many others (myself included) are not willing to use MooseX::Declare or Devel::Declare in production because it is not yet mature enough. Personally, my reasoning is that I feel it still exposes too much internals when it errors and makes for some difficult d

    • I have to agree with chromatic, the language itself cannot be a test bed for experimentation....

      I agree, but that's not my main point here.

      It is a mistake to canonize features before they're ready, unless you have some mechanism of indicating that they may change in subsequent releases. No one wants the chaos of frequent churn.

      It's also a mistake, possibly more severe, to refuse to add features widely-requested and often reimplemented in subtly incompatible ways.

      Having D::D available with core support is

    • I've updated the post to remove the suggestion that the CURRENT Moose API is D:D, or that it is specific to just Moose

  • I seem to recall something Nat said in his "What's With Those Python Fucks Anyway?" rant that "circles should be square so they're easier to draw and measure".

    While I sympathize the the folks that write tools to do static analysis of Perl code, it seems rather putting the cart before the horse to restrict language development to serve those tools. It should be the other way around. It would be nice if we had formal Perl 6 style grammars to make life easier for the toolsmiths, but I'm not holding my breath

    • While I sympathize the the folks that write tools to do static analysis of Perl code, it seems rather putting the cart before the horse to restrict language development to serve those tools.

      If you could create the best language in the universe, but it could only be written using Notepad (or an equivalent), would anyone actually use it?

      Support for good toolchains appears to be correlative with the success of a language (although proving this, and then further proving causality, would be an interesting exerci

      • If you could create the best language in the universe, but it could only be written using Notepad (or an equivalent), would anyone actually use it?

        Sadly, yes. A less panicky question would be to say if you could do without syntax highlighting and indentation, which is really all the Perl specific stuff I use. I'd miss indentation, but syntax highlighting I can live without.

        That said, its not EITHER we have tools OR we get to play with the language. The tools have already had to reverse engineer the entir

  • Considering this:

    my $arrayref_of_hashes = SELECT * FROM table_name;

    I think it gains me nothing. Nothing at all.

    Considering this:

    method morning (Str $name) {
        $self->say("Good morning ${name}!");
    }

    If I can get that (amongst other things), I will cheerfully give up:

    • No/degraded syntax highlighting.
    • No/degraded PPI parsing.
    • No/degraded shiny Padre refactoring tools.

    Different people value different things. I'd hate to give up the items on that list, but I'd much prefer to work with a program

    • That's why D::D should only be a prototyping tool and eventually such features should be available from the core.

      Note, however, that making the new syntax available with a "feature" invocation carries virtually the same problems as D::D. You never know from static analysis (and non-recursive) whether it's on or not. But at least this would mean it's blessed and to be considered part of the language.

      • Well, the difference with use feature is that at least in that case it's official, in the core, works the same on every operating system and every host, and doesn't require the parser to leave the document.

        So it's possible to add the relevant special casing in, where in the generic DD case that is not true.

        • Not really. Consider Modern::Perl, common::sense, and their ilk. And besides the ones on CPAN, any codebase can contain its own equivalent. Sure, you can special-case strict.

    • That example of MooseX::Declare like code is well intentioned but I (personally) think *horrific* for proving your point.

              function morning (Str $name) {
                      say "Good Morning $name"
              }

      This won't piss off the people who think you're pushing OO at them.

      • Both can be made available, but don't forget that Perl doesn't really know the differences between functions and methods. That being said, I want a modern language and P5P is too conservative to provide that to me. Regrettably, they may be right.