[00:07:12] ... I remember you had a choice between two programming language and on one side they taught Fortran and Fortran is the language of science, or it was the language of scientists.

[00:07:40] And then there was this new class that was started by this Professor Niklaus Wirth about Pascal. And it was, I think the first or second year it was taught. There were a lot of people in the Fortran class and not that many people in the Pascal class. So I said, oh, I'll go to the Pascal class.

[00:07:59] And that's how I met Professor Wirth. And that was great. That was my favorite class from that moment because he's such a, such an enlightened person and a clear thinker that it was a great, great experience for me.

[1] https://ethz.ch/en/news-and-events/eth-news/news/2022/05/we-...

All of the Pascals that were widely successful extended the language in key ways. I was an initial fan of Pascal, until I discovered that a large amount of my time was spent trying to work around limitations of the language.

With C, those workarounds disappeared and I was far more productive.

(I know C compilers always have numerous extensions, most of them of dubious value, but still, plain C remains a far, far more useful language than the Pascal of "Pascal User Manual and Report". Which is why C buried Pascal.)

"A lot of the hate centered around how it wasn’t a systems programming language, when it wasn’t supposed to be one. It’s like complaining your driving instructor’s car can’t be used to dig a trench without extensive modification."

After BASIC, I learned on Pascal (Apple and IBM). It was invaluable to clarify in my mind how programming structures work, as opposed to the (fun) chaos of early BASICs. I really didn't need much more than the I/O available in standard Pascal at the time. And it hid details like endianness that I was not yet ready to handle.

Were there problems? Of course. Among others, the vendors should have done a lot more to standardize extensions, the P1 parameterized array bounds should have been in the initial spec, and while the P-machines had many virtues, performance was not one of them. Far too many of the early implementations just ran the P-code in an interpreter.

Walter's complaint is partially that it needed extensions to do anything non-educational on 1973 hardware. This is true, but to me is vaguely non-sensical, as it clearly had not been designed for that and was labelled as such.

* and cheap: I remember in the days of 30 engineers sharing a VAX that if one person was compiling at a time everything was snappy, but (especially near the end of quarters!) if ten people tried compiling at once interactive latency suffered greatly. Classroom use must've been even worse.

Because it was. The fact it could be extended in so many ways to be a production language shows it had 'good bones', but many practical issues, like I/O, were left as an 'excercise to for the student'.

There seems to have been a lot of revisionist history around Wirths passing with people using Pascals limitations as an indictment of his PLT creds, virtually all of which ignore he was an academic working in academic environment on topics that interested him at the virtual beginning of programming on very, very limited machines. It's like calling Watt a hack because he didn't also add a supercharger and emissions control to the steam engine.

I don't think this is a valid take. It sounds like an attempt to rationalize away awful build times from some systems language. C++ has atrocious build times, but in contrast C compiles almost instantly. Other production languages such as C# and Java also have fast build times.

I don't think long build times are correlated with optimization or production-ready code. They are however linked with attempts to get compilers to do a lot of work just to get our code to generate machine code, but some of that work is due to how some aspects of a programming language sucks and require more work just to pull off an optimization.

was that the case 30 years ago?

Also, code was a lot shorter in those days.

[1] https://www.standardpascaline.org/The_Programming_Language_P...

It's more the other way around: learning to drive on a trench digger. Then you find out that what you really need on the places people actually drive, like a freeway, is a car.

Then suddenly I realized there are stuff I cannot do with it. That was the last day I used Pascal - and I remember it like my dearest experience in programming!

Correct. But then you get hired for a trench-digging job, and told that you have to use the car, because reasons. And so you wind up really hating the car, when the problem was the other people who decided that it was the right tool for that job.

That's not a problem caused by the car. That's a problem caused by someone looking at a worksheet, see "dig a trench" in it, and promptly say "this looks like a job for my trusty car.".

No one used Pascal of "Pascal User Manual and Report" from 1976.

Strangley compiler extentions are only cool when talking about C, in fact, most C developers have no idea what ISO C is actually all about.

And I agree with WalterBright. Unextended C was far more usable than unextended Pascal.

During the 1980's there was already several usable Pascal alternatives, plus Modula-2 came out in 1978 exactly to fix the shortcomings of Pascal without extensions, and the largely ignored ISO Extended Pascal came in 1991, retifying many of the 1980's common extensions.

Using original Pascal, was really when there was no alternative, like myself trying to fit some form of Pascal compiler into a 48 KB on top of Timex 2068 ROM, which naturally wouldn't fit.

Neither did the Darthmound BASIC JIT compiler for that matter, or one of those Small-C / RatC alternatives.

Obviously, Object Pascal was a very far cry from the Pascal User Manual and Report, and even at its extended version it was strictly less powerful than C++, so your point still stands. But it was more beginner-friendly. In my opinion, the moment you got beyond the basics (no pun intended), it was friendlier than BASIC or Visual Basic, while far more powerful. That was quite a sweet spot.

Once I felt comfortable with C++, I couldn't go back to Pascal. Even with the extensions, there were some things that were too painful for me like lack of RAII, lack of Generics, short strings by default. Perhaps some of these are addressed by Free Pascal or modern versions of Delphi nowadays, but that ship has sailed. I feel like Pascal with its extensions worked great in the 1980s and 1990s, and I have very fond memories of my time using it, but it just doesn't have much to offer anymore. There are other beginner friendly languages out there that are powerful enough and have better tooling and far larger communities. And it was all about the tooling and community all along.

Pascal's builtin I/O was a major impediment to its usability.

However, one really great feature of Wirth's Pascal is nested functions with access to outer scopes, which D wholeheartedly embraces. They really are slick. I use them heavily.

Can you give an example? What does the function access in the outer scope? Is it like an environment-capturing closure?

    int moon(int s)
    {
        int sum(int x) { return s + x; }
        return sum(3);
    }

Nested functions can also be nested, and can access variables in enclosing functions by walking the static links back.

The neato thing about this is it makes stack frames work exactly like members of a struct. In fact, a pointer to a nested function is analogous to (and binary interchangeable with) a pointer to a stack object.

I had no stack frame at all. Instead, the compiler kept track of the stack offset of every accessible local (relative to the top of stack). That way the implementation of my nested function was kind of trivial: there were no difference between true locals like `x` and locals from an outer scope like `s`, except of course for the possibility of shadowing.

One reason this was not special is that internally, it was nested scopes all the way down: there was one scope per local variable, so merely declaring two variables already means dealing with nested scopes. Once that was out of the way adding nesting functions was really easy (I believe it added less than 20 lines to my compiler).

Nowadays I think I would use a single stack instead, but if my language is simple enough I’ll probably skip the frame pointer and just keep track of offsets like I did this first time.

I guess it’s a good thing I didn’t advertise inner functions and only used them in the standard library…

> ...modular languages offer one implementation for each interface.

Unfortunately, this is totally incorrect. Modular languages absolutely allow any interface to have multiple implementations which can be chosen amongst. This corresponds to how a Java 'interface' can have multiple implementations. In fact programming to the interface and swapping the implementation is one of the main selling points of interfaces.

> Some of those constraints remained long after advances in hardware and software made the insistence on one-pass compilation seem obsolete.

With compile speeds nowadays we can only wish that this insistence was obsolete. It's needed now more than ever with the slow-as-molasses compilers (apart from a notable few) of today.

Still not the same as Objective-C/Java interfaces that later on become more widely known, or Standard ML modules, CLU clusters, all of them type system based.

c++ compilation is mostly slow not because c++ compilers use lalr parsers (they don't) but because c++ programs commonly wedge lots of the implementation into the "interface", i.e., the .h file, and use recursive textual #include

non-c++ compilers are super fast

Closing word at Zürich Colloquium (1968) - https://news.ycombinator.com/item?id=38883652 - Jan 2024 (28 comments)

Niklaus Wirth, 1934-2024: Geek For Life - https://news.ycombinator.com/item?id=38871086 - Jan 2024 (61 comments)

Niklaus Wirth has died - https://news.ycombinator.com/item?id=38858012 - Jan 2024 (403 comments)

Making complicated things is cheaper, easier, and lets you say 'yes' more often to smart, persuasive, people. Simple takes a lot of time, effort, and "getting to no" with people that have good reasons for the things they want to add.

I think the problem is that to learn to make simple things you first need to learn making complicated things. This is my story and pretty much the story of every person I ever talked to that learned to make simple things. Some people get it faster, some get slower and some never learn to appreciate simplicity, but everybody first had to learn to make before they learned to make simple.

So now realise we were through decades of exponential growth of the number of developers and at any point in time people with experience were greatly outnumbered by people with little experience and the answer becomes easier to formulate.

Simplicity isn't something that is easy to teach. The best ways to do it I found is by mentoring and working with people, but there are so many people you can meaningfully mentor on a daily basis. People with experience are so outnumbered (and also promoted up if they are any good) that it is very hard for an average apprentice programmer Joe to be able to find his master.

  A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system. - Gall's Law

Don't believe everything people say. Just because somebody called something "a law" does not mean it is true.

I don't think it's something that can be 'taught' directly. I suspect it requires the experience of building the simple and then complicated things in order to understand the problem enough to make the complicated thing simpler.

There are very little similarities between Go and Wirth's languages. R. Griesemer's doctoral supervisor was H. Mössenböck, not N. Wirth.

> Except for some minor points, Component Pascal is a superset of Oberon-2. Compared to Oberon-2, it provides several clarifications and improvements.

The similarities are hard to overlook, replace curly braces by BEGIN / END Pascal style syntax and you are more than halfway there.

Of course Go has added features that were not present in Oberon / Component pascal, the implicit interfaces come to my mind, Go channels also. But inherently its a Wirthian language.

Also Griesemer is not the only Oberon connection of Go. Rob Pike has studied the Oberon system when developing the ACME editor for Plan 9 (Source: https://wiki.c2.com/?OberonOperatingSystem).

I honestly think Oberon didn't get named, because at the time of launching Go, the Pascal / C conflict was a lot more present in the memories of people so there was nothing to gain from pointing out these roots.

It is not uncommon for programming languages to not talk about their roots during launch due to politics (Java for example traces its object-oriented roots to https://en.wikipedia.org/wiki/Strongtalk a typed Smalltalk descendant, but was advertised as a cleaned-up C++).

The Acme editor has similarities with the original, text based Oberon system user interface, which unfortunately shares the name with the language, but is not the same thing. The user interface of the Oberon system again looks like a stripped down version of the Cedar environment developed at PARC (where Wirth had his sabbatical).

The object model of Java directly traces back to Simula 67, not to Smalltalk or its descendants (see e.g. https://www.youtube.com/watch?v=ccRtIdlTqlU&t=2444).

The most visible Pascal-family influence is the variable declaration syntax ("i int" instead of "int i" as in C et al).

> One major stream of influence comes from languages by Niklaus Wirth, beginning with Pascal. Modula-2 inspired the package concept, Oberon eliminated the distinction between module interface files and module implementation files. Oberon-2 influenced the syntax for packages, imports, and declarations, and Object Oberon provided the syntax for method declarations.

So mostly packages and syntax - not the most exciting stuff, but the package concept contributes to enabling Go's compilation speed, so it shouldn't be disregarded. Ok, you can still argue that many or most of the C/Pascal-family influences were already present in Newsqueak (I'm only familiar with Pascal, C and Go, so I can't judge that), but I think it's understandable that they wanted to have the language the book is about at the focal point of the graph, and not one of its less successful and more obscure ancestors.

Go is a modern programming language, which suffers from a lot of issues that were well known at the time of its creation.

Is it? What in particular makes it "modern"?

And then there comes Rust in all its glory with "my string constant".to_string() awkwardness and Golang with datetime to string formmating using "2006-01-02 15:04:05.999999999 -0700 MST"...

Modern languages are full of idiosyncrasies that work like putting left hand in the right pocket, and from behind.

My sense is that fine-grained, per-object, deterministic memory management simply cannot be made simple or easy, because the very thing you're trying to do is inherently complex and difficult.

I realize it doesn't provide the same level of safety guarantees that you get out of Rust, but I am very sympathetic to Zig's approach of having no implicit default allocator, so that I can instead just use something simple and easy to reason about like an arena allocator in the 90% of cases where that's good enough for my purposes.

Would you feel better if it was `"my string constant".to_owned_string()`?

Why it is under the hood allowed to define your own timeformat is quite obviously legacy data. At least it's human readable.

[1] https://web.archive.org/web/20210324044010/http://www.edm2.c...

Brilliant. It's very important to notice early enough that the clients prefer buying not exactly what you're selling...

> One of his maxims was indeed that the field remains driven by hardware advances, which make software progress possible.

> One of his maxims for a successful career was that there are a few things that you don't want to do because they are boring or feel useless, but if you don't take care of them right away they will come back and take even more of your time, so you should devote 10% of that time to discharge them promptly.

> Wirth seems to have decided in reaction to the enormity of Algol 68 that simplicity and small size were the cardinal virtues of a language design, leading to Pascal

[1]Nested function:

https://en.wikipedia.org/wiki/Nested_function

Also, it’s not even a sound measure: There are C compilers that are extremely fast and some that are a lot slower but achieve better performance. Java compiles to byte code and performs compilation to machine code during execution. Interpreted languages sometimes only use an AST for execution and don’t compile to machine code at all.

The real challenge is combining the two.

I also think focusing on different compilers misses the point, which would perhaps be better expressed by to what extent a naive compiler implementation for the language would be likely to be fast or not.

E.g. Wirth's languages can be compiled single pass, and are fairly easy to compile without even building an AST. Some other languages can fit that too, but for many it's not that you need an AST and multiples passes just to generate good code, but that in some cases it gets increasingly impractical or impossible to compile them at all without much more machinery than Pascal or Oberon needs.

No. OCaml for example has a really fast compiler (like Go), but I would not call it simple. It does have PPX (PreProcessor Extensions) which are like macros, so you can't "blame" the lack of them either.

And everything that uses LLVM is _always_ going to be _slow_, no matter the language.

If Rust had an interpreter in the box algonside the compilers like OCaml (there are multiple ones as well), it would already make a big different in development workflows.

Source: hearsay.

That's basically the story of every single software project ever made.

1. No variable names etc. with a length of more than 8

2. The order of functions matter now; don’t forward-reference anything

3. You can only nest scopes 16 times, max

Would this make the language simpler for me in a way that I would care about?

Generally though, I'm disappointed if hello, world takes more than 20ms to compile -- which is of course true of pretty much every popular language.

Simple for programmer to understand and use (small, orthogonal, consistent) isn't always going to be the same as simple for the compiler writer to implement.

This assumption comes up again and again, but the evidence is rather poor. There are very few and only marginal similarities. The most obvious is the receiver syntax of the bound procedures. But this can be found in Mössenböck's Oberon-2, not in Wirth's Oberon. Although Wirth was a co-author, he ignored any innovations in Oberon-2 in his subsequent work. Go has a completely different focus and is essentially a further development of Newsqueak; it's definitely not a "direct descentant" of Modula or Oberon.

Writing binary directly is simple because the compilation time is zero.

From a compiler's perspective, sure. Not being a compiler, I find that metric not very relevant.

Simplicity of a language is better gauged by how easy it is to express complex things in it, and how difficult it is for one person to comprehend what another wrote.

I'm afraid you're just showing a bit if survivorship bias. I can assure you that compilation speed is a critical trait of any programming language, and the only people who don't understand this are those who benefit from all the work invested by predecessors who did.

Think about it for a moment: how would your turnaround speed be if every single time you had to build your project to test a change you had to brace yourself to wait over one hour to get things to work? After a week of enduring that workflow, how much would you be willing to pay to drive down that build time to 10 minutes, and how much more would you fork to only require 1 minute to pull off an end-to-end build?

If your daily task build is taking over an hour on modern hardware, it's likely you have organizational problems masquerading as tech debt. No language choice will prevent that; good technical leadership can help mitigate it.

Using C++23 standard library, alongside modules, and cargo/vcpkg binary caches for 3rd party libs is quite fast.

Rust well, until cargo does offer the option to use binary libraries, it will always lag behind in what C++ tooling is capable of. Maybe if scache becomes part of it.

I don't think your assertion makes sense. The only thing that conan/vcpkg brings to C++ is precompiled dependencies which you don't have to build yourself. You get the same result if you build those libs yourself, packaged them in a zip file somewhere, and unpacked that zip file in your project tree whenever you had to bootstrap a build environment. The problems that conan/vcpkg solve are not build times or even C++, they are tied to the way you chose to structure your project.

With C++, you get a far greater speedup if you onboard a compiler cache tool like ccache and organize your project around modules that don't needlessly cause others to recompile whever the are touched.

Change was measured in years, compute and storage options were limited. I wonder how many of his OSes / programming languages spanned multiple heterogeneous compute architectures.

Don't get me wrong, love the guy...but wonder what kind of impact he would have if in his prime today...