[Pleac-discuss] Re: Pleac-discuss digest, Vol 1 #418 - 2 msgs

[Anthony B. <aj...@bi...>]

----- Original Message -----
From: <ple...@li...>
To: <ple...@li...>
Sent: Thursday, August 04, 2005 1:12 PM
Subject: Pleac-discuss digest, Vol 1 #418 - 2 msgs

Taro, All,

>
> Message: 1
> Date: Wed, 3 Aug 2005 23:47:09 +1000
> From: Taro <ta...@gm...>
> To: ple...@li...
> Subject: [Pleac-discuss] Re: Pleac-discuss digest,
> Vol 1 #417 - 1 msg
>
> > Anthony Borla writes:
> > With any luck the changes between editions may not
> > be *that* significant,  so not too much additional coding
> > / recoding will be required. I think a sensible course to follow
> > is to stick to Edition 1 format until a migration strategy is
> > decided upon.
>
> There's also the question of whether Edition 2 should
> even be the migration target for PLEAC Mk 2 (Assuming,
> say, that Python, Ruby and Rexx approach 100% sometime
> soonish).
>

My current aim is to have REXX reach 60% by the end of December 2005. It
will require a 10% addition each month until then, so if I can hit 18% by
the end of August, it may well be achievable.

Work commitments permitting, I've been working steadily on the PLEAC REXX
examples. Whilst I've written a fair amount of code, and have completed
sections across several chapters, I've not posted any more contributions
because I want to:

* Consolidate code into general-purpose routines [which I'll
   include in the Appendix]

* Expand a number of examples showing several alternative
   approaches [e.g. in directories / file management show
   handling on hierachical and non-hierachical file systems;
   in pattern matching show non-regex-based matching]

* Include commentary on REXX idioms / approaches, and
   general differences from Perl and other scripting languages

So far much of my time has been spent writing and testing generic code [as
you can appreciate, this is more time consuming than simply whipping up
quick, hardcoded examples]. However, I hope to actually make use of some of
this code in a few weeks :) !

Aside from the above aims, there is the additional complication with REXX in
its being:

* A non-UNIX-originating

* 'First generation' scripting language [it even predates Perl,
   which I'd loosely describe as a 'second generation' scripting
   language]

This means that many of the biases / features that are simply assumed to
exist in Perl / Python / Ruby and similar languages, are either absent, or
only minimally implemented. These include reliance on the UNIX C Library,
most particularly for file handling, and date / time support, UNIX system
calls via [among others] 'fork', 'select', and 'exec' functions, in-built
regular expressions, and the assumed existence of a hierarchical file
structure and pipes / filters.

The end result is that implementing REXX solutions to many of the PLEAC
examples generally requires a greater design / coding effort than it would
for one of the 'second generation' scripting languages where you would
probably simply pick the appropriate Perl-equivalent module, and use the
relevant objects / methods. So far, though, whilst being a tad frustrating,
it has been most enjoyable, and exceedingly challenging, forcing me to
consider problems / situations I'd ordinarily not encounter, or simply take
for granted.

>
> Using the Perl Cookbook as PLEAC's framework has the
> tendency to make for very Perl-ish and Unix-ish solutions
> - you end up with a lot of translations that are correct in
> syntax but not in spirit - either for the language, for the
> OS, or for both.
>

Yes, I recall posting similar observations recently in regards to the PLEAC
User Interface and Process Management code examples, the latter being
particularly troubling. I'm not sure that much can be done about the
UNIX-ish aspect [i.e. the use of UNIX-specific features] of the published
solutions.

For my REXX contributions I've decided to implement system-level functions
where specifically needed [and a more abstract approach to the problem is
not obvious] in order to more closely match the approach taken in the
published solutions. If possible, mention [in the commentary / header
sections] of idiomatic differences will be made, and alternative solutions
provided.

As for the published solutions being Perl-ish, it is, I think, a given,
since it is the *Perl* Cookbook code on which we are basing our efforts :) !
I don't think, though, that it stops anyone implementing alternate
approaches to most of the problems. For instance, string manipulation in
REXX can be accomplished via built-in functions [e.g. SUBSTR and others,
which are very similar to Perl's], via the PARSE instruction and
concatenation operator, as well as via implementing native functions
augmented with third-party library facilities.

I've tried to illustrate all three approaches: using built-in functions
makes for somewhat Perl-ish solutions, use of the PARSE instruction makes
for a REXX idiomatic approach, whilst the other provides for an interesting
contrast.

I think that it simply has to be accepted that both UNIX and
[unsurprisingly] a Perl-ish orientation are key aspects of PLEAC, no matter
how difficult this may make it for contributors. An approach where both
Perl-ish and language-idiomatic solutions [suitably augmented with
commentary] are furnished may prove the most beneficial [for both the
programmer and the PLEAC audience]. Key to facilitiating this may be to look
at each problem in the abstract as much as possible, and let that guide your
solution implementation strategy.

>
> For example I use Windows.  Looping on fileinput.input()
> is just not how I'd solve 99% of  the problems with solutions
> that use it even if what's inside the loop would be perfectly
> ok in its own function [For that matter should that now be
> written "for line in sys.stdin:"? I've never had to use either...]
>
> This is not to say that there shouldn't be a recipe or three
> which demonstrate how to perform some task for every
> line on stdin, just that the structure of the reference answers
> can constrain solutions in ways that have nothing to do with
> the meat of the problem.
>

Following on from what was said earlier, I'd say simply try to:

* Implement a solution as close to the Perl example as
   possible

* Include an alternative [or two] that is more idiomatic
   of the solution language

always being mindful to view the problem in the abstract wherever possible.

>
> Cheers, -T.
> PS: You wouldn't _believe_ how hard it is to find a
> bookshop which sells the Perl Cookbook.
>

Maybe buy it online ?

>
> PPS: Sorry no time to do anything recently.
>  Next week, hopefully...
>

Yes, I have the same problem - so much to do, and so very little time :) !

Cheers,

Anthony Borla