5 ms·

I agree with everyone that Perl syntax can look random gibberish, however, their particular Perl example seems quite easy to interpret.

by Jun8 16y ago

lars512 16y ago
Sure, it's roughly readable, but even here Perl makes several aspects of the loop implicit and buried in syntax (the line variable, stdin as source of the lines).
- pyre 16y ago
  Perl doesn't make it implicit, the programmer does. It could easily be rewritten as: foreach my $line (<STDIN>) { foreach my $word (split($line)) { print "$word\n" if $word =~ /ing$/; } } The programmer made a conscious decision to read STDIN implicitly in a while loop and then call split with implicit usage of $_, then went on to complain that too much was hidden away. I could make the python example equally obtuse: import sys, re for a in sys.fopen(sys.stdin.fileno(),'r',1): for b in re.split(a,r''): if re.search(b,r'.*ing$') print b Compressed forms: # PERL map { print "$_\n" } grep { /ing$/ } map { split($_) } <STDIN>; # PYTHON import sys for a in [ a for a in [ b for a in sys.stdin for b in a.split() ] if a.endswith('ing') ]: print a # PYTHON import sys print "\n".join(filter(lambda x: x.endswith('ing'), [ var2 for var1 in sys.stdin for var2 in var1.split() ]))
  - lars512 16y ago
    Individual programmer style does matter, but languages also guide our style. I'm often asked to convert Perl scripts to Python scripts, and the originals don't exhibit the "optional readability" you're advertising, and which Python encourages by default. An entirely different angle on all of this is that NLTK is aimed at novice programmers (linguists) as well as expert programmers (CS students). Perhaps readability is a different concept for these two user groups...
    - phaylon 16y ago
      Well, since Perl was first designed by a linguist, one might think they aren't all of one mindset :)
  - l0nwlf 16y ago
    "There should be one-- and preferably only one --obvious way to do it." and your code mylord does not passes the bill. Also I do agree with OP, python support readability and it make sense to choose it over other languages where clarity matters. Every language have their own use-case, python suits here quite well.
    - kscaldef 16y ago
      Well, of course, when you assume that the design criteria of Python are the correct ones you reach the conclusion that Python is the preferred language to use. However, even Python fails here. I would say it's "obvious" that you should use filter rather than the for/if combination. Perhaps to someone else it's "obvious" that you should use a list comprehension.
    - sigzero 16y ago
      If find that once you get beyond the "easy" in code there is rarely only "one obvious way" to do it.
pyre 16y ago
Yea. I don't agree with them ragging on the '$' in the Perl example. I could have made the Python code just as obtuse by using the regex library rather than word.endswith(). Ragging on a language because a beginner doesn't understand regular expressions seems a bit misleading. They are also inconsistent with their coding style. In the while() loop, they make use of $_ implicitly (even in the split statement in the foreach loop), but in the foreach loop, they don't use $_, but instead define $word. Then they go off on split being 'difficult to guess what it represents.' > Having used Perl ourselves in research and teaching > since the 1980s, we have found that Perl programs of > any size are inordinately difficult to maintain and > re-use. Says more about the programmer than the language. You can write maintainable code in any language. "Too many choices" doesn't cause code to be unmaintainable. Lack of discipline in your programming practices does (as well as lack of documentation). Saying that a language is better in this respect is just to say that "X language took the ability to choose away from me so that I'm forced to do things a certain way, whether I like it or not."
- sigzero 16y ago
  I agree with you. Bad code isn't the programming languages fault. Bad code is the programmer's fault. Perl itself and the Perl culture has changed enormously since the "1980s".

I agree with everyone that Perl syntax can look random gibberish, however, their particular Perl example seems quite easy to interpret.

by Jun8 16y ago

I agree with everyone that Perl syntax can look random gibberish, however, their particular Perl example seems quite easy to interpret.

lars512 16y ago

Sure, it's roughly readable, but even here Perl makes several aspects of the loop implicit and buried in syntax (the line variable, stdin as source of the lines).

pyre 16y ago
Perl doesn't make it implicit, the programmer does. It could easily be rewritten as: foreach my $line (<STDIN>) { foreach my $word (split($line)) { print "$word\n" if $word =~ /ing$/; } } The programmer made a conscious decision to read STDIN implicitly in a while loop and then call split with implicit usage of $_, then went on to complain that too much was hidden away. I could make the python example equally obtuse: import sys, re for a in sys.fopen(sys.stdin.fileno(),'r',1): for b in re.split(a,r''): if re.search(b,r'.*ing$') print b Compressed forms: # PERL map { print "$_\n" } grep { /ing$/ } map { split($_) } <STDIN>; # PYTHON import sys for a in [ a for a in [ b for a in sys.stdin for b in a.split() ] if a.endswith('ing') ]: print a # PYTHON import sys print "\n".join(filter(lambda x: x.endswith('ing'), [ var2 for var1 in sys.stdin for var2 in var1.split() ]))
- lars512 16y ago
  Individual programmer style does matter, but languages also guide our style. I'm often asked to convert Perl scripts to Python scripts, and the originals don't exhibit the "optional readability" you're advertising, and which Python encourages by default. An entirely different angle on all of this is that NLTK is aimed at novice programmers (linguists) as well as expert programmers (CS students). Perhaps readability is a different concept for these two user groups...
  - phaylon 16y ago
    Well, since Perl was first designed by a linguist, one might think they aren't all of one mindset :)
- l0nwlf 16y ago
  "There should be one-- and preferably only one --obvious way to do it." and your code mylord does not passes the bill. Also I do agree with OP, python support readability and it make sense to choose it over other languages where clarity matters. Every language have their own use-case, python suits here quite well.
  - kscaldef 16y ago
    Well, of course, when you assume that the design criteria of Python are the correct ones you reach the conclusion that Python is the preferred language to use. However, even Python fails here. I would say it's "obvious" that you should use filter rather than the for/if combination. Perhaps to someone else it's "obvious" that you should use a list comprehension.
  - sigzero 16y ago
    If find that once you get beyond the "easy" in code there is rarely only "one obvious way" to do it.

pyre 16y ago

Yea. I don't agree with them ragging on the '$' in the Perl example. I could have made the Python code just as obtuse by using the regex library rather than word.endswith(). Ragging on a language because a beginner doesn't understand regular expressions seems a bit misleading. They are also inconsistent with their coding style. In the while() loop, they make use of $_ implicitly (even in the split statement in the foreach loop), but in the foreach loop, they don't use $_, but instead define $word. Then they go off on split being 'difficult to guess what it represents.' > Having used Perl ourselves in research and teaching > since the 1980s, we have found that Perl programs of > any size are inordinately difficult to maintain and > re-use. Says more about the programmer than the language. You can write maintainable code in any language. "Too many choices" doesn't cause code to be unmaintainable. Lack of discipline in your programming practices does (as well as lack of documentation). Saying that a language is better in this respect is just to say that "X language took the ability to choose away from me so that I'm forced to do things a certain way, whether I like it or not."

sigzero 16y ago
I agree with you. Bad code isn't the programming languages fault. Bad code is the programmer's fault. Perl itself and the Perl culture has changed enormously since the "1980s".