Electromechanical Constraints: Punch Cards, Fixed Form, and Typography
Source video: FORTRAN in 100 Seconds (Fireship, 2:38) · at 00:45. The video shows punch cards and says that old keywords used capitals. It does not give the column layout.
The semantic structures and grammatical constraints of early Fortran were directly governed by the physical properties of the 80-column Hollerith punch card6. Individual lines of program source were punched onto discrete rectangular cards, which were organized into physical decks and fed sequentially into electromechanical card readers6. This physical substrate necessitated the “fixed source form” layout that dictated Fortran development through the FORTRAN 66 and FORTRAN 77 standards6.
| Column Range | Field Name | Functional Purpose and Syntactic Significance |
|---|---|---|
| Columns 1–5 | Statement Label | Reserved exclusively for numeric labels referenced by control transfer (GOTO) or formatting (FORMAT) statements; a character in column 1 marked the card as a comment6. |
| Column 6 | Continuation Indicator | Any non-blank, non-zero punched character indicated that the card was an uninterrupted continuation of the statement on the prior card7. |
| Columns 7–72 | Statement Body | The designated field containing executable statements, variable declarations, and computational expressions7. |
| Columns 73–80 | Card Sequence / ID | Reserved for deck identification numbers, ignored entirely by the compiler parser; used by mechanical sorting machines to reorder dropped decks7. |
The pervasive reliance on uppercase typography throughout classical FORTRAN emerged from hardware limits rather than stylistic preference1. Mid-century keypunches, such as the IBM 026 and IBM 029, featured mechanical encoders that lacked lowercase character sets and shift keys6. Because lowercase keying hardware was not broadly deployed in enterprise computing until the 1970s, compiler grammars treated all inputs as uppercase1. Modern Fortran standards, starting with Fortran 90, introduced free source form, discarding column constraints, allowing dynamic line lengths up to 132 characters, and implementing full case insensitivity alongside inline exclamation point (!) comments5.
Review findings for this part
Section titled “Review findings for this part”The findings come from ../../findings/ (pass 1). The script matches them to this part by source line.
| ID | Severity | Evidence | Status | Location | Problem |
|---|---|---|---|---|---|
| D07-C1 | critical | DOC | open | L5-89, L93, L98 | Claim: The superscript numbers cite sources for each sentence.. Problem: The citations do not support the text. Source [1] is a Facebook group post about formatted input and output. The report cites it about 15 times for history, uppercase letters, character sizes, functions, intent and coarrays. Source [6] is a Hackaday article. The reviewer read it (WebFetch). It does not discuss card columns, keypunch models or errors in the video. But the report cites [6] for these (L11, L15, L20, L53). |
| D07-M4 | major | VIDEO VERIFY | verify | L20 | Claim: The IBM 026 and 029 keypunches had no lowercase and no shift keys. Lowercase came in the 1970s.. Problem: The report repeats the story of the video (01:11 to 01:15) and adds details. The 026 and 029 had a numeric shift. The main limit was the 6-bit character code of the computers, with no space for lowercase letters. Standard Fortran permitted lowercase letters only from Fortran 90. |
| D07-m1 | minor | KNOW | open | L15 | Claim: “a character in column 1 marked the card as a comment”. Problem: Only C (and * from FORTRAN 77) in column 1 marks a comment. A digit in column 1 is part of a statement label. |
| D07-m2 | minor | VERIFY | verify | L20, L65 | Claim: Free form permits lines of up to 132 characters.. Problem: This is true for Fortran 90 to Fortran 2018. Fortran 2023 increased the limit to 10,000 characters. |
Review worksheet
Section titled “Review worksheet”1. Goal of this part
Section titled “1. Goal of this part”What does this part try to show, or help the reader decide?
2. Key claims to test
Section titled “2. Key claims to test”| # | Claim | Evidence given (citation / data) | Verifiable? |
|---|---|---|---|
| 1 |
3. Adversarial review
Section titled “3. Adversarial review”- Strongest counter-argument:
- Unsupported, overstated, or outdated claims:
- Source quality (primary vs. blog/forum/marketing):
- Omissions / what a skeptic would ask:
- Internal consistency with other segments:
4. Evaluation
Section titled “4. Evaluation”- Does the segment achieve its goal? (Yes / Partly / No)
- Confidence: (High / Medium / Low)
- Required fixes: