4 ms·

I used perl for about 5 years for general scripting tasks. It's not about there being too many ways to do something for me, it's that you need to know the subtl

by bwarp 15y ago

I used perl for about 5 years for general scripting tasks. It's not about there being too many ways to do something for me, it's that you need to know the subtlety of each one and cryptic abbreviations.

jleader 15y ago
Regarding "cryptic abbreviations", do you know about "use English;"? It provides readable names for all the "ugly punctuation variables". It's included as part of the core Perl install. http://perldoc.perl.org/English.html http://perldoc.perl.org/English.html
- bwarp 15y ago
  use English in itself is a sign of much turdyness.
fabricode 15y ago
In probably 99% of Perl code, you only need to know two cryptic symbols: $! for errno and $? for child-process exit status. And if you're programming in shell now, you're already using $?. Yes, there are symbols for handling autoflush on handles, input/output record separators, etc. But rarely will you need to use these items. In fact, we have methods for handling these situations for quite some time now. For instance, to unbuffer your output you'd use $|, but now you just use $filehandle->autoflush(1). Another example would be undefining the input record separator so that you could pull in an entire file with one read, but now that's handled via Slurp::slurp_file.
kamaal 15y ago
Can you suggest a real usable pragmatic option to Perl on a Unix scripting environment? Python and Ruby tried to compete with Perl at the large application level. Interacting with databases and other stuff kind of things. That still doesn't fulfill the requirements Perl was invented for. Larry Wall invented Perl not because he wanted a Python or Ruby, The Python and Ruby of that time were already present in the form of C. Perl was invented because C couldn't do a certain things well. Namely it never natively blended with the Unix philosophy. It couldn't do 'Text' properly. It could not be what awk, sed, grep and other Text processing utilities combined together would be. Besides all that, Perl is a natural evolution to bash, shell, sed, awk, tr, cat and many many other text processing utilities combined together working together in a very large application. That continues to remain Perl's biggest and most distinctive unbeatable advantage so far. Perl is a natural extension to Unix, and it has evolved to now be capable of doing nearly everything. If the name Perl would not have been given to Perl, it would probably Unix programming language. Think of it in that terms. Do you know why despite so much trolling, bashing and criticism Perl receives. It still manages to grow and thrive year after year, decade after decade? Its because Perl is same as C, Lisp, SQL etc. Its a first time done right language. Anything that is likely to replace Perl, will be a bad replacement to Perl. Or at maximum will be or look like Perl(Eg Perl 6). To kill Perl you may have to kill the whole Unix philosophy. Because that is what Perl is. Its a natural extension to Unix. Perl is here to stay for decades to come. Every new generation of programmers will discover Perl and use it just like how every new generation of programmers discover and use C and Lisp. That is what enables stuff like DuckDuckGo to be built in Perl.
- gettygermany 15y ago
  Impressive post... Perl Marketing and DuckDuckGo wanna thank you for those wise words :-) (from a guy working for both). Would be nice if you would get into contact with me: getty@duckduckgo.com or getty@cpan.org ;)
- bwarp 15y ago
  I'll probably get downvoted for this. I know Perl very well which is why I don't use it. I disagree with you... If UNIX was a schizophrenic, paranoid, indecisive, eclectic, personality-disorder equipped operating system, then you'd be right but it's not. It's pretty well thought out (I exclude Linux from that which is a right mess). Perl is not a natural evolution of, but a putrid mishmash of shell, sed, awk, tr, cat etc bundled into an incongruous monolithic blob with groupies from the cult of CPAN knocking off the edge cases left right and centre when it doesn't do what you want (using bits of C in some cases!!). Perl is not the UNIX philosophy of small tools and loose coupling. It's entirely the opposite: A monolithic turd that just won't flush. DuckDuckGo was probably built in Perl beause the individual who built it probably knew Perl. You could build DDG in C# or Java if you really wanted! (and it'd spend less time waiting for the Perl interpreter to tick).
  - gettygermany 15y ago
    If you use Perl in CGI only then you seem to misunderstand lots of stuff. The Perl interpreter is loaded once per FastCGI task, so noone waits.... its the startup (which is then 100times faster against C# or Java, but whatever, not the topic). So please, dont compare Apples with Pears.
    - bwarp 15y ago
      I rarely use Perl CGI. I haven't since about 2002. Regarding C# and Java startup. It's not an issue. You can warm start appdomains/JVMs. We do this. Once it's running, both Java and C# run rings around most things.
  - kamaal 15y ago
    One can build anything in any language(considering the mathematical possibility). So by this definition we can all go back to building in Nand gates. But that is not what its all about. Languages get used because they do a certain job well. Perl does, what it was designed to do very well. That is precisely what Larry wall's water bed theory of complexity is about(http://en.wikipedia.org/wiki/Waterbed_theory http://en.wikipedia.org/wiki/Waterbed_theory). You have a problem with CPAN? With CPAN, really? A ecosystem that is considered as a killer feature which no other language has managed to emulate so far? And Perl is monolithic???? Really? Are you aware what you are talking about. Are you just debating for debating's sake? Perl is probably the most extensible and flexible languages that is out there. That is what enables modules like Devel::Declare(http://search.cpan.org/~zefram/Devel-Declare-0.006011/lib/Devel/Declare.pm http://search.cpan.org/~zefram/Devel-Declare-0.006011/lib/De...) to be written. Which is what enable gems like Moose to be built(http://search.cpan.org/search?query=Moose&mode=all http://search.cpan.org/search?query=Moose&mode=all) Outside Lisp, Perl is probably the most flexible and most extensible language that exist. The entire CPAN is a standing proof of that. Have you read Mark Jason Dominus's Higher order Perl, Have you read chromatic's Modern Perl? When you talk of elegance and power? You call Perl a mess of a hundred text processing utilities. Can you show me one language that does regular expressions as well as Perl? Can you show me one language that handles Unicode better than Perl? Every other language I know creates huge spaghetti mess for even simple things like opening files and matching regular expressions. Have you used things like Parse::RecDescent?? Perl also gave a lot of other beautiful things to the world. Thinks like the Artistic License. Not just that Perl is the only language community that has had more syntax based feature additions in the recent past than the rest. They have managed to release great features in the recent past.

by bwarp 15y ago

jleader 15y ago

Regarding "cryptic abbreviations", do you know about "use English;"? It provides readable names for all the "ugly punctuation variables". It's included as part of the core Perl install. http://perldoc.perl.org/English.html http://perldoc.perl.org/English.html

bwarp 15y ago
use English in itself is a sign of much turdyness.

fabricode 15y ago

In probably 99% of Perl code, you only need to know two cryptic symbols: $! for errno and $? for child-process exit status. And if you're programming in shell now, you're already using $?. Yes, there are symbols for handling autoflush on handles, input/output record separators, etc. But rarely will you need to use these items. In fact, we have methods for handling these situations for quite some time now. For instance, to unbuffer your output you'd use $|, but now you just use $filehandle->autoflush(1). Another example would be undefining the input record separator so that you could pull in an entire file with one read, but now that's handled via Slurp::slurp_file.

kamaal 15y ago

Can you suggest a real usable pragmatic option to Perl on a Unix scripting environment? Python and Ruby tried to compete with Perl at the large application level. Interacting with databases and other stuff kind of things. That still doesn't fulfill the requirements Perl was invented for. Larry Wall invented Perl not because he wanted a Python or Ruby, The Python and Ruby of that time were already present in the form of C. Perl was invented because C couldn't do a certain things well. Namely it never natively blended with the Unix philosophy. It couldn't do 'Text' properly. It could not be what awk, sed, grep and other Text processing utilities combined together would be. Besides all that, Perl is a natural evolution to bash, shell, sed, awk, tr, cat and many many other text processing utilities combined together working together in a very large application. That continues to remain Perl's biggest and most distinctive unbeatable advantage so far. Perl is a natural extension to Unix, and it has evolved to now be capable of doing nearly everything. If the name Perl would not have been given to Perl, it would probably Unix programming language. Think of it in that terms. Do you know why despite so much trolling, bashing and criticism Perl receives. It still manages to grow and thrive year after year, decade after decade? Its because Perl is same as C, Lisp, SQL etc. Its a first time done right language. Anything that is likely to replace Perl, will be a bad replacement to Perl. Or at maximum will be or look like Perl(Eg Perl 6). To kill Perl you may have to kill the whole Unix philosophy. Because that is what Perl is. Its a natural extension to Unix. Perl is here to stay for decades to come. Every new generation of programmers will discover Perl and use it just like how every new generation of programmers discover and use C and Lisp. That is what enables stuff like DuckDuckGo to be built in Perl.

gettygermany 15y ago
Impressive post... Perl Marketing and DuckDuckGo wanna thank you for those wise words :-) (from a guy working for both). Would be nice if you would get into contact with me: getty@duckduckgo.com or getty@cpan.org ;)
bwarp 15y ago
I'll probably get downvoted for this. I know Perl very well which is why I don't use it. I disagree with you... If UNIX was a schizophrenic, paranoid, indecisive, eclectic, personality-disorder equipped operating system, then you'd be right but it's not. It's pretty well thought out (I exclude Linux from that which is a right mess). Perl is not a natural evolution of, but a putrid mishmash of shell, sed, awk, tr, cat etc bundled into an incongruous monolithic blob with groupies from the cult of CPAN knocking off the edge cases left right and centre when it doesn't do what you want (using bits of C in some cases!!). Perl is not the UNIX philosophy of small tools and loose coupling. It's entirely the opposite: A monolithic turd that just won't flush. DuckDuckGo was probably built in Perl beause the individual who built it probably knew Perl. You could build DDG in C# or Java if you really wanted! (and it'd spend less time waiting for the Perl interpreter to tick).
- gettygermany 15y ago
  If you use Perl in CGI only then you seem to misunderstand lots of stuff. The Perl interpreter is loaded once per FastCGI task, so noone waits.... its the startup (which is then 100times faster against C# or Java, but whatever, not the topic). So please, dont compare Apples with Pears.
  - bwarp 15y ago
    I rarely use Perl CGI. I haven't since about 2002. Regarding C# and Java startup. It's not an issue. You can warm start appdomains/JVMs. We do this. Once it's running, both Java and C# run rings around most things.
- kamaal 15y ago
  One can build anything in any language(considering the mathematical possibility). So by this definition we can all go back to building in Nand gates. But that is not what its all about. Languages get used because they do a certain job well. Perl does, what it was designed to do very well. That is precisely what Larry wall's water bed theory of complexity is about(http://en.wikipedia.org/wiki/Waterbed_theory http://en.wikipedia.org/wiki/Waterbed_theory). You have a problem with CPAN? With CPAN, really? A ecosystem that is considered as a killer feature which no other language has managed to emulate so far? And Perl is monolithic???? Really? Are you aware what you are talking about. Are you just debating for debating's sake? Perl is probably the most extensible and flexible languages that is out there. That is what enables modules like Devel::Declare(http://search.cpan.org/~zefram/Devel-Declare-0.006011/lib/Devel/Declare.pm http://search.cpan.org/~zefram/Devel-Declare-0.006011/lib/De...) to be written. Which is what enable gems like Moose to be built(http://search.cpan.org/search?query=Moose&mode=all http://search.cpan.org/search?query=Moose&mode=all) Outside Lisp, Perl is probably the most flexible and most extensible language that exist. The entire CPAN is a standing proof of that. Have you read Mark Jason Dominus's Higher order Perl, Have you read chromatic's Modern Perl? When you talk of elegance and power? You call Perl a mess of a hundred text processing utilities. Can you show me one language that does regular expressions as well as Perl? Can you show me one language that handles Unicode better than Perl? Every other language I know creates huge spaghetti mess for even simple things like opening files and matching regular expressions. Have you used things like Parse::RecDescent?? Perl also gave a lot of other beautiful things to the world. Thinks like the Artistic License. Not just that Perl is the only language community that has had more syntax based feature additions in the recent past than the rest. They have managed to release great features in the recent past.