Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much
 
PerlMonks  

Modern Perl and the Future of Perl

by chromatic (Archbishop)
on Dec 20, 2007 at 19:22 UTC ( [id://658216]=perlmeditation: print w/replies, xml ) Need Help??

Max K-A is one of the Bugzilla hackers. You might remember him from The Problems of Perl: The Future of Bugzilla, where he described some of the maintainability problems that Bugzilla faced. After some discussion, he's updated his thoughts in Ooh, I Made Coding Horror (Coding Horror unfortunately drew the wrong lessons from Max's post). Here's one particular insight worth discussing:

Perl isn't fundamentally flawed, but it's kind of flawed in practical terms, in the way that it's commonly used. Imagine that you had a book that taught you how to write, and then after you were done with it, somebody had to come up to you and say, "Okay, that's not really how you write. I mean, you could write that way, but everybody would laugh at you. Also, you can't use that pencil, you should use this special pen, because it makes life a lot easier." There's nothing wrong with the language you're using to write, but there is something wrong with the instructions you were given and the tools you were handed.

Given the recent release of Perl 5.10 (and plenty of nice new improvements), the success of modules such as Perl::Critic and niceness of Moose, and the (finally!) mercy killing of Perl 5.005, how can Perl programmers in the know transfer knowledge of all of the wonderful new features that the admittedly voluminous Perl documentation in the wild doesn't mention.

That is, when can the rest of the world start using wonderful new techniques, idioms, and features that have come around in the past couple of years?

Replies are listed 'Best First'.
Re: Modern Perl and the Future of Perl
by stvn (Monsignor) on Dec 20, 2007 at 21:22 UTC
    ... how can Perl programmers in the know transfer knowledge of all of the wonderful new features that the admittedly voluminous Perl documentation in the wild doesn't mention.

    Well, perl.com has been pretty silent of late, aside from the recent State of the Onion, the last major article was September 21st! I was actually starting to worry that maybe you had lost your job or something :)

    Also, the perl.org website is not just ugly, but it is sooooooo 1996 it hurts, all that is missing is a hit-counter and a link to the guestbook. Compare it to python.org with it's cute little icon of snakes having sex. Or the ultra-sexy-web-2.0-compatible ruby website, whose rounded corners and clean typography alone tells me that ruby hackers get laid much more often than any other language hacker, Nuff Said! On the up side, at least we are cooler than TCL, cause that would be really lame.

    And while I hate to say it, the "Perl 6/Parrot is vaporware" thing is a problem. Those in the know, know that that is bullshit, but for the rest of the interweb it's just an easy way to shoot down anything about Perl.

    I guess my point is that we need a major overhaul of the Perl "image" to more accurately reflect what "Modern Perl" is and can be.

    -stvn
      And while I hate to say it, the "Perl 6/Parrot is vaporware" thing is a problem.

      I think petdance was on the right track when he encouraged more people to add their journals to places like Technorati to improve the amount of Perl information disseminated, and Perl Buzz is a good thing.

      We release a new version of Parrot every month. Getting other people to talk about that would be nice.

      Patrick and I talked a bit yesterday about how to bundle up the nascent perl6 compiler in Parrot into something installable and standalone, and I think we have a good solution there that we can implement in a couple of afternoons, when we both get some time off.

      I know lots of people who are not Ovid and perrin and stvn will read this and never say anything, but what you can do to help is talk to your friends and colleagues about all of the cool stuff that we (collectively, because that includes you) are doing. If you talk about it online in your journals and weblogs or other forae, so much the better.

        Your logic is weak. Okay there is a release of parrot every month, but that provides no prove that perl 6 is not a vaporware. How many more years you have to fight others with words instead of codes - a final release of perl 6 if there ever will be one?

          A reply falls below the community's threshold of quality. You may see it by logging in.
          A reply falls below the community's threshold of quality. You may see it by logging in.

      ++

      It is embarrassing that the granddaddy of dynamic languages looks like a granddaddy.

      (Yeah, I know we weren't the first, but we paved much of the way)

      Cheers,
      Ovid

      New address of my CGI Course.

        It is embarrassing that the granddaddy of dynamic languages looks like a granddaddy.

        It is so true! I mean even the LISP guys (the original crotchety old programmers) are getting a makeover. Meanwhile we are all still rolling our 20-sided die and stroking our RMS beards complaining that Matts Script Archive ruined it for us all. It's time we shaved that beard into a soul-patch and took up snowboarding or something!

        -stvn
      A reply falls below the community's threshold of quality. You may see it by logging in.
      A reply falls below the community's threshold of quality. You may see it by logging in.
      ++

      This really needs to happen. It keeps coming up over and over. Yet it doesn't change. Can we raise money and pay a design firm to do this for us? Or trade them for Perl development?

      But this site is not quiet, 5.10 made some people OD, although quite unneccessarily. If anyone expected 5.10 to make a difference, it won't.

      At my level, I only look at the big picture, and the question that I asked myself was whether 5.10 would sway some non-perl guys. My answer is no! So calm down.

Re: Modern Perl and the Future of Perl
by perrin (Chancellor) on Dec 20, 2007 at 20:32 UTC
    I think it's the usual suspects: write articles demonstrating how nice the stuff is, and get them run in Linux-oriented magazines, Oreillynet.com, and other places people go for new tech info. Get them Slashdotted.

    The only other thing that comes to mind is branding. There's an oft-repeated story about how the most hated phone company PacBell changed its name to Verizon in order to dump the old brand's stigma. Some kind of new designation for modern Perl + modern coding practices (strict, Perl::Critic, perltidy) + quality modules could work. Attempts so far (P5EE) have not gotten anywhere in part because they were too small and had little community support, or had unclear goals. A pure re-branding effort is possible. A recent example with different goals might be Strawberry Perl.

      Attempts so far (P5EE) have not gotten anywhere in part because they were too small and had little community support, or had unclear goals.

      Yes, speaking of "branding" problems, P5EE is a nice idea, but I'm afraid it's a terrible name, guaranteed to be uninspiring to perl programmers. Almost by definition perl programmers are people who don't want to be Java programmers, and are likely to be lukewarm on the idea that perl needs to be more like Java.

      (P5EE has a nice list of recommended perl modules: P5EE Components... I sometimes toy with the idea of creating a perl-centric linux distro, where all the P5EE modules would be installed by default).

      There's an oft-repeated story about how the most hated phone company PacBell changed its name to Verizon in order to dump the old brand's stigma.

      That's a couple thousand miles off! When BellAtlantic and GTE merged the name chosen for the new company was "Verizon". See the Verizon Wikipedia article for more.

        Oh, I think you're right, it was a different phone company. Possibly AT&T changing its name from Southwestern Bell?

      I think it would be worth your rolling this into a separate meditation. We all have this skill, coding Perl, and it is to the benefit of everybody if that skill is well respected.

      Last night I did something I thought was awesome with Perl, but you know what? I didn't tell anybody about it. I didn't mention it to fellow programmers, blog about, any of that. Mostly because I didn't think about it.

      A big friendly reminder to promote neat things done in Perl would be nice :).

Re: Modern Perl and the Future of Perl
by kyle (Abbot) on Dec 20, 2007 at 20:36 UTC

    Reading the replies of the other monks, I see that they've thought something similar to what I thought (but they've said it better). My third edition Camel Book says "July 2000" inside the cover, and it's still the first thing I'd recommend to someone who wants to know Perl.

    So: update the bible. Write a new one, maybe. This seems obvious to the point that it leads me to a question.

    Is this answer not obvious to chromatic? If not, why not? Being a published author (I have Perl Hacks on my bookshelf too), perhaps chromatic knows something about the limits of this solution that the rest of us monks do not. Would it be out of date again when it's done? Do the people with the Right Stuff to do the work have better things to do?

    The state of Perl documentation reminds me of something someone else said a long time ago in a forum far far away. Give a man a fish, teach a man to fish, sure. Give a man a book about the ecological systems of rivers, lakes, oceans, and other bodies of water, and he will starve to death before he figures out how to fish.

      Do the people with the Right Stuff to do the work have better things to do?

      Larry will speak for himself if necessary, but I have the strong impression that he prefers describing Perl as it is and leaving plenty of room for other people to build nice things with it and share how to build nice things with it.

      Besides that, his brain is full of Perl 6 these days, so if there's a new Camel, I expect to see that instead of a Perl 5.10 or 5.12 version.

        I prefer that Larry keep his attention on Perl 6, but it would be so nice to see an updated Camel Book. Maybe other people could take up the burden of writing and he could have a more supervisory role. I don't know, but folks do need to be aware that Perl's still alive and kicking hard. I know that people whose experience is limited to "I wrote a bunch of Perl scripts" 5-10 years ago are consistently amazed at what can be thrown together with a few CPAN modules.

        Besides that, his brain is full of Perl 6 these days, so if there's a new Camel, I expect to see that instead of a Perl 5.10 or 5.12 version.

        But Larry is not the only author of the Camel, and I would hope that Randal is whispering in Tim O'Reilly's ear about how perl 5.10 deserves a new book all on it's own.

        Though if the idea is that we need to promote a new, updated, style of perl programming, obviously that's what "Perl Best Practices" is about.

      A reply falls below the community's threshold of quality. You may see it by logging in.
Re: Modern Perl and the Future of Perl
by gamache (Friar) on Dec 20, 2007 at 19:42 UTC
    I see a disconnect between the blockquote and your question. The blockquote discusses the practical pitfalls of using a language with as little style enforcement as Perl, and you ask when we can start using convenient, new-ish features rather than restricting ourselves to old Perl.

    I do not believe that Perl's newer features, while wonderful in their own right and supportive of good programming practices, will eradicate the problem traced in the quote. Undisciplined programmers will still generate undisciplined Perl code, and Perl is a language where undisciplined code can really sting.

    Had non-strict coding been end-of-lifed, I might see light at the end of the tunnel, but short of a coup like that, I see the new features helping the disciplined coders more than anyone else.

      Undisciplined programmers will still generate undisciplined Perl code, and Perl is a language where undisciplined code can really sting.

      I agree, in part. I've heard Ward Cunningham say that one reason Smalltalk failed is because it was so easy to make messes in Smalltalk. They weren't painful enough to enforce discipline. That's not what I wanted to say though.

      Max's post goes on to suggest that spreading the good word about all of the nice new features of Perl and the CPAN that make using Perl and the CPAN in 2007 much nicer than using Perl in 1998, or 1995, is tremendously important. I agree. How can we do that better?

      A reply falls below the community's threshold of quality. You may see it by logging in.
      Oh wow, I don't think it's the "style enforcement" at all as much as that the main books are a little dated. Programming Perl 3rd ed was y2k! Am I missing a later version?

      The people that are really into style enforcement already moved to python.

      -Paul

        I respectfully disagree. Many of us who use Perl care very much about good style and maintainable code, and some more guidance in the books would be helpful.
      I don't think Perl will be alone with these issues. I think Perl has had more years to grapple with a language that is very versatile and a community that is willing to allow its users to make up their own mind (be the end result pretty or ugly, nice or naughty).

      I think Ruby, Javascript, etc... will have these same (and difficult) issues once they age and have larger existing code bases. (I think javascript has this problem already except now there are 100 magic libraries to choose from that many do similar things.... like CPAN without the nice-ness of CPAN).
    A reply falls below the community's threshold of quality. You may see it by logging in.
Re: Modern Perl and the Future of Perl
by mkanat (Novice) on Dec 21, 2007 at 04:31 UTC

    Okay, I have some thoughts about this.

    • First, the basic documentation that people read when they're learning Perl needs to be updated to at least suggest that people use certain modern things like Moose and Catalyst. There's More Than One Way To Do It, and that's great once you've got a feel for the language and can make decisions more easily, but when you're first learning something, it's nice to have somebody say "just go use this."

      I think this means a new edition of Learning Perl, and updates to the man pages that ship with perl. Possibly also, as some said above, a new Perl 5 version of the Camel Book.

    • A lot of promotion of Perl as a serious language for major applications needs to be done outside of the Perl community. I love Perl Buzz and use.perl, but those are mediums that are read by people who already write in Perl.

      There is a perception that Perl is a write-only language, and that perception needs to be broadly proven untrue. Somebody needs to advertise some extremely-well-crafted Perl. Not some really clever Perl hack, but some really-well-designed huge application.

    • New Perl users need to be treated kindly, not berated or insulted. I think the Monks are pretty good about this, but I mean on IRC, in other forums, on mailing lists, etc. It should become unacceptable in the Perl community to be rude to new users, even if you're the King Of All CPAN. Nobody should have the attitude of "I've been around a long time so it's okay that I'm rude."
    • In general, any encouragement of existing CPAN modules to spiff up their APIs and documentation would be great. If we want to be treated like professional programmers writing in a serious language, we should present ourselves that way. I'm of the opinion that Java is so popular because (a) it has great API documentation (b) it has great tutorials and (c) it got into universities as the primary teaching language.

      I think a great TPF grant would be for somebody to spiff up the documentation of the most useful and popular Perl modules.

    • Updating the web site would be good, too, as some people above have said. Catalyst has the right idea, there. :-) In addition to being nicer to look at, it should be explicitly extremely helpful to new users.
    • An improved method for searching CPAN is probably needed. I think that CPANHQ could do this, particularly with its planned tagging feature.

    Those are just a few things that I thought up off the top of my head.

    Perl is not dead. Now is the time to promote and get serious about keeping it alive, not after it's already died. It's true that Perl is huge, but so was Rome. That might seem like a silly analogy to some, but I think it's very accurate. Rome was so massive and so obviously invincible that nobody worked to prevent its fall until it was too late. Perl is so obviously huge that perhaps some don't imagine that it could ever die, but just because something is huge doesn't mean it can't shrink and shrink and shrink until it hardly exists anymore.

    -Max

      So there are lots of doubt in your mind. Couple of examples:

      • keeping it alive, not after it's already died.
      • doesn't mean it can't shrink and shrink and shrink until it hardly exists anymore.

      I am not saying you, but some perl guys like to use "not dead" as the prove for "not dying". You are right, revive it when it is dying, not after it is dead.

        Cop, why do you come here?

        (I'm asking earnestly)

Re: Modern Perl and the Future of Perl
by jettero (Monsignor) on Dec 20, 2007 at 19:30 UTC
    Perhaps the camelbook authors aught to write another edition? I know I'd buy it again just to have it on the shelf. I'd probably even read it again, since (as I recall) it's written quite well.

    -Paul

      I'd buy one. I never did upgrade my copy of 2nd Ed. By the time I had abandoned the notion that Perl 6 was coming out in the next decade, the language had moved a few versions past the 3rd Ed. Camel Book, and who wants to buy a book that's already comparably obsolete to the one they already own?
Re: Modern Perl and the Future of Perl
by BrowserUk (Patriarch) on Dec 21, 2007 at 01:36 UTC

    I've stayed well away from the ongoing flamefests elsewhere, because:

  • a) I haven't seen the bodies of any of cops posts since something like the 5th post he ever posted thanks to a small bit of CSS markup. He's the only person I have ever applied that to.
  • B) 'Response is reward' in his case, and life is too short.

    And you will doubtless dismiss this because of who I am. None the less...

    If you think that Perl::Critic constitutes "new idioms" and "the future of Perl", then I am, for the first time, truely afraid of the future.

    Because if you think that tying Perl down with bondange and discipline; stylistic monoculture; a usury of pedantic, micro-grammatical correctness; and turning Perl into a uniformly pedestrian mono-dialetic; constitutes making it "modern", then I fear you are not the Saviour of P6 as I thought you might be.

    I just hope to Hell and back that Mr. Wall is not so swayed.


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.

      I think you misunderstand me.

      Because if you think that tying Perl down with bondange and discipline...

      If Perl::Critic were not customizable, I wouldn't use it. I wouldn't recommend it.

      I think it's valuable, in the same way that I think having coding standards are valuable, but I don't think you'd adopt mine wholesale, nor should you.

      I use Perl::Critic as an example of a new tool that can help people improve their code. I think Perl Best Practices is a good book which discusses how people can improve their code. I don't apply every practice when I code, and I'm sure Damian's fine with that.

      Likewise, I don't mind when someone uses Object::InsideOut over Moose or vice versa. They're both fine tools.

      I do mind if someone's rolling his own blessed hash objects with the ref $self || $self idiom and fragile subclassing problems, because there are better solutions that exist that somehow we need to evangelize through the entire Perl community, not just the insular percentages that frequent the top Perl forums in the world.

      Enforcing B&D for everyone at the language level is wrong, but providing sane defaults and giving people the option to turn the thumbscrews to their desired level of pain or pleasure makes more sense. I think it's even Perlish.

      I fear you are not the Saviour of P6 as I thought you might be.

      Never claimed to be, nor wanted to be. (I do think roles are pretty awesome, and I'm happy to share some credit for them.) You might be pleased to learn that I did howl when the idea came up of making classes closed by default. Fortunately, no one suggested that seriously.

        If Perl::Critic were not customizable, I wouldn't use it. I wouldn't recommend it.

        Well yes, it's customisable but only before the fact. Not during.

        One of those 10 commandants is "thou shalt not kill". A pretty good rule for the most part, but we can all think of times and places, people and circumstances in which even this rule must be ignorable. Take your pick from military, to policeman; to a parent defending her children; self-defense; capital punishment. Some each of us can agree with. Some we may not.

        That's why we have courts and judges and juries to decide on a case by case basis. Because no matter how complex and complete the legistlatures attempt to cover all the bases, there are always exceptions and exceptional circumstances.

        Even just opinion influences what was illegal yesterday is legal to day and may be illegal again tomorrow.

        "Yeah but that's just an futile, extreme analogy that doesn't hold up for the case of coding standards techniques and constructs."

        But...the problem with Perl::Critic is that it attempts to take the human out of the decision making process.

        Yes, it can be configured. But that still requires a pre-judgement that must be applied to all cases henceforth. As in--this is the configuration that we will use for this company/dept/team coding standards and all code shall be run against and anomolies resolved.

        But on what basis do you decide the configuration?

        • Imposed from on high (minority rule)

          You (if your the boss) decide what you thinkis right and everyone follows.

          Analogy:apartheid

        • Majority concensus

          What about the opinions of those that don't agree?

          Analogy: American Indians/black 200 or 100 years ago.

          Or those that join the group later?

          Analogy: Americanised Japanese 1941

        • Other?

        The saving argument is that Perl::Critic used correctly, will draw human attention to just those areas of the decision making process requires concensus. That when the programmer choses to ignore a "standardised" configured ruling and a warning is produced, s/he should have to justify their decision to do so to "management".

        1984

        The reduction of the art of programming to the step by step application of a set of rules and procedures. Big brother is watching you.

        Paranoia you cry. But I now live in a society that has the greatest concentration of CCTV cameras per head of population in the entire world.

        For the most part they do not figure in my life at all, but 23 years ago and even 10 years ago, the idea that this could happen was laughable and unthinkable.

        Imagine 11 months ago when I said "Imagine a world where human beings where unable to apply their reason and discrimination to rules and guide lines." that that could ever become true.

        Taking the human out of the decision making process; and even sitting on the programmers shoulder and making his decisions or making him justify every decision; and taking away his voice and influence over the work he does.

        I've worked on a production line in a car factory where you sit for 2 minutes and 13 seconds and then stand and do your 7 alloted tasks for 3 minutes and 2 seconds for 6 hours and 42 minutes each day. You don't want to go there, and this is the start.


        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
          A reply falls below the community's threshold of quality. You may see it by logging in.

        I am dread of this!

        Read through Perl::Critic. Interesting but bad idea. Over the years I don't know how many lines of code (in different languages) I have reviewed, I never once thought of impose anything on anyone.

        Programming is art more than engineering. The "perl encourages bad coding style" critique has been certainly taken in the wrong way, actaully two wrong wayS: 1) total denial, and 2) over-react in the wrong direction with the wrong fix.

      A reply falls below the community's threshold of quality. You may see it by logging in.

      I don't read your posts, but I do LOOK at them. The length simple turn me off. What kind of wisedom could take this many words to express?

Re: Modern Perl and the Future of Perl
by talexb (Chancellor) on Dec 21, 2007 at 15:52 UTC

    Perhaps a numbered list of suggestions?

    1. Get involved in the community; they're happy to help you.
    2. Don't re-invent the wheel. Check CPAN first.
    3. Learn how to install modules on your platform. This will help you with #2.
    4. Read through Damian Conway's Perl Best Practices, and keep those tenets in mind while you write code. Don't follow them blindly -- but keep them in mind.
    5. If possible, develop code using Test Driven Development. It's an awesomely powerful way to develop and maintain code.
    6. Work on your coding skills continuously. Answer questions on IRC (if you dare), and on Perlmonks.
    7. Keep a copy of the Camel to hand. Open a page at random. You never know.
    8. Visit your local Perlmongers group; discuss Perl, ask questions. Attend your local YAPC event.
    9. Comment your code -- the most embarrassing thing that can ever happen to you as a developer is to look at some code you wrote six months ago and have absolutely no idea how it works.
    10. Don't immediately start pounding out code. Take your cup of coffee/tea and go for a walk. Think about the design. Think about an alternative. Think crazy. Think brilliant. Draw boxes on pieces of paper. Put off coding till the next day. Then start pounding away on the keyboard.

    I can't imagine writing Perl code as well as I am right now, without the assistance of the community. And Perlmonks is a big part of that community. That's why I'm so keen to help out here.

    Thanks to all, and to all a happy holiday season. :)

    Alex / talexb / Toronto

    "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

      I'm only going to respond here to #4, as it's the only one I have any nits to pick from.

      I see many people saying not to follow blindly someone else's advice. That's great for experienced programmers, and especially for those with existing experience in Perl. However, the best practices are arrived at from the experience of a very bright person.

      He may not always be right. There may be differences of opinion over some of the practices he suggests. Certain suggestions surely make more sense in certain cases than in others. So to always follow them blindly would be bad.

      My concern is that people give caveats so strong against PBP for people new to the language. These people are flying blind about best practices by default. Rather than developing random habits blindly, it would be beneficial for them to develop good (even if not universally accepted as best) habits blindly. Once they have some experience, then they're better equipped to make decisions about when to break away from Damien's suggestions and when to stick to them.

      To summarize, I guess I'm simply trying to say that perhaps people should be encouraged to follow good advice until they have determined there are valid reasons not to do so rather than to discount the value of the advice simply because some of us already know when to break the general rules (even if we can't always agree on which rules to break and when it's appropriate).

        That's what I wanted to say. Thank you for saying it.

        I don't worry about the people and groups who latch onto a set of standards or styles or best practices and enforce them with sticks and goads. They won't find much success, and it doesn't matter who suggests styles or standards. Their inflexibility will hurt them more than anything else, and there's nothing we can do for them until they fix that problem.

        I see no reason not to suggest good practices for everyone else, though, especially as they're gaining experience and good taste until they reach the point where they can evaluate their options and customize what they do for their current situations.

Re: Modern Perl and the Future of Perl
by Herkum (Parson) on Dec 21, 2007 at 03:44 UTC

    I think that Perl documentation, being integrated with the code is a problem. Perl does have better documentation a lot of other languages. However, in order to update/change the documentation, you have to get the author to update their distribution.

    The other limitation of this is that is hard to include examples for code that is is outside the scope of the immediate module, example: Code on how to integrate Module Foo and Module Bar.

    I would like to see a Perl Wikipedia be set up. We need to be able to provide more documentation than is available in a CPAN module or the Perl faqs.

      The other limitation of this is that is hard to include examples for code that is is outside the scope of the immediate module, example: Code on how to integrate Module Foo and Module Bar.

      People do write "Cookbook" modules that just cover documentation of things like this.

      You also can write "Tutorials" and so on for perlmonks.

      I would like to see a Perl Wikipedia be set up. We need to be able to provide more documentation than is available in a CPAN module or the Perl faqs.

      The perl-wiki idea is a common suggestion, though for whatever reason it doesn't seem to excite the insiders. If I remember right, one of the standard answers is that it's been tried many times, but never seems to catch on.

      (Myself, I have no complaints about perl documentation whatsover -- I suspect it's the best documented language in history.)

      I never thought of the document bit. Good point! My first thought was that Java has a similar issue, but after I thought more, I realized the differences.

Re: Modern Perl and the Future of Perl
by Anonymous Monk on Dec 21, 2007 at 01:00 UTC

    Several hours ago, you seemed to be so assertive that there is no maintainability issue with perl code. Now out of nowhere, you suddenly posted this, which is defensive and even some sort of nervous.

    This very post itself has said it all, and more powerful than any opposition: there is something wrong with perl code's maintainability.

    I knew that you won't admit in public, but take a moment before you go sleep tonight, and think about what I have just said.

      This very post itself has said it all, and more powerful than any opposition: there is something wrong with perl code's maintainability.

      I know posting is fun, and accusing people of hypocrisy and backtracking and doubletalk is a gas, gas, gas, but would it bother you too much to read what I wrote, then read the linked posts, then think about what they said, and only then post?

      It's not about maintainability. It's about simplicity, elegance, abstraction, and good solutions to common problems.

      A reply falls below the community's threshold of quality. You may see it by logging in.
A reply falls below the community's threshold of quality. You may see it by logging in.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://658216]
Approved by jettero
Front-paged by TStanley
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others scrutinizing the Monastery: (5)
As of 2024-03-19 08:08 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found