SCOUG-Programming Mailing List Archives

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

Date:	Sat, 1 Jan 2005 14:27:00 PST8
From:	"Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To:	scoug-programming@scoug.com
To:	< "scoug-programming@scoug.com" > scoug-programming@scoug.com >
Subject:	SCOUG-Programming: A bit too much to byte

Content Type: text/plain

Peter,

Happy New Year. When starting a new year it's good to have
an adrenaline shot.

It's not a matter of succinct code. It's a matter of matching
solution set to problem set. If your problem relies on matrix
multiplication using either arithmetic or logical operators, your
text book says "M op N". The text book is not being succinct.
It's telling you what's being done, what you want done,
without you having to plow through the details.

Now actually the textbook is wrong and APL is correct.
Matrix multiplication involves two operators, the multiplication
of the corresponding rows of one with the columns of the
other and then the sum of the results. Thus in APL the two
operators appear in the right to left order of their application.
In this instance the solution set more accurately represents
the problem set than its descriptive language does.

Once again you make as assumption. In a PL/I aggregate,
either array or structure, you have the option of ALIGNED or
UNALIGNED of the aggregate as a whole or any subset within
it. Thus depending on the data type you can either be bit (for
bit strings) aligned in a sequence or byte (for character
strings) aligned. With UNALIGNED you can opt for byte
alignment (except for bit strings which do get padded on the
right with binary zeros) for all other data types.

The point is you cannot introduce an aggregate either on
input to or output from PL/I that the programmer cannot
control its layout.

You cannot write in C "a = b = c;", where a, b, and c can be
bit or character strings or arithmetic variables as well as
aggregates of such. The corresponding result is "0" for
"false" and "1" for "true" whether element or aggregate
variable. If "a" is a bit string, then it's values are 0'b or '1'b;if
character string, '0' or '1';and if arithmetic, 0 or 1 regardless
whether b or c have the same or mixed data types.

That's the advantage of strong typing combined with default
conversion.

Yes, I shoot for succinct (except in writing this) as it costs
less to create, i.e. develop, and far less to maintain, i.e.
change. It costs less in time. For some of us time is money.

"tfResult = EQUAL(A,B);"

Nice try. Of course, tfResult cannot be a bit string in C. As a
result it can only be a char or int in C.

I never said that a programmer explicitly doing conversion in
an expression was bad, only that in PL/I he had a choice to do
it or not. The fact that he has a choice implies that someone
has to do extra work to allow it. Thus whether you not you
choose economy of expression is that: you choice. It's not
dictated, i.e. no choice, by the compiler writers.

I assume you understand the terms element and aggregate
variables whether as array or structure. In either array or
structure aggregates, regardless of their aligned or unaligned
attributes, the aggregate itself occupies a contiguous, fixed
amount of space. A list aggregate, however, does not as its
sub-lists and elements are connected through "links", i.e.
addresses, and do not necessarily occupy a contiguous area.
Moreover as you can have an "empty" list, the aggregate
occupies in this instance no area at all. Beyond that unlike
other aggregates it has no bounds, no upper limits. As a
result any list (or sub-list) can contain zero, one, or more
elements (which may in turn be lists, i.e. sub-lists).

That says when you evaluate an expression involving a list
aggregate or list aggregates it results in a list aggregate of 0,
1, or more values. This happens, for example, in an SQL query
where you have to check the result to see if the query was
false ( 0 values returned). If not, then retrieve a count that
says how many iterations of drawing from the result you need
to perform.

I do not seek the succinctness of an APL expression. Instead I
seek to match its textbook source. If the textbook (problem
set) is succinct, I see no reason why the program (solution
set) should be any less so. If it is clear in one, then certainly
that transfers to the other.

Now we will have an opportunity over the next couple of
months with the support of Greg and Sheridan to start to
compile the "one roof compendium" you mention. This means
that we not only look at the code, but also try to capture
how they formed their thinking in setting up to write it.

"What other considerations do you have?"

The primary consideration is productivity. You may refer to
specific sections of it as "succinctness" or "economy of
expression". I consider it in terms of development and
maintenance, the effort it takes to write it, the effort it takes
to change it. In normal software development you have the
writing of requirements, their translation into specifications,
their translation into analysis, its translation into design, its
translation into construction, and its incorporation into testing.
All these involve different writing forms, each involved with
development and maintenance. I seek productivity gains in
reducing this number of manual writing efforts down to two:
user requirements and specification. I expect the software to
do, as any good fourth generation software already does, the
remaining "writing".

Do not look at me as a PL/I or APL or LISP (list aggregate)
bigot. For different reasons they different forms of
succinctness. Upgrading them into a fourth generation
environment, one based on logic programming, provides for a
different form of succinctness: reduction in the number of
manually written forms.

The issue is not PL/I or SL/I or programming language per se.
The issue is increasing programmer productivity by providing a
programming environment, a tool if you will, that allows
"people to do what software cannot and software what
people need not".

I have a focus on productivity. That says I have an absolute
abhorrence of programming methodology that requires not
only multiple different written forms, multiple different
languages within a given form, and multiple tools depending
on form, but also one which allows incompatibilities to occur.
I assert that you can with a single tool, a single language, a
single form replace and avoid all that.

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

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".

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

Return to [ 01 | January | 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.