Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses
 
PerlMonks  

The Perl Hacker Inferiority Complex

by Anonymous Monk
on Jul 22, 2006 at 21:45 UTC ( #563050=perlmeditation: print w/ replies, xml ) Need Help??

There seems to be a lot of posts recently along the lines of "Perl needs The Solution" and "Perl is Dying" in which some folks appear to be losing the Faith.

Could it be simply that other languages/frameworks are getting a lot of attention right now? You know which ones I'm talking about - without my saying here.

Could you imagine if every time a new CPAN module was released, it was awarded the hype these other frameworks are receiving? It would literally be non-stop.

Now, can you imagine the wave - nay, shockwave - that will ensue when Perl6 and Parrot are released and we can start using our new platform in earnest? I think any rumors of stillbirth will prove to have been greatly exaggerated. The most advanced language, the most high-tech dynamic VM, the most flexible language and the most pre-existing modules (CPAN) all wrapped up in the either the GPL or Artistic License.

How can it get any better than that? When Perl6 is proven and replaces Perl5 on all the Linux distros. When application frameworks (yes, that's plural) and GUI librarys (plural again) and whatever else starts popping up, Perl6 will breathe new life into an already lively community.

So why are we (collective "we", not any one person in particular) so insecure about Perl? If it's because Perl5 has the reputation of a sysadmin tool that would never scale for large systems, Perl6 solves that. If it's because Perl5's object system is "bolted on", Perl6 solves that too. If it's because Perl5 has too much punctuation, well, Visual Basic solves that (hey, what can I say about it?).

I believe Perl's TMTOWTDI maxim has paid off - sort of like a giant composte of ideas. Everyone added something because there was room to add to it. Three guys in a room didn't invent "The Solution" - thousands of men and women worked together and tried out many solutions. Several solutions were only there to compensate for weaknesses inherent within the language itself - many of which have been addressed in Perl6. Some solutions were really just different approaches: Class::DBI/DBIx::Class, Mason/Apache::ASP, Catalyst/CGI::Application, FEAR::API/HTML::Form, etc. Each dicot solving some things, leaving other parts open.

I don't think Perl5 can be made to suddenly be easy for newbies, but Perl6 sure looks like it could. With some choices made completely moot (eg: inside-out objects, threads, junctions, etc) we can get on with the really important @things.

Maybe all that's left is to build a IDE that will surpass Visual Studio.NET and Eclipse?

Comment on The Perl Hacker Inferiority Complex
Re: The Perl Hacker Inferiority Complex
by Marza (Vicar) on Jul 22, 2006 at 22:16 UTC
    Why hide behind anon monk?

    How is Perl5 hard? I am not a programmer by trade and I was able to write things.

    Unless of course you are that snob that wrote about writing perfect code.

    Perl is not going away anytime soon. New languages are just like fads. Some last, many don't, and some you never hear about.

    It doesn't mean anything, but I haven't heard about Eclipse....

      Why hide behind anon monk?
      I don't remember my password (I'm jdrago_999) and I can't check the email address it goes to (my work email) from home.

      How is Perl5 hard?
      It's not hard - it's super easy. And super powerful. And, to paraphrase Larry Wall, maybe just a little too flexible at times.

      I haven't heard about Eclipse....
      Eclipse is a platform that happens to have a popular Java IDE built on top of it (as well as several other languages, including Perl). You can learn more at The Eclipse Website
      For the record - I'm now at work and this was my post.
Re: The Perl Hacker Inferiority Complex
by rodion (Chaplain) on Jul 23, 2006 at 02:20 UTC
    I enjoyed Perl4. I was also glad when Perl5 came out, and as successive versions of Perl5 acm out, and CPAN dramatically expanded its capabilities, Perl has become a central part of my work life. Based on its current strengths and the promising plans for Perl6, my team at work is planning to move our legacy applications into Perl. I also really like Perl. I like the Perl community. I like the appreciation of language that it brings to working with computers. I'm even not that impatient about the wait for Perl6, since it was clear some time ago that Perl6 was a very large undertaking.

    Thus am I one of the faithful. But as one of the faithful, I think there are some important issues highlighted in both Perl needs The Solution and Perl is dying. While Perl6 will give us a great deal, there are still some problems that it won't solve. And yes, some of those problems may be significant enough to blunt Perl's future success.

    Pluralism is one of Perl's greatest strenghts, and responsible for much of its thriving success. While we're benefitting from pluralism, we also need to mittigate some of its costs. For me, the most important ways we can do this are to provide:

    • A guide to Best Practices.
    • A set of recommendations on pre-Perl6 goodies, one that is aimed at the people who ask questions on PM.
    • A package of modules for doing web apps, one which well serves those who aren't committed to using Perl, and who would rather go check out Rails if you present them with a list of different choices with the strengths and weeknesses of each.
    TheDamian has given us the first item on this list and we owe him our deep gratitude, both for seeing the need and for doing the job. While the recomenations are very good, IMO, for some purposes just the existence of authoritative recomendataions is the most important part, and is enough to take care of a score of reasonable concerns about Perl. When you're selling perl for a major project, and management has heard rumors about tower-of-babble coding practices, you can plunk his book down on the table and you don't have to say much after that.

    If those with the knowledge and credibility can establish the other two items anywhere near as well as TheDamian has managed the first, with Best Practices, then Perl will be a very strong contender for being "the language for the rest of us". The additions won't make it any less of a wonderfully flexible language for those of us who already know it fairly well, they will just help others to follow.

    This is not a matter of fad or fashion, it's just a matter of improving service to a wider community.

      There _is_ a Perl Best Practices, by HRH Damien Conway. Excellent book, BTW.
      > package of modules for doing web apps
      Try WebGui - its more than a CMS, it is a "an application framework that handles content management".
        Sigh. WebGui may be may be an absolutely wonderful system. For myself, I appreciate the tip and I will check into it further than I have, but my point was that most people who are newer to perl won't do that. There are many wonderful systems and modules out there providing functions that may be relevant to a first project. There are even some less wonderful systems that look good at the start. It's too much to deal with for someone who is learning his/her way around. Later, as experience grows, it can be a valuable education to look at what others have done and how they've done it, and it can be a satisfying exploration. We need to help people through the early stage so they can get to that later one.
        WebGUI is not a framework IMHO, it just is a CMS with plugins. The original article mentions two web frameworks and they are the best IMHO: Catalyst and CGI::Application.
Perl 6 and CPAN
by audreyt (Hermit) on Jul 23, 2006 at 04:59 UTC
    To me, Perl 6 is like a director's cut of CPAN. From the RFC process till today, each part of Perl 6 feature either came from, or has been realized, as CPAN modules. (cf. the v6.pm stack diagram -- much more modules are present in each layer than shown there.)

    During the making of Perl 6, what we are doing can be seen as: Take those Perl 5 extensions, which are all nice tools that solves real problems, present them as the default, and make them play well with each other.

    Of course, the "play well" part involves a lot of work. However, one thing I like about the v6.pm path is it's gradual and completely opt-in. If you are interested only in some part of Perl 6, use them as CPAN modules today. For the few features that truly needs internals support, simply upgrade to 5.10.

    When the CPAN community is reasonably happy with the tool chain, we'll see more CPAN modules written with "use v6-alpha;" as their first line, calling for more integrated internal support in Perl 5.12. When all of it works well together enough that TimToady++ is happy to declare the syntax stable, then it'd be time to drop the "-alpha" suffix. Which wouldn't be this Christmas, but the advent has started now. :-)

      That plan, however, omits one part of CPAN: It cannot get all the Inline::* languages play well with each other. Fortunately, the Parrot project is making a director's cut of all dynamic languages, and have them play well with each other...
        Question for you.

        You are a lot closer to Parrot development than I am. However as an outsider I've given up on Parrot achieving its original goals. Has there been any sign that what I complained about there is changing? Is there, for example, any sign that we will someday have a version of Python running on Parrot that can pass the Piethon? Like the Python and JPython do, and IronPython almost does.

        After this I've wondered from day one how incompatible behaviours between different languages will be handled. Everything from minor discrepancies (eg whether you create new copies of data upon assignment, or upon modification) to major design issues (eg how you break down your error-handling hierarchy). But over time I've become convinced that we'll never get to the point where we have to worry about that.

        I'd love to be wrong on this. I really would. But I fear I'm not.

      To me, Perl 6 is like a director's cut of CPAN.

      So, will Han shoot first? :D

Re: The Perl Hacker Inferiority Complex
by vkon (Deacon) on Jul 23, 2006 at 09:44 UTC
    IMO when Perl was the only alternative for fast programming, it got many attention.
    When other scripting languages appeared, they, of course, distract attention.
    However I don't see perl comunity as shrinking...

    Also, consider following evolution -

    • assembler - is convenient way to write machine code.
    • C - is big assembler (much more convenient to code, and still very close to hardware)
    • Perl - is big C, it is very similar to C except its code more condensed and easier to write. But other scripting languages could perfectly replace Perl.
    • XXXXX - is big Perl. At this step something special should be invented... Is it perl6? :)
Re: The Perl Hacker Inferiority Complex
by matthewsnape (Acolyte) on Jul 23, 2006 at 12:22 UTC
    I think that the whole "is perl dyeing" debate tends to over complicate the issue. It assumes that people even make a coherent decision as to what framework or language they use. I have spent years coding perl to create web applications. The reason I decided on Perl in the begininng was because it was a scripting language supported on the free netfirms hosting package. Since then PHP has taken over as the easiest most available scripting language. My point is that we tend to over emphasize the importance of high end coding. I continued with Perl because it was so acessibile to people with little coding experience. You could create inrteresting stuff by using a handfull of modules. The quality of the source was low, but you could still get results. In recent years Perl has become less useful to people like me. Things like Class::DBI, CGI::Application and mason are great, but out of the reach of most people who dont have there own server. Look at godaddy (largest shared hosting provider in North America), most of CPAN is out of reach to these users. Just to difficult to install. Perl may run on any OS, but it is inaccesible to many users. The Perl community has always prided itself for being compatible on any os. But Perl does have an accessibility problem for new users on limited systems.
        But is it easy for an inexperienced user to do? I believe that CPAN offers a huge benefit to inexperienced programmers. But expecting them to install the modules themselves and adjust their code to use those libraries may be to great a hurdle. CPAN is cool precisely because you dont have to install modules yourself or adjust your code. New users of language are fickle and to many "Internal Server" errors can really put them off.
Re: The Perl Hacker Inferiority Complex
by spiritway (Vicar) on Jul 23, 2006 at 13:14 UTC

    I don't think Perl hackers have any sort of "inferiority complex". What I see happening is that some people are perhaps feeling a bit threatened by the popularity of other languages, wondering whether they're wisely staying with a superior language (Perl), or whether they're missing something even better. That's always going to be a question with computer trends. In the past, conservatism has usually resulted in stagnation and losing the lead on new technology. Why trouble with those new-fangled VDT's, when you can just toggle the code in through the front-end switches? I fought like a tiger against using a mouse...

    Part of the problem, I suspect, is our impatience to see Perl6 unveiled. Everyone else has a bright, shiny new toy to play with, and we're still using good old Perl 5. Poor us... And yet, it says a great deal that Perl 5 is still competitive, considering its advanced age. I like Perl 5. I'm content to use it, until Perl6 comes along. I still have plenty to learn about Perl 5, to keep me busy. Once I've learned all the language, I'll get impatient - but if I ever get that good, I'll start helping out with Perl6.

    I agree that TIMTOWTDI has paid off handsomely and continues to do so. It seems to me that a similar approach works in biology. Genetic diversity pays off. You never know when some off-the-wall mutation will be the one to survive the changing environment. Too much purity leaves a species vulnerable to extinction by impairing its ability to create these mutations. That's OK if the environment is stable - but history shows this is not the case. In IT, the environment is even less stable.

    Perl 5 isn't hard for newbies - unless you're referring to those who have never programmed in any language. Programming itself is difficult for a newcomer, because it requires a highly structured way of thinking that is not usually taught to non-programmers. It's the disciplined thinking that is difficult, not the particular idiom (though some idioms are more difficult to grasp). For someone who already understands the concepts of programming, Perl is not at all difficult to learn.

      I agree, Perl 5 isn't hard for newbies, it's just a little hard for the relative newbie to accomplish what they want in Perl. That accomplishment usually involves the web. PHP and Ruby make that easier, as matthewsnape above makes clear. If we reduce the hastle of that first accomplishment in Perl, more talented people will start Perl earlier, get used to its advantages, learn, and contribute. The health of a language depends as much on the new talent coming in as it does on the accomplished fellows already here.
Re: The Perl Hacker Inferiority Complex
by rhesa (Vicar) on Jul 23, 2006 at 13:51 UTC
    I think your title is too melodramatic, and overgeneralizing. You make good points, and I agree with most of what you say, but - IMHO - you overstate the validity of the claims made in those threads. Just look at the arguments made by chromatic and Ovid. Their points are convincing enough in their own right, but if you realise where they work, you can see how that gives them an excellent view on the overall state of Perl. From where I stand, that makes them far more authorative than some random anonymonk.

    <rant> I have the sneaking suspicion that the handful of FUD-spreading anonymonks are just a bunch of whiny saps who landed lousy jobs, where they resent the technology desicions being made higher-up, and think their peers are all monkey coders. Their complaints aren't with Perl itself, but stem from their unhappiness with their personal situation. </rant> -- Yes, it's a hot day ;^)

Re: The Perl Hacker Inferiority Complex
by zentara (Archbishop) on Jul 23, 2006 at 14:37 UTC
    Inferiority Complex ??

    I would say the opposite. Most Perl hackers, when confronted with another language, respond with "I don't need that sh*t, I already have Perl". :-)


    I'm not really a human, but I play one on earth. Cogito ergo sum a bum
      These two last years, when the chief requested a new task to me, my motto was:
      "Naaah!, I can make it in TWO lines!..."
      This was my work :)
      Let me explain what I mean by "insecure".

      Never needing to look outside our own box to find a solution sounds like a good thing (and it is), but after years of not having to look elsewhere for solutions, I found myself questioning whether I was missing out!

      It is so rare that I come across a coding problem that requires more than 2 minutes searching CPAN before I discover a solution (or several!).

      Rare. Maybe too rare. So rare in fact that I feel insulated from the rest of the coding world. I have never come across a problem I could not solve with Perl.

      The added bonus of direct access to the source code of CPAN modules has given me an accelerated learning path (compared with Java or .NET) - further perpetuating the cycle of Perl-only knowledge. Or is it?

      I happen to work at a 50/50 Microsoft/OSS shop where everything *we* write is written in VB, and anything *I* write is in Perl. At one point we were going to convert everything to Perl, but nobody else bothered learning Perl. To make a long story short, we're doing .NET now.

      Having spent the last few weeks porting some VBScript code to C#, it's not much different than when I ported something similar from VBScript to Perl. It could be that it was me doing the porting both times, and that both Perl and C# have a C-style syntax.

      In the past I have experimented with C++. Even though it is considered a "real" programming language, I couldn't see how anyone got anything *done* in it - so much that I took for granted with Perl simply was not available to me.

      Learning C# was very different. Even though it has static typing and "One Way To Do It", its garbage collection and the .Net framework class library (analogous to a proprietary CPAN) means I can be more productive than I would be with C++, since most of the wheels I need have already been built and are part of the standard install. (Nice run-on sentence!).

      I look forward to Perl6 with its vast CPAN library, built-in object system, threading and delegation. The "insulation" factor will probably still be there, but since Parrot will promote interoperability, the insulation may be more transparent.
Re: The Perl Hacker Inferiority Complex
by Ieronim (Friar) on Jul 23, 2006 at 15:44 UTC
    I have read discussions about "dying Perl", "Perl needeng a solution to survive" and i went through the comments to this node.

    I still think that my Engish is to poor to explain my thoughts about this discussion. But i'll try.

    I think that every computer language is a INSTRUMENT. Like a hammer or a drill. And if you need to to a certain work, you will choose the instrument to do it—but you won't think that "My hammer is better than any drill, so i'll perforate holes in the wall with it" or "Hammers are dying, so i'll drive this nail with my favourite drill". You will take the drill or the hammer and do the appropriate work with it, won't you?

    I do my own work with Perl—and i can explain why i chose Perl to do it. And it does not matter for me if PHP is more popular than Perl or not.

    And i don't understand how the popularity of PHP, Python, Ruby or VB does affect the usage of Perl for tasks that are better solved with it.

    P.S.
    I understand that there are people who learn their first language to create the first dynamic webpage in their life. They will choose PHP. As PHP is a "language for creating dynamic webpages" :) And if somebody forgot, PHP was initially written in Perl as The Solution for creating webpages :)


         s;;Just-me-not-h-Ni-m-P-Ni-lm-I-ar-O-Ni;;tr?IerONim-?HAcker ?d;print
      "Hammers are dying"

      Hilarious. :)

      Yes, very well said - it's the tool (or "instrument" as you said, but same point). There is a saying, though - "to someone with a hammer, every problem looks like a nail." Something to think about. Our choice of solution may depend on our tool or instrument, as much as our choice of tool might depend on the problem.

      I'm sorry to hear that hammers are dying. I'll have to go out and buy another drill now.

Justification against Java
by rodion (Chaplain) on Jul 24, 2006 at 13:38 UTC
    A Perl vs. Java fight brews over in SoPW is quite relevant to this discussion. Take a look at it if you haven't seen it yet.

    And if you know Java reasonably well then it's a chance to help make the case for Perl where it counts, in a team's pending design decision.

    Update: link fixed. (Thanks jdporter.)

Re: The Perl Hacker Inferiority Complex
by jfroebe (Vicar) on Jul 24, 2006 at 14:37 UTC

    I use both C# and Perl without considering one superior to the other one. If I want a GUI interface, I use C# (version 2003 - haven't been able to convince my fiance that 2005 is needed). For utility type programs, I tend to use perl. I use the tool that is best for the particular job at hand.

    Perl and .NET are about the same for cross platform compatibility (.NET *does* work with other platforms: see Mono).

    Jason L. Froebe

    Team Sybase member

    No one has seen what you have seen, and until that happens, we're all going to think that you're nuts. - Jack O'Neil, Stargate SG-1

Re: The Perl Hacker Inferiority Complex
by Velaki (Chaplain) on Jul 24, 2006 at 17:52 UTC

    A hammer for a nail; a screwdriver for a screw. Yeah, there are some people who will use a butter knife to screw in the leads to an electrical socket, just as there are those who will use a stale loaf of bread wrapped up in six layers of aluminum foil and dipped in three coats of shellac to use as an organic mallet on the third day after midsummer's eve to pound Hershey's kisses into used corn cobs.

    Why do people do these things? It's a fear of change, or sheer laziness. And learning a new perl dialects is no different. One chum codes everything as .pl files, all Perl4-esque, and hates anything OO in Perl5. Another has been living on the latest tidbits of Perl6 to come out.

    However, I've also encountered people completely new to Perl programming, and they're not overwhelmed at all. They credit the plethora of books that have been written, and especially the user community here at perlmonks.org, with dispelling any FUD they might have about the language.

    I myself am helping them become more comfortable about using regexes, and sure enough they learning it, and learning it well. No fancy IDEs, no Eclipse, no VS.NET.

    Just vi and a dream.

    I've used Eclipse, and I like it for Java, but it's like jumping back into smalltalk on steroids after a fashion, and using a heavy IDE can sometimes be daunting, just like trying to learn enough TSO/ISPF and JCL to compile COBOL programs.

    Do Perl hackers have an inferiority complex? Not that I've seen. We're some of the most capable, strong-willed, upstanding bunch I know. The industry tends to play us down in favor of more traditional (read: compiled) languages, such as Java or C#. What Perl6 will do to that perception will depend on which CIO reads the appropriate Hip & Trendy™ buzzwords in some magazine recommended by Someone-Who-Knows.

    Is Perl in any danger of dying out? No. It's ubiquitous because it is useful, and continues to evolve with its programming family of adherents.

    Falling off my soapbox,
    -v.

    "Perl. There is no substitute."
Re: The Perl Hacker Inferiority Complex
by ady (Deacon) on Jul 25, 2006 at 07:02 UTC

    Problems, not The Solution.
    No, Perl does not need 'The Solution' to survive, it needs Problems, and there are lots of problems in daily development work that Perl is The Uniquely Best Suited Tool to solve in the most clean, concise, efficient and portable way.

    Results, not Hype.
    To realize this requires a broad and deep personal experience with computer architectures, OS'es, languages and tools (ie. you must have worked with complex data structs such as deep combined hashes&arrays and you must have wrestled with pointers/references in C, C++/STL, C#, Java, AWK, Perl etc. on DOS'es, UNIX'es and WindowsXX'es).

    The Perl Way, or the Highway.
    Maybe you just need a fast & flashy framework to put up a web site. Maybe you just need a large scale team framework to crank out a lot of heavy business objects.

    Then, maybe you don't need the general power and flexibility of Perl to solve the tasks in your specific problem domain, or maybe you don't want to enter a long learning curve to master yet another general language with a large library. Then by all means: take The Highway that will solve your specific problem today!

    "Who's inferior or dying?"
    But don't think Perl is dying because the majority of developers may take The Highway to solve specific problems; The majority of developers do not have a broad and deep personal experience with computer architectures, OS'es, languages and tools, but the day they really crash&burn on The Highway with their slick&slim or obese&obstructing vehicles, they will either die, -- or they will go looking for an offroader like Perl to cruise the bush, just like wee did, back then when we needed it. And they will certainly not feel inferiorior for having a Hummer in the driveway

    The Way i see it,
    Allan Dystrup
Re: The Perl Hacker Inferiority Complex
by RolandGunslinger (Curate) on Jul 25, 2006 at 13:33 UTC
    I haven't coded Perl for a while now, but I read this and felt obligated to comment. I've coded Perl and found it easy to learn, but sophisticated enough to handle very complex problems. I haven't been keeping up with it primarily because of demands from my programming job, where I'm having to master .Net, but I can honestly say Perl rocks, and will always have a place in my toolbox and on my resume.
Re: The Perl Hacker Inferiority Complex
by Anonymous Monk on Jul 25, 2006 at 13:50 UTC
    I think part of the reason that Perl gets the bad press is because it really is a genuinely bad language. Combine the poor hackish design with the flippant attitude and complete disregard for standards shown by Larry Wall and the criminal intents of that guy with the cracker monicker "merlyn", and the superior designs of Ruby and Visual Basic, and you are left with a steaming pile of undulating and evilly sentient hostility that literally takes an "appocalypse" to make even the slightest change to the "code base" if you could even laughingly call it that.

    For example, once I was logged into a BBS over a phone line during a thunderstorm, and a close enough strike disconnected my line with such a violence that blew up my modem and sent pages and pages of complete ascii garbage tearing across my poor procomm screen, and my boss walked by and asked if I was "learning perl." Folks, this sort of reputation is no good, and its no wonder that Microsoft fired those losers from Activestate, even Microsoft has little taste for the abomination that is the "modern perl."

    BTW, it took 20 minutes to load this web page, let me guess, built with perl eh?

      Thanks. Never read such an amusing pile of FUD :)

      Ordinary morality is for ordinary people. -- Aleister Crowley

      The fact that you used Procomm instead of Telix say's volumes in and of itself.

      The fact that it took your system 20 minutes to load this page means your probably still using it and your modem.

      The fact that Microsoft fears the access Perl gives to a system and proved to be financially unexploitable by them is ++Perl in my book.

      . . . you are left with a steaming pile of undulating and evilly sentient hostility that literally takes an "appocalypse" to make even the slightest change . . .

      I love that line.. Don't agree with it but it's still quite amusing

      once I was logged into a BBS over a phone line during a thunderstorm

      You had phone lines ... you lucky bastard let me tell you about the time we tried ordering supplies during a freakish mid-winter hurricaine ... the electrical discharge fried the mod40 operators fingers and we went through several cords of wood before we realized the storm was shifting the smoke in an undpredicatable manner. You should have seen the boss' face when the 4000 blue ascots with kittens on them showed up. We tried to switch to semaphore ... but once again the wind ... the wind ...

      -derby
        Well, we had it tough. Back in my day, we didn't have these "modems" and "phone lines". No, we had to transmit data by steam power, aaaand feed the coal into the engine. Modems? Luxury!

        </ob_monty_python>

        --
        tbone1, YAPS (Yet Another Perl Schlub)
        And remember, if he succeeds, so what.
        - Chick McGee

      So, what's a genuinely *good* language? Something tha follows standards? OK, so who gets to create the standards, and why them? In the case of Perl and Larry Wall, well Larry invented Perl. He didn't follow the sed or awk standards (if any existed), nor did he adhere to C standards (and many exist). He took what he wanted, and made the rest up, and came up with something that is being used by a huge number of people. There *were* no Perl standards before Larry created Perl. Your criticism of Larry is much like dissing any other innovator for thinking outside the box. You don't innovate by adhering to standards.

      Lucky for you, since you hate Perl so much, there are dozens of other programming languages that you can try. I'm sure you'll be able to find some that adhere carefully to standards, don't have troublesome innovations, and only color inside the lines. Try Pascal, maybe.

      Much as I love Perl and PM, I don't think I'd sit around waiting 20 minutes for the page to download... But I suppose if you have nothing better to do, then 20 minutes isn't all that much.

      and sent pages and pages of complete ascii garbage tearing across my poor procomm screen, and my boss walked by and asked if I was "learning perl."

      Once, I was playing with an Etch-a-Sketch, when my boss walked by and asked if I was "learning Visual Basic".

        Of course the advantage of developing on an Etch-a-sketch is that they are quicker to reboot than other devices, the downside is that version control is difficult - you have to put the sucker very very carefully upside down into a photocopier.

        /J\

      Perl is not a "genuinely bad language". A CS professor might tell you that because Perl was not designed as an academic innovation. It was designed to, as Larry Wall said, "make easy things easy and hard things possible"(or something like that). The academics denounce Perl because it does not boil down to some beautiful simple rule. These are the people that love Lisp and think the idea of such a context sensitive language like Perl is absurd. Lisp can be boiled down to a small set of Beautiful Rules, but do you know anybody who solves any problems with it? These languages have their place. They innovate new ideas, but typically only seem to focus on doing that one thing well. Since Perl is designed for solving problems, it picks and chooses from these vast academic achievements and lets you use them at your discretion.
      Here is what it comes down to:

      A monk wants to solve a problem in as few lines as possible.

      An academic wants to be able to write compilers with as few lines as possible( because every statements is broken down into executions of the few Beautiful Rules).
        Lisp can be boiled down to a small set of Beautiful Rules, but do you know anybody who solves any problems with it?

        How 'bout extending Emacs?

        Says the vi guy...

        ----Asim, known to some as Woodrow.

        Lisp can be boiled down to a small set of Beautiful Rules, but do you know anybody who solves any problems with it?

        Orbitz and Yahoo! Stores (formerly ViaWeb) both use Lisp for their software, or, at a minimum, they used to.

        I've been reading Hackers and Painters by Paul Graham and will probably post a review of it when I'm done. Only 2 more chapters to go!

        The book is a bit preachy in points but is overall a good read. He's very heavily biased towards lisp as the best tool for the job - any job. He was adamant enough that I've started learning it myself.

        One of the points he raised in one of the chapters was that he paid attention to the languages his competition was using. If somebody showed up using Java or C or the like he wouldn't worry at all, dismissing them as suits that would fail. If he found out a potential competitor was using Perl or Python or the like, he'd start to lose sleep about it. They were using a language that allowed for more nimble development and most likely chose it because they knew what they were doing. He said that he would have probably wet himself if he found out a competitor was using lisp.

        The point he was making was that languages started off with two very distinct paradigms - machine language and lisp. And the machine language side (progressing through Assembly and C and Perl and Ruby and such) is skewing leaning more towards lisp-ish things that've been around for decades anyway. So if everything else is becoming more lisp-ish, why not just use lisp?

        Now, mind you, I'm not going to abandon perl for lisp any time soon, no matter how cool it may be (I didn't abandon perl for objective-c either, and that language is also terribly cool), but I am finally curious enough to see what the hype is about. If nothing else, looking at other languages gives me ideas and concepts to bring back and use in Perl.

        I don't care about beautiful rules or number of lines, I care about beautiful solutions and beautiful software. Perl, properly done, really excels at that.

Re: The Perl Hacker Inferiority Complex
by DBX (Pilgrim) on Jul 25, 2006 at 14:00 UTC

    The plural of library is "libraries" not "librarys"

      > librarys (plural again)

    It's hard to take someone seriously who doesn't pay attention to details.

      Perl is NOT DYING! It has already been dead for several years now. Perl died when Microsoft bought Larry Wall and put him out to pasture. Remember the Perl movule for vs.net? What ever happened to that?

      2006-07-26 Retitled by GrandFather, as per Monastery guidelines
      Original title: 'The Perl Hacker Inferiority Complex'

      The plural of library is "libraries" not "librarys"
      You mean The plural of "library" is "libraries", not "librarys".
      It's hard to take someone seriously who doesn't pay attention to details.
      Indeed.
        Heh - I would have fixed it but I wrote it as "Anonymous Monk".
Re: The Perl Hacker Inferiority Complex
by Anonymous Monk on Jul 25, 2006 at 15:34 UTC
    Well, we can allude to the forthcoming Perl6 all we want, but: "real artists ship."

      We needn't allude to Perl6. Perl 5 is alive and well, doing quite nicely, thank you. If you feel some other language is more appropriate, do not hesitate to use it. As Ernest and Julio Gallo said, "We will ship no software before its time" - or words to that effect.

Re: The Perl Hacker Inferiority Complex
by belg4mit (Prior) on Jul 25, 2006 at 15:42 UTC
    I'd just like to point out that I feel a lot better about the imminent doom that is Perl 6 after seeing Autrijus' v6 talk at Boston.PM. With v6 you can start using some of the good bits of Perl 6, but aren't yet forced to adopt all the nastiness too ;-) ... although they are working on it.

    As for newbies, I too, do not see how P6 is going to be "beeter". Indeed, for sometime it will probably be worse until everyone gets used to having the rug yanked out form underneath them.

    UPDATE: By everyone, I mean the experienced perl hacks whom would help the newbies.

    --
    In Bob We Trust, All Others Bring Data.

Re: The Perl Hacker Inferiority Complex
by Anonymous Monk on Jul 25, 2006 at 16:00 UTC

    I have been a big Perl fan for many years, but I admit I'm on to Ruby now. Why? Because Ruby 1.8 has many of the features Perl 6 is going to have, but Ruby 1.8 is here NOW, and that makes all the difference in the world.

    Also, the implicit comparison of Rails to any old CPAN module is disingenuous. Rails is far more comprehensive than any single CPAN module and far more well integrated than any handful of CPAN modules one might combine to do the same thing.

    I miss CPAN, though, for most things that are not Rails. CPAN has far more modules and most of them are more mature of course than their Ruby equivalents. I often come back to Perl so I can get at something I need from CPAN, and when I do, I find now that the core language feels "clunky" compared to Ruby. Maybe when Perl 6 gets here people like me will once again count Perl their favorite language instead of second favorite.

    "Dying" may be an exaggeration, but there's no denying that the long development of Perl 6 has cost some mindshare. But that leads to another point - who cares? It's not like Ruby and Perl are competing for market cap or customer dollars. Like I said, I can switch between them at need because I paid zero dollars for both of them.

Re: The Perl Hacker Inferiority Complex
by Anonymous Monk on Jul 25, 2006 at 19:41 UTC
    Finally a place for people to weigh in where the parent node isn't a Diggthink-powered troll.

    I use perl because
    * it's on every *N*X server I encounter and I never have to install it
    * I can use it for just about everything
    * the might of clean code is insignificant compared to the power of a stream of oneliners

    Given these three, even if there were no CPAN I would use perl. By way of analogy the trolls are saying I should throw away my dependable Swiss Army knife and learn how to use the new deluxe canopener that just came out instead. It bears mentioning that drivel like this never saw the light of day back when perl5 was released. We said things like "I like sed better than perl because I know it so well". We never said "perl is teh suxors, use C" and we killfiled anyone who did. We didn't have time for meaningless noise because we were too busy building the Internet with perl, all because we had a dream that someday moronic youngsters would be able to send each other into fits of apoplexic rage by insulting each others technology from a thousand miles away.

      If you have a church I want to join!! Hallelujah brother!
      The internet wasn't built on perl. The biggest problem I have with perl is this idea that no other language should exist. In this thread alone, how many people have indicated that "after Perl 6 comes out and we get some GUI environments for it, etc. then no one will want to use any other languages". You don't see this in any of the other comunities, why is it seemingly the dominant voice in Perl land? It was this attitude expressed daily from a college for over 5 years that has driven me away from Perl forever.

        Personally, I wouldn't know what is said in other communities, because I find everything I need with Perl and PM. If you've been "driven ... away from Perl forever", what are you doing here? Apparently you still have some feelings for the language or its users - some attraction.

        I am often puzzled by how many people come here to explain how Perl isn't worth anything, it's a useless, stupid language, blah, blah, blah - and yet, they return here daily to tell us all about it. Don't you have any programs to write?

Re: The Perl Hacker Inferiority Complex
by Anonymous Monk on Oct 10, 2006 at 00:46 UTC

    Perl isn't dying. Perl is already dead, murdered in cold blood by those who created it.

    There are two languages called Perl, and we must not confuse them. One is Perl 5 - abandoned and declared obsolete by its developers in 2000. Another is Perl 6 - which isn't here after 6 years of development (not even beta versions), and nobody really believes it will ever be here.

    And even if by some chance Perl 6 - a completely new language - is released, what's the point of using it ? Do you seriously believe it's going to have full Perl 5 compatibility ? If Perl 5 compatibility was that easy, someone would have already added it to Ruby and Python.

    A total rewrite is always a stupid thing and Perl developers are stupid people for attempting it.

      All that is gold does not glitter
      Not all those who wander are lost
      The old that is strong does not whither
      Deep roots are not reached by the frost
      From the ashes a fire shall be woken
      A light from the shadows shall spring
      Renewed shall be blade that was broken
      The crownless again shall be king
      

        C'mon, this plagiarism is getting ridiculous.

        This appeared many years ago, and can be seen at the following URL: http://www.poemhunter.com/p/m/poem.asp?poet=6607&poem=33363.

        Sheesh. Trying to pass off the work of JRR Tolkien as your own.

        For shame.

        ;-)



        --chargrill
        s**lil*; $*=join'',sort split q**; s;.*;grr; &&s+(.(.)).+$2$1+; $; = qq-$_-;s,.*,ahc,;$,.=chop for split q,,,reverse;print for($,,$;,$*,$/)

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others browsing the Monastery: (9)
As of 2014-08-28 03:17 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (255 votes), past polls