CC's LE strictures are understandable, not least because he has done things with it that few others have had the temerity to attempt.
As I have said here before: The LE Vendor Interfaces manual is the best reference for knowledgeable people; there is no good reference for novices; and I am not sure that a comprehensive one is possible. The mathematical subroutines are superb; and the dynamic-storage management routines, support for heaps and stacks, are now eminently usable. Some of the other facilities are intrinsically problematic. In the interest of keeping it "small", Brian Kernighan's self-abnegating design of C avoids any use of execution-time descriptors, quondam dope vectors; and if you do not know what they are or why anyone would wish to use them you will find them intrusive; COBOL programmers are unused to distinguishing static and LIFO (automatic) storage, etc., etc. To sum up, application programmers need help; but everyone who has set out to help them has found the experience of trying to do so disagreeable. They are a motley crew, and it is hard to meet their very diverse needs concurrently. On 2/22/12, Chris Craddock <crashlu...@gmail.com> wrote: > On Tue, Feb 21, 2012 at 7:01 PM, Charles Mills <charl...@mcn.org> wrote: > >> Also remember when perusing the LE publications that the inventors of LE >> in >> their wisdom thought it would be too clear to the uninitiated to call the >> languages dependent on Language Environment "languages," choosing instead >> to >> further overload the word "member." >> > > > And let's not get started on enclaves and all that... > > >> > it is made easy, for one C function to call another C function >> >> What does that have to do with LE? No other platform that I know of has >> LE, >> but on every platform cannot a C function trivially call another C >> function? >> Otherwise wouldn't every C program have to consist simply of one humongous >> main()? > > > > All high level languages on all platforms have a runtime that provides the > magic behind the curtain. Ours happens to be called LE. However, most > others are vastly more transparent and obvious than LE - the main point of > which was *NOT* so that C functions could call other C functions, but so > that multiple varieties of PL/1 and COBOL programs could call each other. > Yes folks, that baby really is ugly. LE is old and crufty for lots of > reasons and the doc you need to make sense of it is smeared across multiple > publications and as myth and legends in the tribal mind. To quote a former > president of ours; > > "I feel your pain". > > Please count this as the 2012 edition of my now long-standing semi-annual > rant about LE. I will now retire from the discussion before mortally > offending my IBM friends. > -- > This email might be from the > artist formerly known as CC > (or not) You be the judge. > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN > -- John Gilmore, Ashland, MA 01721 - USA ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
