SCOUG-Programming Mailing List Archives
Return to [ 16 |
April |
2005 ]
Content Type: text/plain
Sheridan,
Wow! And to think I had concerns about getting squeeze on
time in our monthly meetings for PSIG activity. If we maintain
the recent pace of messages here, we don't need no stinking
time in the monthly meeting.
Unfortunately all my planets converged on this weekend and I
had to bypass visiting one of them. As a result Tim Katz does
not have a ride to this mornings meeting.
While I admire the stinging rebuke to PL/I awkward nature
relative to Python I also appreciate the opening that it does
offer. I offered the example of "controlled" storage attribute
to show something that to the best of my knowledge did not
exist in any other programming language. Considering its
1965 vintage, the absence of virtual storage, its ability to
dynamically allocate arrays at execution time, and the general
inability of its competitors, FORTRAN and COBOL, to come
anywhere close it stood head and shoulders above the rest.
However, its reign was shortlived with the advent of "based"
storage and pointer variables which gave it full list processing
capabilities. Had you been patient step 4 would have offered
you an introduction to list processing.
"...Too much grunt work that the compiler should take care of.
Python proved that. PL/I is worse. I would not trouble myself
to learn it."
The grunt work, of course, get done by the compiler writer.
We agree that he could and should do more programming so
that we can do what we want with less. He obviously can't
do more with what we do with less. He can't use the same
tool to do grunt work if that tool doesn't allow grunts.
Now to Steven, who is not fooled by all this, the secret lies in
picking the right tool based on the problem. Thus having one
language to write a tool which in turn offers a different
language to the user seems reasonable. So if you have a text
processing problem, a business problem, a scientific problem, a
real time processing problem, a compiler writing problem, and
so on why not believe in the use of a specific language, i.e.
the right tool, for each one? Why in the hell would you ever
want to have one tool, one language, which provides the
same level of "competence" as special languages for all those
problems? What happens when you want the business
application to invoke the scientific application in a real time
environment?
What happens when your business solution stores arrays in
column-major order (COBOL) and your scientific in row-major
(FORTRAN)? Who gets to do the "grunt" work?
Why is this important? Sheridan, you have an attitude
problem. You have your blinders on. You want ease of use
without the grunt. In fact without the ability of the grunt.
How does that affect the basis of open source? How does
that effect you ability to customize an application to suit your
needs...the ultimate freedom effect of open source? If you
are not willing to do grunt work, then you remain either a
prisoner of or dependent upon those who willing to do it.
We entered this PSIG project originally to address the open
source issues raised by the use of multiple programming
languages. Steven accepts this as the name of the game.
Unfortunately it inhibits a very large number from playing it.
Now we seek a way to lower those inhibitions. One way lies
in easing the learning curve of multiple languages. Another
lies in replacing their use with that of a single language. That
language ought to allow both grunt (lower level) and
non-grunt (higher level) programming. It ought to because at
the lowest level, the machine level, its pure grunt. Ultimately
all higher levels reduce to this.
When we get into list processing then we introduce higher
level constructs based on lower level that offer the ease of
use (non-grunt) that you enjoy...in a single language. Maybe
in parallel to this we can apply LEX & YACC to C, PL/I, and
Python. That should prove interesting.
Meanwhile enjoy this mornings meeting. Sorry I can't join you.
=====================================================
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
"postmaster@scoug.com".
=====================================================
Return to [ 16 |
April |
2005 ]
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.
| 
