Re: status of PL/I as a viable language

["Donald L. Dobbs" <donaldldobbs@cox.net>]

Richard Riehle wrote:
> Hyman Rosen wrote:
> 
> 
>>Dmitry A. Kazakov wrote:
>>
>>>Should it mean that an unability to create a perfect code (a thing I
>>>never saw) in one language excuses any design fault of another?
>>
>>Nope. I'm just objecting to "If it broke, and it's C++, it's the
>>language's fault. If it broke, and it's Ada, it's the programmer's
>>fault."
> 
> 
> Good point.   We need to understand that there are limits to what
> can be accomplished by depending only on our tools.   Ada has
> a lot to recommend it for high-integrity software.   Other languages
> have a lot to recommend them.  This started as a PL/I thread, and
> I have learned, more recently, of improvements in PL/I since I
> last used it.   Even so, PL/I, for all its improvements, requires
> skilled programmers.  Ada requires skilled programmers.  C++
> requires skilled programmers.
> 
> My personal preference, based on my experience and current
> knowledge of competing languages continues to be Ada, for
> the kind of software (such as F-22) we have been discussing.
> However, I realize that a highly skilled C++ programmer, one
> who understands the built-in pitfalls of the language, and one
> who understands how to use smart-pointers, smart arrays, and
> lots of other useful C++ classes, can create reliable software.
> The same is  probably true of a PL/I programmer, but I am not
> aware of PL/I being used for many safety-critical applications.
> Someone can help me on that, I suppose.
> 
> The key to successful safety-critical software remains, good
> engineering.   Most programmers have no engineering education,
> and all too often, they have insufficient mathematics.   On systems
> such as the F-22, it is critical that the developers are engineering
> aware, and that they have strong mathematics.
> 
> Yesterday, I particiapted in a discussion of requirements specifications
> where some of the participants thought it was enough to simply specify
> the mathematics needed for the application.   The mathematics happened
> to involve relatively simple calculus.   The eventual design of the
> algorithm was expected to be the job of the programmer.  Of course,
> there would checking, inspection, and testing at some stage, but my
> point was that the algorithm should be specified in more detail and
> not left to the programmer.
> 
> As long as we ignore the importance of engineering when developing
> safety-critical software, we are going to continue to make a mess of it,
> and no programming language will save us.
> 
> Ada is like using a torque wrench.  C++ is like using any convenient
> long-handled wrench.   If the mechanic is careful and has a lot of
> experience, using that long-handled wrench, it will work just fine.  In
> most cases, though, we might find the toque wrench a little more
> reliable.   However, if we have no clue about the appropriate level
> of torque, cannot before-hand do the required computations, and
> have no idea what torque is, we are going to twist off the head of
> the bolt just as easily as the guy with the simple long-handled wrench.
> 
> Richard Riehle
> 

Richard, you have touched on a subject (actually pet peeve of mine for 
many years in this industry) that I will elaborate on, now.

When I first got into the computing business (circa 1962 -- oh my, that 
probably makes me older than David Frank) we had systems analysts and 
programmers.  The latter were actually "coders".  The systems analysts 
were subject matter experts for the application being contemplated.  If 
it was an accounting or payroll package the S.A. was either a CPA or 
someone who had a strong background in accounting/bookkeeping, etc.  If 
it was a guidance program for a missile the S.A. was probably a Ph.D. in 
math or celestial mechanics. The programmer (coder) only had to know his 
Cobol, Fortran, PL/I or assembly language.  He didn't have to know the 
subject matter of the application to any great degree because the S.A. 
wrote an air-tight spec that the coder was to rigorously implement.  His 
was not to reason why.  We developed pretty good software in those days.

Somewhere along the way, it all fell apart when we (as an economy 
measure in smaller shops, I suppose) invented the Programmer-Analyst. 
This, IMHO, is the worst single act that has occurred in this industry 
because we now expect the PA to be both subject matter expect and 
programmer/coder expert at the same time. The trade journals and web 
sites are replete with help wanted ads always demanding an individual 
who is a brain surgeon with ten years of Java, etc.  (I exaggerate the 
point but not by much in many cases.)  I suspect that big aerospace 
projects require so many bodies that there is still some division of 
labor, but in the commercial world this just isn't sufficiently the 
case.  Dual experts are a rare commodity and even when you find them 
they have a self-contained conflict of interest because the quality of 
the Analyst functions will be compromised by the Coder subconscious 
telling himself that the requirement is too hard to implement or should 
be implemented in a different way which diminishes the original 
requirements.

I suspect these opinions will instigate a whole new discussion, which I 
welcome because I think we've all been victim of this phenomenon, 
directly or indirectly.