[lukego]

Besides all his innumerable accomplishments he was also a hero to Joe Armstrong and a big influence on his brand of simplicity.

Joe would often quote Wirth as saying that yes, overlapping windows might be better than tiled ones, but not better enough to justify their cost in implementation complexity.

RIP. He is also a hero for me for his 80th birthday symposium at ETH where he showed off his new port of Oberon to a homebrew CPU running on a random FPGA dev board with USB peropherals. My ambition is to be that kind of 80 year old one day, too.

[cscheid]

> not _better enough_

Wirth was such a legend on this particular aspect. His stance on compiler optimizations is another example: only add optimization passes if they improve the compiler's self-compilation time.

Oberon also, (and also deliberately) only supported cooperative multitasking.

[superluserdo]

>His stance on compiler optimizations is another example: only add optimization passes if they improve the compiler's self-compilation time.

What an elegant metric! Condensing a multivariate optimisation between compiler execution speed and compiler codebase complexity into a single self-contained meta-metric is (aptly) pleasingly simple.

I'd be interested to know how the self-build times of other compilers have changed by release (obviously pretty safe to say, generally increasing).

[frognumber]

Supported cooperative multitasking won in the end.

It just renamed itself to asynchronous programing. That's quite literally what an 'await' is.

[spongebobism]

That's fascinating. I'd imagine there are actually two equilibria/stable states possible under this rule: a small codebase with only the most effective optimization passes, or a large codebase that incorporates pretty much any optimization pass.

A marginally useful optimization pass would not pull its weight when added to the first code base, but could in the second code base because it would optimize the run time spent on all the other marginal optimizations.

Though the compiler would start out closer to the small equilibrium in its initial version, and there might not be a way to incrementally move towards the large equilibrium from there under Wirth's rule.

[steveklabnik]

Do you happen to remember where he said that? I've been looking for a citation and can't find one.

I think that some of the text in "16.1. General considerations" of "Compiler Construction" are sorta close, but does not say this explicitly.

[kristianp]

In the past, this policy of Wirth's has been cited when talking about go compiler development.

Go team member, Robert Griesemer, did his Phd under Mössenböck and Wirth.

[pjmlp]

Note that Oberon descendents like Active Oberon and Zonnon, do have premptive multitasking.

[gjvc]

> ... his 80th birthday symposium at ETH where he showed off his new port of Oberon to a homebrew CPU running on a random FPGA dev board with USB peripherals.

This was a fantastic talk. https://www.youtube.com/watch?v=EXY78gPMvl0

[lynguist]

Thank you for sharing. I was there and didn’t expect to see this again. :)

He had the crowd laughing and cheering, and the audience questions in the end were absolutely excellent.

[microtherion]

According to his daughter (she runs a grocery store, and my wife occasionally talks to her), he kept on tinkering at home well past 80.

[vram22]

A Wirthwhile ambition. :)

Sorry, couldn't resist.

I first wrote it as "worthwhile", but then the pun practically fell out of the screen at me.

I love Wirth's work, and not just his languages. Also his stuff like algorithms + data = programs, and stepwise refinement. Like many others here, Pascal was one of my early languages, and I still love it, in the form of Delphi and Free Pascal.

RIP, guruji.

Edited to say guruji instead of guru, because the ji suffix is an honorific in Hindi, although guru is already respectful.

[kragen]

i hope you are! we miss you