I feel like Wirth doesn't get enough credit these days. I have come to really appreciate his writing, especially books like Project Oberon and Compiler Construction. I thought Pascal (and by extension, the Modula languages) was lame when I was younger and full of C-and-Unix machismo, but I came to have a strong appreciation for the design of those languages (especially Modula-3, which wasn't Wirth but derived from his work).
Wirth is one of my biggest influences. I was just inspired by this post to finish a short little draft I had sitting around about Wirth as an influence, and the Oberon language report. Oberon-07 is defined in a 17 page document that is simplicity itself. Of that, about 2 pages is EBNF (Wirth published the first EBNF variation too...) for Oberon, and the rest is easily accessible prose...
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.
@vidarh I was going to write a post, but you already wrote it. It's a great shame that many young programmers I meet think they need the noise of c# to pull off some good code. M2 with so few keywords, excruciating compile time checking, a great module system for the time, and beautiful green threading was just a joy to work with. It encouraged good engineering practice that helped me become a complete sme on the apps I created because I could keep so much more of the flow in my head than with my comparable experience with other languages. Golang has certainly rejuvenated my enjoyment of programming because it helps me recreate some of those experiences I had with M2.
The language spec is actually based on refining the original Oberon, rather than any later versions. I don't know which code base his implementation was started from - there are so many to pick from..
Plan9 has a lot of Wirth inspiration. Particularly the Acme text editor. The concept of text as menus is taken straight from Operon. In Acme you can use any text as an action by middle clicking and because Acme exposes it's internals via a synthetic file system you end up with a very powerful application. There are no drop down menus.
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.
I've always liked Pascal and Modula-2 (never got round to trying Oberon). These programming languages are actually much simpler to learn than many recent languages, including supposedly "friendly" scripting languages that tend to have quite large and loose syntax.
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?
Being a Turbo Pascal expert by the time I got to learn C (early 90's), I never liked the language.
Turbo Pascal already offered me stronger type safety, real modules, OO, system programming capabilities. So C was meh, it only had better portability[0] 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.
[0] whoever wrote K&R and early ANSI C code across commercial UNIX systems, knows how much "portable" C was really back then.
I first learned Pascal around 1978, tried Microsoft's QuickPascal around 1990, then used Turbo Pascal for work on a planetary science simulator [0] and teaching. From 1995 on I used its successor, Object Pascal and Delphi, which I thought was a really powerful combination of a good language, libraries/frameworks, and IDE. Mostly for the PC, Borland tried briefly to market to Unix systems with Kylix, but it didn't gain as much traction as they would've liked, I guess. Anders Hjelsberg [1] was inspired by Wirth's Tiny Pascal in his Algorithms + Data Structures = Programs book to work on Pascal. I think his efforts on Turbo Pascal, and Object Pascal were truly inspired.
By the time I was ready to learn the next thing after BASIC and assembler as a teenager in the mid-90s, the "Pascal is dead" meme had already spread enough (at least here in the US) that I never even realized that Pascal had advantages over C. And then I fell for the "safe languages can't be compiled" myth propagated by Java and the popular dynamic languages (Perl, Python, etc.).
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).
Pascal was quite strong in Europe up to when the web started taking off around early 2000.
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.
For someone who's "retired" he's certainly not slowed down much ... From the section about his talk at the symposium (there appears to be papers related to this on his personal website: http://www.inf.ethz.ch/personal/wirth/)
"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 work was tremendously valuable to me. His book "Algorithms + Data Structures = Programs" shaped the way I approached programming, and the Pascal language (in its various Borland incarnations since Turbo Pascal 1.0 until Delphi) was my primary tool for many years.
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.
I owned the book "Algorithms + Data Structures = Programs" and I learned a lot out of it. And while I wrote quite a few programs in Pascal, I found myself always confined too much: I fled to C.
"
- 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#.
Pretty much all of these were "fixed" in Modula 2 and Oberon/Oberon 2/Oberon-07 too, which Wirth designed.
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.
Pascal is the language taught and used on the course of Data Structure When I was in college, the book "Data structures + Algorithms = programs" is the most favorite book during my college,and it inspired me to code better. Happy birthday to N. Wirth.
I was thinking about this, too, when I read his name.
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. [1]
