As a starting point, contrary to the claims NEW! Most Popular Programming Languages 1965 - 2022 by Data Is Beautiful where FORTRAN ranked the first until 1980 and COBOL was surpassed by Pascal in 1977Q2, according to DoD's "TINMAN" Language Evaluation, Jan. 1977, COBOL seemed to be the most widely used higher order language (pp.54), and FORTRAN was still the most widely used language after COBOL (pp.52). The experience with PASCAL was largely in a research environment. It had not been widely used for large production programs. (pp.24)
PL/I was more widely used by an order of magnitude than any of the other proposed base languages (pp.21), claims High Order Language Working Group (HOLWG), which is totally left out by the video.
Link: Ada and its candidate languages
Candidates evaluated were:
A: Recommended Languages
(These languages each represent a different synthesis of large amount of previous experience,
and constitute the nucleus of a family of derived languages).
1. PL/I: Includes concepts from FORTRAN, ALGOL 60 and COBOL
2. PASCAL: A successor of ALGOL 60 emphasizing simplicity
3. ALGOL 68: A successor of ALGOL 60 emphasizing generality
B: Languages which are Relevant and Deserving of Further Consideration
4. HAL/S: PL/I based, NASA Language, strongly typed, real-time
5. PEARL: PL/I-based, German process control language
6. SPL/I: PASCAL-based NRL real-time signal processing language
7. PDL/2: PASCAL with parallel processing, independent module facilities, Texas Instr.
8. LTR: PASCAL-based official French common language
9. CS-4: PASCAL-based real-time with extension facilities, Intermetrics
10. LIS: PASCAL-based French system implementation language
11. EUCLID: PASCAL-based experimental language emphasizing verification
12. ECL: Extensible language with good support environment, Harvard University
13. MORAL: New British language for embedded computer applications
14. RTL/2: Real-time British language developed at ICI
C: Languages Not Acceptable
15. FORTRAN: Developed by IBM in 1954-58
16. COBOL: Business data processing language developed in 1959-61
17. ALGOL 60: Block structure language developed in 1957-60
18. TACPOL: Army language developed in the late 1960's
19. CMS-2: Navy language developed in 1966-69
20. SIMULA 67: Simulation language developed in Norway
21. JOVIAL J3B: Air Force language developed in 1972
22. JOVIAL J73: Air Force language developed in 1969-73
23. CORAL 66: British common language for real-time applications
The 98 specific TINMAN language requirements are grouped into the following 13 categories:
2.1 Data and Types
The requirements in the "Data and Types" category may be summarized as follows:
A1. Date types determinable at compile time and unalterable at run time.
A2. Integer, fixed, float, Boolean, character, array and record types.
A3. Precision specs for floating point arithmetic and variables.
A4. Exact fixed point numbers with user specified range and fractional part.
AS. Character sets with user defined collating sequence.
A6. Arrays with static lower bound and dynamic upper bound.
A7. Variant records fully discriminated at run time.
A1 is a general requirement on data types.
A2 specifies the set of required data types.
The remaining requirements specify in greater detail the characteristics of required data types.
Requirement A7 is intended as a substitute for the union data types.
2.2 Operations
The TINMAN requirements on operations may be summarized as follows:
B1. Assignment and reference operations for data types
B2. Equivalence operator for all data types
B3. Relational operations for numeric and enumeration types
B4. Arithmetic operations +, -, *, /, ÷, ↑, unary minus
B5. Truncation and rounding of least significant digits
B6. Boolean operators and, or, not, xor, short circuit mode
B7. Direct assignment for conformable composite data types
B8. No implicit type conversion
B9. No conversion required for numeric ranges, range checking optional
B10. I/0 operations for files, channels, terminals
B11. Power set operations (logical operations on Boolean vectors).
B1 and B2 specify operations applicable to all data types.
B8 specifies a restriction on conversion between types.
The remaining requirements indicate specific types required by the language and properties of some of these types.
2.3 Expressions and Parameters
The TINMAN requirements on expressions and parameters may be summarized as follows:
C1. Side effects evaluated left to right
C2. Readable expressions with few levels of operator precedence
C3. Expressions permitted whenever constants and variables allowed
C4. Constant expressions evaluated before run time.
C5. Consistent rules for parameters of procedures, arrays, declarations, etc.
C6. Type agreement of formal and actual parameters
C7. Classes of formal parameters
C8. Optional parameter attributes in procedure declaration
C9. Procedures with variable number of parameters
C1 - C4 are concerned with properties of expressions.
C5 - C9 are concerned with parameters of procedures and arrays.
2.4 Variables, Literals, and Constants
The TINMAN requirements on variables, literals and parameters may be summarized as follows:
D1. Identifiers with constant values may be defined
D2. Constants will have some value in programs and data
D3. Declared variables may be initialized. No default initial values
D4. Range and step size for fixed point variables must be specified
D5. Arrays and records may have components of any type
D6. Pointer variables must be as safe as other variables
D1 and D2 specify properties of literals and constants.
D3 - D6 specify certain properties of variables.
2.5 Definition Facilities
The TINMAN requirements on definition facilities may be summarized as follows:
E1. Users will be able to define new data types
E2. Defined types will behave like built-in types
E3.- There will be no default declarations
E4. Operations will be extendable to new data types
E5. Type definitions do not automatically inherit operations
E6. New types may be defined by enumeration, Cartesian product, discriminated union, power set
E7. Type definition by free union and subsetting is not desired
E8. Type initialization and finalization procedures are definable
2.6 Scopes and Libraries
F1. Distinction between scope of allocation and scope of access
F2. Access to identifiers can be limited both at their point of definition and point of call
F3. Scope of identifiers will be determined at compile time
F4 Libraries will be supported and easily accessible
F5. Libraries will not exclude routines written in other languages
F6. Libraries and compools will be indistinguishable
F7. Standard library definitions for machine dependent interfaces
F1 - F3 are concerned with scopes and rules for accessing identifiers, while
F4 - F7 are concerned with the interface between the language and libraries.
2.7 Control Structures
The TINMAN requirements on control structures may be summarized as follows:
G1. Structured control mechanisms, parallel processing, exception and interrupt handling
G2. Go-to only within most local access scope
G3. Fully partitioned if-then-else, case statement, Zahn's device
G4. Iterative control with local control variable
G5. Recursive and non-recursive routines
G6. Parallel processes, synchronization, critical regions
G7. User defined parameterized exception handling
G8. Real and simulated time, relative priorities, synchronization
G1 lists the desired control mechanisms.
G2 - G5 indicate desired conventional control structures.
G6, G7, G8 respectively indicate requirements for parallel processing, exception handling and real-time.
2.8 Syntax and Comment Conventions
H1. Free format, statement delimiter, easily parsed
H2. No modification of source language syntax
H3. Language definable in 64-character ASCII set
H4. Formation rules for identifiers and literals
H5. No continuation of lexical units across lines
H6. Keywords will be few, reserved, informative, not confusable with identifiers
H7. Uniform readable comment convention
H8. No unmatched parenthesis are permitted
H9. No language imposed distinction between function calls and data selection
H10. Symbols in same context cannot have different meaning
2.9 Defaults, Conditional Compilation, Language Restriction
I1. No undefined defaults which affect result of computation
I2. Defaults which optimize implementation of language features are encouraged
I3. Compile time variables which specify object computer environment
I4. Conditional compilation
I5. Simple base language which allows efficient definition of complete language
I6. Translator restrictions should be part of language definition
I7. Object machine restrictions should not be part of language definitions
2.10 Efficient Object Representation
J1. No run-time costs for unused generality
J2. Language design should allow safe optimizations
J3. Encapsulated access to hardware facilities and machine code
J4. Object representation of data structures can be specified
J5. Programmer can specify routine calls to be open or closed
2.11 Program Environment
K1. Language will not require an operating system
K2. Language will support integration of independent modules
K3. Linkers, loaders, -debuggers, and other systems software available
K4. Documentation, editing, testing and other support software available
K5. Optional assertions, debugging specs, measurement probes
2.12 Translators
L1. No supersets. Features not permitted are forbidden
L2. No subset implementations will be allowed
L3. User control of optimization and compile time costs
L4. Translators for a variety of object machine;
L5. Translator is not required to run on object machine
L6. Syntax checking but not error correction by translator
L7. Error diagnostics specified as part of language definition
L8. Internal translator structure not part of language standard
L9. Translators will be written in the source language
2.13 Language Definition Standards and Control
M1. Individual features must be state of the art
M2. Unambiguous and clear language definition
M3. Tutorial and reference documents, defined by abstract comput
M4. Configurations control to ensure translators conform to standard
M5. Support agent responsible for maintaining language and support software
M6. Standards and support agents for libraries
![Which Programming Language Should I Learn First? [Infographic]](https://carlcheo.com/wp-content/uploads/2014/12/which-programming-language-should-i-learn-first-infographic.png){kind=link}