3 ms·

[Author/submitter here] > Modula-2 is really just Pascal with modules, which was welcome My impression is that Modula was "just Pascal with modules", and Modu

[Author/submitter here] > Modula-2 is really just Pascal with modules, which was welcome My impression is that Modula was "just Pascal with modules", and Modula-2 is "Pascal with modules and coroutines". (At risk of dramatic over-simplification.) Secondarily, the existence of Modula-2+ and Modula-3 (from 3rd parties) and then Wirth himself moving on to Oberon suggests that while Modula/Modula-2 were not quite there yet, Oberon was at least a lot closer. Although the relative plethora of Oberon variants (Oberon, Oberon-07, Oberon 2, Active Oberon, etc.) suggests that maybe it was still not quite fully evolved. I do wonder if, rather than competing implementations and variants, it would be possible to re-unify them under one standard, in the way that Common Lisp managed to do... even if it were not something quite as minimal and elegant as Prof Wirth would endorse.

Rochus 4y ago
> Although the relative plethora of Oberon variants [..] suggests that maybe it was still not quite fully evolved. That's a reasonable conclusion, but one has to consider that most variants came from academia and focused on specific scientific questions, not on the adaptation to practical needs of the industry. > it would be possible to re-unify them under one standard, in the way that Common Lisp managed to do I did that with Oberon+ which unifies Oberon, Oberon-07 and Oberon-2. It also includes what I consider the best ideas of Component Pascal and Active Oberon (though I don't like the syntax of these two languages very much). See https://oberon-lang.github.io/2021/07/15/motivation-for-a-new-oberon-version.html https://oberon-lang.github.io/2021/07/15/motivation-for-a-ne..., https://oberon-lang.github.io/2021/07/16/comparing-oberon+-with-oberon-2-and-07.html https://oberon-lang.github.io/2021/07/16/comparing-oberon+-w... and https://github.com/oberon-lang/specification/blob/master/The_Programming_Language_Oberon%2B.adoc https://github.com/oberon-lang/specification/blob/master/The....
- lproven 4y ago
  > I did that with Oberon+ which unifies Oberon, Oberon-07 and Oberon-2. Oh I see! But, AIUI, that's just a compiler on other OSes, right? It's the IDE and the OS that interests me. If I wanted to program on Linux or whatever, I'd probably use FreePascal or something. It's the OS and the integration that makes Oberon interesting for me. In a world of sprawling multi-gigabyte OSes implemented in half a dozen languages and held together with sticky tape: various scripting language. One tiny elegant OS, self-hosted in one tiny language, has charm for me.
  - Rochus 4y ago
    > that's just a compiler on other OSes, right? It's possible to run an Oberon System with it (see https://github.com/rochus-keller/OberonSystem https://github.com/rochus-keller/OberonSystem ); it runs on all platforms and the generated C code could even be made run as an OS on an embedded system if need be; I currently also experiment with System 3 and alternative backends; but this is more for curiosity; from my humble point of view the OS topic is solved with Linux (which can also be configured for very low resource systems).
    - lproven 4y ago
      That is very cool!
HarHarVeryFunny 4y ago
I wouldn't really call Pascal elegant ... it's downright weird in places, and seems poorly thought out. For example you can't have a one-character string constant in (ISO standard) Pascal since it regards 'c' as a char, while '12' (both single quotes) is a "string"! Of course Pascal didn't even really have strings, but it at least allowed you to write (print) any "packed array [1..N] of char" to a "text" file, so that was sort of a string... The only parameter type your own functions could take that would accept any such (for different N) "strings" was using a variable length "conformant array" parameter "packed array [lo..hi:integer] of char", but this would have to be a value parameter (entailing an inefficient array copy) if you wanted it to accept string constants as well as other "packed array [1..N] of char" strings... However, god forbid one function taking a conformant array "string" parameter wanted to pass that to another function taking the same type of parameter, since Pascal didn't allow conformant arrays to be used this way. Pascal's standard I/O system was downright weird too. You could open files (reset/rewrite) but not close them, the language itself had no way to associate a filename with a file (!!), although it did say that any files given as parameters to "program" were "permanent" (presumably named, with the name coming from who knows where!) files, as opposed to others which were transient temporary ones. Then there's Pascal's file "buffer variables", whereby file.bv was treated as a pointer to the item at the current read/write position in the file... Umm.. or how about for loops with separate keywords for loops that count up (for to) as opposed to down (for downto), which I suppose was a necessity given that you couldn't actually specify the loop increment (i.e only implicit 1 or -1). Ugh. Although not a Wirth language, perhaps Ada comes closest to being a usable, if cumbersome, language from the same mindset. I'm not familar with Oberon though.
- lproven 4y ago
  Thanks for the real-world perspective. There's a lot of stuff I didn't know in there. > Although not a Wirth language, perhaps Ada comes closest to being a usable, if cumbersome, language from the same mindset. A legit point. I find it very amusing (in a tragi-comic sort of way) that despite regularly ranking as the fastest language outside the C family in the "Benchmarks Game" – https://benchmarksgame-team.pages.debian.net/benchmarksgame https://benchmarksgame-team.pages.debian.net/benchmarksgame – it gets overlooked or ignored compared to trendier languages for xNix types. (Interestingly, getting that link, I see that it's changed in the last year or so since I last looked. E.g. Julia is doing well, which is impressive: it is designed to be fast at numerical stuff, but even so, it's not compiled.) Ada was seen as huge and bloated in the '80s, yes. Compared to most 20th century languages, it's positively lean and svelte. > I'm not familar with Oberon though. It's been a research interest of mine for years now; cf. https://www.theregister.com/2015/12/02/pi_versus_oberton/ https://www.theregister.com/2015/12/02/pi_versus_oberton/ I got some interest from the Squeak community a while ago. Not sure if anything will come of it, though. I am in an Oberon Telegram chat channel, but it's in Russian, a language of which I understand very little. Various Russian institutions have been working with Wirthian languages for 30+ years now. There is active interested and R&D going on there. I think it's worth a look. A complete compiler, together with its own IDE and self-hosted on its own (somewhat rudimentary) OS, in just a few tens of thousands of lines of code. It's got the functionality of an early x86 Unix but it's down around the size of mid-era MS-DOS. I am not aware of anything else that compares to it. A list of its characteristics I thought notable: • a clean, simple OS, with SMP support, that supported pre-emption, memory management etc. • in a type-safe language, with a native-object-code compiler — not JITTed, not using a VM or runtime • and a readable language, not something far outside the Algol family of imperative HLLs • that was portable across different architectures • that was FOSS and could be forked • that was documented and had a user community who knew it • that can be built with FOSS tools (which RISC OS fails, for instance) • which is or was used by non-specialists for general purpose computing • which can usefully access the Internet • which runs on commodity hardware
kjs3 4y ago
Wirth himself moving on to Oberon suggests that while Modula/Modula-2 were not quite there yet Well...that depends on your perspective, and Wirth had a particular one. Wirth was an academic, and mostly confined his real interests to academic topics rather than 'real world' programming concerns (not to say he was unaware of them). In particular, his interest in compilers resulted in languages that are generally straightforward to write decent compilers for, rather than appeal to every programmer PLT wishlist. That gets you things like "I/O is an exercise left to the student". So, yes, Wirth moved on from languages when he felt there was something more interesting to explore. Oberon has been described as an exercise in how much syntax can be take out of a programming language, for example (at risk of dramatic over-simplification), because that sort of minimalism became a research interest to Wirth. On the other hand, I personally think the existence of so many useful variant/extended Pascals and Modulas (and decedents like Ada & VHDL) means that lots of people thought they were good 'bones' that just needed to be fleshed out to move from academic to commercial use. That's not uncommon from stuff that starts out in universities. YMMV.
- kjs3 4y ago
  N.B. - I should apologize for referring to Wirth in the past tense. He's still around and still active.

Rochus 4y ago

> Although the relative plethora of Oberon variants [..] suggests that maybe it was still not quite fully evolved. That's a reasonable conclusion, but one has to consider that most variants came from academia and focused on specific scientific questions, not on the adaptation to practical needs of the industry. > it would be possible to re-unify them under one standard, in the way that Common Lisp managed to do I did that with Oberon+ which unifies Oberon, Oberon-07 and Oberon-2. It also includes what I consider the best ideas of Component Pascal and Active Oberon (though I don't like the syntax of these two languages very much). See https://oberon-lang.github.io/2021/07/15/motivation-for-a-new-oberon-version.html https://oberon-lang.github.io/2021/07/15/motivation-for-a-ne..., https://oberon-lang.github.io/2021/07/16/comparing-oberon+-with-oberon-2-and-07.html https://oberon-lang.github.io/2021/07/16/comparing-oberon+-w... and https://github.com/oberon-lang/specification/blob/master/The_Programming_Language_Oberon%2B.adoc https://github.com/oberon-lang/specification/blob/master/The....

lproven 4y ago
> I did that with Oberon+ which unifies Oberon, Oberon-07 and Oberon-2. Oh I see! But, AIUI, that's just a compiler on other OSes, right? It's the IDE and the OS that interests me. If I wanted to program on Linux or whatever, I'd probably use FreePascal or something. It's the OS and the integration that makes Oberon interesting for me. In a world of sprawling multi-gigabyte OSes implemented in half a dozen languages and held together with sticky tape: various scripting language. One tiny elegant OS, self-hosted in one tiny language, has charm for me.
- Rochus 4y ago
  > that's just a compiler on other OSes, right? It's possible to run an Oberon System with it (see https://github.com/rochus-keller/OberonSystem https://github.com/rochus-keller/OberonSystem ); it runs on all platforms and the generated C code could even be made run as an OS on an embedded system if need be; I currently also experiment with System 3 and alternative backends; but this is more for curiosity; from my humble point of view the OS topic is solved with Linux (which can also be configured for very low resource systems).
  - lproven 4y ago
    That is very cool!

HarHarVeryFunny 4y ago

I wouldn't really call Pascal elegant ... it's downright weird in places, and seems poorly thought out. For example you can't have a one-character string constant in (ISO standard) Pascal since it regards 'c' as a char, while '12' (both single quotes) is a "string"! Of course Pascal didn't even really have strings, but it at least allowed you to write (print) any "packed array [1..N] of char" to a "text" file, so that was sort of a string... The only parameter type your own functions could take that would accept any such (for different N) "strings" was using a variable length "conformant array" parameter "packed array [lo..hi:integer] of char", but this would have to be a value parameter (entailing an inefficient array copy) if you wanted it to accept string constants as well as other "packed array [1..N] of char" strings... However, god forbid one function taking a conformant array "string" parameter wanted to pass that to another function taking the same type of parameter, since Pascal didn't allow conformant arrays to be used this way. Pascal's standard I/O system was downright weird too. You could open files (reset/rewrite) but not close them, the language itself had no way to associate a filename with a file (!!), although it did say that any files given as parameters to "program" were "permanent" (presumably named, with the name coming from who knows where!) files, as opposed to others which were transient temporary ones. Then there's Pascal's file "buffer variables", whereby file.bv was treated as a pointer to the item at the current read/write position in the file... Umm.. or how about for loops with separate keywords for loops that count up (for to) as opposed to down (for downto), which I suppose was a necessity given that you couldn't actually specify the loop increment (i.e only implicit 1 or -1). Ugh. Although not a Wirth language, perhaps Ada comes closest to being a usable, if cumbersome, language from the same mindset. I'm not familar with Oberon though.

lproven 4y ago
Thanks for the real-world perspective. There's a lot of stuff I didn't know in there. > Although not a Wirth language, perhaps Ada comes closest to being a usable, if cumbersome, language from the same mindset. A legit point. I find it very amusing (in a tragi-comic sort of way) that despite regularly ranking as the fastest language outside the C family in the "Benchmarks Game" – https://benchmarksgame-team.pages.debian.net/benchmarksgame https://benchmarksgame-team.pages.debian.net/benchmarksgame – it gets overlooked or ignored compared to trendier languages for xNix types. (Interestingly, getting that link, I see that it's changed in the last year or so since I last looked. E.g. Julia is doing well, which is impressive: it is designed to be fast at numerical stuff, but even so, it's not compiled.) Ada was seen as huge and bloated in the '80s, yes. Compared to most 20th century languages, it's positively lean and svelte. > I'm not familar with Oberon though. It's been a research interest of mine for years now; cf. https://www.theregister.com/2015/12/02/pi_versus_oberton/ https://www.theregister.com/2015/12/02/pi_versus_oberton/ I got some interest from the Squeak community a while ago. Not sure if anything will come of it, though. I am in an Oberon Telegram chat channel, but it's in Russian, a language of which I understand very little. Various Russian institutions have been working with Wirthian languages for 30+ years now. There is active interested and R&D going on there. I think it's worth a look. A complete compiler, together with its own IDE and self-hosted on its own (somewhat rudimentary) OS, in just a few tens of thousands of lines of code. It's got the functionality of an early x86 Unix but it's down around the size of mid-era MS-DOS. I am not aware of anything else that compares to it. A list of its characteristics I thought notable: • a clean, simple OS, with SMP support, that supported pre-emption, memory management etc. • in a type-safe language, with a native-object-code compiler — not JITTed, not using a VM or runtime • and a readable language, not something far outside the Algol family of imperative HLLs • that was portable across different architectures • that was FOSS and could be forked • that was documented and had a user community who knew it • that can be built with FOSS tools (which RISC OS fails, for instance) • which is or was used by non-specialists for general purpose computing • which can usefully access the Internet • which runs on commodity hardware

kjs3 4y ago

Wirth himself moving on to Oberon suggests that while Modula/Modula-2 were not quite there yet Well...that depends on your perspective, and Wirth had a particular one. Wirth was an academic, and mostly confined his real interests to academic topics rather than 'real world' programming concerns (not to say he was unaware of them). In particular, his interest in compilers resulted in languages that are generally straightforward to write decent compilers for, rather than appeal to every programmer PLT wishlist. That gets you things like "I/O is an exercise left to the student". So, yes, Wirth moved on from languages when he felt there was something more interesting to explore. Oberon has been described as an exercise in how much syntax can be take out of a programming language, for example (at risk of dramatic over-simplification), because that sort of minimalism became a research interest to Wirth. On the other hand, I personally think the existence of so many useful variant/extended Pascals and Modulas (and decedents like Ada & VHDL) means that lots of people thought they were good 'bones' that just needed to be fleshed out to move from academic to commercial use. That's not uncommon from stuff that starts out in universities. YMMV.

kjs3 4y ago
N.B. - I should apologize for referring to Wirth in the past tense. He's still around and still active.