🚀 go-pugleaf

In article <avhch3ro@myrias.com> cg@myrias.com (Chris Gray) wrote:
>In article <2416@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) wrote:
>>
>>[Rubin's ideal language] should be such as to enable the programmer 
>>to express his problem in a manner that is compatible with the structure 
>>of his problem and the capabilities of the machine.  It should also be 
>>such that the resulting program is reasonably efficient. [...]
>>Making it extensible can enable local modifications to be made. 
>
>Herman has a completely different set of needs (from a programming language)
>than I do.  [Our] opinions on what a good programming language needs differ.
>Herman is concerned about the efficiency and ease of representation of 
>small pieces of code which are crucial to his overall application.
>I am concerned about the readability, maintainability and efficiency of much
>larger programs. [...]  I let the compiler worry about code size and speed. 
>I worry about the overall operation and readability of the whole program, 
>since I am constantly adding new things, fixing bugs (...), etc.

In all of Herman's postings over the last 2 years that I have had 
continuous recent net access, my impression of his work is thus:
[1] Attaining the maximum speed provided by the hardware is important.
[2] No one but he will ever work on the programs that he writes.
[3] He never makes sweeping changes in any program that he writes.
[4] He has no collection of users of his programs who present him with
    new or changed requirements for his programs that he must satisfy.
[5] Errors in his programs are not life-threatening nor comparably critical.

Were it not for Herman's insistence on all possible speed from
apparently arbitrary machine architectures and organizations, 
numerous programming language design academicians ought to be able 
to design a language that would suit him.

In an era when the size of resident code for single-task operating 
systems + environments for microcomputers exceeds the size of the resident 
code for multitasking operating systems for the mainframes of 20 years ago,
and the dominant microcomputer software house ("those who fail to learn
from history...") is rumored to be The Second Coming Of The Mythical 
Man-Month ("...shall be destined to repeat it"), the most important
challenges in the programming languages field seem to be in designing
languages and compilers that can be an asset (not a hindrance) in
development, maintenance, and market-driven enhancement of large but
reliable and reasonably efficient software products.

I suspect that many of us in the business of providing compilers to 
The Real World adopt this orientation because of an intense desire
to quit being bitten by bugs resulting from our own innocent mistakes
("to err is human"), or from the laziness and stupidity of others :-).
I believe that despite the admiration that many of us doing language
design or compiler work in The Real World feel for certain prominent
programming languages academicians, and despite our appreciation for all
of the useful ideas that they have contributed to the field, many of us 
remain skeptical that most academicians will ever overcome their lack of 
experience with large software projects in The Real World, so as to design 
programming languages that meet the often less-than-ideal ("life is cruel") 
requirements of software development and *maintenance* and *enhancement* 
in The Real World.

>I also disagree with Herman [on] very loose syntax, extensibility, etc. 
>Such a beast would have very poor error handling, 

It's implausible to me that the people who made the effort to extend
the language--if speed freaks like Herman--would make the effort to
provide error handling that was up to the standards of an original
compiler-writer concerned about the quality of the human interface.

I recall clearly that those nifty "one-liners" written in APL 
by its zealots never seem to have any error-handling other than
the system built-in ("DOMAIN" | "INDEX" | "RANK" | "VALUE") "ERROR"
two-word diagnostic messages.

>and hence would be quite unfriendly to work with 
>(even worse than pre-ANSI C!!). 

I'd much rather have a griping compiler than a boss who has just gotten
an earful of griping from an important ($$$) user of a shipped product.
C is customarily not the former, but can certainly make the latter easy.

>It would, also, in my opinion, be DANGEROUS to work with - the compiler 
>would have to trust the programmer implicitly (just like in assembler), 

I've long wanted to use language features for expressing my intent 
in a program in a form that can be checked by the compiler.
I have in mind more than just "assert" statements or range-checking,
but I'll have to defer that to a future posting.

>so would have few opportunities to point out things that don't make sense.

Like in passing parameters between separately compiled routines of 
the large dusty-deck FORTRAN programs still in use today ?

>I wouldn't want such a language to be used in things like 
>nuclear reactors, railroad control systems, etc. 

That is, like those dusty decks written for good ole FORTRAN ?

>It could be fine for Herman's fine detail fiddling, but its not for me!
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
That depends whether or not Herman is like many university faculty
members whose income is raised above subsistence level by consulting.
If his "fine detail fiddling" is on statistical failure analysis of
nuclear reactors, buildings in active seismic zones, or the incidence
of illness among users of proposed "wonder drugs" undergoing testing,
the consequences will reach far beyond his ivory tower in Hoosier Country.

Herman's contrarian views are useful to those of us who would prefer
not to exclude users of our own programming languages through our own
oversights, as hidden by personal blind-spots (e.g.: making it impossible 
or unnecessarily aggravating to perform multiple-precision arithmetic,
without intending that things work out that way).  Considering that
just about everything in language design imposes a cost, or conflicts
with some desirable goal, there will probably continue to be plenty of 
instances in which the cost of accomodating Herman's perceived needs 
simply exceeds the cost to a language design of doing so, or conflicts
with a goal deemed more important by the person who has to make the
language design work.
-- 
[The foregoing may or may not represent the position, if any, of my employer, ]
[ who is identified solely to allow the reader to account for personal biases.]
[Besides,  this was posted during test runs executing during the "lunch-hour".]
                                              
Clay Phipps 
Intergraph APD: 2400#4 Geng Road, Palo Alto, CA 94303; 415/852-2327
UseNet (Intergraph internal): ingr!apd!phipps
UseNet (external): {apple,pyramid,sri-unix}!garth!phipps        EcoNet: cphipps
[Patience--our delay for receipt of postings is now approximately 2 weeks !!!!]