SCOUG Logo


Next Meeting: Sat, TBD
Meeting Directions


Be a Member
Join SCOUG

Navigation:


Help with Searching

20 Most Recent Documents
Search Archives
Index by date, title, author, category.


Features:

Mr. Know-It-All
Ink
Download!










SCOUG:

Home

Email Lists

SIGs (Internet, General Interest, Programming, Network, more..)

Online Chats

Business

Past Presentations

Credits

Submissions

Contact SCOUG

Copyright SCOUG



warp expowest
Pictures from Sept. 1999

The views expressed in articles on this site are those of their authors.

warptech
SCOUG was there!


Copyright 1998-2024, Southern California OS/2 User Group. ALL RIGHTS RESERVED.

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.

The Southern California OS/2 User Group
USA

SCOUG-Programming Mailing List Archives

Return to [ 12 | January | 2004 ]

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


Date: Mon, 12 Jan 2004 10:56:23 PST8
From: Peter Skye <pskye@peterskye.com >
Reply-To: scoug-programming@scoug.com
To: scoug-programming@scoug.com
Subject: SCOUG-Programming: QA equals testing, Part One:Detection

Content Type: text/plain

Lynn H. Maxson wrote:
>
> "...The PL/I Level F compiler ..."
>
> Somewhere along your line of reasoning you forgot
> that it generated code that other languages could
> not, because they had no means of expressing it.

Did you really mean to say the above? If so, give me an example. The
PL/I syntax is robust, but the code itself is still simple code and can
be generated without waving a magic wand.

BEGIN blocks, as far as my humble research would allow me some insight,
are just memory allocations. Event Control Blocks are just small tables
to manage attached tasks. Procedural ENTRY points are an enticement and
I'm not a C programmer so I can't say how C might handle these, but one
additional parameter on a call can quickly identify the desired entry
point (methinks Rexx does this quite nicely, and perhaps more robustly
than PL/I although I'll have to get out my PL/I docs and review them).

I love PL/I, and I'm not too fond of Rexx, and I admire your decisive
future thinking, Lynn. And I enjoy arguing with you. But PL/I is not
magical, it is simply robust and comfortable.

> It didn't require additional libraries.

It was quite slow _because_ it used libraries. Every routine got a
pointer instead of a value, then had to go back to the pointer's table
to see what the heck it was working with. If all this was "inline" then
PL/I (at least Level F, I've never gotten into the innards of the OS/2
version) would be a lot faster.

It's not just PL/I. I can make Pascal scream like assembler or as slow
as a dodo. It's how you code that makes the difference.

So how are you suggesting that this be "spec'd"? Maybe like this:

Optimization: EXECUTION SPEED then MEMORY USAGE then EXECUTABLE SIZE

which will "inline" those library calls?

- Peter

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

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
"rollin@scoug.com".

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


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

Return to [ 12 | January | 2004 ]



The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA

Copyright 2001 the Southern California OS/2 User Group. ALL RIGHTS RESERVED.

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.