SCOUG-Programming Mailing List Archives

<< Previous Message <<

Date:	Sun, 16 Jan 2005 21:32:22 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: Ongoing

Content Type: text/plain

Thanks, Steven, for informing about version 2.4 on Hobbes.
I've downloaded and executed it. Maybe I will be better
prepared for the additional instruction by Greg and Sheridan. I
think they have set the bar for any exploration of a
programming language by the rest of us. Maybe once we get
the website relocated and make their material available from
it, we can return to our original goal of contributing to the
success of open source for OS/2.

I did enjoy Bill Ritcher's presentation of Guiffy despite its
length. I tried to thank him it guiding him out of the caverns
of the facility. I think we will be coming back to the product
once we have more familiarity with the the problems of
collaboration and synchronization of open source code.

I make no secret that PL/I is my language of choice and that I
have little respect for post-1970 languages infected by the
"int" disease of C. That doesn't mean I don't respect the
views and preferences of others. Certainly it doesn't indicate
an unwillingness to learn.

I wished I could get more excited about dynamic typing. We
have a word for when the same word, in this instance a
variable name, has more than one meaning: homonym. That
means it is a source of ambiguity. It's particularly or
potentially harmful when it leaves a local for a more global
use, when it crosses functional, procedural, or program
boundaries.

Homonyms (same name, different referents) and synonyms
(different names, same referent) are the bane of most, if not
all data dictionaries which abhor ambiguities in either names
or referents. On the one hand it means having to use fewer
names in the same manner that we have words with multiple
meanings. On the other hand it limits the reliance we can
have on the name alone.

I guess I would prefer to have dynamic typing limited to a
single variable instance. In however used first, thus assigned
dynamically, it would not allow a different reuse within the
same procedure block or across procedure blocks.

One of the characteristics of my proposed data
directory/repository is that it provides a global, across all
applications, detection of homonyms and synonyms. Thus if
you have the same referent with multiple names (synonym),
you can globally replace all use instances with a single name.
It provides a similar global function for homonyms. The point
is to provide a simple means of reducing and in fact
eliminating name ambiguity in source code.

That doesn't make dynamic typing "bad". It's not. It's that its
innocent or frequent use, particularly as it relates to
"persistent data" where fields or columns have names, can
lead to increase program maintenance costs. Remember that
the cumulative maintenance costs, their increasing over the
life cycle of software, far exceed that of development. In
fact it is the maintenance costs that begin in development
that make it so expensive.

I can't let 2/3.1 pass without comment. It's the 'int' disease.
That says that only binary integers exist in the universe.
Whereas in the real world binary and decimal integers exist.
It also says that the only "real" numbers allowed are floating
point. Whereas in the "real" world decimals reals, decimal
numbers with fractional components, exist. I dislike belaboring
the point that the "real" world represents the "problem
set";our software world, the "solution set".

It makes a difference if 2/3.1 is a /
or a /. In the first instances
you have two different types with different precision where
you compromise "strong" typing by implementing an implicit
conversion without even bothering with the type of the result
and its assignment. In the second you have a single type
(fixed point decimal) with different precisions and no type
conversion (only that of precision) occurs.

If you write business applications using binary and floating
point variables, you will not get the same results which occur
with using using fixed point decimal arithmetic. I've seen this
happen so many times in a C environment. The most recent
damning instance was that between the ISO and the PX (when
it still existed) which couldn't have their energy costs
calculations match between the two companies.

Maybe I will introduce the change making program which I
used as a class assignment for PL/I which we can transcribe
into different programming languages, if for no other reason
than increase the consciousness of the issue.

As a final comment (this time around) I want to to discuss
"mutable" and "immutable". I don't understand the need for
their introduction as they are synonyms for the well
established concepts of "variable" and "constant" in
programming. What Python introduces as "native" data types
not present in PL/I are variable and constant list aggregates. I
have to admit that I hadn't considered the idea of a 'constant'
list aggregate. That's probably because in my mind the value
of a list aggregate lies in its ability to have 0 (False) or 1 or
more True instances. When it restricts that ability, when it
sets the number of True instances, then I have to think about
whether it's worth it or not. My first impression is that a
constant list aggregate is unnecessary, because once set (and
the initial setting is the same for either variable or constant) if
I don't change it, it's constant. Thus I don't need two different
symbolic notations.

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

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 [ 16 | 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.