SCOUG-Programming Mailing List Archives
Return to [ 02 |
March |
2003 ]
Content Type: text/plain
"Language religion will not go very far in proving your case. I
may not have mentioned it, but in a past life, I wrote a
significant amount of PL/1. A Google search for 3M Medlab
Utah will give you an idea of the scope and size of the system.
When I drifted into embedded systems work, C and assembler
became the better choice in most cases. Of course, all I
believe this experience does is give me enough knowledge of
both to know which language is probably the better choice
for a specific task. As you say, work smart not harder. I see
no reason to use a hammer when a screwdriver is the better
choice."
Steven,
I regret the delay in responding, but my other lives have
managed to interrup with their higher priorities. Coming back
to this life I must comment that I find the above quoted
comments disturbing. Three inferences in particular. One,
that may language preferences rely on religious choice, faith
not fact, not empirical evidence. Two, that the choices of
PL/I in the first instance and assembly and C in the second
came from having a full language palette--Lisp, APL, Fortran,
COBOL, PL/I, Pascal, Modula 2, Oberon, Forth, etc.--to choose
from. And finally, three, that the analogy of hammer and
screwdriver applies.
I view language from the perspective of general semantics as
a means of providing verbal maps of the real world. Their
value lies in the degree that the one corresponds and properly
represents the other. In the instances where they don't
correspond you make changes to the map and not the
territory. The map then represents the solution set; the
territory, the problem set. In all conflicts the problem set, the
territory, the real world rules.
When it comes to programming languages the verbal maps
have an interest in only three aspects of the real world: (1)
operands (data), (2) operators, and (3) their order. That's
how we in our solution set map the processes occurring in our
problem set.
This gives us a start up on our metrics to allow us to compare
and in turn evaluate languages with respect to tasks. We can
create a list of the possible operands, first the different data
elements (types) supported, and second their aggregates. We
can create a list of the possible operators, first the primitive
ones and second their aggregates (arrays, structures, lists).
Then we can list which operators support aggegate operands.
These account for the possible ways we can describe
processes, i.e. maps, of the real world: how well our solution
set corresponds to the problem set. It remains then to provide
a list of descriptive rules. Part of these rules determine the
syntax, which in turn determines writing ease. Another part
determines semantics, e.g. which words are "keywords" as
well as which "keywords" are "reserved words". Taken
together these affect the learning curve from initial contact
to proficiency.
So far from making a language a religious choice I have a
definite metric in making a choice. In so doing I have gone for
a synthesis of different languages. From PL/I I've selected
data types, syntax, and semantic rules. From APL I've
selected the symbol set and primitive operators. From Lisp
I've selected the list aggregate and list operators. From logic
programming I've selected the assertion and the two-stage
proof process.
The only religion I've injected here comes from assiduous use
of the scientific method along with the guidelines associated
with KISS and Occam's Razor. In short I've examined a host of
different programming languages, applied my metrics, and
selected the best choices from among them.
I would use the same metrics in selecting a language for a
specific task. If the task required a "hammer" in one instance
and a "screwdriver" in another, I would pick that language
which best allows me to create either...or any other tool like a
"saw", "chisel", "file". In fact I would pick one that allowed
me to have as many varieties of each that occur in the real
world.
For you see the specific task arises from the problem set and
the tool from the solution set. As a result I still have only one
descriptive task to perform in the solution set: to most
accurately conform to the problem set. As discussed
previously I have a metric for that descriptive effort: how
much I have to write and how long it takes me to learn how
to write it.
If I look at PL/I, say that associated with PL/I for OS/2, I note
that it includes C as a proper subset. That means you can
translate every C program into an equivalent PL/I program.
By implication it also means that you cannot translate every
PL/I program into C.
With this aside we come down to the metrics related to
descriptive ease, number of rules, and learning curve relative
to a specific task. The amount of writing which must take
place and the amount of time necessary to learn it.
So if I look at an assignment statement in C or PL/I, for any
one that I write in C how different must I write the equivalent
PL/I? I don't. No difference. If I write something in PL/I, how
different must I write the equivalent C where a difference
does occur? For example, take "a += b > c;", where if b is
greater than c, we add 1 to a, otherwise 0. Furthermore let a,
b, and c be equal, three dimensional arrays (or structures),
e.g. "dcl (a, b, c) (20,20,20) fixed bin (15);"
I infer that you regard PL/I as a "hammer" and C a
"screwdriver", yet in this instance C with no support for
aggregate operands or logical operators in assignment
statements in terms of writing quickly becomes a hammer to
PL/I's screwdriver. We could go on to enumerate all the
possible instances in which in every instance PL/I's descriptive
effort is at least equal to or better than C's.
I suggest that the choice of PL/I in the first effort and
assembly and C in the second did not occur on the basis of
any scientific metric on a full palette of language choices. I
will argue that it should, that as a user I ought to have my
choice of tools regardless of any vendor's offerings. I won't
ask why if you had to have assembly skills, did you even
bother with C. Or why if you had C, why did you need
assembly.
I will argue that users should unite to protect themselves from
the abuses of vendors. Part of that protection lies in
providing their own software tools and their own operating
system. In that manner gain the independence necessary to
insure that vendors' solution set fits the users' problem set by
the user becoming when necessary his own vendor.
Open source provides a window of opportunity for the OS/2
and other communities to dictate the functionality and thus
the full range of capability of their tools, including the
operating system as a tool. Your experience should have
shown you that you didn't always have a universal set of
choices, but only certain available ones (for political, religious,
economical, psychological, sociological, practical, arbitrary,
and vendor-supplied reasons). I'm simply saying that those
who don't learn from their experiences are doomed to repeat
them. In the instance of the OS/2 community the lack of such
learning spells eventual doom.
So you see I do have a set of programming language metrics,
providing quantitative as well qualitative measures. I think
that we can use them in our pursuits here to do what
apparently no computer science curriculum does: comparative
linguistics. They don't emphasize it for programming
languages or operating systems. I imagine that you don't
want your students to know that due to budgetary
constraints they can only offer you second-rate examples of
each.
You can't with such methods protect them in the long run
from finding themselves unable to have their solution set
maintain pace with the dynamics of the problem set. People
may question why I continue to raise this issue. It does come
down to language, to descriptive forms, to the ease of
learning them, to the ease of creating them, and to the ease
of maintaining them.
You know that you must use a language. Need you use more
than one? You know that you must use a tool. Need you use
more than one? The least number of necessary acts is one. If
more are needed, we need to understand why. In that
understanding perhaps we can eliminate the need.
=====================================================
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 [ 02 |
March |
2003 ]
The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA
Copyright 2001 the Southern California OS/2 User Group. ALL RIGHTS
RESERVED.
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.
| 
