SCOUG-Programming Mailing List Archives

Date:	Fri, 16 May 2003 07:32:54 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: What I Hate About Your Programming Language

Content Type: text/plain

Peter,

I would have felt a little better if you had said "while we'all
are studying programming languages...". The article touches
on many of the things we have discussed here. It also accepts
many of the myths as gospel, e.g. the one about the closeness
of C to assembly language. It's acceptance of a
poly-linguistic, programming language universe in a open
source world fails to appreciate the stifling threat it offers.

Open source depends upon a significant portion of its "takers"
also playing a role as "givers". While some may feel
proficiency in multiple languages less challenging than others,
something that goes with the territory, they ignore the
impact, the non-participation by others put off by such
demands.

Let's not forget that PL/I initial form was Fortran VI. It went
from an upgrade to Fortran, in essence a special purpose
language (scientific applications), to a general purpose
language (scientific, command and control, and business
applications). It did so because the two largest IBM user
groups, SHARE (largely scientific users) and GUIDE (largely
business users) found their poly-lniguistic environments placed
barriers to application integration.

One of my early PL/I contracts came from Carnation Company
whose operations research people used linear programming to
determine daily the different ingredient choices for their
animal feed mixes for minimum cost. They used a linear
programming package written by IBM France. I wrote a PL/I
program which accepted the data input to the linear
programming package and generated the input program which
the package then compiled and executed.

Once that decision was made then those results had to go to
the data processing department responsible for the billing
with the customers as well as maintaining the ingredient
database. So the data processing department kept track of
the dynamic price changes of the ingredients, submitting them
to the operations research people for optimization and then
accepting the new optimization as an update to their
ingredient database.

The basic problem came down to array processing in that
FORTRAN (operation research) stores arrays in row-major
order while COBOL (data processing) stores them in
column-major (don't ask me why) order. FORTRAN and
COBOL don't talk to each other easily. Neither knows of the
existence of the other.

PL/I, however, knows about FORTRAN, COBOL, and Assembly.
It stores its arrays in row-major order like FORTRAN, as any
intended upgrade should. However, if it is told that an API is
COBOL based, it converts any array argument from row- to
column-major on input to the API and from column- to
row-major on output. That's all done under the covers.

The fact is that PL/I resulted in a better FORTRAN than
FORTRAN as well as a better COBOL than COBOL to
paraphrase a well-known OS/2 claim to fame. It's a better C
than C, where performance-wise it's a damn sight closer to
assembly language as well. Far from being a Swiss Army
knife to use Greg's analogy it offers more of a surgeon's
scalpel than the special purpose language it replaces: it's
simpler to learn, easier to write, and more inclusive in terms
of function.

You see function, their algorithmic expression, represent a
user need independent of any programming language. Higher
level functions require the use of lower level, again
independent of any programming language. Functions
integrate well in theory, less well in practice due to the
dependence on programming language idiosyncrasies. If it
caused such a stink in IBM's two major user groups to alter the
development of a new programming language, you can well
imagine that in open source we have history repeating itself.

You have to pay attention to the common gripe within the
open source community the declining ratio of givers to takers
of the source code. Where you have more and more
depending on less and less you reach a non-sustainable
threshold. We need to find a way to increase the ratio of
givers to takers in open source.

I don't know that we feel like missionaries or even pioneers.
Certainly by looking at common algorithms expressed in
different languages we cover existing territory. It gives us a
chance not only to come to understand it better, but perhaps
also to understand how to make it better. If we simply
encourage more people to become more proficient in more
languages, we have contributed to increasing the ratio of
givers to takers. If our contribution lies in the means of doing
so through comparative linguistics, then maybe we will have
discovered the Rosetta stone to increasing the giver to taker
ratio. That will enhance the chances for continuing open
source success.

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

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