5 ms·

Out of interest, in what way do you consider Swift a Wirth-influenced language? Go seems a closer cousin to Wirth's languages. Its strict type coercion, value

Out of interest, in what way do you consider Swift a Wirth-influenced language? Go seems a closer cousin to Wirth's languages. Its strict type coercion, value copying semantics, package system, lack of OO, use of ":=", type declarations with "type", "var", GC, colons, etc. are all reminiscent of Wirth's languages, especially Oberon. (Robert Griesemer worked with Oberon under Wirth at ETH Zürick, so there's a clear relationship.) Another highly wirthian language is Nim, though its influence comes via Delphi/ObjectPascal.

acqq 11y ago
> in what way do you consider Swift a Wirth-influenced language? It looks to me you misunderstood the post.
- lobster_johnson 11y ago
  How so? He wrote: "As someone that [...] has always been a fan for Wirth influenced languages, Swift [is in a better position]." Why is the sentence premised on Wirth, if it's unrelated to Swift?
  - pjmlp 11y ago
    Because Wirth designed/influenced languages for system programming that I consider better than C. Algol, Mesa, Object Pascal, Modula-2, Modula-3, Oberon, Oberon-2, Active Oberon, Oberon-07, Ada All of them were used to write full operating systems for a few years. However, except for Ada, all of them suffered from not being adopted by OS vendors that were able to deliver mainstream OS, as mainstream OS vendors adopted C to replace Assembly (Object Pascal on Apple's case) and eventually C++.
pjmlp 11y ago
> Out of interest, in what way do you consider Swift a Wirth-influenced language? In the context that system programming languages shouldn't sacrifice safety, except when needed and be explicit about it with constructs like unsafe/SYSTEM and so on. Swift is very explicit when doing C style tricks, e.g. UnsafePointer<>. There is more to Wirth school of languages than just syntax.
- lobster_johnson 11y ago
  The only "safe" Wirth language I know about is Oberon-2, which has bounds-checking of arrays, sentinels and runtime-checking of pointers — though no compile-time checking. Is this what you're referring to? I like Wirth, but his type systems were always super simple, and as far as I know, he never innovated at compile time safety in the way that, say, Rust or Haskell do. Again, Go seems a better analogue; anything that needs to deal with unsafe pointers needs to use the "unsafe" package.
  - pjmlp 11y ago
    Not sure what you mean with runtime-compile time checking of pointers. Wirth type systems weren't always super simple, not when compared with C style ones. Wirth has designed Pascal, Modula-2, Oberon, Oberon-2, Active Oberon and Oberon-07 He has contributed to Extended Pascal, Object Pascal, Component Pascal. Also worked on Algol compilers and some of its dialects, Mesa and Cedar while at Xerox PARC. His work had an influence in Ada, Modula-2+ and Modula-3. Some of the type safe things that Modula-2 in 1978 already offered, that C still doesn't do today: - Type safe enumerations - Bounded checked arrays - Arrays indexed by enumerations - Type safe sets - Range typed integers - No implicit conversions - reference parameters instead of pointers for function/procedure calls - tagged records - low level coding/assembly intrisics require use of the SYSTEM package The only thing lacking was automatic memory management, which we later introduced in the Oberon family. However as you can see from the list there are a whole class of errors that aren't possible. If you like to research old stuff, have a look at B5000 system, which used Algol as their system programming language in 1961. Common to his languages and Xerox PARC ones, was the idea that you can do systems programming in higher level languages, provided the language provided some unsafe path that needs to be explicitly mentioned. But type safety should precede "performance at any cost" mantra. Something also mentioned by Hoare on his ACM Award speech in relation to Algol in 1980. "A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interest of efficiency on production runs. Unanimously, they urged us not to - they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law. " The problem is that younger devs never learned any of this and probably the only thing they know about Wirth languages is some braindead Pascal compiler.

acqq 11y ago

> in what way do you consider Swift a Wirth-influenced language? It looks to me you misunderstood the post.

lobster_johnson 11y ago
How so? He wrote: "As someone that [...] has always been a fan for Wirth influenced languages, Swift [is in a better position]." Why is the sentence premised on Wirth, if it's unrelated to Swift?
- pjmlp 11y ago
  Because Wirth designed/influenced languages for system programming that I consider better than C. Algol, Mesa, Object Pascal, Modula-2, Modula-3, Oberon, Oberon-2, Active Oberon, Oberon-07, Ada All of them were used to write full operating systems for a few years. However, except for Ada, all of them suffered from not being adopted by OS vendors that were able to deliver mainstream OS, as mainstream OS vendors adopted C to replace Assembly (Object Pascal on Apple's case) and eventually C++.

pjmlp 11y ago

> Out of interest, in what way do you consider Swift a Wirth-influenced language? In the context that system programming languages shouldn't sacrifice safety, except when needed and be explicit about it with constructs like unsafe/SYSTEM and so on. Swift is very explicit when doing C style tricks, e.g. UnsafePointer<>. There is more to Wirth school of languages than just syntax.

lobster_johnson 11y ago
The only "safe" Wirth language I know about is Oberon-2, which has bounds-checking of arrays, sentinels and runtime-checking of pointers — though no compile-time checking. Is this what you're referring to? I like Wirth, but his type systems were always super simple, and as far as I know, he never innovated at compile time safety in the way that, say, Rust or Haskell do. Again, Go seems a better analogue; anything that needs to deal with unsafe pointers needs to use the "unsafe" package.
- pjmlp 11y ago
  Not sure what you mean with runtime-compile time checking of pointers. Wirth type systems weren't always super simple, not when compared with C style ones. Wirth has designed Pascal, Modula-2, Oberon, Oberon-2, Active Oberon and Oberon-07 He has contributed to Extended Pascal, Object Pascal, Component Pascal. Also worked on Algol compilers and some of its dialects, Mesa and Cedar while at Xerox PARC. His work had an influence in Ada, Modula-2+ and Modula-3. Some of the type safe things that Modula-2 in 1978 already offered, that C still doesn't do today: - Type safe enumerations - Bounded checked arrays - Arrays indexed by enumerations - Type safe sets - Range typed integers - No implicit conversions - reference parameters instead of pointers for function/procedure calls - tagged records - low level coding/assembly intrisics require use of the SYSTEM package The only thing lacking was automatic memory management, which we later introduced in the Oberon family. However as you can see from the list there are a whole class of errors that aren't possible. If you like to research old stuff, have a look at B5000 system, which used Algol as their system programming language in 1961. Common to his languages and Xerox PARC ones, was the idea that you can do systems programming in higher level languages, provided the language provided some unsafe path that needs to be explicitly mentioned. But type safety should precede "performance at any cost" mantra. Something also mentioned by Hoare on his ACM Award speech in relation to Algol in 1980. "A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interest of efficiency on production runs. Unanimously, they urged us not to - they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law. " The problem is that younger devs never learned any of this and probably the only thing they know about Wirth languages is some braindead Pascal compiler.