Fortran.CodeCompared.To/R

A Fortran program needs a program name ... end program name wrapper and a compile step before it can run. R has neither: a script is just a sequence of top-level expressions, and print() writes a value with no ceremony at all.

Fortran comments use !; R comments use # — both run to the end of the line, and both languages have no block-comment syntax at all.

Fortran must be compiled to machine code before it runs — a separate step that catches type errors ahead of time. R is interpreted line by line with no compile step: Rscript runs the file directly, and type errors surface only when the offending line actually executes.

Fortran with implicit none requires every variable to be declared with an explicit type before use. R requires no declaration whatsoever — a name springs into existence the moment it is assigned, and its type is whatever value it currently holds. R variables can even change type across their lifetime with no error, something Fortran's static typing forbids entirely.

Fortran assigns with a bare =. R's idiomatic assignment operator is <- (a left-pointing arrow made of two characters) — R also accepts = for assignment at the top level, but <- is the convention nearly every R programmer follows, since = is reserved for named function arguments in most style guides.

Fortran has genuine scalar types distinct from arrays — an integer variable is not a 1-element array. R has no scalar type at all: 42 is actually a numeric vector of length 1, and length(singleValue) confirms it. Every R value is a vector; what looks like a scalar is simply the length-1 case.

Fortran maintains a strict distinction between integer and real types, chosen explicitly at declaration. R's ordinary number literals — even one that looks like a whole number, such as 5 — are always the double type unless explicitly marked otherwise with an L suffix (5L). This matters for arithmetic: R division always produces a double, never truncating the way Fortran integer division does.

Fortran's boolean literals are .true./.false., surrounded by dots. R's are the bare words TRUE/FALSE (or the shorthand T/F, though R style guides discourage the shorthand since T and F can be reassigned as ordinary variable names).

Fortran's compiler rejects assigning a string to an integer variable before the program ever runs. R has no such check: reassigning count from a number to a string is completely legal, and any bug this introduces only appears later, when code that expects a number receives a string instead — often far from where the reassignment happened.

Fortran builds an array literal with square brackets: [1, 2, 3, 4]. R has no array-literal syntax — every vector is built by calling c() ("combine"), which concatenates its arguments into a single vector.

Unlike Pascal or C, both Fortran and R apply arithmetic element-wise to a whole vector with no loop needed — prices * 0.9 scales every element in a single expression in both languages. This is the deepest structural similarity between the two, and it is exactly why the sharper contrast on this page is about shape-matching rules, not about whether vectorization exists at all.

Another point of agreement: both Fortran and R index from 1 by default, matching mathematical convention. The first element of a 3-element vector is index 1 and the last is index 3 in both languages — a Fortran programmer's indexing instincts transfer directly to R, unlike the adjustment needed for Python, C, or Ruby.

Fortran has no negative-index syntax at all — reaching the last element means calling ubound() explicitly. R does accept negative indices, but they mean something a Fortran programmer would not expect: numbers[-1] returns every element except the first, not the last element. Getting the actual last element in R requires numbers[length(numbers)] or tail(numbers, 1).

Fortran's numbers(2:3) and R's numbers[2:3] are visually near-identical and semantically identical: both select the 2nd and 3rd elements, both are inclusive on both ends, and both use 1-based positions.

This is the headline difference between two otherwise deeply similar languages. Fortran requires elementwise operands to have matching shapes — mismatched array extents are a compile-time or runtime error, full stop, with no silent workaround. R instead recycles the shorter vector, repeating its elements until it matches the longer one's length, so c(1,2,3,4) + c(10,20) silently produces 11 22 13 24. R issues a warning only when the longer length is not an exact multiple of the shorter — otherwise recycling happens with no signal at all, a frequent and hard-to-spot source of R bugs that Fortran's stricter rule would catch immediately.

Fortran's pack(array, mask) intrinsic extracts the elements where a logical mask is true — conceptually the same operation as Fortran's where construct, but returning a new (possibly shorter) array instead of assigning in place. R reaches the identical result by indexing a vector with a logical vector: numbers[numbers > 10] builds the mask and filters in one expression.

Fortran's sum() and maxval() intrinsics map onto R's sum() and max() almost exactly, right down to the function name for sum. R goes one step further with a dedicated mean() built directly into the base language — Fortran has no intrinsic mean function, since computing one is only ever a single extra division away from sum() and size().

Fortran's plain / performs integer division when both operands are integers. R's / always produces a double (since R numbers default to double) — integer division requires the dedicated %/% operator, and remainder requires %%. Ordinary / in R on 17 and 5 gives 3.4, not 3, which surprises a Fortran programmer's reflexes.

Fortran's exponentiation operator is **. R's is ^ — both languages have a dedicated infix exponentiation operator (unlike Pascal, which has neither and requires a Power() function call instead).

sqrt, abs, and the trigonometric functions are intrinsic in Fortran and built into base R with the same names and no import needed in either language — one of the closer one-to-one mappings on this page.

Fortran's nint()/int()/floor()/ceiling() map directly onto R's round()/trunc()/floor()/ceiling() — same four operations, nearly the same names. One subtlety: R's round() uses "round half to even" (banker's rounding) for values exactly halfway between two integers, which can surprise a Fortran programmer expecting nint()'s round-half-away-from-zero behavior.

Fortran's KIND system lets a program choose 32-bit or 64-bit precision deliberately, which matters for memory layout in large scientific arrays. R offers no equivalent control at all — every ordinary numeric value is a 64-bit double, with no lower-precision option, since R was designed for interactive statistical analysis rather than memory-constrained numerical computing.

Fortran concatenates with the dedicated // operator. R has no concatenation operator at all — paste() is a function that joins its arguments with a separator (a space by default; paste0() is the no-separator shorthand). Fortran's fixed-width fields also need trim() to strip padding, which R's dynamically-sized strings never accumulate in the first place.

Fortran needs len_trim() to get the length ignoring trailing blank padding (versus len(), which returns the fixed declared width). R's nchar() always returns the exact character count with no padding to account for, since R strings carry no fixed width.

Fortran's phrase(1:5) bracket syntax and R's substr(phrase, 1, 5) function call both take a 1-based start and end position, both inclusive — a near-exact match, differing only in whether the operation is spelled with brackets or a function name.

Fortran has no built-in case-conversion intrinsic — converting case requires a hand-written loop over character codes with iachar()/achar(), as shown here. R provides toupper() and tolower() directly, a case where R's standard library is considerably more convenient for a common text operation.

Fortran has no string-splitting intrinsic at all — breaking a string on a delimiter always means writing a manual loop with index() to find each delimiter position. R's strsplit() does the whole job in one call, returning a list (hence the [[1]] to unwrap the single result for one input string).

Fortran's if / else if / else / end if and R's if (...) { } else if (...) { } else { } read almost identically, with R using braces where Fortran uses then/end if to delimit each branch.

Fortran surrounds its logical operators with dots (.and., .or., .not.). R uses C-style symbols: &&, ||, !. Note R's single-&/| variants are vectorized (they operate elementwise across whole vectors), while the double forms &&/|| used in if conditions look only at the first element — a distinction that has no Fortran counterpart, since Fortran's logical operators are always scalar unless applied to whole logical arrays directly.

R's ifelse(condition, yesValue, noValue) evaluates a condition across an entire vector at once and picks the matching value for every element in a single expression, including non-numeric results like strings. Fortran has nothing directly equivalent for producing an arbitrary-typed result per element — the closest built-in tool, where, only assigns into an already-declared array of matching type, so a genuinely per-element branching choice like this one needs an explicit loop, as shown here.

Fortran's select case is a statement that runs code in each branch. R's switch() is an expression that returns a value — the trailing unnamed argument ("Unknown" here) serves as the default, matching Fortran's case default. Where Fortran executes a chosen block of statements, R's switch() is typically wrapped in an assignment to capture its result.

Fortran's do i = 1, 5 counts through a numeric range. R's for (i in 1:5) iterates directly over the elements of the vector 1:5 — conceptually R's for always iterates over a vector's elements (which happens to look like counting when that vector is a numeric range), whereas Fortran's do is a dedicated counting construct.

Fortran's do while (condition) and R's while (condition) { } are functionally identical: both test the condition before each iteration and may run zero times.

A Fortran elemental function is written to accept a single scalar, but the compiler automatically applies it across an entire array with no explicit loop. R's sapply() achieves the same visible effect — applying a scalar-oriented function to every element of a vector — but does so by actually looping under the hood and simplifying the results back into a vector, rather than through a compiler-level broadcasting guarantee. (In this particular case, R's ordinary vectorized prices * 0.9 would be simpler still — sapply becomes necessary once the per-element logic is too complex for a single vectorized expression.)

Fortran's cycle (skip to the next iteration) and exit (break out of the loop) map onto R's next and break — same two concepts, different names for the first one.

Both languages have real functions with return values usable inside expressions. Fortran requires declared types for the parameter and the result, plus an explicit result() clause or assignment to the function's own name. R needs none of that: a function is just an anonymous value assigned to a name, its parameters carry no type at all, and the last evaluated expression in the body becomes the return value with no explicit return needed.

Fortran's optional parameter attribute, checked with present() inside the subprogram, corresponds to R's far simpler default-argument syntax: greetingWord = "Hello" directly in the parameter list. R needs no equivalent of present() at all — the parameter is simply always bound to either the caller's value or the default.

Fortran returns multiple values through several intent(out) parameters on a subroutine. R has no multi-value return syntax either, but achieves the same effect more directly: bundle everything into a single named list() and return that one value, then access fields with $ on the caller side.

R functions are true closures: a nested function captures its enclosing environment, and the super-assignment operator <<- lets it modify a variable in that captured environment even after the outer function has returned — makeCounter() hands back a working counter with private state. Fortran has no equivalent concept at all; internal subprograms after contains share the host program's variables only while that host program is still executing, and there is no way to package "a function plus its own private state" as a single returnable value.

R's NA is a first-class "missing" marker built into every vector, central to statistical computing where real-world data always has gaps. Any arithmetic touching an NA propagates it — sum(c(1, NA, 3)) is NA, forcing an explicit decision about how to handle missingness. Fortran has no equivalent concept at the language level; the closest approximation is IEEE NaN (accessed via ieee_value() from the ieee_arithmetic module), which similarly poisons arithmetic but carries none of R's dedicated missing-data tooling (no is.na(), no na.rm).

Fortran's ieee_is_nan() (from the ieee_arithmetic intrinsic module) tests each element for NaN, similarly to R's is.na(). Crucially, in both languages you cannot test for missingness with a plain equality comparison — NaN == NaN is false in Fortran, and NA == NA is itself NA in R — so the dedicated detection function is the only correct check in either language.

Since Fortran has no first-class missing-value concept, ignoring "missing" entries in a computation means manually filtering the sentinel values out before computing a statistic. R's statistical functions accept a dedicated na.rm = TRUE argument that skips NA entries automatically — one argument, versus the manual filtering Fortran requires.

A Fortran type is declared once with fixed field names and types, then instantiated many times — every person value has exactly the fields name and age, guaranteed by the compiler. An R list() needs no declaration at all: any list can have any fields, of any type, chosen fresh each time one is built. R offers no compile-time guarantee that two "employee" lists share the same shape.

Every Fortran array holds elements of one single, uniform declared type — there is no way to mix a string, a number, and a boolean in one array without wrapping them inside a variant-like derived type first. An R list() can freely hold values of completely different types side by side, indexed with double brackets ([[1]]) to extract a single element as its own value rather than a length-1 sub-list.

Growing a Fortran allocatable array by one element means building a new, larger array and copying the old contents in — items = [items, 3] does this implicitly but still reallocates under the hood. Growing an R list is a single assignment past its current length (items[[3]] <- 3), and unlike a Fortran array, an R list can also gain entirely new named fields on the fly (items$label <- "done") — something no Fortran array or even a fixed type definition permits.

A Fortran type is a fixed, compiler-checked structural definition. R's lightest object system, S3, is the opposite extreme: any ordinary value (here a plain list) becomes an "object" simply by attaching a class attribute to it — no declaration, no structural guarantee, just a label that later drives method dispatch.

The Fortran function speak here only ever handles one specific type (dog) — calling it with anything else is a compile-time type error, and there is no built-in mechanism for the same function name to behave differently depending on the runtime type of its argument. R's S3 system provides exactly that: speak <- function(x) UseMethod("speak") declares a generic, and R dispatches to speak.Dog based on the class attribute of whatever value is passed in at runtime — a form of polymorphism Fortran's static type system does not provide.

Fortran has no hook for customizing how a value displays — every piece of code that prints a point must format its fields by hand, every time. R's print() is itself an S3 generic, so defining print.Point once makes every future print(somePoint) automatically use that formatting, site-wide.

Fortran has no exception-handling mechanism at all: an error condition is normally communicated through a status integer that the caller must check explicitly, as shown here — or, for a truly unrecoverable situation, by calling stop to terminate the entire program immediately with a given exit code, with no way to "catch" it and keep running. R's stop() looks similar by name but behaves completely differently: it raises a catchable condition that tryCatch() can intercept, recover from, and continue execution afterward — Fortran has nothing resembling this recoverable middle ground between "check a flag" and "kill the whole program."

Since Fortran has no exception mechanism, "handling an error" always means checking a status flag or a sentinel return value after the fact — the caller must know in advance to check it. R's tryCatch() wraps an expression and supplies a handler keyed by condition class (error = function(e) ...) that runs automatically if that expression raises a matching condition, with no sentinel-value convention required.

Fortran has no distinct "warning" mechanism separate from ordinary printed output — a program that wants to warn without stopping simply prints a message and continues, with nothing structured for a caller to detect. R's warning() raises a genuine, catchable condition distinct from an error: it does not abort execution by default, but tryCatch() can still intercept it with a warning = handler if the caller wants to react to it specifically.

Fortran programmers already know IEEE NaN famously never equals itself (NaN == NaN is false), so the general caution around comparing special values transfers. R's trap is subtly different and easier to fall into: value == NA does not return FALSE — it returns NA itself, since any comparison involving a missing value is itself unknown. Code that does if (value == NA) silently misbehaves (an NA condition in if raises an error) rather than cleanly failing the comparison; is.na() is the only correct way to test for missingness.

R only warns about recycling when the longer vector's length is not an exact multiple of the shorter one's — recycling by a length that divides evenly (as with lengths 2 or 3 into 6 above) produces no warning message at all, even though it is exactly the same silent-repetition behavior. A Fortran programmer relying on "R will warn me if something's off" should know that the warning is a partial safety net at best, not a guarantee — the only way to be certain no recycling occurred is to check vector lengths explicitly before the operation.

R has two different ways for "nothing" to appear, and they are not interchangeable: NULL represents the complete absence of a value (it has length 0 and cannot occupy a slot in a vector), while NA represents one specific, known-missing value inside a vector (it has length 1, like any other element). Fortran's closest concept, a null() pointer, is neither of these — it describes a pointer's association state, not a placeholder value that arithmetic or a vector can hold.

Fortran's compiler rejects a type mismatch like adding a number and a string before the program ever runs. R performs no such check ahead of time — the equivalent mistake compiles (there is no compile step to reject it) and only produces an error the moment that specific line executes, which could be deep inside a rarely-triggered branch that a test run never reaches. Every type error a Fortran compiler would have caught for free becomes, in R, a bug that only surfaces in production.