TL;DR - I learned procedural programming in Fortran, wrote essentially the same queueing network solution algorithms and simulator in Fortran, then PL/I, then Pascal. For those purposes, PL/I seemed best, but Fortran was OK. (With Fortran and PL/I) the critical issue was to avoid undesirable constructs of the language.

When I got started with procedural programming at U.T. Austin C.S. in 1971, the dominant machine and language was CDC 6600 Fortran. For my dissertation I needed to write a queueing network simulator to attempt to validate approximate numerical methods I developed. Though by then Pascal was an option, Fortran seemed expedient.

In 1975 I joined IBM Yorktown and was asked to dramatically enhance my simulator. It became the core of the “Research Queueing Package” (http://web.archive.org/web/20130627040507/http://www.research.ibm.com/compsci/performance/history.html#RESQ). For the first year or so, I continued to use Fortran. From my perspective, the biggest problems weren’t the bad features, which I could avoid, but the lack of more natural control structures, pointers, and something like structs. My managers lamented that I wasn’t using PL/I. I spent a couple of weeks crafting a SNOBOL program to successfully translate the Fortran to PL/I. For the next decade plus, RESQ development was in PL/I (even after I left Yorktown and subsequently left IBM).

While writing Computer Systems Performance Modeling (https://www.amazon.com/exec/obidos/ISBN=0131651757/0596-2808191-282542), I wanted to illustrate the analysis, algorithms, and simulation concepts developed with RESQ, but be careful not to take anything directly from RESQ. So I wrote everything for the book in PASCAL. 

For a variety of reasons, I remember much preferring PL/I over Fortran and Pascal. The Pascal development environments I used weren’t as productive as the PL/I environments.  Fortran was missing very useful constructs. But Fortran was OK, in my experience.