Modula-2 GCC compiler front-end patches sent out for review
phoronix.com
phoronix.com
I shelled out large chunks of hard earned chore cash (sorting bottles for bottle depot recycling, mowing lawn, etc.) to get these (second hand copies). Probably over $200 in today's $$ when accounting for inflation
"Today's Kids Will Never Know!"
It was quite the adventure learning how to program an Amiga with, effectively, a pile of header files, but I had a great time.
The manual for Benchmark Modula-2 (which, IIRC, is all it came with) is in Archive.org.[0]
[0] https://archive.org/details/benchmark-modula-2-manual-1988/m...
On the Atari, in GEM, there's just a boatload of C unions used for UI elements. And void pointers galore. So not friendly to Wirth style languages which have very strict static typing rules.
That and getting documentation in those days was also a nightmare. Everything was in books/manuals, and it's not like you could just get them from Amazon or even a local bookshop. And books were expensive. And it's not like my Modula 2 compiler manual had good documentation on the OS syscalls, etc. It didn't even include a real full set of bindings.
Somewhere out there there's an ST Format issue with a printed letter from my 14-year old Canadian rural-living self begging for help finding documentation on the Line A graphics calls for the ST.
Coupled with compiling with a floppy based system because hard drives were unaffordable. Challenges.
By the time I got my hands on a C compiler and decent documentation I had moved onto Linux on my 486. The 90s were very much a different era from the 80s!
It wasn't no longer like on MS-DOS where all language had the same capabilites accessing BIOS and MS-DOS interrupts, rather if Borland hadn't provided the external bindings to Windows APIs, someone had to write them.
Whereas using C++, alongside OWL, gave me the nice language features I came to love from Object Pascal, a framework similar in usage like Turbo Vision, with bounded checked strings, arrays, collection types, and all the Win16 was one #include away.
A great language that really got me thinking in a more structured fashion about programming.
At one point, I used the built-in assembler in MS-DOS's DEBUG.COM to write a Bresenham line drawing routine, targeting the frame buffer directly.
Then I took a hex dump of the code, and planted it as hex inline assembly code into a Modula-2 function. Rubeyes, it worked.
One project was an implementation of the Core War game. I made it nice with a split-pane window showing the dueling programs as a pair of step debugger windows showing a disassembled section of memory with the current instruction highlighted.
:)
Mesa/Cedar people from Xerox went on to DEC Olivetti research labs, to create Modula-2+, using Modula-2+ as their baseline, and eventually their project grew into Modula-3.
Meanwhile on the Modula-2 world, many compilers added language extensions for OOP, GC, generics based on what going on with those projects.
So while Modula-3 isn't the direct descendant from Modula-2, they are kind of intertwined.
This is a topic that a book could be written about, tracing the 50 year old history
Also, by that time OOP started to rear its seven heads, and Modula-2 didn't have an answer to that, whereas yet another Pascal extensions (e.g. by Apple or Borland) filled that role. ISO Pascal and late Turbo Pascal/Delphi are about as far apart as they're to Modula-2, but you still had the name and quite often transitioned by compiler release, not language standard.
Modula-3 and Oberon answered the OOP call, but the former wasn't officially Wirthian and the latter probably too minimalist and non-industrial.
Also, of course, the BCPL language family enjoyed a steady rise during that time, first C eating into the Pascal space and then C++ becoming the standard low-level OO language.
But then Borland decided to go after enterprise market, and they never recovered from the damage.
Their products are still strong among the German market, though.
Except classic MacOS, Pascal wasn't that popular for system programming.
The culture still survive until today. Try searching at OSDev forum or Github, and you'll see most kernel projects are done in C.
And, of course, in a land where Bell Labs won, upper-case keywords instead of glyphs are hard to sell.
But on the general notion, I'd vehemently disagree. Not having stuff in your standard library but spread about is one of the worst things the languages in this generation copied from C++. Give me a good standard library. Maybe factor out the UI and definitely truly adjacent packages like Obliq.
Note that a huge library also didn't hurt Java too much. And there it was even worse, as you had to distribute most of it as a runtime, whereas a compiled language usually gets by with less (take this with a grain of salt, I don't remember how huge Modula-3's equivalent to MSVCRT was back then on Windows, for example).
C# is finally there, since .NET Native and the improvements they keep doing since C# 7. Sadly WinDev keeps ignoring what comes out of DevDiv, they worship their COM with C++ implementations.
Go, well, plenty to catch up in regards to Modula-3 features.
While upper case keywords are a bit of a bummer, like on Visual Basic and most modern SQL tooling, there are options to automatically format keywords into uppercase.
Among all modern alternatives, I would say C# 11 and Swift are the closest to Modula-3, with a rich ecosystem in the backpack.
D and Nim could also be candidates, but they still miss much of the tooling to make them competitive in current times.