Unlike most languages, Wirth's languages have gotten simpler, but more powerful, from generation to generation. His greatest legacy to me is his focus on engineering vs. science in programming language design. He's never been concerned with adding the latest and greatest features, but on what is proven, and what has a well understood means of efficient implementation.
This is both the beauty and elegance of his language designs, and in some ways probably his "downfall" in terms of getting credit outside of quite small circles:
Wirths languages are not "sexy". They're stripped down and bare. Their implementations are not sexy - they're stripped down and bare: Simple recursive descent parsers with direct code generation (most, or possibly all, of his compiler implementations output code without generating an AST at all) and minimal optimization - focusing on being easy to understand and modify, predictable, and fast, rather than on producing the fastest possible code.
But that's what makes him stand out as a beacon of programming language engineering. We need the fancy, sexy languages and implementations too, but "Wirthian" languages and compilers are an important counterpoint.
(The blog post is here: http://www.hokstad.com/oberon)
The EBNF is great. I learned the Wirthian compiler engineering from a Prof. who was a former colleague of Wirth.
Combine with the other synthetic file systems and the combination is incredibly useful. There is an email client, for instance. And my friend fgb added image viewing and now we even have a Web browser.
I visited that page one day, looked at the screen shot and said "wow, that person uses Acme just like me, even using Opened" and it eventually it dawned on me that it was a screenshot of my screen I had posted elsewhere.
The way you define methods is based on Oberon-2.
Data + Algorithms = Programs
Inline image viewing and web browsing? Available in p9p? Screenshots?
Feel free to ask any questions. FGB is a nice guy so feel free to contact him directly
Brian Kernighan wrote an influential essay "Why Pascal is not my favourite programming language" that strongly influenced the perception that Pascal was suitable only for teaching and not real production work.
The important point about languages with a small, finite (and clear) syntax is that you actually feel you could fully learn the language, maybe even master it. Your code may end up a little bit more verbose (anathema to many programmers, I know) but that doesn't mean it's unreadable.
I don't mind if a language is strict about the way it's syntax is written. I'm happy if it doesn't have shortcuts either (i.e. it has just one method to perform an operation or function). This, in my view, actually makes learning the language simpler and easier.
I've longed wished that there was a simple, strongly-typed compiled language with the lineage of Pascal available for modern server side web programming. Does anything like this exist?
Turbo Pascal already offered me stronger type safety, real modules, OO, system programming capabilities. So C was meh, it only had better portability going for it.
This lead me to follow Wirth's work and I became a scholar of Wirth's advocacy for safe systems programming.
I was also lucky to have access to Oberon and discover that implementing OS in GC enabled systems programming languages was feasible.
 whoever wrote K&R and early ANSI C code across commercial UNIX systems, knows how much "portable" C was really back then.
Maybe it's time for a Pascal resurgence. Pascal is only dead if we treat it as such. And I see there's at least one active open-source Pascal compiler (Free Pascal).
Here Pascal was actually Turbo Pascal/Delphi, as other dialects were usually ignored.
> And then I fell for the "safe languages can't be compiled" myth propagated by Java and the popular dynamic languages (Perl, Python, etc.).
This is why I sometimes tend to defend Go, even when I used to bash here some of its design decisions. Or keep bringing up Pascal family of languages or alternative commercial AOT compilers for .NET/JVM.
It is a mean for young generations to learn you don't need VMs for memory safe languages.
"It was Paul Reed, who suggested in 2010 that the book ought to be updated. After all, the processor used became extinct. I decided to take up the challenge and to design my own processor subsequently called RISC. I implemented it with a small, low-cost Spartan-3 development board, building an entire replacement for Ceres. This, however, implied the construction of a new compiler and linker, and the rewriting of the corresponding chapters of the book.
All this provided a welcome opportunity to further simplify and refine both language and system. As a consequence, all parts formerly written in obscure and unpublishable assembler code - such as garbage collector, device drivers, and display pattern generators - are now expressed in Oberon too. Also the entire hardware is displayed in full detail, expressed in the language Verilog."
I really hope I'm still able to undertake projects of that kind of ambition when I'm well into my 70's....
Wirth's law: "Software is getting slower more rapidly than hardware becomes faster."
Sometimes paraphrased as: "Intel gives, Microsoft takes."
Referring to Andy Grove  of Intel and Bill Gates  of Microsoft.
 No link required
Finally a short story for the record. In 1968, the Communications of the ACM published a text of mine under the title "The goto statement considered harmful", which in later years would be most frequently referenced, regrettably, however, often by authors who had seen no more of it than its title, which became a cornerstone of my fame by becoming a template: we would see all sorts of articles under the title "X considered harmful" for almost any X, including one titled "Dijkstra considered harmful". But what had happened? I had submitted a paper under the title "A case against the goto statement", which, in order to speed up its publication, the editor had changed into a "letter to the Editor", and in the process he had given it a new title of his own invention! The editor was Niklaus Wirth.
There are some critiques on Pascal: http://www.lysator.liu.se/c/bwk-on-pascal.html , 'Why Pascal is Not My Favorite Programming Language'. A summary from the article:
- Since the size of an array is part of its type, it is not possible to write general-purpose routines, that is, to deal with arrays of different sizes. In particular, string handling is very difficult.
- The lack of static variables, initialization and a way to communicate non-hierarchically combine to destroy the ``locality'' of a program - variables require much more scope than they ought to.
- The one-pass nature of the language forces procedures and functions to be presented in an unnatural order; the enforced separation of various declarations scatters program components that logically belong together.
- The lack of separate compilation impedes the development of large programs and makes the use of libraries impossible.
- The order of logical expression evaluation cannot be controlled, which leads to convoluted code and extraneous variables.
- The 'case' statement is emasculated because there is no default clause.
- The standard I/O is defective. There is no sensible provision for dealing with files or program arguments as part of the standard language, and no extension mechanism.
- The language lacks most of the tools needed for assembling large programs, most notably file inclusion.
- There is no escape.
Many of these were fixed in Borland's Object Pascal, by the way. Written by Anders Heijlsberg, who also designed C#.
Modula-2 was known from at least 1978, and pretty all commercial Pascal implementations added features that solved all or most of the issues in Kernighans article, so frankly it was a bit of a strawman. Indeed, plain, original Pascal was unsuitable for large scale non-teaching use, but very few people even had access to a Pascal implementation that implemented "just" the original Pascal.
A very few of the issues he raises are intrinsic to Wirth's philosophy of compilers, though. Such as one-pass compilation, which massively simplifies his compilers and speeds up compilation. This is a feature of Wirth languages, which one may certainly disagree with. While I prefer more flexibility, I never felt all that restricted by it, given forward declarations support in every implementation I've seen.
Whereas Europeans generally pronounce his name the right way ('Nick-louse Veert'), Americans invariably mangle it into 'Nickel's Worth.' This is to say that Europeans call him by name, but Americans call him by value.