SCOUG-Programming Mailing List Archives

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

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

Content Type: text/plain

Peter,

I inadvertently deleted your message so I don't have it here in
front of me. If SCOUG has an archive, I can't locate it. So I
will have to do the best I can with a first reading.

You might say I'm obsessed with the match between the
problem set and the solution set. The obsession arises from
the fact that at least one programming language, namely PL/I,
has a 1:1 mapping of problem to solution set data types. That
raises a question of why every programming language doesn't
have the same mapping? It's obviously not impossible. The
answer is very simple, going back to the logic K&R invoked in
authoring C: it increases the effort needed in writing the
compiler. It's too much work.

I don't really care whether you have an actual bit string
('01010101010101010101'b) or character string
('010101010101001010101'). I do care if the problem set has it
in bit format when I need to define a data structure. I do care
if I want to convert a bit string to a character string and vice
versa. I do care if I want to perform an expression which
includes both string types involving logical and arithmetic
operations like and, or, nor, equal, not equal, greater than,
less than, add, subtract, multiply, divide. I do care if I can
perform logical operations in a "if" statement and I cannot
perform it in an expression in an assignment statement.

In short I do care if language authors and specifically compiler
writers don't make the effort to allow to achieve a more
perfect match without compromise between the problem set
and the solution set. If I continue to raise the issue of PL/I, it's
because it's not a product of laziness. It authors, its compiler
writers go the extra distance so I don't have to. The extra
effort within that small population reduces the effort of the
larger, producing a net productivity gain.

With the exception of C with its "weak" typing all other
programming languages invoke "strong" typing. Again with
the exception of PL/I they invoke it strictly. They do not
provide for a default conversion nor allow a "direct"
conversion between data types, e.g. between bit and
character strings or bit strings and arithmetic variables. Thus
they do not allow "mixed" expressions without the
programmer invoking explicit conversion routines as part of
the expression.

PL/I does provide for mixed expressions with default
conversions. It also provides for programmer control of
conversions as in other programming languages. in short it
doesn't dictate to you the programmer how you have to do
something. It only attempts to follow your lead. That goal of
not questioning the programmer's thinking, but implementing it
good or bad, was and remains a design imperative. Instead of
Programming Language/One it should have been called
Programmers Language/One. The authors followed the
programmer's lead and not vice versa.

So PL/I is my standard. It says what can exist. It raised the
bar to a level as yet unmatched by any other programming
language. So if I want to raise the bar even further, why
would I start with anything less?

C makes a distinction between a single character string stored
without a null terminator and a variable length string with a
null terminator. It's not rocket science to see how this logic
collapses when it comes to bit strings and why C doesn't
support them: the null terminator.

PL/I on the other hand supports fixed and variable length bit
and character strings. It supports variable length character
strings with (varying) and without (varyingz) null terminators.
It provides a default conversion between them and between
them and arithmetic variables. Moreover it allows their
aggregates (structures and arrays) to occur in expressions as
well.

In short its authors go the extra distance so you won't have
to.

Now PL/I does not have a "native" list aggregate. It must if
PL/II wants to support fourth generation, logic programming.
PL/I does not "natively" support all the APL operators. It
must in order to provide a closer match between the problem
and solution set symbolic descriptions as well as the
succinctness of an APL expression.

None of this affects application of the Whorf-Sapir Hypothesis
to programming languages. How you think efficiently in APL
differs significantly from how in C or PL/I or COBOL or REXX or
Python. While between others the significance may reduce to
a nuance it still exists.

Therefore if you have to deal with understanding multiple
programming languages, you need to understand their
"Weltblick" (World View) to obtain the most effective use of
each. Now in our second pass beginning with Python I think
we need to focus on these "native" views to give us a better
understanding of the languages, their differences, and what
to use when.

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

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.