You already know Fortran.Now explore other languages.

The other ubiquitous systems language — but C is row-major where Fortran is column-major, and passes by value where Fortran passes by reference, two classic sources of real interop bugs between them.

• Row-major array storage — the opposite of Fortran's column-major, a classic source of silent bugs when interfacing the two
• Passes everything by value by default; Fortran passes everything by reference — an intent(out) parameter needs an explicit pointer and & in C
• No exponentiation operator at all — pow() from <math.h> is the only way, and ^ means bitwise XOR
• 0-based indexing versus Fortran's 1-based default
• Arrays decay to a bare pointer at a function boundary, losing all size information — Fortran's assumed-shape arguments retain their own size
• The two oldest languages still in everyday use on this site (1957 and 1972) — both ahead-of-time compiled, both manual memory management

Built for exact money math, not floating-point science. COBOL's PIC 9V9 fixed-point fields store decimal digits exactly — the opposite tradeoff from Fortran's binary REAL/DOUBLE PRECISION, which is precisely why COBOL, not Fortran, runs the world's bank ledgers.

• PIC 9V9 fixed-point decimal fields store money exactly — no IEEE 754 rounding error the way Fortran's REAL always carries
• Four mandatory DIVISIONS (IDENTIFICATION/ENVIRONMENT/DATA/PROCEDURE) replace Fortran's single program ... end program block
• A plain PROCEDURE DIVISION paragraph takes no parameters at all — no INTENT system, just shared global WORKING-STORAGE fields
• 88-level condition names are COBOL's closest thing to a LOGICAL type — there is no boolean type otherwise
• MOVE, not =, is the assignment verb, and CALL can only invoke a genuine subprogram, never a paragraph
• One of the two oldest languages on this site alongside Fortran (1959 vs. 1957) — both still running critical infrastructure decades later

A close cousin from the same structured-programming era. Pascal's var/const parameter modes map almost directly onto Fortran's intent(inout)/intent(in) — but Pascal has no whole-array arithmetic at all, unlike Fortran.

• var and const parameters mirror Fortran's intent(inout)/intent(in) almost exactly — a rare direct correspondence
• No whole-array operators at all — prices := prices * 0.9 needs an explicit for loop, unlike Fortran's native array arithmetic
• Real functions usable inside expressions, just like Fortran — no COBOL-style output-parameter workaround needed
• No ** exponentiation operator — Power() from the Math unit is the only way to raise to a power
• repeat...until is a post-tested loop with no direct Fortran equivalent
• Both languages default to 1-based array indexing — no adjustment needed moving between them

Built for exactly Fortran's audience — high-performance numerical computing — with Python-like syntax and an intent-like argument model.

• mut parameters map onto Fortran's intent(inout) almost directly — borrowed (read-only) is the default, just like intent(in)
• SIMD[DType, width] vector types are an explicit, type-level take on the same hardware vectorization Fortran's compiler infers automatically
• Compile-time square-bracket parameters generalize Fortran's KIND system beyond just numeric precision
• Compiles ahead of time to native code, like Fortran — despite the Python-like syntax, there is no interpreter
• raise/raises gives Mojo a genuine catchable-error mechanism Fortran has never had
• Still pre-1.0 — syntax is actively evolving, unlike Fortran's decades-stable ratified standard

Built explicitly to replace Fortran in scientific computing. Julia arrays are column-major for BLAS/LAPACK compatibility, just like Fortran — but * means real matrix multiplication in Julia, not the elementwise operation it always is in Fortran.

• Column-major array storage, matching Fortran exactly — deliberately chosen for BLAS/LAPACK interoperability
• * between two matrices is genuine linear-algebra multiplication in Julia; Fortran's * is always elementwise, with matmul() for the real thing
• Multiple dispatch resolves at compile/JIT time from an open, extensible set of methods — Fortran's generic interfaces resolve from a closed, fixed list
• JIT-compiled, not ahead-of-time — a script compiles the first time each function runs, in the same process that executes it
• Square-bracket compile-time parameters generalize Fortran's KIND system beyond just numeric precision
• 1-based indexing, matching Fortran and MATLAB — deliberately, not by accident

Array programming taken to its extreme. Where Fortran writes a loop over each element, APL has no loop at all — 2×1 2 3 4 5 doubles a whole array in one glyph, and reduction operators replace both sum() and hand-written accumulator loops alike.

• No explicit loops anywhere — 2×numbers scales a whole array with no do loop, more radical than even Fortran's own native array arithmetic
• Right-to-left evaluation with no operator precedence at all — 2×3+4 is 14, not 10, a rule Fortran's ordinary math notation shares nothing with
• Reduction glyphs (+/, ×/, ⌈/) replace Fortran's sum(), product loops, and maxval() all with one composable operator
• A single character is a complete, working array-processing program — the opposite extreme from Fortran's verbose, fully-typed declarations
• Trains compose functions tacitly with no named variables at all — (+/÷≢) is the average function, something Fortran has no syntax to express
• Both languages are deeply array-oriented, but APL treats the array operator itself as the entire unit of computation, where Fortran still writes ordinary scalar-shaped statements that happen to broadcast

The other vector-native language — but where Fortran demands exact shape conformance for elementwise arithmetic, R silently recycles mismatched-length vectors to fit.

• Whole-vector arithmetic is native, exactly like Fortran — numbers * 2 needs no loop in either language
• Vector recycling silently repeats a shorter vector's elements to match a longer one — Fortran would refuse a shape mismatch outright
• No type declarations at all, not even a LOGICAL equivalent — a variable's type is just whatever value it currently holds
• 1-based indexing, matching Fortran and unlike almost every other language compared on this site
• NA is a first-class missing-value marker with no Fortran equivalent — the closest approximation is IEEE NaN
• No compile step — R is interpreted, so a Fortran-style type mismatch only surfaces when that exact line actually runs