7 ms·

FYI, I use Perl extensively for text file parsing and processing Yeah, me too, but that's the issue. It's great at that. Great at quick and dirty command line

by jlees 16y ago

FYI, I use Perl extensively for text file parsing and processing Yeah, me too, but that's the issue. It's great at that. Great at quick and dirty command line hacks. Hell, most of my PhD code was written in Perl. (Something I take a perverse satisfaction in.) But it's not great for rapid webapp development, it's probably harder to hire people, there are fewer libraries and interfaces and open source toolkits, etc - so people like me moved from Perl to Python (it's a really easy jump). I still use my old perl scripts now and again, but even for quick and dirty stuff I tend to use Python - just in case I want to come back to it later and have a chance of understanding what the hell I wrote. :) (Aside: One of my summer internships was on the web backend team at my university's Engineering lab. We wrote an object oriented student class administration system, in Perl. It was quite probably the most hideous piece of software engineering I've ever seen...)

berntb 16y ago
>>But it's not great for rapid webapp development Interesting, do you know what you talk about and have references? AFAIK, there are some quite neat libraries and a better OO system than the usual competition (Ruby, Python, Java et al). Etc.
- jlees 16y ago
  Observe the vague handwavy terms I used: I'm about 18 months out of date as I made the switch to Python around the start of 09. At the time, Catalyst was very unfriendly (a quick google - it still is) and nowhere near as rapid-accessible as Django, just because of the amount of head-twisting you have to do to get things up and running. It may have changed, but frankly I have little interest in investigating it, and I expect most other people who drifted away from Perl are in a similar boat. Also, having developed an OO backend for a site running in Perl, I never wish to do so again. Your definition of 'better OO system' clearly differs from mine.
  - KaeseEs 16y ago
    He's referring to Moose, which is an insanely good object system, which wasn't prevalent at all 18 months ago but is nearly de rigueur in all but a handful of cases today. It's a mashup of CLOS, Perl 6, Smalltalk and a few other things that remains consistent, Perlish and intuitive. It's also crazy extensible - just look at the MooseX namespace on CPAN to see what I mean.
    - prodigal_erik 16y ago
      How much of CPAN has been migrated to Moose, as opposed to directly calling "bless" as the docs[1] advocate even now? As I understand it, the story on interop between the two styles is "don't go there". [1]http://perldoc.perl.org/perlobj.html http://perldoc.perl.org/perlobj.html
      - berntb 16y ago
        The perlobj perldoc is about the old style OO -- and discusses the old style OO... :-) It doesn't discuss any CPAN modules at all (there are quite a lot about OO). Are you trolling? What problems do you mean with Moose and the blessed OO?
        prodigal_erik 16y ago
        Not at all. I learned Perl from the manpages, and I'm mystified how noobs are to discover and convince themselves that "man perlobj" is now bad advice yet remains official. As for bless/Moose interop, I read somewhere there were big problems mixing the two but don't remember the specifics (I mostly dropped Perl a long time ago over its dogged attempts to guess what I probably wanted when I made a mistake). Others in this thread now say that's not true if it ever was, which is good news for users of pre-Moose CPAN modules.
        berntb 16y ago
        >>I learned Perl from the manpages Well, that was impressive. Stupid, but impressive... :-) >>discover and convince themselves that "man perlobj" is now bad advice yet remains official. AGAIN: Those man pages doesn't discuss CPAN modules. But afaik, they recommend books and the web...
  - deleted 16y ago
    [deleted]
- joe_the_user 16y ago
  Post: "I've done a bit of X and my overall impression of Y in was..." Reply: "References, sources, double blind studies please! Prove you know what you're talking about..." It seems like asking for references has become a far too easy way to pull karma points, even against posts which make their sources fairly clear.
  - berntb 16y ago
    Feel free to vote me down, if you're all about karma... :-) I asked because his claim went against what I've read on the subject. I don't really know, since I haven't really been working with web development for a couple of years (which is why I started with "Interesting").
    - jlees 16y ago
      I'll vote you down for calling me he. ;)
      - berntb 16y ago
        Long enough after to be invisible... I of course voted you up for that down vote. :-)
leif 16y ago
> from Perl to Python (it's a really easy jump) I disagree. Python is incredibly restrictive when you're used to perl. I would be so frustrated if I went that direction.
- Goladus 16y ago
  Just curious, what ways you found python restrictive?
  - leif 16y ago
    The whole language is all One Way To Do It-ified. It's fine, there's nothing wrong with it, I just always feel a lot more like I'm part of a creative process when I'm working with perl, like it's this magic goop I can mush around and throw at anything and it'll do everything I can think of. With python, it feels more like I'm trying to fit my program into the python world, which is very nice and square and proper and everything works perfectly fine, except if I happen to want to do it the other way just for kicks, I can't. Or, worse, I can and the performance is crap for no obvious reason (or a very good obvious reason that should've been fixed ages ago by relaxing things just a little bit). I used to be a real big python fan, now it just seems like too much training wheels. I like perl's weirdness: its global variables, implicit returns, gotos and loop labels, weird calling conventions that, while unexpected, are perfectly well documented and reliable, and _boy_ do I love its string support.
    - Goladus 16y ago
      Ok, I was sort of hoping for a more concrete example. Do you mean like not being able to use 'unless' constructs? Not having regular expression operators? Not being able to reference default variables like $_? What is an example of doing it "the other way"? I can usually find several different ways to do anything in Python, too. In fact I find this is true even for trivial things. For example, here are 4 ways to parse /etc/passwd and return a list of objects such that you can reference each value by the field name, for example: >>> passwd_data('/etc/passwd')[5]['shell'] '/bin/bash' 4 ways: http://pastebin.com/wPa5q7Mc http://pastebin.com/wPa5q7Mc
rcfox 16y ago
> there are fewer libraries and interfaces and open source toolkits, etc Um... What? According to http://search.cpan.org/ http://search.cpan.org/, there are 85193 community-contributed modules. Okay, some of that is stupid stuff (http://search.cpan.org/perldoc?Acme::Meow http://search.cpan.org/perldoc?Acme::Meow) but they don't make up a large percentage. Compare that to PyPI's 11199 packages and RubyGems' 15674 gems.
- pragmatic 16y ago
  Yes, but do they _work_? That's why I became disillusioned with Perl, even though it was heavily used at my last company. I got the "oh, yeah, just go to CPAN and grab the module." I usually ended up using Java (how perverse is that?). I now prefer Python and C# because I find more stuff that works (but still plenty of broken old stuff).
  - perigrin 16y ago
    The CPAN ecosystem provides some basic guarantees that I haven't seen mentioned for other language's repositories. For example every distribution uploaded to the CPAN is tested on some subset of (using last month's statistics[1]) 15 different operating systems, across 81 platforms, and 26 different versions of Perl. Not every package is tested on every perl and every platform because this is a volunteer effort, but the major platforms (Linux, Windows, BSD, Solaris) are generally covered. These test results are aggregated and reported on search.cpan.org. Every package uploaded is given a Bug Queue (rt.cpan.org) so bugs and patches can be reported to the author. Additionally distributions can now specify in their metadata (META.yaml/META.json) the source code repository for the code so you can see from search.cpan.org the place to get the latest code to patch against. Additionally there is a process that if a maintainer goes rogue and stops responding, packages can be taken over. This doesn't happen often but has been used when other options fail. Many modern projects have several co-maintainers who can all make releases lowering the "bus factor". Right now the biggest problem is finding the wheat for all the chaff. Sturgeon's Law applies, 90% of everything is crap. With 21038 (as of this writing) unique distributions, finding the ones that are well written, useful, and generally "best" is actually a difficult problem. You're not alone in finding that hard, but there are projects like Task::Kensho[2] to curate CPAN. This process is hard and would require a full time team of experts to perform properly. It is big problem but one I think I'd rather have than when I was (for example) working in Java in 2005 and not only had to go through the effort of assessing the module in question (will this work? is it good? will I have problems later) but also had to hunt around the web for where all the different projects were located. [1]: http://stats.cpantesters.org/ http://stats.cpantesters.org/ [2]: Full disclosure, Task::Kensho is a project I started in 2007 based upon the feedback of several people in the Perl community.

by jlees 16y ago

berntb 16y ago

>>But it's not great for rapid webapp development Interesting, do you know what you talk about and have references? AFAIK, there are some quite neat libraries and a better OO system than the usual competition (Ruby, Python, Java et al). Etc.

jlees 16y ago
Observe the vague handwavy terms I used: I'm about 18 months out of date as I made the switch to Python around the start of 09. At the time, Catalyst was very unfriendly (a quick google - it still is) and nowhere near as rapid-accessible as Django, just because of the amount of head-twisting you have to do to get things up and running. It may have changed, but frankly I have little interest in investigating it, and I expect most other people who drifted away from Perl are in a similar boat. Also, having developed an OO backend for a site running in Perl, I never wish to do so again. Your definition of 'better OO system' clearly differs from mine.
- KaeseEs 16y ago
  He's referring to Moose, which is an insanely good object system, which wasn't prevalent at all 18 months ago but is nearly de rigueur in all but a handful of cases today. It's a mashup of CLOS, Perl 6, Smalltalk and a few other things that remains consistent, Perlish and intuitive. It's also crazy extensible - just look at the MooseX namespace on CPAN to see what I mean.
  - prodigal_erik 16y ago
    How much of CPAN has been migrated to Moose, as opposed to directly calling "bless" as the docs[1] advocate even now? As I understand it, the story on interop between the two styles is "don't go there". [1]http://perldoc.perl.org/perlobj.html http://perldoc.perl.org/perlobj.html
    - berntb 16y ago
      The perlobj perldoc is about the old style OO -- and discusses the old style OO... :-) It doesn't discuss any CPAN modules at all (there are quite a lot about OO). Are you trolling? What problems do you mean with Moose and the blessed OO?
      - prodigal_erik 16y ago
        Not at all. I learned Perl from the manpages, and I'm mystified how noobs are to discover and convince themselves that "man perlobj" is now bad advice yet remains official. As for bless/Moose interop, I read somewhere there were big problems mixing the two but don't remember the specifics (I mostly dropped Perl a long time ago over its dogged attempts to guess what I probably wanted when I made a mistake). Others in this thread now say that's not true if it ever was, which is good news for users of pre-Moose CPAN modules.
        berntb 16y ago
        >>I learned Perl from the manpages Well, that was impressive. Stupid, but impressive... :-) >>discover and convince themselves that "man perlobj" is now bad advice yet remains official. AGAIN: Those man pages doesn't discuss CPAN modules. But afaik, they recommend books and the web...
- deleted 16y ago
  [deleted]
joe_the_user 16y ago
Post: "I've done a bit of X and my overall impression of Y in was..." Reply: "References, sources, double blind studies please! Prove you know what you're talking about..." It seems like asking for references has become a far too easy way to pull karma points, even against posts which make their sources fairly clear.
- berntb 16y ago
  Feel free to vote me down, if you're all about karma... :-) I asked because his claim went against what I've read on the subject. I don't really know, since I haven't really been working with web development for a couple of years (which is why I started with "Interesting").
  - jlees 16y ago
    I'll vote you down for calling me he. ;)
    - berntb 16y ago
      Long enough after to be invisible... I of course voted you up for that down vote. :-)

leif 16y ago

> from Perl to Python (it's a really easy jump) I disagree. Python is incredibly restrictive when you're used to perl. I would be so frustrated if I went that direction.

Goladus 16y ago
Just curious, what ways you found python restrictive?
- leif 16y ago
  The whole language is all One Way To Do It-ified. It's fine, there's nothing wrong with it, I just always feel a lot more like I'm part of a creative process when I'm working with perl, like it's this magic goop I can mush around and throw at anything and it'll do everything I can think of. With python, it feels more like I'm trying to fit my program into the python world, which is very nice and square and proper and everything works perfectly fine, except if I happen to want to do it the other way just for kicks, I can't. Or, worse, I can and the performance is crap for no obvious reason (or a very good obvious reason that should've been fixed ages ago by relaxing things just a little bit). I used to be a real big python fan, now it just seems like too much training wheels. I like perl's weirdness: its global variables, implicit returns, gotos and loop labels, weird calling conventions that, while unexpected, are perfectly well documented and reliable, and _boy_ do I love its string support.
  - Goladus 16y ago
    Ok, I was sort of hoping for a more concrete example. Do you mean like not being able to use 'unless' constructs? Not having regular expression operators? Not being able to reference default variables like $_? What is an example of doing it "the other way"? I can usually find several different ways to do anything in Python, too. In fact I find this is true even for trivial things. For example, here are 4 ways to parse /etc/passwd and return a list of objects such that you can reference each value by the field name, for example: >>> passwd_data('/etc/passwd')[5]['shell'] '/bin/bash' 4 ways: http://pastebin.com/wPa5q7Mc http://pastebin.com/wPa5q7Mc

rcfox 16y ago

> there are fewer libraries and interfaces and open source toolkits, etc Um... What? According to http://search.cpan.org/ http://search.cpan.org/, there are 85193 community-contributed modules. Okay, some of that is stupid stuff (http://search.cpan.org/perldoc?Acme::Meow http://search.cpan.org/perldoc?Acme::Meow) but they don't make up a large percentage. Compare that to PyPI's 11199 packages and RubyGems' 15674 gems.

pragmatic 16y ago
Yes, but do they _work_? That's why I became disillusioned with Perl, even though it was heavily used at my last company. I got the "oh, yeah, just go to CPAN and grab the module." I usually ended up using Java (how perverse is that?). I now prefer Python and C# because I find more stuff that works (but still plenty of broken old stuff).
- perigrin 16y ago
  The CPAN ecosystem provides some basic guarantees that I haven't seen mentioned for other language's repositories. For example every distribution uploaded to the CPAN is tested on some subset of (using last month's statistics[1]) 15 different operating systems, across 81 platforms, and 26 different versions of Perl. Not every package is tested on every perl and every platform because this is a volunteer effort, but the major platforms (Linux, Windows, BSD, Solaris) are generally covered. These test results are aggregated and reported on search.cpan.org. Every package uploaded is given a Bug Queue (rt.cpan.org) so bugs and patches can be reported to the author. Additionally distributions can now specify in their metadata (META.yaml/META.json) the source code repository for the code so you can see from search.cpan.org the place to get the latest code to patch against. Additionally there is a process that if a maintainer goes rogue and stops responding, packages can be taken over. This doesn't happen often but has been used when other options fail. Many modern projects have several co-maintainers who can all make releases lowering the "bus factor". Right now the biggest problem is finding the wheat for all the chaff. Sturgeon's Law applies, 90% of everything is crap. With 21038 (as of this writing) unique distributions, finding the ones that are well written, useful, and generally "best" is actually a difficult problem. You're not alone in finding that hard, but there are projects like Task::Kensho[2] to curate CPAN. This process is hard and would require a full time team of experts to perform properly. It is big problem but one I think I'd rather have than when I was (for example) working in Java in 2005 and not only had to go through the effort of assessing the module in question (will this work? is it good? will I have problems later) but also had to hunt around the web for where all the different projects were located. [1]: http://stats.cpantesters.org/ http://stats.cpantesters.org/ [2]: Full disclosure, Task::Kensho is a project I started in 2007 based upon the feedback of several people in the Perl community.