Why not use PL/I? 
Author Message
 Why not use PL/I?

Why you should consider using PL/I:

---It is an easy language to use; the syntax is clean, and the rules are
uniform.  There are many built-in functions to assist.

It is a good first language, and provides an excellent growth
path for the professional.

1. The best part of PL/I is the input and output.  You can rely on it.

   The input/output is achieved with statements that are ready to use,
   and easy to use.

   There's no setting up to do.  They are *not* procedures or functions
   made to look like statements.

   In formatted output, you don't get silly numbers displayed when
   you include the format specification, but omit the name of the
   variable (e.g. C);  nor when you use the wrong format (e.g. I4
   with a fortran REAL variable).  PL/I converts to/from the type
   that you specify, be it integer, fixed-point, or string.
   You don't get silly things happening because you left off the
   "&" from the "scanf" function in C.  That's because the input operation
   (GET) is a statement, not a function.

   And when you want formatted output, you have a variety of formats
   that you can choose, such as Picture format, with drifting signs
   and drifting $ sign.  You can insert commas or spaces in very long
   numbers, to make the output readable (e.g. 123,456,789.356,251 is better
   than 123456789.356251).  You can use either Picture formats or
   the specific codes to get integer, decimal fixed-point and
   floating-point outputs.

   And if you don't want to be bothered with formats, you can use
   simple free-formatted output, e,g, PUT (X);

2. For business applications, you can have decimal data, whereby
   data is stored exactly (e.g. 5.14 is stored EXACTLY, not as
   5.13999), and arithmetic operations give exact results
   (e.g. 3 x 5.14 gives you 15.42, not 15.41998)

3. Files are easy to use.  If you can do output to the screen, and input
   from the keyboard, you can do Input/Output to files, simply by inserting
   the file name into the GET or PUT statement.  e.g. GET FILE (MYDATA) etc.

   Outstanding and helpful facilities include:

1. the debugging facilities are all part of the language (checking
   with STRINGRANGE and SUBSTRINGRANGE etc are most helpful, along
   with appropriate ON statements to display the variables).

   The best part of this is that you can display everything you need
   (statement number, variables, procedure call trace, etc)
   instead of those cryptic messages from other languages such as
   "floating-point trap" at some inidentified location somewhere in
   the program.  (When you've had this message in a 20,000 line program,
   you'll know what I mean!)

2. The ability to intercept errors (via ON statements) and to
   continue execution;

3. The simple, handy I/O statements GET LIST, PUT LIST, along
   with the very handy PUT DATA statement (for debugging mostly).

4. Everything is "ready to go" unlike some other languages, such as Ada!

5. The whole-array operations simplify programming and increas under-
   standing, and increases execution speed into the bargain;

6. The COMPLEX data type is provided, which simplifies the preparation
   of programs because complex arithmetic is provided, along with a
   number of essential functions for producing complex square root:
   the conjugate, the absolute value, and for extracting either the
   real or complex components, and for fabricating a complex number from
   two real numbers. (SQRT, CONJG, ABS, REAL, IMAG, CPLX).

   Even more importantly, the debugging of such is simplified, because
   the error messages are more-appropriate (compared to
   programming without using COMPLEX data).  And the COMPLEX
   type can be applied to integer as well as to FLOAT.

7. PL/I has excellent string-handling facilities.  First, there
   are two types of string -- the fixed-length string and the
   varying-length string.  These two data types are supported by a
   range of functions that speed up string processing compared to
   other languages.  It isn't necessary to write your own "string-search"
   routines like you need to in other languages such as C and Pascal, for
   example.  The search functions are already there (INDEX, SEARCH, SEARCHR).
   What's more, if the machine has a "search" instruction, it can use that,
   and search 10 times faster than some hand code using a loop. (Having
   to write your own search routine is like having to turn out
   your own nuts and bolts on a machine lathe).

   PL/I can search from either the right-hand end or from the left-hand
   end of a string (SEARCH and SEARCHR)

   Joining strings is a simple operation (catenation); the length of
   a string can be discovered by using the LENGTH function; strings
   containing blanks (or any unwanted character) at the beginning or the end
   can be removed using the TRIM function.  Strings can
   be centered using the CENTER function (helps with page headings etc)
   and so on.

8. And when you want to do something special (rarely, but it's
   nice to know that you have something to fall back on in
   an emergency) it's there -- With UNSPEC you can peek at
   the bits of a data item (be it a character string, an
   integer, bit string, or floating-point data).



Tue, 27 May 1997 09:12:08 GMT  
 Why not use PL/I?
[Robin Vowels]

|   Why you should consider using PL/I:

do you have an FTP site with a PL/I compiler on it that I can snarf and so
try it out?

#<Erik>
--
The check is in the mail.  This won't hurt.  You'll find it on the Web.



Tue, 27 May 1997 12:35:39 GMT  
 Why not use PL/I?

: Why you should consider using PL/I:
[snip]
: 4. Everything is "ready to go" unlike some other languages, such as Ada!

are you serious? C'mon!
I ask you to change from soap opera to argumentation.
You are a friend of PL/I which is ok.
I, for my part, am a friend of Ada on the basis of technical merits.
Just a simple comparison between PL/I and Ada:
PL/I went the opposite way concerning strong typing:
You always have such {*filter*} conversions under the carpet
which is a loss of control for the programer.
This design decision is breaking the backbone of any language
in that it makes it useless for reliable software.
The decision has been made in the wrong assumption
to relieve the programer from burdening work.
This turned out to become counterproductive.

: 5. The whole-array operations simplify programming and increas under-
:    standing, and increases execution speed into the bargain;

execution speed is not a matter of language.

[snip]

--

Pfaffenwaldring 27, 70569 Stuttgart Uni Computeranwendungen
Team Ada: "C'mon people let the world begin" (Paul McCartney)



Tue, 27 May 1997 22:55:39 GMT  
 Why not use PL/I?

:
: Why you should consider using PL/I:
:
Why you should NOT consider using PL/I:

1) No reserved words.  The following nonsense is legal:

    IF THEN THEN THEN = ELSE; ELSE ELSE = THEN:

2) Control flow: no case statement, no break or continue.

3) Labels everywhere.  Labels with goto's, labels as procedure entries,
   labels on loops, label variables, labels passed as arguments to procedures.

4) No user-defined types.  NO user-defined types!

--
--Bill Kinnersley

226 Transfer complete.



Tue, 27 May 1997 23:49:56 GMT  
 Why not use PL/I?

Quote:


>:
>: Why you should consider using PL/I:
>:
>Why you should NOT consider using PL/I:

>1) No reserved words.  The following nonsense is legal:

>    IF THEN THEN THEN = ELSE; ELSE ELSE = THEN:

Picking poor variables names is easy with or without reserved
keywords.  Using 'IF', 'THEN' or 'ELSE' is probably not too
smart.  On the other hand 'VALUE' as a variable can be okay and
it is a rather obscure keyword.

Not having reserved keywords makes it possible to add new keywords
without breaking existing code.  C customers are not so fortunate.

Quote:
>2) Control flow: no case statement, no break or continue.

PL/I has the 'select' statement which is equivalent to the case
statement, the 'leave' statement is equivalent to break, and 'iterate'
is equivalent to continue.

Quote:
>3) Labels everywhere.  Labels with goto's, labels as procedure entries,
>   labels on loops, label variables, labels passed as arguments to procedures.

They are rarely needed.  Most languages have these constructs, it is
up to the programmer to use them wisely.

Quote:
>4) No user-defined types.  NO user-defined types!

I agree and they were added to the latest release of PL/I.  Typed
pointers were also added.

Paige Vinall - PL/I Development Manager, IBM



Fri, 30 May 1997 05:43:24 GMT  
 Why not use PL/I?

Quote:

>: Why you should consider using PL/I:
>[snip]
>: 4. Everything is "ready to go" unlike some other languages, such as Ada!

>are you serious? C'mon!
>I ask you to change from soap opera to argumentation.
>You are a friend of PL/I which is ok.
>I, for my part, am a friend of Ada on the basis of technical merits.
>Just a simple comparison between PL/I and Ada:
>PL/I went the opposite way concerning strong typing:
>You always have such {*filter*} conversions under the carpet
>which is a loss of control for the programer.
>This design decision is breaking the backbone of any language
>in that it makes it useless for reliable software.
>The decision has been made in the wrong assumption
>to relieve the programer from burdening work.
>This turned out to become counterproductive.

The merits of automatic conversions have been debated for several
years.  As a result of design sessions with customers, a compiler
option was implemented to make automatic conversions illegal.  During
beta programs, it proved to be too restrictive.  For instance
consider:

  dcl i fixed bin(31);
  i = 10;

The assignment causes conversion from fixed dec (aka packed decimal)
to fixed bin.  So conversions during assignments were excluded but that
caused some obvious 'bad' conversions to be missed.  In the end, the
decision was made to flag only those conversions that are likely to
cause performance problems.

Paige Vinall - PL/I Development Manager, IBM



Fri, 30 May 1997 06:26:59 GMT  
 Why not use PL/I?

Quote:


>>1) No reserved words.  The following nonsense is legal:

>>    IF THEN THEN THEN = ELSE; ELSE ELSE = THEN:

>Picking poor variables names is easy with or without reserved
>keywords.

Right.  No language makes it hard to write unreadable code (but some make
it hard to write readable code).  Consider that no one even *thought* of
having obfuscated code contests until C came along!  And even if the
keywords were reserved, the following nonsense would be legal:

IF FI = THAN THEN THAN = FLSE; ELSE FLSE = THAN;

If the original poster was concerned that the lack of reserved keywords
makes it easier for typoes to go unnoticed, I don't think that's a problem.
If you use a keyword where an identifier is expected, you'll almost certain
get a warning about an undeclared variable or function.  If you use a
keyword somewhere else unexpected you'll just get a syntax error.
Languages without keywords make life a little harder on the compiler
implementor, but it rarely affects the programmers.

Quote:
>>2) Control flow: no case statement, no break or continue.

>PL/I has the 'select' statement which is equivalent to the case
>statement, the 'leave' statement is equivalent to break, and 'iterate'
>is equivalent to continue.

I don't think ANSI PL/I requires the SELECT statement.  I don't remember it
being in Multics PL/I, which claimed to conform to the ANSI spec.  IBM has
lots of extensions in their PL/I (so does Multics), but that doesn't make
them part of the standard language.
--

Barry Margolin
BBN Internet Services Corp.



Sat, 31 May 1997 03:30:37 GMT  
 Why not use PL/I?

Quote:

>>---If you want explicit type conversions in PL/I, you can have them too.
>That misses the point.  The point is that you can't _prevent_ the hidden
>implicit ones, so it is not obvious what is going on (especially if you
>are a beginner).  If modern PL/Is provide some way of disabling the
>default conversions, _that_ would defeat this argument.

I don't know about "modern" PL/I's, but Multics PL/I has been warning about
non-trivial implicit type conversions for at least 15 years.  It doesn't
disable them completely, but they aren't "hidden", so it's obvious what is
going on.
--

Barry Margolin
BBN Internet Services Corp.



Sat, 31 May 1997 03:41:42 GMT  
 Why not use PL/I?


: :
: : Why you should consider using PL/I:
: :
: Why you should NOT consider using PL/I:

: 1) No reserved words.  The following nonsense is legal:

:     IF THEN THEN THEN = ELSE; ELSE ELSE = THEN:

This is no more non-sensical than 75% of the C code I've seen.

: 2) Control flow: no case statement, no break or continue.

I've used PL/1 compilers that did, indeed, provide case (switch) statements.

: 3) Labels everywhere.  Labels with goto's, labels as procedure entries,
:    labels on loops, label variables, labels passed as arguments to procedures.

As opposed to C's ability to branch anywhere, whether it's got a label
or not.

: 4) No user-defined types.  NO user-defined types!

Admittedly the only flaw you've mentioned, and one which could
be corrected.

: --
: --Bill Kinnersley

: 226 Transfer complete.
--
--

"The large print giveth, and the small print taketh away."  -Tom Waits



Sat, 31 May 1997 05:02:09 GMT  
 Why not use PL/I?

: : Why you should consider using PL/I:
: [snip]
: : 4. Everything is "ready to go" unlike some other languages, such as Ada!

: are you serious? C'mon!
: I ask you to change from soap opera to argumentation.
: You are a friend of PL/I which is ok.
: I, for my part, am a friend of Ada on the basis of technical merits.
: Just a simple comparison between PL/I and Ada:

: PL/I went the opposite way concerning strong typing:

: You always have such {*filter*} conversions under the carpet
: which is a loss of control for the programer.

You can bypass type conversion if you need to, using based pointers.

: This design decision is breaking the backbone of any language
: in that it makes it useless for reliable software.
: The decision has been made in the wrong assumption
: to relieve the programer from burdening work.
: This turned out to become counterproductive.

Only if you come from the NIH school of programming, which is
apparantly true of _most_ programmers. Until programming starts
to attract disciplined people, many programmers _should_ be
chained up by the language they use.

: : 5. The whole-array operations simplify programming and increas under-
: :    standing, and increases execution speed into the bargain;

: execution speed is not a matter of language.

Smalltalk programmers have demonstrated time and time again that
even though it (Smalltalk) does not compile to native code, the
same program written in another language (like C++) does _not_
run faster, but either the same or slower. So yes, given a
particular platform and problem definition, the choice of
language can mean _everything_ to execution speed.

--
--

"The large print giveth, and the small print taketh away."  -Tom Waits



Sat, 31 May 1997 05:09:32 GMT  
 Why not use PL/I?

[..deletia..]

: >4) No user-defined types.  NO user-defined types!

: I agree and they were added to the latest release of PL/I.  Typed
: pointers were also added.

I'd very much like to see a complete definition of this latest PL/1
( I used to use subset-G on a Pr1me system).

--
--

"The large print giveth, and the small print taketh away."  -Tom Waits



Sat, 31 May 1997 05:11:38 GMT  
 Why not use PL/I?


: >---Yes.  It is difficult for a beginner to grasp I/O in Ada, and to come to
: >grips with type conversions just to print strings and numbers, for example.

: This puzzles me, because NO TYPE CONVERSIONS ARE REQUIRED to print
: strings or numbers in Ada.  In fact, Ada shines here in comparison with
: C (I am _not_ saying anything here about PL/I).  The only portable way
: that I know to print
:         size_t x                printf("%lu", (unsigned long)(x))
:         ptrdiff_t x                printf("%ld", (long)(x))
:         time_t x                -- there isn't any because the meaning
:                                 -- of the numbers you get is not portable

        I think part of the point is thet you're not supposed to
be printing sich things.  Could you show me how to print the difference
between two pointers in ada?  Or the current system clock?

--
------------------------------------------------------------------------------

| Laboratory for advanced computing      |      My employer barely KNOWS me. |
------------------------------------------------------------------------------
And at that point, he did not know if he was a man who had been
imagining he was a god or a god playing at being a man.  Thus was his
illumination perfected.



Sat, 31 May 1997 08:19:59 GMT  
 Why not use PL/I?
I learnt PL/1 when it was called NPL(1965).  
In the last ten years only one student wanted to learn it.
It never caught on, I wonder why?

--

ftp://ftp.csci.csusb.edu/dick
<a href="http://www.csci.csusb.edu/dick/">WWW</a>
Disclaimer::=`CSUSB may or may not agree with this message`.
Copyright(1994)::=`Copy as long as you include this copyright and signature`.



Mon, 02 Jun 1997 04:00:13 GMT  
 Why not use PL/I?


   : ... The only portable way
   : that I know to print
   :         size_t x                printf("%lu", (unsigned long)(x))
   :         ptrdiff_t x                printf("%ld", (long)(x))
   :         time_t x                -- there isn't any because the meaning
   :                                 -- of the numbers you get is not portable

           I think part of the point is thet you're not supposed to
   be printing sich things.  

Your not supposed to print out a value with the type size_t?



Thu, 05 Jun 1997 20:15:12 GMT  
 
 [ 25 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Why _not_ use PL/I?

2. Why not use PL/I ?

3. Why not try PL/I ?

4. WHY NOT USE PL/I (regular post)

5. Why not use PL/I ? (regular post)

6. Why *not* use PL/I (regular post)

7. Why *not* use PL/I? -- (regular posting)

8. It's not PL/1, it's PL/I

9. It's not PL/1, it's PL/I

10. Why not using functional Types?

11. Why not using LOCALs in LOOPs ?

12. Why not using [] instead of () for array?

 

 
Powered by phpBB® Forum Software