11 ms·

Yes: Perl. This was the original use case for the language. We used to have to glue together sh, awk, sed, grep, CLIs (custom C), etc in order to automate any

Yes: Perl. This was the original use case for the language. We used to have to glue together sh, awk, sed, grep, CLIs (custom C), etc in order to automate anything in Unix. Perl brought all of this functionality under one roof with a simple, coherent interface. Most every complaint I read about Perl (too flexible, weird sigils) is a direct reflection of the system it was replacing. It's funny to read how people love that there's more than one way to do just about anything in Linux, but gasp that there are too many ways to do equivalent actions within Perl. They're one in the same. (I am not going to re-re-address its "readonly" nature since that's a red herring which applies to any language.)

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).
camel7k 15y ago
Don't tell a lie. What's the best way to interleave two Python lists? http://blog.jarrodmillman.com/2010/10/whats-best-way-to-interleave-two-python.html http://blog.jarrodmillman.com/2010/10/whats-best-way-to-inte... Fucking many ways to do something also in Python.

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).

camel7k 15y ago

Don't tell a lie. What's the best way to interleave two Python lists? http://blog.jarrodmillman.com/2010/10/whats-best-way-to-interleave-two-python.html http://blog.jarrodmillman.com/2010/10/whats-best-way-to-inte... Fucking many ways to do something also in Python.