SCOUG-Programming Mailing List Archives

>> Next Message >>

Date:	Sun, 17 Apr 2005 18:59:01 PDT7
From:	Sheridan George <s-geo@usa.net >
Reply-To:	scoug-programming@scoug.com
To:	scoug-programming@scoug.com
Subject:	SCOUG-Programming: Stirring the Pot

Content Type: text/plain

Lynn H. Maxson wrote:
> Sheridan,
>

>
> While I admire the stinging rebuke to PL/I awkward nature
> relative to Python I also appreciate the opening that it does

Precisely why I wrote the piece and titled it "Stirring the Pot".

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

Lynn, you have portrayed PL/I as being the best there could be as of 1965. I'm not quibbling that
point. My point is let's use PL/I as a basis and move forward. I just want it (SL/1 ?) to do more
of the work. (More on that later.)

>

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

[From this point on Lynn changed my definition of grunt. Mine was the compiler should take care of
memory management, variable declarations, whether a function returns a value or not (making it a
subroutine), or a host of other mundane tasks. Lynn changed it to mean low level (as in closer to
machine language) programming. From here on I'll be using his definition.]

> The grunt work, of course, get done by the compiler writer.

Yep! just as it should be. It's a 1-to-n situation. One write for many users. It is very
reasonable to spend a lot of nasty programming effort, by some really smart people, on the compiler
so us mere mortals can have easily usable, unimaginable power at our finger tips.

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

[A burst of laughter here -- Lynn, you crack me up.]

But there are tools that allow the compiler writer to do all of the grunting s/he wants to do. And
if a tool can be produced from them that combines all those disjoint tools into a simpler to use
system then that would be good. If that heavy grunt tool can present a face that will not scare
away light grunters all well and good. In fact, perfect. If not, then maybe the goal of one tool
is inappropriate and we need two tools -- one for heavy grunters and one for light grunters. The
heavy grunt tool can be used for compiler writing and other very nasty tasks and the light[er] grunt
tool will do for the other 95% of the world's problem set.
>

> 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?
>snip>

It is true that the system we have now where one has to choose a tool that best fits the problem
works but not without difficulty. Since many of the attributes of these tools are overlapping why
not build a tool that embodies all of the necessary features. I think that is your main point,
Lynn. I think it should be one tool, also.
>
> 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?

Yes, one tool would go a long way to solving the many at-odds implementations.
>
> 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.

Whoa, whoa, whoa. Where did you get the idea I *never* want to grunt? Or want a tool that will not
allow another person who thrives on grunting to grunt. I simply said the compiler (writer) could
take over a lot of busy work instead of forcing it on me.

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

See my above remark.
>
> 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.
>
Exactly. Most of my engineering experience was marrying hardware and electronics. (It was not
computer based electronics in those days as computers were few and far between and very expensive
and very large. I had to "roll my own" electronics.) I believe I have a skill set that could be
used to create device drivers except for one thing ... I don't program in C. I have not had enough
projects to warrant learning C and then re-learning it when the next project came by.

The same has pr oven true of Java. I read a lot of Java but I don't program in it. I'm hung up on
having to tell the compiler the type of the variable I'm using every time I use it. At least Ada
didn't require that of me. Also, why should I have to tell the compiler my function is a subroutine
and will not return a value? grrr

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

No argument there. In fact to do device drivers the low level stuff is necessary. What I want is a
compiler that is smart enough (even if I have to train it (grunting?) somewhere in my program) to
reset a bit in some device's register when I write "fan.off". I don't want to have to do something
like: and("pointer-to-fan-word", 0xFF5F) or worse and("pointer-to-fan-word", 0b111111111011111). If
a register needs to be rotated, I want to write: foo.rotateL(5).

[Now don't nobody flame me for my ignorance of C, C++, or any other language.] (Double negative
intended.)
>
> 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.
>
I'm not sure fooling around with LEX & YACC won't prove to be a diversion. We have a goal: create a
programming language that combines the data types of PL/I, the operations of APL2, and the list
aggregate from LISP. In addition, the ease of use of Python would be cool. [A, hopefully humorous,
jab at Lynn: perhaps we should start with Python and make sure it has the data types of PL/I and the
operations of APL2. It all ready does a lot of list stuff.]

Sheridan

PS: Fodder for another discussion: since one of our goals is to participate in on going open source
projects and most of those projects are being written in C or C++, perhaps our language should be a
front end (preprocessor) for gcc. Then our work could more easily be merged with the on going
project at least if the project is being done in C.

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

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 [ 17 | April | 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.