GCC 13 to support Modula-2: Follow-up to Pascal lives on in FOSS form Incoming support for Modula-2 in GCC, and a new Gitlab repository for its descendant Oberon, shows that the Wirthian family of programming languages remains livelier than you might think. Modula-2 is what Pascal inventor Niklaus Wirth did next. Modula-2 is the direct descendant of Pascal, aimed at more modular (the clue's …
Ha, yeah, we learned Pascal, then Modula-2 (mid eigthies, on a VAX). I don't think many people from my course made use of these for real. TBH I'm not sure why they were taught in the first place, most people of the course already understood the elements of programming as we all knew BASIC, we could have spent the time learning C or something with real world application.
"We all knew BASIC"
That's why Pascal was taught!
80's BASIC hackers (I was one) produced appalling code in multiple dialects often on limited availability OS (and thus machine) dependent interpreters and few of which were language compatible.
Pascal was not only a language but a programming methodology, a standard language (yes "the book" even had full syntax diagrams!) enabling use across multiple platforms and, like a programmer's Rosetta stone, allowing easy transfer of the programmer's mindset to multiple other sequential languages which were emerging at the time. It was also used in its own right in the real world where designers hadn't yet taken the leap of faith to C and could be patially self documenting which, even today, would have to be regarded as a bonus ...
The major advantages of Pascal back in the days when it was created were that it could be used in different environments and that when you gave the end-users the Pascal code that was all you need to do to document the functionality in most cases. I started by teaching myself assembler, went to college and learned FORTRAN and then got some jobs needing both methods - watching the end-users coding was a mess in both environments but when Pascal appeared then coding appeared everywhere in the academic world, everyone worked together to make technical calculations like gait analysis work and then shared their code to document what was done and how it was done. Modula-2 was an easy way forward that I enjoyed, but the academic world was addicted to Pascal so I ended up using that all the time.
I have never cared what languages people use, I'm just spending all my time helping people get their things working - and when they are happy then I am too.
We also did Pascal on a Vax* and Modula-2 on... er, I can't remember now; probably also a Vax but possibly a Sun. But by that time I was obsessed with trying to understand C which I just didn't get; until I did, at which point I was too distracted to pay attention. I dunno how I scraped through with a pass.
* That one was an 11/785. I was impressed by its "bigness" at the time although not so much its quickness when it hit its 60 login limit and all of whom were trying to compile their Pascal programs. The following year they replaced it with an 8650 which was enormously quicker even with nearly thrice the number of users.
something with real world application.
Pascal had real world application up until comp-sci courses stopped teaching it, Development shops shifted away from it when they couldn't hire graduates.
Personally, I worked on a transport ticketing system, an agricultural cattle-tracking system, and finance-treasury system.
I've heard two arguments for why comp-sci shifted from pascal to c:
(1) They actually didn't like the tighter/safer environment and prolix syntax (they had to do their own code entry instead of using a typing pool)
(2) They wanted to teach operating-system design.
It certainly wasn't the case that c had a lock on 'real world' applications. Although I was working in Pascal, most of the existing enterprise systems were Fortran, BASIC, COBOL or assembler. The business schools were using IBM or business-oriented mini-computers, of which unix was only a minor player. The IBM people laughed at unix and c: memorably, unix was 'not a real operating system' -- a phrase the comp-sci students later adopted without knowing the origin or why it hurt.
Mid-eighties...
After graduating I never used StructFor or Algol-68 again, but the they had served their purpose and enabled me to readily pick up C, Ada, et al.
Suspect part of the problem goes back to how do you teach programming. Pascal was really intended to be a first teaching language, sitting somewhere between Basic(*) and Algol. Remember Computing degree courses back then took in those who had done CSE/GCSE/O-level computer, A-level computing or no computing at all. Hence part of the problem of the first year was getting everyone up to the same level and providing a good enough vehicle on which to learn computing fundamentals and skills that would help in their second year when richer procedural languages such as Cobol, Fortran, Ada, C were introduced(*2).
Naturally, this leads to a debate about teaching languages and whether they should be different to those used in the outside world: Should we be teaching Rust at GSCE? To my mind Rust would be a 80's second year language, which probably places it as an A-level/degree first year language today.
(*) GW-Basic is the level of "Basic" I'm referring to in this context.
(*2) All of which buggered the brain when introduced to non-procedural languages such as LISP and Prolog.
Pascal seems like a reasonable bridge language between BASIC and C, to be honest. It's more forgiving than C (in some ways it's a bit like C with training wheels on) but more structured than BASIC.
As someone who started out with BASIC, Pascal was how I learned the structure and syntactic sugar of "real", block-based languages.
Shame the OberonStation is no longer available. I missed that one when it was announced, but it looks like it was a fascinating way to play with the Oberon language on the OS it was intended to run on.
The Modula influence on Java isn't surprising. Despite the C like syntax with braces and such, Java was heavily influenced by Smalltalk, which like Mesa was a Xerox creation. Java's libraries were also influenced by NeXTStep, which in turn had its roots in Smalltalk.
[Author here]
> So many things would have been different in the S/W world.
ISTM that there are some profound lessons to be taken from this, ones of special relevance in the FOSS world.
For instance:
* Pascal took off, went mainstream, didn't adopt any of the improvements of later descendants, and so became unable to compete and died off.
* Modula-2 *did* go quite mainstream for a while -- see the comments about TopSpeed, which I name-checked for this very reason. But Modula-2 was outcompeted by its own grandparent Pascal.
* See the comments about Modula-2 from someone who had to use it (Mr Tyson here)? ISTM that it too wasn't finished enough yet.
* Oberon is the offspring of Modula-2 and a whole family of tiny efficient OSes have been implemented in it.
* When an earlier version of a programming tool takes off, it tends to acquire critical mass (and thus, the need for backwards-compatibility) which inevitably results in it snowballing into this vast unmanageable conglomeration, while its more refined descendants struggle on in obscurity.
Pascal -> Turbo Pascal -> Delphi -> Embarcadero
(While Modula-2 and Oberon remain obscure.)
BCPL -> B -> C -> C++
(Rivals can't get critical mass: D, Go, Rust, Hare...)
Research Unix -> proprietary Unix -> Linux
(While Plan 9 and Inferno and even Minix 3 remain obscure.)
Pascal took off, went mainstream, didn't adopt any of the improvements of later descendants, and so became unable to compete and died off.
One big problem with Pascal was that it was not really portable. The "pure" language part mostly was, but every implementation had its own idea about how to interact with the OS, so a program that wanted to open a named file had to do it differently, not to mention reading any command-line parameters. Wirth's original design clearly assumed the program would be run from "cards" (or batch script), where a control card would define what input, output and any additional file parameters of "program" refer to. Also there was no standard way to split your program into separate modules.
Later many implementations added modules and OO features, but all in a different way. C by contrast always came with the file handling basics and crude modularity included, and any differences could be papered over with #if and macros (both also feature that Pascal did not have). So it is no wonder practical programmers quickly switched to C.
A huge problem with Pascal was a lack of direct support for defined variable types. One could specify "word" and "longword" and other nonsense terminology and hope that the bloody compiler would generate a structure of the exact size required. A lot of leaping through hoops was required at times.
Variable portability where one just doesn't really care is good for much code, but for real world code that interacts with external systems being able to easily and clearly define the exact data types is critical. For example, just including support for int8, uint8, int16, uint16, int32, uint32 and so on would have made life tolerable instead it was a farce of having to override error handling and compilation checks for "byte" depending on whether or not it was representing a signed or a unsigned integer. The horrors of real vs float vs numeric(?) were pretty nasty too.
Part of the abject pain in Modula-2 was Wirth's delusional dream of single pass compilation, while entirely forgetting that in the real world one often has to implement code that self-references and where multiple units rightly need to depend on each other. One had to put in place all kinds of really non-intuitive structures just to work around this restriction and the problems that it forced on use.
Other than that kind of horror, the other problem with Modula-2 when I was forced to use it was the utter scarcity of third party libraries, in particular quality third party libraries that weren't cobbled together by an amateur coder and then sold as if they worked in any meaningful way (suffered from these)
An eighties engineering undergraduate, this correspondent was introduced to Pascal after a term of familiar but unsatisfying BASIC coding.
Pascal explained brilliantly what was wrong with BASIC.
The next year we were introduced to C. I liked it a lot, but there was always an underlying feeling that it was just dirty Pascal. I toyed with using the preprocessor to make "clean" Pascal constructs work in C. Experience has taught me to master the language you are given; don't try to make it something else. Apparently this is beyond those who were first infected by FORTRAN.
I now realise that "dirty Pascal" is actually pretty useful in the real world.
-A.
Similar experience with Pascal --> C in the early 80s.
Not sure what the FORTRAN snark is all about, though. As someone whose initial infection was indeed FORTRAN, punched cards and all, I never had, and have never had, any inclination to "make it something else" - it is is what it is, and does what it does (close-to-the-maths array number-crunching) with admirable transparency and extreme efficiency. As a scientific programmer, I still have cause to use it occasionally (mainly hacking legacy code), and its influence lives on in systems like Matlab/Octave (Matlab in fact started life as a scriptable wrapper for FORTRAN linear algebra libraries like EISPACK and LINPACK; their "modern" descendants, LAPACK, SLICOTT, et al. are still very much with us, and still largely coded in FORTRAN 90).
Arguably, mind you, the language developers themselves tried to make it something it wasn't with FORTRAN 2003 (object-oriented FORTRAN?!? Just... no!)
this makes me unreasonably happy. One of my first "real jobs" was programming in Modula-2 on a "Gepard" (Cheetah) micro-computer (who would remember them?). The concept of breaking up code helped me in my transition to C only a few years later. Somewhere, buried, mouldy and barely legible, I may still have print-outs lying around.
Modula-2 is still in use today, for instance in the Russian GLONASS sat-nav system.
Wait, what? Where the hell is this documented anywhere? Google gives me Wikipedia, which points me to a Russian document that's 404, and a Y-Combinator snippet that says "interesting tidbit" with nothing to back it up.
I do know of several missile systems that were "written in ADA" due to DoD requirements, except it was an ADA initialization routine that called a C routine that never came back... i.e. "ADA" in name only.
I recognize myself in that last paragraph. Many years ago, as an undergraduate in a CS graphics course, we were given an assignment that required the use of some graphics libraries that were available in Modula-2, and were pointed towards the Modula-2 compiler and documentation. Everyone else just did the assignment in Modula-2, somehow. In the first couple of days I found that the bug that I was chasing was a compiler code-generation bug, so I immediately switched my design to use two processes: one was a thin wrapper around the Modula-2 graphics library that took simple drawing commands over stdin; the other was the main logic of the assignment, which I wrote in C, writing drawing commands to stdout. Compiler bug safely contained I got the assignment working on time...
The only use of Modula-3 that I was ever aware of was the "cvsup" tool that FreeBSD used, back when the repository was in CVS. It was a remarkable, multi-threaded high efficiency piece of kit that the author claimed relied heavily on the support that Modula-3 provided for writing safe multi-threaded code. While I admired the code, it did suffer a bit from being written in "not C", which always made it difficult to maintain, as they needed to maintain both the code and the toolchain. Git seems to have solved that problem to everyone's (?) satisfaction.
The story missed one of the big features of the language, which was "opaque types". This was a different approach to solving the same problem as object oriented programming was trying to address at about the same time.
The name of an opaque type would be declared in the module interface, but any details of what it actually was would be hidden in the implementation, and so not visible to anything outside of the implementation (interface and implementation were defined parts of each module, and in separate files).
The interface would also declare functions which would take the opaque type as a parameter, and so allow you to manipulate it. Anything outside of the module however couldn't do anything with the type directly.
Overall it was equivalent to an object's attributes and methods, but defined at the module level. It differed from objects however in that there was no internal state to the module, you needed to pass around the opaque types explicitly.
I did several projects using TopSpeed Modula 2. It was probably by far the best compiler, IDE, and debugger available for MS-DOS PCs in that era. I also had their C compiler as well.
If I had any criticism about Modula 2 it was that screen I/O was a lot of work due to the strong typing of the I/O. Every data type had its own output function, and even newline was a separate function. C's printf may be complex and sloppy, but it's also a lot less work to use.
I liked Modula 2 a lot at the time, but I don't think it's going to make a come back. The industry went firmly down the object oriented route and Modula 2's opaque types are an interesting but forgotten side diversion.
> could it in 1978 when Modula-2 came out?
Yes. See "The C Programming Language" (1978) by Brian Kernighan and Dennis Ritchie section 8.7 (Type names) and the following sections; it still works the same today: you can e.g. declare a named pointer type without giving any details about what the pointer points to and use this type as an argument of your module's functions, all made accessible to other compilation units by a header file.
I did a lot of work in Topspeed (1.17 and later 3.1x), and I came from Turbo Pascal in that time. The compiler was very nice and had lots of nice embedded features (like custom calling conventions).
Compared to Pascal, the thing I liked most was the import/export system and the improved block structure (still my favourite block system). Things that I didn't liked were the string support (too laborious) and the case sensitivity.
I also disliked the function name at the end, but that might also be because the IDEs back then didn't really assist refactoring. In general it felt more evolutionary than revolutionary, but of course TP already had some M2 stuff merged back relative to standard (70s) pascal
After useful compiler life for Topspeed ended Imigratied back to 32-bit Delphi and Free Pascal.
Heh. IMHO one of the reasons ARX failed to be anything like ready in time, was Modula-2.
"Extra-linguistical objects" - the M2 world and the compiler folk rejected the idea that a program was going to run on actual hardware.
I was writing the hard disc file system, so I needed to lay out the on-disk structures in memory, then issue a read or write to actual hardware.
There was real dogma about finding out, programatically, the address in memory of an object, or the offset into it. New compilers would change the size of my nicely-organised disk-block object from 256 bytes to 257. They even said things like "you don't need to know the units of sizeof() because you only ever feed it back into other routines that know the units". Eventually we got the academic idiots to understand that this was actual physical hardware, and the compiler doesn't get to change the block size from 256 to 257 bytes (or even 2048 to 2056 if sized in bits!) and they came up with the label "extra-linguistical objects" and a separate set of built-in functions that used units of bytes. Like every sane environment has. Sigh.
I mean, if a program cannot change in any way external objects, then you can optimise it away to "main() {return;}" can't you.
Separately, opaque types. This was because there was no initialised static data at all, IIRC. I mean you could not even set a static int to zero, nor assume anything about its value at all. So every module that held state had a "opaque FooData Foo::init()" member and you pass the opaque back to every single function call. When it came to making an efficient OS executable they were talking about ideas of running it up to a certain point where all the init()s had been called, then snapshotting the memory state and building that into the image, into the BSS section, outside of anything the language could do. FFS.
Such bodges required to make a sensible executable image.
Anyway, you'll have gathered that we hated it.
Anyway, you'll have gathered that we hated it.
The Hugo Tyson, creator of some rather amazing Archimedes "demos" and (IIRC) main author of a comms package I actually bought, where the viewdata implementation was by Jan Paxton? There were three of us in the "Acorn Club" at polytechnic - me, Jan and some other bloke whose name I forget. Glad to hear you're still around.
M.
Um, I think you have me conflated with someone else re: Archimedes demos; I didn't do a lot there.
I was working with the ARC folks on ARX when Arthur/RISCOS was arriving, and on RISCiX (BSD4.3) when later RISCOS/Archimedes things were happening.
But I did write Beeb 6502 ADFS and took DFS from 0.9 to 1.2 which more-or-less worked correctly. And the ARM ISA test suite, used to verify the silicon, which a couple of decades on, ARM was foolishly distributing binaries to ISA licencees with all the swears on failure left in. No-one had ever made an ARM chip whose shifter was fsckd until Intel made their own StrongARM/XScale machines from scratch! They were, as I understand it, offended, and ARM mgt sent a rocket about unprofessional code blah blah... I was long gone, never joined ARM.
And Atom Snapper and Atom Invaders... :-)
I still have my Acorn-issued M2 book from the days when EVERYTHING was going to be written in M2.
Even just before Arthur 1.2 came out, Acron manglement were still talking of the OS being written in M2, just that we were 'still working on device drivers in assembler' - or rather that was the lie that they were being fed!
The code generated by M2 was 'interesting'. For some reason it seemed to avoid using R6. In the early days of Arthur, one of us had fouled up something sitting on TickerV with the result that R6 was being corrupted at 100Hz. BASIC went TITSUP almost immediately but AAsm happily kept going. Found it never ever referenced R6.
"I mean, if a program cannot change in any way external objects, then you can optimise it away to "main() {return;}" can't you."
I always feel that way about functional languages. If there are no external side effects, then does it matter if the program runs or not?
It seems that it was just a port of the Verilog published in the 2013 book by Wirth and targeted at a Digilent Spartan 3 Dev board. Best as I can figure this is way outclassed by the £50 Sipeed Tang Primer, which has everything you need on a modern board (HDMI, USB 2 OTG, 128MB of DDR3, Ethernet, SD card slot and built in JTAG/USB serial).
I’ve no doubt that trying to sell these would be a losing proposition, but as an open source core on off-the-shelf hardware it might generate some interest. I’m also interested in the fact that it is described as running on a “RISC5” core, I wonder if this is in any way related to RISCV?
Nope.
Wirth's RISC-5 came much earlier.
The RISC-V people also like it to be pronounced "risk five" (as Apple wanted us to say "oh ess ten" not "oh ess ecks") -- but given that they overloaded an existing acronym, I personally say "risk vee" which everyone understands.
https://riskfive.com/RISC5_overview.htm
Wikipedia even has a disambiguation page:
https://en.wikipedia.org/wiki/RISC5
Designed and wrote a system using networked PCs in the late 80s all written in Modula 2 using the TopSpeed compiler. Worked very well as the well defined module interfaces allowed easy team working, and the multi tasking features allowed the system to work in real time controlling a radio system
M2 still going? Used to teach this to UGs in the late 80s - nice - but I/O was an Achillies hea - by design as M2 was aimed at System programming level. I worked with person who wrote the formal definition of Modula-2 and the related BSI standard - some my IO stuff still in the libraries I think!
Well, well, well...
In the early 90's, as a young CompSci student, I had a copy of TurboPascal 6, and that's what we used in most of my 100 and 200 CompSci classes. I got pretty good at it. Then, in Junior year, I took a class that centered around Modula-2. It was OK, but I remember there were some syntax differences from Pascal/TP. Minor little things, IIRC. Minor but important . Most of the rest of my classes were in C or C++ or even ADA (bleh...). So I didn't do much TP for a couple of years. When I finally found a problem that was screaming for Turbo Pascal, I realized that Modula2 had corrupted my previously pristine knowledge of Pascal to the point that the F9 key caused horrible messages to appear on-screen. I never really did recover from that, and wound up doing VB6 for the next several years in self-induced penance (plus VB6 jobs were a dime a dozen by the late 90's, whereas Pascal/Modula2 jobs were practically non-existent around here).
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
