Re: Starting Perl

[drieux]

On Saturday, Nov 15, 2003, at 23:38 US/Pacific, R. Joseph Newton wrote:
[..]
The most recent comment seems to be about the organizational process
involved with keeping files sorted by category.  It is a fairly
straightforward issue.  It seemed a very cogent point.  Nothing in
the origin of the thread concerns the fine detail of
maintaining concurrency in an enterprise development environment.
That is material for next term, or maybe next year, for the OP.
[..]

and your point?

When should persons new to coding and/or perl be introduced
to the ongoing problems that both professional and amatuer
coders are all going to have to deal with, namely the classic
conflict between
        code design
        code maintenance
It's not like I presume that in the best of all possible worlds
folks will waltz in and have the best of all possible organization
processes in play. If anything the problem as the OP and I have
chatted a bit back channel, is that no one is teaching them about
the Great Holy Wars about which were the top level directories
in the Unix Grand Struggle between the forces of SYSV v. BSD
let alone the compromises that became the POSIX approach.
So why not offer some ideas on why a person can replicate the
basic structure in their own home directory with
        /bin
        /lib
        /include
        /src
        /tmp
        /man
        /doc
This provides them with a basic framework of thinking about
how to provide SOME structure to that process. It also helps
them prep up for the rest of the core work that they will
need to acquire along the way. Clearly if they want to
test their installer, they can target
        $ENV{HOME}/bin
        $ENV{HOME}/lib/perl
They will also be able to run their own code at the command
line, or by what ever means floats their boat, by making
sure that their PATH element has that $HOME/bin element,
most likely as the first... it of course will then be
able to use as folks like to note, the FindBin offset
and/or the standard 'use lib' tricks - and NOT require
that they bloat out their command line shell environment.
Since at some point in the process they ARE going to wind
up asking that Ugly Question
        I have some [functions,globals,configInfo] that I want
                to share between scripts....
and then they are no longer in the happy land of merely
cobbling a few scripts here or there...
The ChomskyIte freaks tend to get into ideological struggles
about the technical minutia of syntax and semantics, and one
knows that the coding language one is working with has fully
arrived when it CAN have it's very own "Obfuscatory <ourLanguage>"
contest to establish the complete WhackoNeff that 'can' be
done in a language. Most folks forget that these started out
originally based upon the unpleasantries of 'spaghetti code'
that was unreadable, unfathomable, and PAINFULLY unmaintainable.
So the obligatory "Obfuscatory <ourLanguage>" contests, in
which I also include 'perl golf' are great for showing the
arcanea, as well as for demonstrating where THAT EDGE lies.
This allows one's fellow peers and associates to politely
recommend that one 'refactor that code' by simply suggesting
that it
        a. could have won the Obfuscatory contest in <year>
        b. should be nominated for this years contest.
and hence that there might be some 'best practice' that
was overlooked and should be reconsidered. If anything I
so enjoy watching the young bucks come up with, well,
"interesting solutions" to technical minutia. And the
stuff worth remembering stays and winds up in code. But
I fear my days of running off to the CodingJihaud between
this or that coding style, OS, whatEver have come and left.
Which leaves me with the dull and boring 'back and fill'
stuff to write about. Those bits of experience about why
a given set of 'habits' have become the 'best practice'.
Oh to be young again, and Dashing...

ciao
drieux
---

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]