SCOUG-Programming Mailing List Archives

<< Previous Message << >> Next Message >>

Date:	Mon, 18 Apr 2005 17:13:38 PDT7
From:	"Gregory W. Smith" <gsmith@well.com >
Reply-To:	scoug-programming@scoug.com
To:	< "scoug-programming@scoug.com" > scoug-programming@scoug.com >
Subject:	SCOUG-Programming: Stirring the Pot

Content Type: text/plain

On Sun, 17 Apr 2005 18:59:01 PDT7, Sheridan George wrote:
>
>
>Lynn H. Maxson wrote:
>> Sheridan,
>>
>
>
>>
>> While I admire the stinging rebuke to PL/I awkward nature
>> relative to Python I also appreciate the opening that it does
>
>Precisely why I wrote the piece and titled it "Stirring the Pot".
>
>> offer. I offered the example of "controlled" storage attribute
>> to show something that to the best of my knowledge did not
>> exist in any other programming language. Considering its
>> 1965 vintage, the absence of virtual storage, its ability to
>> dynamically allocate arrays at execution time, and the general
>> inability of its competitors, FORTRAN and COBOL, to come
>> anywhere close it stood head and shoulders above the rest.
>
>Lynn, you have portrayed PL/I as being the best there could be as of 1965. I'm not quibbling that
>point. My point is let's use PL/I as a basis and move forward. I just want it (SL/1 ?) to do more
>of the work. (More on that later.)
>
>>
>
>
>>
>> "...Too much grunt work that the compiler should take care of.
>> Python proved that. PL/I is worse. I would not trouble myself
>> to learn it."
>>
>
>[From this point on Lynn changed my definition of grunt. Mine was the compiler should take care of
>memory management, variable declarations, whether a function returns a value or not (making it a
>subroutine), or a host of other mundane tasks. Lynn changed it to mean low level (as in closer to
>machine language) programming. From here on I'll be using his definition.]

Deja Vu all over agian. We went over all this with the engineer vs.
programmer thrash a while
back. Peter pointed out the virtues of the automatic memory management
you get for free
with BEGIN/END. And I agreed that an engineer prefers automatic memory
management
over what a programmer would be concerend with. Lynn asserted that the
"Engineer"
should specifically allocate memory and obsess on the memory
management of his program.
My contention was that the "Engineer" (like a civil engineer progrmming
the stress
analysis of a bridge truss) is concerned with the accuracy of his
calculations, and
not how the memory is managed during the calculation of the bridge
stress analysis.

>> The grunt work, of course, get done by the compiler writer.
>
>Yep! just as it should be. It's a 1-to-n situation. One write for many users. It is very
>reasonable to spend a lot of nasty programming effort, by some really smart people, on the compiler
>so us mere mortals can have easily usable, unimaginable power at our finger tips.
>
>> We agree that he could and should do more programming so
>> that we can do what we want with less. He obviously can't
>> do more with what we do with less. He can't use the same
>> tool to do grunt work if that tool doesn't allow grunts.
>
>[A burst of laughter here -- Lynn, you crack me up.]

Yep. Deja Vu all over again.

Off on another tangent.

===============================================================
Gregory W. Smith (WD9GAY) gsmith@well.com
finger gsmith@well.com for PGP public key

=====================================================

To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-programming".

For problems, contact the list owner at
"postmaster@scoug.com".

=====================================================

Return to [ 18 | April | 2005 ]

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.