Re: [PATCH] [DOCS] Modernize perlopentut.pod

From: Nathaniel R. Reindl

Date: July 23, 2011 03:38

Subject: Re: [PATCH] [DOCS] Modernize perlopentut.pod

Message ID: CADNnFb7CiR0pyd1Y7fq-Ko63839sregb+gLSXKiVE8fUFAuNjA@mail.gmail.com

July 23, 2011 03:38Re: [PATCH] [DOCS] Modernize perlopentut.pod

On Tue, Jul 19, 2011 at 9:39 PM, Aristotle Pagaltzis <pagaltzis@gmx.de> wrote: > But that’s a shell-ish design that is closer to UI than API and > of interest primarily in the classic sysadmin stratum of Perl[1] > users. It can be actively unwanted in other strata. As a practicing system administrator on modern systems, I find myself writing scripts in well-structured and testable POSIX/Bourne shell and POSIX awk/sed more often than I find myself writing scripts in Perl. The motivation for this stems from the fact that my system of choice no longer includes Perl in the base OS install. Even then, when I do write system administration scripts in Perl, I use modules like FileHandle.pm and IO::File and bind the resulting instances to lexical variables. Given the advent of the SUS and the rapidly increasing (often implicit, due to licensing) compliance of modern systems to the SUS, I expect more practicing system administrators to go back to basics and focus more on using these tools. As the years drag on, I also expect that the old gripes about incompatibility between vendors' commands will hence become a distant memory for those of us who remember such things. That all said, I'd rather see Perl become a real, bona-fide programming language that I can easily use for implementing large, gnarly systems. Part of this future involves a pedagogical renaissance of sorts, and instructing newbies on the use of two-argument open seems to me somewhat counterproductive to this end. As a consequence, the instruction on two-argument (and one-argument) open should come ideally from material not meant for crib reading. Recall that, when you were a child, your bicycle had stabilizers in order to get you used to the sense of normalcy when riding before actually knowing how. Consider my proposal to move the material on two- and one-argument open elsewhere somewhat of an analogue. Besides, if you're wanting to convert system administrators partially into developers for the impending "devops" revolution, you'll have to include best practices in there somewhere. The best practices for two-argument open are challenging to enumerate at best and impossible at worst. tl;dr: I want to use Perl to write programs, not scripts. I've not used open in years, but I appreciate the significance. Stop and think about the education and outreach challenges inherent in some of Perl's features. /n



