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.

Didn't We Use The Phrase "Reverse Sublimation" a While Ago? 16 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • ... is a reality check! The way you think people perceive the Perl6 development just isn't the way the world works. Scientifically everything's going well and correct but it will never work with the people you want to persuade that Perl6 is coming along nicely and is a thing to watch. Please stop bashing people for criticizing the Perl6 development, chromatic! I understand that you're putting your heart and soul and a lot of work in it but criticism still is a good thing and in the case of Perl6 it's really

    • A reality check?

      If you (or perladmin or anyone else) want to give the Perl6 devs such a thing, then there are lots of better ways of doing this than commenting the bikeshed colour.

      1) Fix your pet peeve in the source code. Don't like the lack of an install-base on Debian? Make some .deb's and work to get them included in the official Debian repositories. Don't like the lack of contributors? Start recruiting - make people excited about the language.

      2) Start playing with Perl 6 to see if it's really as good as

      • What if I just want to create apps without having to dive into the guts of my favourite language's next version? Not every developer loves poking around at such a low level and I'd like to leave this to the ones who know and love this stuff. I don't think many PHP/Python/Ruby (and Perl) programmers developing popular high-volume web sites participate in developing the next version of their language, do you? What do you think how many construction workers build their own jack hammer? ;-) I didn't mean to diss anyone and have high respect for every perl6 developer. But just ignoring (or bashing against) all this "perl5 is dying and perl6 is vapourware" stuff is dangerous IMHO because it shows what perl is missing the most: a face and a positive image. Not solely some super awesome stuff going on deep in the guts that sends chills down every comp-sci's spine.
        • What souldchild said. I have been trying to follow the development of Perl 6 and, not having a comp-sci background (I'm an engineer), most of it was gobbly gook to me. For instance I have not idea what any of this means:

          Better internals? Pervasive OO? Mutable lexical grammars? Working exceptions? NCI? Macros? JIT? Bytecode? Grammars? Serializable continuations? Multidispatch? STM? Hyperoperators? Pervasive laziness? Immutable sigils? True reference context? Aliasing and binding? Few globals? A robust pars

          • But of course the real question is: if you are not willing to spend the few hours to research what these things are, and how they would benefit your work, why --pray-tell-us-- should anyone be even slightly interested in what you have to say on the matter of Perl6 development?

            [[Side question: do you really not know what "Better internals" means? "A robust parser"? "Macros"? "Working Exceptions"? Hmm...]]

            There's a lot of pushme-pullyou going on in this comment thread: on the one side chromatic wants to push

            • the real question is: if you are not willing to spend the few hours to research what these things are, and how they would benefit your work, why --pray-tell-us-- should anyone be even slightly interested in what you have to say on the matter of Perl6 development?

              Ah, is that the real question? I was wondering.

              Maybe you should be slightly interested because he's a human being, and it might be beneficial not to marginalize [wikipedia.org] and trivialize him? Or because you can't predict where the black swans [wikipedia.org] might come from

              • Once in a while a disinterested, uninformed (not meant pejoratively) observer makes a brilliant observation which transforms a field of study. For every one of those, you have to put up with most of a million Time Cubes. (I can think of a few people in this discussion who've written about why those features matter and why anyone should care, not that some people have bothered to look -- nor apparently even ask.)

                That's a nice segue to let me be unequivocably clear about the singular thesis of this journal

            • do you really not know what "Better internals" means?

              LOL! Could this be any more vague?

              • Fine, let me spell it out for you.

                Perl 5's internals are a mess of poorly documented and often intrinsically contradictory features implemented as mazes of macros calling macros calling macros and pseudo-OO C code implemented as semi-isomorphic structs. There's little distinction between an internal and an external API, and it's almost completely unknowable if changing any part of the API will break the guarantees of backwards source compatibility that p5p tries to maintain even between stable major releas

                • As an example of that, I proposed that “length undef” should silently return undef rather than returning 0 after warning about undef. Rafaël took a first short at implementing this, but it broke thousands of tests, which puzzled him. Nicholas spotted the problem quickly, but it took him an extended tracing session to figure out where all he needed to stick flags in order to make disparate parts of the guts work together so that this would work as specified. When it takes Nicholas and half a

                  • In Perl 6, if length were written in Perl 6, we'd add another multi variant for the undef case. It's two SLOC. If length were written in PIR, it's four or five SLOC. Either way, it's trivial code.

                • Yes -- sorry to have raised the temperature of this discussion.

                  I agree that they're painfully complex. I have the git clone of the blead repository sitting on my disk as we type. But I think one of the things Perl 5 teaches is the value of staring complexity in the face and beating it to death with the available blunt instruments. Starting over always feels great -- I love doing so with my own code -- but there are reasons that perl5, like many other mature pieces of software, is so ugly. And it will ta

                  • there are reasons that perl5, like many other mature pieces of software, is so ugly.

                    Many of those reasons, in the case of Perl 5, are very bad reasons though. The biggest problems are the lack of a specification beyond "What someone discovers that the implementation has been doing for several years" and a lack of encapsulation.

                    I reserve judgement about whether it's better enough to make up for perl5's maturity.

                    That's fair. I believe it will be, but that doesn't happen overnight, and it doesn't happen

                    • The two main reasons for ugliness I'm talking about are weird platform issues and non-obvious cases where some language behavior makes more sense. It's almost impossible to anticipate these things, so you just have to spend years tripping on and fixing them.

                      I think Perl 6 has an advantage in uncovering these things because of its heritage, but it's far from automatic.

                    • But those are not the reasons why the Perl 5 interpreter codebase is so convoluted.

                    • *Sigh*

                      My point is that being cross-platform is necessarily ugly, and that it takes time to acquire the warts.

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.