Programming Language / I a. Craig Dixon
Download 45.15 Kb.
|
- Navigate this page:
- Results
- Scoping
- Appendix: Abridged* Text of Email Interview With PL/I Programmer Dana Guild
- Bibliography
Programming Language / IA. Craig DixonCSC 415: Programming Languages Dr. Lyle
October 9, 2001 History of Programming Language / IDevelopmentIn the early 1960’s, computing itself was still evolving. Most innovations in the industry were brought about by necessity rather than long range planning and research. This had lead to a wide separation between computers for business applications, which required more fixed point and string operations, and computers for scientific applications, which required more support for arrays and floating point operations. IBM, the major player in the computer industry at the time, had developed models 7090 and 1620 for the scientists and models 7080 and 1401 for the business programmers. (Sebesta 69) However, toward the middle of the decade, these two groups had begun to move closer together in terms of their computing needs. IBM saw the opportunity to unite most of the computing world under a single system design. The result was IBM’s all-purpose System 360. With the release of the System 360, IBM had united much of the hardware side of the industry, yet the software side remained divided; business applications were programmed in COBOL, while scientific applications were done in FORTRAN. The logical next step for IBM was to create a universal, all-purpose development tool. The result was Programming Language / I (PL/I.) Of PL/I, Peter Norton writes, "PL/I was built out of four parts: FORTRAN's calculations, COBOL's I/O formatting, ALGOL's structure, and some new topics." Later he identifies these "new topics" as "support of interrupts, use of macros and program libraries, and other goodies of that ilk."
Though somewhat popular through the 1970’s, PL/I never experienced the success that the System 360 did. For the most part, FORTRAN programmers continued to program in FORTRAN, and COBOL programmers continued to program in COBOL. As it turns out, PL/I’s greatest strength was also its fatal flaw: flexibility. As Robert Sebesta puts it: “…the design of PL/I was based on the premise that any construct that was useful and could be implemented should be included…” (Sebesta 71) This philosophy led to a language that was almost infinitely complex and much too complicated for the average programmer to master fully. PL/I was not without its merits, however. As Peter Norton points out above, PL/I included some programming constructs that were completely without precedent. Sebesta cites concurrency, error handling, pointers as a data type, and cross sections of arrays (slices.) (Sebesta 71) Problems with these new features will be discussed in other sections of this report, but it is important to remember that, as with any innovation, the first implementation seldom turns out to be the best implementation.
Data types in PL/I are both numerous and flexible. Numeric types include integer, fixed-point, floating-point, and complex. Each of these types can be declared as signed or unsigned, stored as binary or decimal, and can have a set length and precision at runtime or be left a variable length and precision. A character data type is included, as is an array data type. Arrays can be manipulated at the elemental level, but part or all of the array can be manipulated as an aggregate. That is, if A is declared as a 3 x 3 array of any numeric type, performing the square root operation on the array yields a second 3 x 3 array whose elements are the square roots of their corresponding elements in A. While many languages choose to implement strings as arrays of characters, PL/I treats strings as a separate data type, including functions that concatenate, reverse, search, and compare strings as part of the language rather than an external package. For this reason, PL/I is often considered one of the best languages for string manipulation. As mentioned earlier, pointers are also a data type to themselves in PL/I. Sebesta maintains that dangling pointers (pointers that contain the address of heap-dynamic variables that have been deallocated) and lost heap dynamic variables (variables no longer accessible to the user program) are problems in PL/I. (Sebesta 241-42) However, in an email interview with this author, Dana Guild remarks that pointers in PL/I “…are more intuitive making it much easier to read and write with pointers.” (The complete text of this interview may be found in the appendix to this report.) PL/I is touted by its proponents as one of the best languages for data types both because of the sheer number of types that are inherently supported and because data types in PL/I are structure type compatible, allowing variables with the same structure to be related (e.g. assigned to one another, etc.) While this allows a good deal of mixing data types, sometimes in powerful arrangements, it also can lead to programming mistakes that will not be caught by the compiler.
PL/I is considered the first structured programming language. Peter Flass describes PL/I’s structure thusly: PL/I is a block-structured language. The outermost block, the External Procedure, provides the shell for all code and data. Other blocks, Procedures, which are executed only as subroutines or functions, and Begin-blocks, which are executed inline can be nested to any depth. An example of PL/I’s block structure can be seen in the following code sample from Concepts of Programming Languages by Robert Sebesta: /* READ INPUT DATA INTO AN ARRAY AND COMPUTE THE SUM */ DO COUNTER = 1 TO LISTLEN; GET LIST ( INTLIST (COUNTER)); SUM = SUM + INTLIST (COUNTER); END; (Sebesta 72) The block starts with the keyword that identifies the kind of block (i.e. DO indicates a loop,) and ends with the keyword END. Keywords vs. Reserved Words At this point an important distinction in terminology should be noted. Keyword and reserved word are not synonymous terms. For this discussion, we shall use Sebesta’s definition of these terms. “A keyword is a word of a programming language that is special only in certain contexts. … A reserved word is a special word of a programming language that cannot be used as a name.” (Sebesta 158) In other words, a reserved word has significance to a compiler and can only be used in the context which the compiler expects. For example, in C++ the programmer cannot make the following declaration: int new;
because new is a reserved word which declares a new block of dynamic memory. If new is used in any other context, the compiler generates a compile error. By contrast, a keyword is a word that has significance to a compiler, but can be used as an identifier without conflict. PL/I uses keywords rather than reserved words. Many proponents of PL/I consider this a benefit because a beginning programmer does not have to have knowledge of all the words that are significant to the compiler. He or she can just code the program using identifiers that make sense to him or her. This is especially important in PL/I because it has so many significant words. The downside, however, is that the experienced programmer may have a hard time reading such a program because of the perceived ambiguity of using keywords as identifiers. Furthermore, Sebesta points out that the following hopelessly confusing declaration is perfectly legal: INTEGER REAL; REAL INTEGER; While the experienced programmer will likely know to avoid such strange declarations, the novice programmer could easily write totally unreadable code without even knowing it.
Because of its block structure, PL/I allows variables to be declared in the middle of executable code. This feature was borrowed from ALGOL 60. (Sebesta 177) In fact, scoping in PL/I is pretty much identical to scoping in ALGOL 60. Peter Flass describes PL/I’s scoping scheme as follows: “Data declared within a block has a ‘scope’ consisting of the block within which it is declared and all nested blocks, unless overridden by another declaration.” By “overridden,” Flass means that a variable declared in a nested block that has the same name as a variable declared in any parent blocks will override the declaration in the parent block. When the inner variable goes out of scope, (i.e. the block in which it is declared terminates,) any further references to a variable of that name will refer to the variable in the parent block, which will have retained its original value throughout the execution of the nested block. To pass a variable that would otherwise be out of scope, PL/I allows subprograms to receive arguments. By default, these are passed by reference, that is, any modifications made to the variable in the subprogram are made to the variable in place (the address where it is stored.) This can be changed however, by enclosing the argument in parentheses when the subprogram is called. This will cause the subprogram to receive a copy of the variable, so no change will be made to the variable itself. Consider this example from Sturm’s Power vs. Adventure: call Sub ((K), M, A); In this example, M and A are passed by reference and K is passed by value. Concurrency PL/I was also the first language to support concurrency. Of course, it isn’t true concurrency, in the sense that two processors are performing two separate tasks at the same time. At the time that PL/I was introduced, multi-processor systems hadn’t even been developed yet. Peter Norton describes use of concurrency in PL/I like this: PL/I programmers use event or task variables to spawn and coordinate tasks, with two built-in functions -- STATUS and COMPLETION. PL/I programmers can prioritize tasks with the PRIORITY option and check the priority of any executing task with the PRIORITY built-in function. PL/I performs task rendezvous with the WAIT statement. Sebesta points out that this feature of PL/I wasn’t that good. True concurrency is just becoming possible. It is likely that we will only now begin to see languages where concurrency that is well implemented. Evaluation The last part of this report will be this author’s evaluation of the PL/I language. This evaluation will be based on Sebesta’s four criteria of program language evaluation, namely: readability, writability, reliability, and cost. Readability For all its flexibility and innovation, PL/I is notoriously difficult to read for a number of reasons. First is its use of the much-maligned GOTO statement. Though a common feature at the time of PL/I’s creation, the GOTO has been largely abandoned in recent years because of its tendency to produce “spaghetti code,” that is, code that is so intertwined that it is difficult to read. Further contributing to this problem is PL/I’s method of exception handling. In PL/I, exceptions are dynamically bound, that is, bound at run-time. Therefore, the last encountered definition of an exception is the one used when that exception is raised, no matter its location relative to the statement that raises the exception. While this problem can be avoided by giving all exceptions unique names, the concept of dynamic binding as it relates to exception handling has been long-since abandoned. Yet another impediment to PL/I’s readability is discussed in Eberhard Sturm’s article “Power vs. Adventure: PL/I and C.” Sturm points out that the following two declarations are identical in PL/I: dcl F float init (1) nonasgn abnormal; dcl F float nonasgn abnormal init (1); In other words, as long as the first keyword is present, the subsequent statement modifiers may be in any order that the programmer chooses. (It should be noted that although Sturm presents this as a beneficial feature of PL/I, it is this author’s opinion that it impairs readability and is here presented as such.) Writability Most of the features that hinder readability in PL/I are helpful in terms of writability. Not having to worry about reserved words or ordering of statements makes PL/I easily writable for even novice programmers. Also, unlike C++, PL/I is not case sensitive. That means that the keyword “put” functions the same whether the programmer spells it “put,” “PUT,” “Put,” or even “PuT!” Another feature that adds to the writability of PL/I is use of compiler defaults. Peter Flass’s website best sums up this feature: In the minimal case, data does not need to be declared at all, but will be provided with a set of default attributes depending on the context in which it is used. The programmer has to declare only enough information as necessary and the compiler will fill in the rest. For example, declaring a variable FIXED with no other attributes will cause the compiler to add the default attributes DECIMAL and a precision (number of digits). PL/I is very similar to QBASIC in this respect. This feature is a clear advantage to beginning programmers who do not yet fully understand data types, although in the commercial programming world, Dana Guild points out, “the standard … is to always declare variables,” so commercial programmers will likely get little or no benefit from this feature. Reliability The ultimate measure of code reliability is code lifespan. If code is not reliable, companies will obviously abandon it in favor of something better. Not to do so is to incur unnecessary cost. While it is by no means commonplace, PL/I code is still in place at many large companies worldwide. This would seem to speak highly of its reliability. On the other hand, Dana Guild points out that “PLI is definitely on the way out.” Though it is still supported by IBM, as PL/I legacy code becomes less and less common, IBM’s support of the product itself will wane. Companies who still have PL/I legacy code when this happens will find it very difficult to maintain that code without IBM’s continued support. Cost When discussing cost, we do not simply mean the cost of the software itself. Cost also includes expenses incurred from training people to use software, finding qualified personnel to use the software, and the hardware to run the software. PL/I runs on both mainframe and microcomputer systems and is available for most every operating system, so hardware costs are not a problem. VisualAge PL/1 Enterprise V2.1, which runs under both Windows and OS/2, sells on IBM’s website for $2,849.00. I would assume that this is comparable to most other commercial design environments. That leaves only the cost of personnel. When asked about finding PL/I personnel, Dana Guild responded: “It’s difficult to find people who already know PLI … but it’s not too hard to find people willing to learn it.” While knowledge of PL/I is a rare commodity, it’s also one that is in low demand, which keeps the cost of hiring qualified programmers to a minimum. With PL/I, the major cost is training. To train a programmer in all the features of PL/I would obviously be extremely costly because of the sheer volume of features of the language. Companies must decide which features are most important to their purpose, and train their employees accordingly. Overall
The following is the text of an email interview that the author conducted with Dana Guild. Ms. Guild is a Murray State University alumnus and maintains PL/I code for State Farm Insurance. Questions and answers are included exactly as they appeared in the email. Craig Dixon: How long have you been programming in PL/I? Dana Guild: 3 years CD: What other programming languages do you have experience with? DG: Cobol, C, C++, Visual Basic, Pascal, SQL, PowerBuilder, RPG, Assembler CD: Overall, how does PL/I compare to these languages? DG: It’s a bit of a cross between Pascal and C++...not nearly as wordy as Cobol, but not as cryptic as C++. I'd say it’s fairly close processing-wise to Cobol (good at handling everyday data manipulation, etc), although it makes handling pointers much easier. CD: Overall, is PL/I the best language you have used? DG: I guess it probably depends on what you are using it to code for (if it’s highly mathematical, definitely no), but I'd probably have to say overall no it’s not the best. I've run into limitations with it just in the minimal contexts I use if for (variable definitions, for example) and sometimes you have to jump through hoops to get it to do what you want (data conversions, for example) CD: Many would consider PL/I a dead (or at least dying) language. In your opinion, is PL/I on its way out, or will it live on through legacy code the way COBOL has? DG: Oh, PLI is definitely on the way out...there are very few companies left that have any code in PLI. However, the companies that do still have it, will probably have it until they have to get rid of it. Almost half of all the mainframe code at State Farm is in PLI and we do still develop new code in PLI. COBOL is much more common in companies all over the US, so PLI will probably leave the scene way before COBOL, but I don't see it dying anytime soon. CD: Most universities don't teach programming in PL/I. How difficult is it to move from another language to PL/I? DG: Not difficult at all. It’s pretty easy to pick up any new language, so long as you have the basics of programming (linear, not OO) down already. All you have to do is learn the syntax and most of that is similar enough to other languages that its easy to learn. There are a few oddities of PLI that you would have to learn (such as based storage, or pointers) but they are pretty easy to understand. The class they give here at SF is only about 6 - 8 weeks and they include more than just learning PLI (such as SF standards and tools, etc). CD: Is it difficult to find programmers who can already write and maintain PL/I or who are willing to learn PL/I? DG: It’s difficult to find people who already know PLI (I don't think SF even looks for that anymore), but its not too hard to find people willing to learn it...I'm sure most people would prefer to work with something that makes them marketable, but if there are other opportunities available in the same company, people are easily willing to work with PLI for a while. State Farm doesn't seem to have a hard time finding people willing to learn PLI...they just hire the people and train them on it. CD: What is the primary purpose of the PL/I programs that you maintain? DG: My programs support some Accounting functions...we pull in payments made and make sure the transactions get ledgerized and EFTed(money transferredfrom bank account to bank account) to the correct places. CD: Why was PL/I chosen for this task? DG: I'm not sure...it was way before my time here when these programs were written. My best guess is that PLI was the State Farm standard at the time or that other, similar functions were already written in PLI. Today if we make changes which require a new program or module, we still write it in PLI just because that's what everything (in this system) is already in. However, the standard today is COBOL...brand new systems that have been written in the past 10 or 15 years have been written in Cobol. CD: PL/I is platform independent. On what platform does your PL/I code run? DG: IBM mainframe (OS/309) CD: My preliminary research indicates that PL/I is interpreted rather than compiled. (Author’s note: Further research revealed that PL/I is compiled rather than interpreted.) How does this fundamental difference affect the performance of PL/I programs? DG: I haven't noticed any performance issues with PLI at all, but then most of the stuff we use it for doesn't really depend on milliseconds to make the difference. It is completely transparent to me...we use a complier, just the same way we do for Cobol programs and they both seem to very similar. CD: I have also discovered that there are no reserved words in PL/I. Many proponents of PL/I claim this is one of the beneficial features of PL/I, but it seems to me that this would lead to problems with both readability and writability. Based on your experience with PL/I, what is your opinion on this issue? DG: I haven't had any problems not having reserved words. Standards here at State Farm requires naming variables descriptively, so I haven't really run across any problems with reserved words, but I don't think it would cause problems with readability so long as the variables were defined. CD: Specifying lengths and types of variables is optional in PL/I. Do you find this beneficial, or do the language's default settings and implicit conversions make the code too hard to debug? What other benefits or problems does this feature cause? DG: The standard here at State Farm is to always declare variables, so all the code here has the variables declared. When I was learning the code though, it did make it a bit more difficult to debug, if you accidentally left out a variable declaration or misspelled a variable somewhere, because it doesn't cause the compile to crash, so you might not even realize that you had made a mistake (and its always harder to debug logic errors than compile errors). I suppose a benefit would be that you don't have type quite as much, but I don't think that's worth the effort you would have to put in to make sure you followed the standards to get the defaults used correctly. CD: From the sparse sample code I have looked at, it seems that pointer variables are easier (at least in terms of readability) in PL/I, than say, C++. How do PL/I's pointers stack up in terms of writability and reliability? DG: I really like the way PLI uses pointers...they are more intuitive making it much easier to read and write with pointers (at least from my point of view). I guess the only drawback that I can see is that you may not always realize you are dealing with a pointer unless you check the declarations (if you don't use a naming convention for pointers). But it makes using pointers so easy and simple to understand that it’s like a normal variable. BibliographyFlass, Peter. The PL/I Language. 6 Sept. 2001 Guild, Dana. Email interview with the author. 5 Oct. 2001 IBM.com. 6 Sept. 2001 Marco, Lou. “In Praise of PL/I.” Enterprise Systems Journal (December 1996): 32-37. Rpt. at Norton, Peter. “The Norton Chronicles.” PC Magazine (15 May 1984). Rpt. at Sebesta, Robert W. Concepts of Programming Languages. 4th ed. Reading, MA: Addison-Wesley Sturm, Eberhard. “Power vs. Adventure: PL/I and C.” Presentation at G.U.I.D.E. & SHARE Europe Joint Conference (10-13 October 1994, Vienna, Austria). Rpt. at Vowels, Robin. “Why You Should Consider Using PL/I.” Editorial. 5 Sept. 1998. 13 Sept. 2001. Directory: academic -> faculty -> wlyle -> 415 415 -> Python Ben Hester csc 415 November 2012 a look at Python 415 -> How Ada was conceived: the language not the woman. Kyler Branaum 415 -> Review of Pascal Jinbo Lin 415 -> C++ Programming Language History of C++ 415 -> Murray State University csc 415 Programming Languages Dr. William Lyle 415 -> C# Megan Yahl csc 415: Programming Languages Dr. Lyle November 20, 2012 History of C# 415 -> Csc 415: Programming Languages Jonathan Huelman 415 -> Visual Basic. Net 415 -> Matthew Carson csc 415: Programming Languages Download 45.15 Kb. Share with your friends:
|