No, AT&T was forbidden by law to take advantage of Bell Labs work commercially, hence why UNIX spread into universities, the famous lions book came to be[0], and tapes with source code where shared with a license cost that was symbolic versus the 1970's mainsframe OSes.
When this situation changed during the mid-80's, AT&T was rather quick to sue Berkley university regarding BSD, forbid the further publishing of the lions book (which kept being widespread via black market copies), however by the time these events took place the influence of UNIX and C across the industry was already quite visible.
All of that is true (still have my n-th generation Lions photocopy someplace), but Modula-2 was early '80s (1982?). By that timeframe you had lots of folks shipping commercial Version 7 or System III variants (e.g. Unisoft, ISC, Microsoft (Xenix), Venix, Amdahl, Sun), with System V based systems just around the corner. These generally were, as the OP said, "proprietary and very expensive".
I recall we still got a sweetheart deal on university licensing from AT&T (usually obtained only because it was required to get a 4BSD distribution tape from UCB...we won't discuss the 3B20s), but commercial shops were charged real cash. Or did I miss your point?
Modula-2 was 1978 actually, and those systems were still a couple of years away as you mention.
And even when they came to be, the real money they were charging (while licensing for peanuts the original source code) was still quite cheap versus paying for what the competition was asking for, hence why long term UNIX wiped out most of them, with IBM and Unisys mainframes/micros being the last standing survivors.
> This significantly understates the real appeal of C at the time, even and especially to people who had alternative languages. A great illustration of this is C on the early Macintosh. You see, unlike environments like MS-DOS (which had no language associated with it, just assembler), the early Macintosh systems already had a programming language; they were designed to be programmed in Pascal (and the Mac ROMs were originally written in Pascal before being converted to assembler).
> This was more than just an issue of Apple's suggested language being Pascal instead of C. The entire Mac API was designed around Pascal calling conventions and various Pascal data structures; it really was a Pascal API. Programming a Mac in C involved basically swimming upstream against this API, full of dealing with things like non-C strings (if I remember right, Mac ROM strings were one byte length plus data).
[snip]
> Despite all of this, C crushed Pascal to become by far the dominant programming language on the Macintosh. [snip] C was enough better to displace Pascal in a hostile environment.
> C did not win just because it was at the right place at the right time. C won in significant part because it was (and is) a genuinely good language for the job it does. As a result it was the language that a lot of pragmatic people picked if you gave them anything like a choice.
UNIX and C certainly helped each other spread (UNIX helped C because if you wanted UNIX, you got C; C helped UNIX because porting an OS which isn't a few thousand kilobytes of assembly is easier than porting one which is) but C could spread just fine without UNIX going along with it.
That is all good and well, except what crushed Object Pascal on Mac OS was C++, with App Toolbox C++ port and Metrowerks PowerPlant, hardly anyone was doing anything that serious with C instead of C++ on the Mac.
Newton OS (after Dylan lost to C++ on Newton), Taligent, and Copland were also written in C++.
Whereas on the PC world, C was mostly used to port UNIX stuff, and being the low level underpinings of Windows and OS/2, while application software made use of OWL, MFC, CSet++,...
Hence why BeOS also went down the C++ path instead of C.
In a way it is kind of ironic, as C++ was also born as a UNIX language, adopted by major desktop OS vendors, although many mistakenly assume Microsoft was the main cause for its adoption.
The free beer platform almost certainly helped with universities and hobbyists. It enabled free (as in beer) software - that doesn't work quite the same if you have to pay hundreds for the compiler.
But your narrative doesn't explain why C took over commercial software. Why was Windows written in C? It wasn't because Microsoft could get the compiler for free.
Because Microsoft was also a UNIX vendor, actually used Xenix in the context of MS-DOS development (via downlink cables) and already had knowledge in-house?
There was already a relatively popular compiler called Pascal-2 back in the day from Oregon Software. It was a heavily extended Pascal for the PDP-11 and some other contemporary platforms. I doubt that would have stopped Wirth from calling it that if he wanted to, but it was called Modula-2 instead for other reasons.
Back when Modula-2 came out, that wasn't as much an issue as it is today, where BCPL family style is just seen as "normal".
Pascal being seen as normal, and Modula-2 not having that much an unique selling point beyond that. Sure, modules are great, but several Pascals already had C-like separate compilation and then Units came around (UCSD?) and established themselves. I think co-routines were the other big difference, and most people didn't really know what to do with that. Still don't.
I mean, it's not like nobody tried. There was a time where you both had Modula-2 implementations available and units weren't done. Borland had a Modula compiler and only introduced Units with TP 4.
On big machines, Ada stole a lot of the thunder. Somwhere I've got a "Software Engineering in Modula-2 and Ada"from that age to cover all your bases.
And then C++ went big, and here we are…
Note that I'm very happy that this is now so universally available and will definitely write a few things in Modula-2 next year.
Portability between different compilers was a problem. People complain about C's portability, but at least you can rely on `fopen` existing. The best that Modula-2 offered was a semi-standard InOut module that provided stdin/stdout functionality (no files).
Eventually a real standard library was added by the ISO standard, but that was published about 10 years too late to have an impact.
I used Modula-2 at Acorn c.1982 (did some development for PANOS), as well as being half of the Acorn team that developed the Acorn ISO Pascal system. I have to say that to me both languages - straight-up standard (not extended) Pascal and Modula-2 suck! Modula-2 is really just Pascal with modules, which was welcome, but even the ISO Pascal standard mentioned the "external" directive as a common extension to support separate compilation which is 3/4 the benefit of modules (the other 1/4 being the module namespace).
Extended versions of both languages such as Borland Turbo Pascal or TopSpeed Modula-2 were great, but it rather damning that the only way to make a language really useful is to extend it !
C, which was around at the same time, was always a much more useful language.
Loved that demo. Still have the code for it. TopSpeed Modula-2 was superb, so much so that even as a college student I bought it - twice, because I damaged the first one.
> 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.
> 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).
> 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.
It's possible to run an Oberon System with it (see 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).
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.
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 – 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 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
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.
I don't think so. Wirth languages are generally not appreciated because they are short sighted. They guy designs a language with only one goal: to build a compiler that runs in the machine he's currently working on.
* This system has a way to run programs where I need to specify the program name and the files it'll work on? Ok, that goes into the language: `program X (input, output)`
* I need a couple of variadic functions? Why bother creating a protocol for them? Let's put the ones I need into the language.
* I need to format numbers in these couple of functions? No need to write a library function for that; that would force me to create a variable string type, which I don't need. No, I'll add a special parameter syntax just for these functions into the language.
Etc., etc. Somebody needs to come and works hard in making a Wirth language usable for general programming before they can be appreciated.
Ah, just like a couple of dudes made a language that targeted only PDP-11, and then suffered lots of extensions until it was standardized about 15 years later?
The "extending" was an order of magnitude less intrusive with C than it was with Pascal. With C, you wrote a new function that wasn't part of the AT&T distribution, which was a perfectly normal thing to do. With Pascal, you had to change the language definition, which probably meant changing the compiler.
> Forgetting about everything else besides bare bones terminal output?
No. You could write things that were not "bare bones terminal output" as functions (or libraries) within C, and do anything you needed to do. You could "extend the language by adding library functions" without having to "extend the language by changing the compiler or the shipped-with-the-compiler libraries".
Some of those library extensions could be useful enough to sell as a package, and people did. That's not the same as what you had to do with Pascal.
> I have some 1980's books with lots of extending and dialects like RatC.
Yes, some people also altered the syntax in various ways. But that wasn't necessary with C the way it was with Pascal.
Nothing changes the fact that C's actual portability came decades later, and people did had to cater for those changes, doesn't matter if it were a few or a bunch of them.
So? If we were arguing about whether C was perfect, your point might be relevant. But we were arguing about whether C was more usable than Pascal. And your latest reply makes it look like can no longer argue that point, but still feel compelled to argue something.
C was more usable in unextended form than Pascal was. C extension more often took the form of libraries, which were more portable. This made C programs themselves more portable between compiler variants than Pascal programs were.
And that is a big part of why C won and Pascal lost. It wasn't just free compilers. (By the way, were any of the extensions and dialects free? To the degree that they caught on, that disproves your "free" argument; to the degree they didn't, that disproves your "but variants!" argument.)
Nah, we are arguing that when C dudes get pointed out that C also required extensions to be usable outside UNIX and PDP-11, the outcome is always this two weights, two measures kind of hand waving.
That latter line of thinking was quite apparent in Go, where a bunch of the global functions had signatures that weren't expressible in the type-system.
I believe much of the love for Modula-2 comes not from the language, but the development environment from ex-Borland Jensen & Partners, TopSpeed Modula-2. It was even better than the Turbo suite from Borland.
When compared with Turbo Pascal for Windows 1.5, with OWL, or Turbo Pascal 6/7 with Turbo Vision not really, as it lacked similar frameworks if I recall correctly.
Wirth's original language design book (yes I have a proofed copy and it's not for sale). Also an awesome book I'd recommend is KN King's Modula 2. I loved that book.
What is the state of Modula-2 in 2022? Has the language been developed over the years, or is it basically the same as in the 1990s? Any good references?
We used Modula-2 and later Modula 3 in the University, and I've dabbled with Oberon. Oberon is still very magical and amazing
If you are interested in trying out a modern and actively developed language, maybe have a look at Nim. The author / main dev is a fan of Pascal/Modula/Oberon and took a lot of inspiration for Nim.
I've probably written 100k lines or so in M2 30 years ago, and I still miss it. Usable interfaces and sub-interfaces at the module level instead of class interfaces, top notch green threading, really strict compilation - it helped programmers become better programmers instead of commodity programmers. Think about that in the future when you get into an autonomous driving vehicle. If not for the tyranny of C, maybe it would be the systems language of choice if it had been given the opportunity to evolve and get some more commercial apps supporting it.
You can do some stuff to the Lazarus ide env to get it close to tolerating a M2 style using macros and such, but it needs a bit of work. Just haven't had time to fiddle with the code yet. Otherwise, the FPC/Lazarus combo is amazing and continues to be one of the greatest open source communities of all time, IMO.
51 comments
[ 1.0 ms ] story [ 114 ms ] threadModula-2 never had such support, the syntax was never such a big issue, there were even IDEs with auto formating for uppercase.
Additionally on the PC front Turbo Pascal offered most relevant Modula-2 as extensions, thus reducing the interest.
Great that it lives on GCC.
When this situation changed during the mid-80's, AT&T was rather quick to sue Berkley university regarding BSD, forbid the further publishing of the lions book (which kept being widespread via black market copies), however by the time these events took place the influence of UNIX and C across the industry was already quite visible.
[0] - https://warsus.github.io/lions-/
I recall we still got a sweetheart deal on university licensing from AT&T (usually obtained only because it was required to get a 4BSD distribution tape from UCB...we won't discuss the 3B20s), but commercial shops were charged real cash. Or did I miss your point?
And even when they came to be, the real money they were charging (while licensing for peanuts the original source code) was still quite cheap versus paying for what the competition was asking for, hence why long term UNIX wiped out most of them, with IBM and Unisys mainframes/micros being the last standing survivors.
Your saying that reminds me of this:
https://utcc.utoronto.ca/~cks/space/blog/programming/CTriump...
> This significantly understates the real appeal of C at the time, even and especially to people who had alternative languages. A great illustration of this is C on the early Macintosh. You see, unlike environments like MS-DOS (which had no language associated with it, just assembler), the early Macintosh systems already had a programming language; they were designed to be programmed in Pascal (and the Mac ROMs were originally written in Pascal before being converted to assembler).
> This was more than just an issue of Apple's suggested language being Pascal instead of C. The entire Mac API was designed around Pascal calling conventions and various Pascal data structures; it really was a Pascal API. Programming a Mac in C involved basically swimming upstream against this API, full of dealing with things like non-C strings (if I remember right, Mac ROM strings were one byte length plus data).
[snip]
> Despite all of this, C crushed Pascal to become by far the dominant programming language on the Macintosh. [snip] C was enough better to displace Pascal in a hostile environment.
> C did not win just because it was at the right place at the right time. C won in significant part because it was (and is) a genuinely good language for the job it does. As a result it was the language that a lot of pragmatic people picked if you gave them anything like a choice.
UNIX and C certainly helped each other spread (UNIX helped C because if you wanted UNIX, you got C; C helped UNIX because porting an OS which isn't a few thousand kilobytes of assembly is easier than porting one which is) but C could spread just fine without UNIX going along with it.
Newton OS (after Dylan lost to C++ on Newton), Taligent, and Copland were also written in C++.
Whereas on the PC world, C was mostly used to port UNIX stuff, and being the low level underpinings of Windows and OS/2, while application software made use of OWL, MFC, CSet++,...
Hence why BeOS also went down the C++ path instead of C.
In a way it is kind of ironic, as C++ was also born as a UNIX language, adopted by major desktop OS vendors, although many mistakenly assume Microsoft was the main cause for its adoption.
But your narrative doesn't explain why C took over commercial software. Why was Windows written in C? It wasn't because Microsoft could get the compiler for free.
Pascal being seen as normal, and Modula-2 not having that much an unique selling point beyond that. Sure, modules are great, but several Pascals already had C-like separate compilation and then Units came around (UCSD?) and established themselves. I think co-routines were the other big difference, and most people didn't really know what to do with that. Still don't.
I mean, it's not like nobody tried. There was a time where you both had Modula-2 implementations available and units weren't done. Borland had a Modula compiler and only introduced Units with TP 4.
On big machines, Ada stole a lot of the thunder. Somwhere I've got a "Software Engineering in Modula-2 and Ada"from that age to cover all your bases.
And then C++ went big, and here we are…
Note that I'm very happy that this is now so universally available and will definitely write a few things in Modula-2 next year.
Eventually a real standard library was added by the ISO standard, but that was published about 10 years too late to have an impact.
Extended versions of both languages such as Borland Turbo Pascal or TopSpeed Modula-2 were great, but it rather damning that the only way to make a language really useful is to extend it !
C, which was around at the same time, was always a much more useful language.
> 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.
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-ne..., https://oberon-lang.github.io/2021/07/16/comparing-oberon+-w... and https://github.com/oberon-lang/specification/blob/master/The....
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.
It's possible to run an Oberon System with it (see 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).
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.
> 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 – 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/
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
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.
* This system has a way to run programs where I need to specify the program name and the files it'll work on? Ok, that goes into the language: `program X (input, output)`
* I need a couple of variadic functions? Why bother creating a protocol for them? Let's put the ones I need into the language.
* I need to format numbers in these couple of functions? No need to write a library function for that; that would force me to create a variable string type, which I don't need. No, I'll add a special parameter syntax just for these functions into the language.
Etc., etc. Somebody needs to come and works hard in making a Wirth language usable for general programming before they can be appreciated.
I have some 1980's books with lots of extending and dialects like RatC.
No. You could write things that were not "bare bones terminal output" as functions (or libraries) within C, and do anything you needed to do. You could "extend the language by adding library functions" without having to "extend the language by changing the compiler or the shipped-with-the-compiler libraries".
Some of those library extensions could be useful enough to sell as a package, and people did. That's not the same as what you had to do with Pascal.
> I have some 1980's books with lots of extending and dialects like RatC.
Yes, some people also altered the syntax in various ways. But that wasn't necessary with C the way it was with Pascal.
C was more usable in unextended form than Pascal was. C extension more often took the form of libraries, which were more portable. This made C programs themselves more portable between compiler variants than Pascal programs were.
And that is a big part of why C won and Pascal lost. It wasn't just free compilers. (By the way, were any of the extensions and dialects free? To the degree that they caught on, that disproves your "free" argument; to the degree they didn't, that disproves your "but variants!" argument.)
And of course Wirth's "Programming in Modula-2".
Not interested in upper case keywords or unnecessary semicolons? Try the Windows, Mac or Linux Oberon+ version with IDE: http://oberon-lang.ch
We used Modula-2 and later Modula 3 in the University, and I've dabbled with Oberon. Oberon is still very magical and amazing
You can do some stuff to the Lazarus ide env to get it close to tolerating a M2 style using macros and such, but it needs a bit of work. Just haven't had time to fiddle with the code yet. Otherwise, the FPC/Lazarus combo is amazing and continues to be one of the greatest open source communities of all time, IMO.