Oberon-2 had runtime-checking of pointers: It could check the validity of a pointer and immediately panic rather than return garbage or crash with a page fault. Similarly with arrays.
Wirth did some nice things with type safety, of course (I've always liked his type-safe set/range types), but he never was much into type systems. For example, his set and range types were hardwired into the language; you couldn't build a set-like type yourself, or build something that acted as a range, or overload any of the standard function such as inc() or min(), or indeed any type coercion. With the exception of Oberon-2's (limited and highly Go-like) notion of abstract classes, nothing was polymorphic, every type was only "itself" and their purpose was always entirely about holding data. This is what I mean by his type systems always being "simple". He was attacking practical engineering problems, not type-theory problems.
Go is exactly the same. Swift isn't; it has generics and sum types and protocols and OO and pattern matching and lambdas and a bunch of other stuff that Wirth would probably find too complex (his last few languages tended towards mercilessly removing features).
I don't disagree that Wirth's languages are more advanced than C, though!
> Oberon-2 had runtime-checking of pointers: It could check the validity of a pointer and immediately panic rather than return garbage or crash with a page fault. Similarly with arrays.
Ah, but this was a property of any sane systems programming language with automatic memory management.
> With the exception of Oberon-2's ....
How well do you know Active Oberon, Zonnon and Component Pascal?
They extend Oberon(-2) with abstract classes, generics, tasks (active objects), type extensions, method definition signatures.
Also many consider his work as influence in Ada and Modula-2 successors, whose type systems are not very far from C++ ones.
Incidentally he became disillusioned with these language variants and went with a minimalist view (Oberon-07) that makes even Go look like a complex type system.
Sure, Active Oberon is pretty advanced, and Modula-3 had all sorts of things, including generics — but to my knowledge Wirth was not directly in those languages (or with Zonnon or Component Pascal), and he was unhappy with their complexity. (He apparently prefers the entire language's grammar to fit on a single screen.)
Wirth did some nice things with type safety, of course (I've always liked his type-safe set/range types), but he never was much into type systems. For example, his set and range types were hardwired into the language; you couldn't build a set-like type yourself, or build something that acted as a range, or overload any of the standard function such as inc() or min(), or indeed any type coercion. With the exception of Oberon-2's (limited and highly Go-like) notion of abstract classes, nothing was polymorphic, every type was only "itself" and their purpose was always entirely about holding data. This is what I mean by his type systems always being "simple". He was attacking practical engineering problems, not type-theory problems.
Go is exactly the same. Swift isn't; it has generics and sum types and protocols and OO and pattern matching and lambdas and a bunch of other stuff that Wirth would probably find too complex (his last few languages tended towards mercilessly removing features).
I don't disagree that Wirth's languages are more advanced than C, though!