SCOUG-Programming Mailing List Archives

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

Date:	Thu, 7 Aug 2003 17:10:53 PDT7
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: Object-Oriented Programming

Content Type: text/plain

Gregory W. Smith writes:
"No, I won't. Go back and look at the Python program
examples I have posted to this group. I am using Python the
same way I would use YAPL (Yet Another Procedural
Language). As I see it, a "method" is a function/procedure
call by another name--and with a slightly different syntax.
And an "object" is just another data item like the much
derided "int" or "char". ..."

It will be awhile before I remark again about the lack of
responses on this mailing list. We get into so many items that
I get caught off guard sometimes, not really sure that I catch
the drift of the response properly.

It's somewhat difficult when you come from a language that
defines something as it is to one which defines it as it is not.
You see when you come from a language like PL/I that can
express an integer value as decimal, binary, and float, it's
seems regressive to tout something good for only one of the
three. The same thing occurs when you can express a
non-integer in either of the three forms and the other again
allowing only one. Then you get told it's a lot closer to
assembly language and machine architecture, which it is not.

There's something about "fixed dec (7)" or "fixed bin (31)"
that states both the encoding as well as the range of values,
which to tell the truth is far less than that implied by
"integer". As the UNIX community discovered early on K&R's
"portability" didn't mean that one vendor's "int" meant the
same as another's. The same held true for the "long" and
"short" of it. Resolving it and getting to a portability
(data) that K&R didn't have in mind took establishing a
standards committee. All this could have been avoided with
using "fixed bin" instead.

As for "char", well, it's just another screwup, adding confusion
to a data type where none had existed before. Then they
had the brilliant idea of using the * prefix to a name to
denote its address, whereas in PL/I an address is a specific
data type (pointer or offset). The difference is that to use
the same data space, i.e. address, by two (or more) different
data types you had to come up with a crutch like a "union".

What you actually have here are two different cultures, one
(C) which emphasizes the convenience of the implementer (to
achieve what K&R meant by "portability") and the other
(PL/I), that of the programmer. Thus if a programmer
declared a data variable as "fixed bin (17)", it became the job
of the implementer to insure the correct processing logic
occurred regardless of the underlying architecture of the
machine. For some silly reason, based probably on large
accounts having a multiplicity of different machines of
different architectures, that it ought to be possible to have
data and source portability across all of them. Thus PL/I,
which was user-defined (SHARE and GUIDE), placed emphasis
on the programmer defining the environment and the
implementer supporting the programmer's definition. I have
always had the feeling that instead of "Programming" IBM
should have named it "Programmer's Language/I".

So you have declarations for fixed-length strings (char(n),
bit(n)), variable-length strings (char(n) varying), and
null-terminated variable-length strings (char(n) varyingz).
You can convert character strings to bit strings (and vice
versa), providing the character string consists solely of "0"s
and "1"s. Otherwise you get a conversion error. You can
convert character strings to arithmetic (decimal or binary),
providing again it consists solely of numeric values. Otherwise
you get a conversion error.

I haven't mentioned "unspec" which converts any character
into an 8-bit string, and "substr" which allow you then to to
select and change any sequence (1 or more) of bits, and then
use it to put the result back into the original character
location. "unspec" and "substr" are only two of the many PL/I
builtin functions, part of the reason that PL/I is a complete
language which C is not without a library. That's important
because while C may be portable, libraries tend to be less so.

So if I seem to deride "int" and "char", I regard them as
regressive. In my mind evolution in programming languages
means taking the best as the starting point and raising the bar
from there. So when I talk of synthesizing a language based
on aspects of LISP, APL, and PL/I as well as logic
programming, I regard them as the best available in terms of a
starting point.

Understand my desire to build a "universal" specification
language. It has to have the means, for example, to specify
the instruction sets of any machine architecture. Thus in the
same specification pool you have both machine-dependent
and machine-independent specifications along with a means of
mapping from one to the other. "int" and "char" just don't cut
it.

I appreciate the remainder of your statements that this seems
perhaps much ado about very little.

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

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 [ 07 | August | 2003 ]

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.