6 ms·

Isn't that the Perl culture? As someone who has seen a lot of Perl code, I'm serious.

by va_coder 15y ago

Mithaldu 15y ago
I'd like to answer, but the question is a bit vague. What are you referring to with "that"?
- mgkimsal 15y ago
  I took "that" to mean "hard to read / cryptic code".
  - Mithaldu 15y ago
    That is by far not the norm for code written nowadays by CPAN authors who are aware of advances in the art. Have as an example the code in the very first module featured on frepan.org at the moment: https://metacpan.org/source/ALEXMV/Module-Refresh-0.17/lib/Module/Refresh.pm#L73 https://metacpan.org/source/ALEXMV/Module-Refresh-0.17/lib/M...
    - w0utert 15y ago
      Well, that code starts out with the following procedure: ====>8====>8====>8====>8====>8====>8====>8====>8====>8====>8====>8====>8====>8====>8 BEGIN { # Turn on the debugger's symbol source tracing $^P |= 0x10; # Work around bug in pre-5.8.7 perl where turning on $^P # causes caller() to be confused about eval {}'s in the stack. # (See http://rt.perl.org/rt3/Ticket/Display.html?id=35059 for more info.) eval 'sub DB::sub' if $] < 5.008007; } ====>8====>8====>8====>8====>8====>8====>8====>8====>8====>8====>8====>8====>8====>8 As someone with a 2-digit number of years of experience in 4 different programming and casual experience with about 4 others, I couldn't for the life of me have figure out what that code does, if some hadn't commented it. The rest of the code looks a bit like PHP by the way, except uglier (not trying to flame here, just my opinion). Maybe some day someone will be able to explain why anyone in their right mind would voluntarily choose to program in Perl, if not because of prior experience with the language, or some form of religious beliefs. The 'look at the xyz CPAN modules!' argument doesn't really cut it for me.
      - Mithaldu 15y ago
        Literally the only hard part there are the magic variables, which one can look up easily as long as one knows that they're all listed under `perldoc perlvar`. (Though i'd like to mention that he should've used `use English;`.) Either way, my point still stands. I took an entirely random and fresh piece of code and aside from one tiny well-documented bit, all of it is easily readable and most importantly: Extremely different from the code example used in that study. The rest of your comment does not merit discussion because you've your prejudices and are content with them.
        w0utert 15y ago
        > Literally the only hard part there are the magic variables [..] Sure, I'm not even saying that stuff like this makes Perl 'hard', just obscure and in many cases obfuscated. I have no idea whether you could write non-trivial Perl code that doesn't use magic variables or weird operators, but every piece of Perl code I have ever had to read or debug/maintain has suggested it's an integral aspect of the language. Maybe I've just been unlucky so far... The code you linked to contains lots of other weird and obscure stuff by the way, I just picked the first routine to make my point. To illustrate it in another way: I challenge anyone who doesn't know anything about Perl to explain why there is another block labelled 'BEGIN' at the end of the module, which goes like this, and what it is needed for: ==>8==>8==>8==>8==>8==>8==>8==>8==>8==>8==>8==>8==>8==>8==>8==>8 no strict 'refs'; foreach my $sym ( sort keys %{ __PACKAGE__ . '::' } ) { next if $sym eq 'VERSION'; my $code = __PACKAGE__->can($sym) or next; delete ${ __PACKAGE__ . '::' }{$sym}; *$sym = sub { goto &$code }; } ==>8==>8==>8==>8==>8==>8==>8==>8==>8==>8==>8==>8==>8==>8==>8==>8 Imagine having to come up with this if you are new to Perl programming :-S > The rest of your comment does not merit discussion because you've your prejudices and are content with them That's funny, I hear the exact same thing every time I ask someone about what makes Perl great, and how it stands out from any other language. Somehow I never get a real answer, just accusations of being prejudiced or anti-Perl. I'm not against any programming language (except maybe VB ;-), I'm just curious why Perl is still relevant for anything except legacy code, now that we have so many nice languages for almost every problem domain.
    - mgkimsal 15y ago
      There's different things being discussed here at this point. You're saying "CPAN authors don't write crappy code". Fair point, but CPAN authors aren't looking for tutorials, nor are they writing tutorials (otherwise, they'd be tutorial authors, not CPAN authors). The original point was that googling for tutorials brings up old crappy code. What modern perl experts write has no bearing on this issue. What's needed is an concerted effort to have those talented CPAN authors focus their efforts on writing modern tutorials, publicizing them, getting linked, and also contacting owners of older tutorials and asking them to link to the modern stuff. It won't happen overnight, but there's a cyclical downward spiral with perl that needs to be stopped. People looking at old/bad perl tutorials may never get to the point where they even learn about or use CPAN in the first place, and won't get exposed to better techniques. Many tutorials in other languages are bad, of course, but compare a bad PHP tutorial to a bad perl one, and the PHP will still be easier for newbs to grok.
      - Mithaldu 15y ago
        Let me just point out that i wrote the linked blog post. :) I agree with everything you said and would like to make it more succinctly: We need to figure out a way to make what CPAN authors write relevant for newbies.
        cube13 15y ago
        >I agree with everything you said and would like to make it more succinctly: We need to figure out a way to make what CPAN authors write relevant for newbies. Unfortunately, I'm not sure if this is going to help all that much at this point. I think the main group of people that use the current, rather poor tutorials are newbie(or even experienced) developers that have inherited Perl code that uses the language in a way that they have never encountered before. Those devs need a good way to find all the insane single character typing optimizations built into the language. If you have a script that consists of one 1500 character line with approximately 10 alphanumeric characters total, well written Perl examples aren't going to help you figure it out that much. Sure, it will help if you're a complete newbie to Perl, and learning it from scratch. For those people, drilling good coding standards into them from day 1 is a GREAT thing, if for no other reason than to avoid the spaghetti that plagues a lot of Perl.
mchanson 15y ago
I think there are two very different sides to perl culture. About ten years ago I worked on a OO Perl project which was ~10k lines. It had coding standards, test suites, documentation, and was easy to maintain and bring new engineers into. The other side is hacked together scripts. Which have their place, but are often a mess.
- Mithaldu 15y ago
  Actually, there is a name for both sides: There is the CPAN, which is obviously what it is; And there is the DarkPAN, a term describing all the internal projects in companies, or small tools hacked together by people who don't know or care about the CPAN.
  - jpdoctor 15y ago
    > or small tools hacked together by people who don't know or care about the CPAN. In some parts, the latter is referred to as BedPAN.

Isn't that the Perl culture? As someone who has seen a lot of Perl code, I'm serious.

Mithaldu 15y ago

I'd like to answer, but the question is a bit vague. What are you referring to with "that"?

mgkimsal 15y ago
I took "that" to mean "hard to read / cryptic code".
- Mithaldu 15y ago
  That is by far not the norm for code written nowadays by CPAN authors who are aware of advances in the art. Have as an example the code in the very first module featured on frepan.org at the moment: https://metacpan.org/source/ALEXMV/Module-Refresh-0.17/lib/Module/Refresh.pm#L73 https://metacpan.org/source/ALEXMV/Module-Refresh-0.17/lib/M...
  - w0utert 15y ago
    Well, that code starts out with the following procedure: ====>8====>8====>8====>8====>8====>8====>8====>8====>8====>8====>8====>8====>8====>8 BEGIN { # Turn on the debugger's symbol source tracing $^P |= 0x10; # Work around bug in pre-5.8.7 perl where turning on $^P # causes caller() to be confused about eval {}'s in the stack. # (See http://rt.perl.org/rt3/Ticket/Display.html?id=35059 for more info.) eval 'sub DB::sub' if $] < 5.008007; } ====>8====>8====>8====>8====>8====>8====>8====>8====>8====>8====>8====>8====>8====>8 As someone with a 2-digit number of years of experience in 4 different programming and casual experience with about 4 others, I couldn't for the life of me have figure out what that code does, if some hadn't commented it. The rest of the code looks a bit like PHP by the way, except uglier (not trying to flame here, just my opinion). Maybe some day someone will be able to explain why anyone in their right mind would voluntarily choose to program in Perl, if not because of prior experience with the language, or some form of religious beliefs. The 'look at the xyz CPAN modules!' argument doesn't really cut it for me.
    - Mithaldu 15y ago
      Literally the only hard part there are the magic variables, which one can look up easily as long as one knows that they're all listed under `perldoc perlvar`. (Though i'd like to mention that he should've used `use English;`.) Either way, my point still stands. I took an entirely random and fresh piece of code and aside from one tiny well-documented bit, all of it is easily readable and most importantly: Extremely different from the code example used in that study. The rest of your comment does not merit discussion because you've your prejudices and are content with them.
      - w0utert 15y ago
        > Literally the only hard part there are the magic variables [..] Sure, I'm not even saying that stuff like this makes Perl 'hard', just obscure and in many cases obfuscated. I have no idea whether you could write non-trivial Perl code that doesn't use magic variables or weird operators, but every piece of Perl code I have ever had to read or debug/maintain has suggested it's an integral aspect of the language. Maybe I've just been unlucky so far... The code you linked to contains lots of other weird and obscure stuff by the way, I just picked the first routine to make my point. To illustrate it in another way: I challenge anyone who doesn't know anything about Perl to explain why there is another block labelled 'BEGIN' at the end of the module, which goes like this, and what it is needed for: ==>8==>8==>8==>8==>8==>8==>8==>8==>8==>8==>8==>8==>8==>8==>8==>8 no strict 'refs'; foreach my $sym ( sort keys %{ __PACKAGE__ . '::' } ) { next if $sym eq 'VERSION'; my $code = __PACKAGE__->can($sym) or next; delete ${ __PACKAGE__ . '::' }{$sym}; *$sym = sub { goto &$code }; } ==>8==>8==>8==>8==>8==>8==>8==>8==>8==>8==>8==>8==>8==>8==>8==>8 Imagine having to come up with this if you are new to Perl programming :-S > The rest of your comment does not merit discussion because you've your prejudices and are content with them That's funny, I hear the exact same thing every time I ask someone about what makes Perl great, and how it stands out from any other language. Somehow I never get a real answer, just accusations of being prejudiced or anti-Perl. I'm not against any programming language (except maybe VB ;-), I'm just curious why Perl is still relevant for anything except legacy code, now that we have so many nice languages for almost every problem domain.
  - mgkimsal 15y ago
    There's different things being discussed here at this point. You're saying "CPAN authors don't write crappy code". Fair point, but CPAN authors aren't looking for tutorials, nor are they writing tutorials (otherwise, they'd be tutorial authors, not CPAN authors). The original point was that googling for tutorials brings up old crappy code. What modern perl experts write has no bearing on this issue. What's needed is an concerted effort to have those talented CPAN authors focus their efforts on writing modern tutorials, publicizing them, getting linked, and also contacting owners of older tutorials and asking them to link to the modern stuff. It won't happen overnight, but there's a cyclical downward spiral with perl that needs to be stopped. People looking at old/bad perl tutorials may never get to the point where they even learn about or use CPAN in the first place, and won't get exposed to better techniques. Many tutorials in other languages are bad, of course, but compare a bad PHP tutorial to a bad perl one, and the PHP will still be easier for newbs to grok.
    - Mithaldu 15y ago
      Let me just point out that i wrote the linked blog post. :) I agree with everything you said and would like to make it more succinctly: We need to figure out a way to make what CPAN authors write relevant for newbies.
      - cube13 15y ago
        >I agree with everything you said and would like to make it more succinctly: We need to figure out a way to make what CPAN authors write relevant for newbies. Unfortunately, I'm not sure if this is going to help all that much at this point. I think the main group of people that use the current, rather poor tutorials are newbie(or even experienced) developers that have inherited Perl code that uses the language in a way that they have never encountered before. Those devs need a good way to find all the insane single character typing optimizations built into the language. If you have a script that consists of one 1500 character line with approximately 10 alphanumeric characters total, well written Perl examples aren't going to help you figure it out that much. Sure, it will help if you're a complete newbie to Perl, and learning it from scratch. For those people, drilling good coding standards into them from day 1 is a GREAT thing, if for no other reason than to avoid the spaghetti that plagues a lot of Perl.

mchanson 15y ago

I think there are two very different sides to perl culture. About ten years ago I worked on a OO Perl project which was ~10k lines. It had coding standards, test suites, documentation, and was easy to maintain and bring new engineers into. The other side is hacked together scripts. Which have their place, but are often a mess.

Mithaldu 15y ago
Actually, there is a name for both sides: There is the CPAN, which is obviously what it is; And there is the DarkPAN, a term describing all the internal projects in companies, or small tools hacked together by people who don't know or care about the CPAN.
- jpdoctor 15y ago
  > or small tools hacked together by people who don't know or care about the CPAN. In some parts, the latter is referred to as BedPAN.